Zeo delivery method

Global Site & URL Architecture

One route grammar per market-language purpose, tested against the platform's real edge cases, with an owner, a fallback, and a way back on every route.

Choosing a domain, subdomain, or folder structure for each market affects publishing control, crawlability, analytics boundaries, and how safely you can launch the next locale, and it's expensive to unwind once content and links depend on it. We inspect the URL estate you actually have, compare the models that would genuinely work against your platform's constraints, and give every route an owner, a fallback, and a tested way back. We define a maintainable URL model for markets and languages, test it against real platform constraints and edge cases, and give every route a clear owner, fallback, and migration path.

Discuss URL architecture with ZeoInternational SEO
Specialists arrange market and language route signs across a large site map while a second specialist checks paths between domains, folders, and locale selectors.

Some of the 500+ brands we've worked with

See all references
  • Mini
  • Yeditepe Üniversitesi
  • Memorial
  • Albaraka Türk
  • Exquise
  • Akşam
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • GE
  • 3M
  • Domino’s
  • Lexus
  • Trendyol
  • Hepsiburada

Stages and gates

How we do it

We assess each option against the market plan, existing URL estate, and deployment controls, then test difficult cases before rollout.

  1. Define the market and language requirements

    We separate language requirements from differences in regional offers, law, brand, ownership, and reporting. Every planned locale gets a purpose, business owner, release horizon, and clear reason to exist. The business owner confirms each locale's purpose, release horizon, and reason to exist before the team discusses URL patterns.

    A market-language requirements map that keeps the team from choosing a URL pattern before it understands the business need.

  2. Inspect the current URL estate

    We map hosts, paths, locale parameters, selectors, canonicals, redirects, sitemaps, analytics boundaries, and observed user and bot behavior. Valuable legacy URLs and existing inconsistencies remain visible throughout the decision. Before the audit closes, the technical owner confirms which reported collisions are genuine routing defects and which are intentional legacy exceptions.

    A reproducible current-state audit that identifies route ownership, collisions, continuity requirements, and platform-specific constraints.

  3. Compare the workable models

    We assess domains, subdomains, and subdirectories against deployment control, authority continuity, legal separation, analytics, cookie behavior, maintenance cost, migration effort, and future expansion. If an option fails a required constraint, we remove it rather than quietly lowering its score. The technical and legal owners confirm which constraints are genuinely non-negotiable for the organization before a model is eliminated.

    An architecture matrix that records assumptions, trade-offs, exceptions, and why one model suits the current organization better than the alternatives.

  4. Specify routing and test edge cases

    We define default locale, user selection, crawlable paths, canonical ownership, redirects, fallbacks, error behavior, unsupported locales, shared content, cookies, and bot handling. Representative cases are tested in rendered output. The engineering owner confirms the rendered test evidence actually matches the specified behavior before the routing rules ship.

    A URL and routing specification backed by tests for normal journeys, clean sessions, bots, failures, and rollback.

AI compiles, crawls, and generates the test matrix; owners decide what the business can actually support.

AI compiles a first pass of planned locales from market and product documents, crawls and cross-references thousands of existing hosts, paths, and redirect chains to identify collisions and orphaned locale routes, evaluates each candidate model against the documented constraints and shows the elimination logic instead of asserting a preferred answer, and generates the edge-case test matrix from the routing specification. The architecture call stays with named owners. We do not create crawler-only locale behavior or hidden routes users cannot reach and choose, we do not use forced geolocation to remove user choice, and we do not add market URLs for offers, languages, or operations the organization cannot support and maintain.

Deliverables and acceptance

What you get

Engineers get a route model they can implement. Market teams can extend it later without dragging the old inconsistencies back in.

  • Decision matrix

    Architecture option matrix

  • Architecture map

    Recommended URL and routing specification

  • Redirect map

    Market rollout and continuity map

  • Policy document

    URL exception and ownership record

We call it done when: The option matrix, URL specification, rollout map, and exception record are done when every viable model has been compared against the same requirements with assumptions and rejected options explicit, the public paths, defaults, selectors, canonicals, redirects, fallbacks, errors, bot behavior, analytics boundaries, and future-route grammar form one testable rule set, every existing and future URL connects to a launch group with acceptance evidence, an owner, and a rollback condition, and every departure from the shared rules names its routes, reason, approver, review condition, and retirement plan.

Fit and readiness

When you need this

Market plans and platform constraints have to turn into public routing rules eventually. The test is whether your teams can still maintain them a year after launch.

A good fit when

  • You are adding markets or languages and need to compare country domains, subdomains, and subdirectories without assuming that one pattern is right for every organization.
  • Existing hosts, locale folders, parameters, selectors, canonicals, or redirects have developed inconsistently, and route ownership is unclear.
  • A replatform or international migration needs to preserve valuable URLs, user choice, search discovery, analytics, and a practical way to roll back.

Better handled as other work when

  • The organization has not decided which markets, languages, offers, legal differences, or owners it can support and only wants a preferred URL format.
  • The current hosts and routing behavior cannot be inspected, or no technical team is available to test and implement the chosen model.

If one of these is closer to your situation, start here instead: International SEO

We call it done when: Every supported market-language purpose has one public route, an owner, default and fallback rules, a user-visible selection path, a canonical and redirect position, acceptance tests, and a rollback condition. Future markets can use the same route grammar without reopening the entire architecture decision.

The specialists behind this SEO work

Zeo's SEO work goes back to 2006, when we started what we call the first SEO blog in the MENA region. The consultants shown here are doing that work today, matched to what this page covers.

Content we've produced on this topic

Articleby Samet ÖzsüleymanInternational SEO Strategy Recommendations for Leading the Asian Market

Tools we use

Tools behind this work

  • Screaming Frog

    maps hosts, locale paths, redirects, canonicals, and selector links

  • Sitebulb

    turns route inconsistencies into testable architecture exceptions

  • Oncrawl

    compares proposed route rules with observed crawler behavior

  • WebPageTest

    tests locale routing behavior from clean sessions and locations

  • Google Analytics

    documents locale selection, cross-domain sessions, and reporting boundaries

  • Google Search Console

    records search continuity requirements for valuable international URLs

Next step

Plan a global URL model your teams can maintain

Show us the market roadmap, the hosts, the platform constraints, and the migration risks you are worried about. We will map the first decisions and what it takes to test them.
Discuss URL architecture with Zeo

Before we start

Questions we hear

Are country domains always the best choice for international SEO?

No. Domains, subdomains, and subdirectories have different implications for market separation, authority continuity, deployment control, analytics, migration effort, and maintenance. We compare those trade-offs with your actual markets and platform.

Can we change the URL model without a migration plan?

Not safely when existing URLs carry search visibility, links, analytics history, bookmarks, or dependencies. The architecture needs an inventory, redirect and canonical actions, acceptance evidence, owners, observation points, and a tested restoration path.

Can we mix models (for example, ccTLDs for our two biggest markets and subdirectories for the rest)?

Yes, when the reasons are documented and the mixed pattern still resolves to one specification engineers can maintain. An undocumented mix of models is what usually causes the collisions this method is built to catch.

Why doesn't a country-code domain always win the comparison?

A ccTLD can only target a single country and needs its own domain, deployment, and maintenance per market (a real advantage for some organizations, but a maintenance and authority-fragmentation cost a smaller team may not sustain across many markets).