One website or many? Choosing the right structure for multiple brands, locations and markets

As organisations grow, the website estate often grows around them.

A new brand receives a separate site. Locations create local pages. International teams launch country versions. An acquisition brings another CMS. Ecommerce sits somewhere else again. Each decision can make sense at the time.

Eventually the organisation asks whether it should consolidate everything into one website or preserve distinct experiences.

Neither answer is automatically more efficient or better for search.

One website can concentrate content, authority, analytics and governance. It can also flatten meaningful brand or market differences into a confusing compromise. Separate sites can create focus and autonomy. They can also duplicate content, technology, maintenance and campaign effort.

Share what genuinely benefits from being shared. Separate what users, brands, markets or operating responsibilities require to be distinct.

The short answer: five credible patterns

Pattern	Strong fit when	Principal risk
One consolidated site	Audiences, proposition, content and governance are substantially shared	A broad hierarchy becomes difficult to understand or own
One domain with structured sections	Brands or markets need distinct content within a coherent parent relationship	Sections become inconsistent or compete without central rules
Separate sites on a shared multisite core	Experiences need separate domains or identities while technology and administration benefit from reuse	One shared release or component decision affects several sites
Separate independent sites	Brands, users, operations, risk or markets are genuinely autonomous	Duplication, fragmented data and uneven standards grow
Hybrid portfolio	Some capabilities should be central while others need separation	The boundary becomes unclear and creates duplicated ownership

The right pattern follows the portfolio requirement.

The public URL, CMS, codebase and infrastructure are different layers. For example, four branded domains may run on one shared application, while one domain may contain several independently managed market areas.

Begin with portfolio purpose

Map every brand, location, market and digital service.

For each, record:

• Business owner
• Priority audiences and tasks
• Brand relationship
• Products, services and pricing
• Content and language
• Transactions and customer accounts
• Systems and data
• Legal or regulatory differences
• Marketing and search demand
• Internal publishing team
• Planned change

Then identify what users need to understand. Do they see one parent organisation, a house of brands, endorsed brands or independent businesses? Can they move meaningfully between offerings? Is the relationship commercially useful or likely to confuse?

The brand architecture and website architecture should inform one another, but they are not identical. A portfolio may need distinct brand experiences without completely independent technology.

Factor 1: audience and journey overlap

One website is often strongest when the same people move across related services and benefit from a unified account, search or navigation.

Separation becomes more credible when:

• Audiences have little meaningful overlap
• Tasks and terminology are materially different
• A shared navigation would be dominated by internal structure
• Each site needs a focused conversion journey
• Access, permissions or service availability differ

Do not assume that internal divisions deserve equal prominence to users. Customers rarely think in an organisation chart.

Test representative journeys. If a user seeking one service must first choose among corporate entities they do not recognise, consolidation may have created an internal hub rather than a useful experience.

Factor 2: brand relationship and proposition

A masterbrand can often support one coherent website. A house of independent brands may require separate sites. Endorsed brands and sub-brands sit between those positions.

Ask:

• Is the parent brand visible and valuable?
• Does each brand have a distinct promise, audience and voice?
• Are products complementary or competing?
• Would shared design strengthen recognition or dilute identity?
• Will brands be added, sold or retired?
• Who owns the decision when brand interests conflict?

Shared components can still allow different colour, typography, imagery and content. Independent sites can still use common governance and technical standards.

The decision is not "same design or different design". It is which parts of the experience and operating system should be common.

Factor 3: content, search and duplication

Consolidation can reduce duplicated corporate information, policies, careers content and resources. It can also concentrate internal linking and make related expertise easier to discover.

However, merging sites does not automatically transfer all search performance. The project must understand:

• Current ranking URLs and queries
• Backlinks and referral relationships
• Local and market-specific content
• Duplicate and near-duplicate pages
• Internal linking
• Domain history
• Redirect mapping
• Search demand by brand and location

Google’s site-move guidance recommends mapping old URLs to new destinations, using server-side permanent redirects and monitoring the move. A mass redirect to the parent homepage discards relevance and harms users.

Separate sites can be justified when each has distinct, useful content and demand. They become weak when they repeat the same service copy with only a location or logo changed.

Factor 4: locations

Multi-location does not automatically mean multisite.

A single structured location model can often support:

• Unique location pages
• Opening hours and services
• Local teams
• Contact and booking actions
• Map data
• Local proof and content
• Location search and filters

Separate sites may be appropriate for autonomous franchises, legal entities or locations with materially different offerings and operations. The decision should reflect content ownership, customer expectation and governance, not a desire to rank by creating many thin domains.

Primary Dental’s public case study, for example, describes one parent website serving more than 60 dental practices, with a page for each practice and a location finder. That is one valid multi-location pattern, not a universal rule.

Factor 5: markets and languages

International architecture needs to distinguish language from region.

A multilingual website offers content in more than one language. A multi-regional website targets users in different countries or regions. Some organisations need both.

Google’s guidance for multi-regional and multilingual sites recommends different URLs for language versions rather than changing the page only through cookies or browser settings. Its localised-page guidance describes `hreflang` methods for signalling equivalent language or regional versions.

Architecture also needs to handle:

• Translation and review workflow
• Market-specific products and prices
• Legal, privacy and accessibility obligations
• Local contact and fulfilment
• Regional campaigns and analytics
• Content fallback
• Ownership of shared and local content

Flags are not a reliable language selector, and automatic redirection based only on detected location can prevent users and crawlers from reaching the version they need.

Factor 6: commerce and customer identity

Commerce can be the strongest argument for sharing or separation.

Consider:

• Can customers purchase across brands?
• Is there one cart, checkout and account?
• Are price, tax, currency, inventory and fulfilment shared?
• Do membership or trade rules differ?
• Which system owns product and customer data?
• Can consent and preference move across brands?
• What should happen when one brand is unavailable in a market?

A single commerce core can improve stock and account consistency. It can also create complex rules and release coupling. Independent commerce can protect autonomy but duplicate product, customer and integration capability.

Document the operating model before choosing a platform pattern.

Factor 7: systems and data

Map the sources of truth for products, inventory, customers, locations, content, pricing and identity.

One shared CMS does not automatically create one data model. Several sites may still exchange data with different CRM, ERP or PIM systems. Conversely, independent frontends may consume one central source.

For each exchange, define direction, frequency, mapping, failure handling, monitoring and owner. Architecture that looks elegant on a diagram can be operationally fragile if data boundaries are unclear.

Factor 8: governance and capability

The structure must match how the organisation can make decisions.

Centralised models need authority to set standards, prioritise shared components and coordinate releases. Local models need clear boundaries and the capability to publish, maintain and measure each site.

Decide:

• Who owns the portfolio?
• Which design and content standards are mandatory?
• Who approves shared versus local change?
• How are security updates and releases coordinated?
• Who pays for common capability?
• How are exceptions evaluated?
• What happens when a brand leaves the portfolio?

A shared platform without shared governance can become a queue of competing priorities. Independent sites without central standards can drift in security, accessibility, content and measurement.

Share by evidence, not by organisational habit.

Five patterns in more detail

One consolidated site

Use one domain, experience and operating model. This can suit a masterbrand, related services and central team. Structure sections and content types so users can move without learning the organisation chart.

One domain with structured sections

Brands, locations or markets receive distinct areas under one domain. This can preserve a coherent parent relationship while allowing tailored content. Governance must prevent sections from becoming inconsistent mini-sites.

Separate sites on a shared core

Distinct domains or experiences share code, components, CMS or services. This can reduce duplication and support central releases while retaining brand distinction. Test blast radius: one faulty shared release may affect several sites.

Separate independent sites

Each site has its own platform and operation. This is credible for genuinely autonomous entities, materially different risk or incompatible requirements. The portfolio still needs minimum standards for domains, access, security, privacy, accessibility, analytics and transition.

Hybrid portfolio

A corporate hub, shared service or commerce capability can coexist with separate brand or regional experiences. A hybrid model often reflects reality, but the boundary must be deliberate. Duplicate content and journeys should have named owners.

Model both duplication and coupling

Architecture creates cost in two directions. Separating sites can duplicate platforms, content, integrations, analytics, testing and governance. Sharing too much can couple teams and brands that need to move independently.

Create a portfolio model that lists each capability and asks four questions:

1. How often does this capability change?
2. Must every site change together?
3. Who funds, approves and supports the shared version?
4. What is the consequence if it fails or no longer fits one part of the portfolio?

Shared navigation, design components, product data, customer identity or checkout can deliver substantial consistency. They can also create a wide release blast radius. If one shared component must satisfy incompatible brand or market rules, exception handling can become more costly than a controlled separation.

Duplicated capability deserves the same scrutiny. Four independent consent configurations, analytics implementations or location databases may drift in ways that are expensive to detect. Count not only build effort, but also recurring updates, assurance, training, incident response and provider management. A cheap additional site can create a permanent operating obligation.

The useful comparison is therefore total portfolio behaviour, not the licence count or the number of domains. Model an expected year of real change: a campaign release, regulatory update, new product, staff transition, integration upgrade and brand-specific exception. Ask which architecture allows the organisation to make those changes safely with its actual team.

Plan the transition as carefully as the destination

Moving from an existing estate to a new architecture can be more consequential than selecting the end state. Inventory domains, URLs, content, media, data, integrations, analytics history, user accounts, subscriptions and legal records before deciding that assets can be merged or retired.

Choose whether the change will occur in one coordinated release or in stages. A phased transition can reduce operational risk, but it may require temporary synchronisation, duplicate governance and clear customer communication. A single release can simplify the final state, but concentrates migration, testing and launch dependencies.

For each existing site, assign a treatment: retain, migrate, consolidate, redirect, archive or retire. Define where its audiences and priority journeys will go. Preserve useful search signals with direct URL mapping and appropriate permanent redirects rather than sending every old page to a generic destination. Where languages or regions remain, use distinct crawlable URLs and explicit localisation signals.

Also define the exit path for shared services. If a brand is sold, a region closes or a partner relationship changes, can its content, data, domain and required components be separated responsibly? Architecture that only works while the organisational chart remains unchanged may be efficient in the short term and restrictive later.

Public Emote examples: the same pattern can solve different problems

The public Brown Brothers case study describes four brand sites running from one shared core and one CMS. The architecture supported distinct brand character, central stock management and cross-brand purchasing.

The public Natrio case study describes four sites across English, Spanish and Portuguese, with international location content and a brand that had evolved through a long Emote relationship.

Both use a multisite idea, but their requirements differ. Brown Brothers centred brand commerce and shared inventory. Natrio centred international reach, languages and global capability. The platform pattern followed the portfolio job.

The same broad pattern can serve different operating requirements.

A practical portfolio decision process

1. Inventory every domain, site, brand, market and owner.
2. Map audiences, tasks, offers and relationships.
3. Identify content and capability that is truly shared.
4. Document local variation and legal requirements.
5. Map systems, data and customer identity.
6. Review current search value and migration risk.
7. Compare the five architecture patterns.
8. Model governance, release and lifecycle cost.
9. Test difficult journeys and exit scenarios.
10. Select the smallest architecture that supports real distinction without unnecessary duplication.

Where the portfolio, systems and governance are complex or contested, Focused or Full Website Discovery can resolve the consequential questions before implementation. A controlled portfolio can proceed through a strong brief and focused validation.

Name one portfolio owner

Shared standards fail when every brand or market can create exceptions without an accountable owner. Assign decision rights for domains, templates, shared components, analytics, accessibility, security and lifecycle retirement.

Related Emote guidance: How to choose the right CMS, SEO migration checklist and Website integration decisions before development.

Frequently asked questions

Is one website always better for SEO?

No. One site can consolidate signals and reduce duplication, but useful distinct sites can perform well. Content quality, relevance, technical implementation, authority and migration execution matter.

Is WordPress Multisite the same as having multiple websites?

It is one technical way to manage a network of sites. Multiple websites can also use independent installations or other shared architectures. Choose the portfolio model before the product feature.

Should every business location have its own domain?

Usually not by default. Structured location pages on one site can support many organisations. Separate domains need a clear user, operational or legal reason and sufficient distinct content and ownership.

Can different brands share one CMS but look different?

Yes. A shared content and component foundation can support brand variations. The required degree of independence, governance and release control should be defined.

Should each language have a separate URL?

Google recommends distinct URLs for language versions and provides guidance on `hreflang`. The exact domain, subdomain or subfolder model should also consider governance, market needs and platform capability.

Does a portfolio architecture require Focused or Full Website Discovery?

Not always. It becomes appropriate when material questions about audiences, brand relationships, systems, data, search migration or governance cannot be resolved through a controlled brief.

How Emote can help

The best website estate is not the one with the fewest domains or the most advanced multisite technology. It is the one users can understand and the organisation can govern.

Consolidate where shared experience and capability create value. Separate where genuine distinction requires it. Use shared foundations where they reduce duplication without creating unacceptable coupling.

If you are deciding whether to consolidate, separate or rebuild a website portfolio, book an initial meeting with Emote. We will clarify the portfolio, known requirements and material unknowns, then recommend the appropriate next step. Detailed architecture, migration and governance planning form part of an agreed engagement.