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 affects publishing control, market switching, crawlability, analytics boundaries, and how safely you can launch another locale.

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

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.

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

    AI assist
    AI compiles a first pass of planned locales from market and product documents, grouping them by language differences and regional-offer differences.
    Human gate
    The business owner confirms each locale's purpose, release horizon, and reason to exist before the team discusses URL patterns. Locale purpose and ownership must be confirmed before any URL choice.

  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.

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

    AI assist
    AI crawls and cross-references thousands of existing hosts, paths, and redirect chains to identify collisions and orphaned locale routes.
    Human gate
    Before the audit closes, the technical owner confirms which reported collisions are genuine routing defects and which are intentional legacy exceptions. The estate audit must be approved before models are compared.

  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.

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

    AI assist
    AI evaluates each candidate model against the documented constraints and shows the elimination logic instead of simply asserting a preferred answer.
    Human gate
    The technical and legal owners confirm which constraints are genuinely non-negotiable for the organization before a model is eliminated. A model is eliminated only when it fails a real constraint.

  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.

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

    AI assist
    AI generates the edge-case test matrix, clean session, returning cookie, unsupported locale, bot request, redirect loop, from the routing specification.
    Human gate
    The engineering owner confirms the rendered test evidence actually matches the specified behavior before the routing rules ship. Routing ships only after rendered tests pass cleanly.

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

    Accepted when

    Each viable model is compared against the same market, platform, legal, control, continuity, cost, and expansion requirements. Assumptions and rejected options stay explicit.

  • Architecture map

    Recommended URL and routing specification

    Accepted when

    Public paths, defaults, selectors, canonicals, redirects, fallbacks, errors, bot behavior, analytics boundaries, and future-route grammar form a single testable rule set.

  • Redirect map

    Market rollout and continuity map

    Accepted when

    Existing and future URLs connect to launch groups, dependencies, redirect actions, acceptance evidence, owners, observation points, and rollback conditions.

  • Policy document

    URL exception and ownership record

    Accepted when

    Every departure from the shared rules names the affected routes, reason, approver, review condition, and retirement plan. A recurring exception triggers a rule review.

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).