Completions

For multi-location marketing + SEO leadership

URL hierarchy authoring for multi-location site migrations

Author the URL taxonomy — do not inherit it. Per-location templates, per-vertical patterns, collision detection, link-equity preservation, and a per-location canary that keeps ranking trajectory intact through the migration.

By Jay Christopher10 min read

What this gets you

  • Per-location URL hierarchy templates — corporate template + per-location override + per-vertical pattern.
  • Canonical-URL pattern library — service pages, location pages, blog posts, and product pages each get the right canonical shape.
  • URL collision detection before publish — conflicts surface during authoring, not in 404 logs after rollout.
  • Link-equity preservation — redirect-chain compression, canonical-tag coordination, and new-URL authoring move together as one workflow.
  • Per-location migration canary — 1-2 locations migrate first; the rest follow on green canary. Blast radius stays contained.

Three agencies, fifty locations, four different URL patterns

Multi-location site migrations create URL drift. The corporate template says /locations/{city}/{service} but Location X has /{city}/{service}/{subservice}/ from a prior agency, and Location Y has /{service}-in-{city} from a different agency, and Location Z is on a templated platform that produced URLs with category IDs in the path because nobody told it not to.

The migration team picks one template and ships. Thirty percent of location pages 301-redirect to the new structure. Twenty percent of incoming link equity is lost to bad redirect chains. Fifty location URLs collide with corporate URLs because no one ran a collision check. The migration is technically live; ranking is six weeks into a recovery sprint.

URL hierarchy authoring moves URL taxonomy off agency-soup and onto an explicit authoring pipeline. Per-location templates inherit corporate defaults but allow per-vertical overrides — restaurant location URLs differ from retail location URLs in structurally meaningful ways. URL collision detection runs against the full site before migration ships. Link-equity preservation coordinates redirect-chain compression, canonical-tag management, and the new URL authoring as one workflow. Per-location migration canary tests 1-2 locations first; the rest follow only after the canary stays green for two-to-four weeks.

For a 50-location operator migrating from agency-soup to canonical URL hierarchy, this is the difference between a Q4 ranking-recovery sprint and a clean migration that preserves equity.

What is in market — and what each category leaves to you

The crawler and audit side of this problem is mature. The authoring and governance side is operator-side wiring.

Desktop crawlers — Screaming Frog, Sitebulb

Excellent on a one-shot diagnostic run before or after migration. They do not author URLs, do not maintain a template library, and do not coordinate the per-location canary rollout.

Enterprise crawlers — OnCrawl, DeepCrawl / Lumar, Botify

Stronger at scale and at log-file integration. Same boundary — they surface drift and broken structure; they do not generate the right URLs in the first place.

Continuous monitoring — ContentKing

Continuous URL change detection and alerting. Useful for governance after the migration. Does not author the template library or run the pre-publish collision check.

CMS templating — the per-location page CMS

The CMS produces URLs according to its template configuration. Most multi-location CMS deployments use the default URL pattern, which becomes the corporate template by accident. There is rarely an explicit per-vertical override or a collision check.

The migration agency

Picks one template and ships. Sometimes runs a redirect audit. Rarely runs a pre-publish collision check across the full URL set, and almost never proposes a per-location canary because the project plan assumes one cutover weekend.

The authoring pipeline

URL hierarchy authoring is a defined set of components, not a single tool. Each one is independently replaceable and auditable.

  1. URL template library. A corporate template plus per-vertical patterns — restaurant, retail, service, healthcare, regulated. Each pattern is named, versioned, and tied to the page types it covers.
  2. Per-location override workflow. Corporate template is the default; per-location augmentation is allowed through a reviewable workflow. Drift gets caught at authoring time, not in production.
  3. Canonical-URL pattern library. Service pages, location pages, blog posts, category pages, and product pages each have a defined canonical shape. The canonical tag generator reads from the same library that produces the URL.
  4. URL collision detection. A full-site collision check runs before migration ships. Duplicate slugs, corporate-vs-location conflicts, blog-vs-category conflicts, and per-jurisdiction collisions surface during authoring.
  5. Link-equity preservation. Redirect-chain compression (collapse 2+ hops to 1), canonical-tag management, and new-URL authoring move together. The link graph stays consistent across the migration.
  6. URL slug generation. Buyer-language slugs, not internal-system codes. Slugs read like the query a buyer would type, not like a database join.
  7. Per-location migration canary. One or two locations migrate first. The rest hold until the canary stays green on crawl, ranking, conversion, and redirect health for two-to-four weeks.
  8. Redirect-chain optimization. Every 2+ hop chain collapses to a single hop. Inbound link equity lands on the new URL with one redirect, not three.
  9. URL audit gate at publish. Migration blocks if drift, collision, or canonical conflict is detected. The gate is enforcement, not advisory.
  10. Per-vertical URL governance. Corporate template plus vertical rules plus an escalation workflow for exceptions. Compliance overlays for regulated verticals (healthcare, financial, cannabis) sit on top.
  11. Operator dashboard. Hierarchy depth distribution, collision count, canonical conflicts, canary status, and migration-readiness in one view.
  12. Staged rollout. Per-cohort canary, not a single cutover weekend. Bulk migration is the anti-pattern that produces the six-week recovery sprint.

Frequently asked

What is URL taxonomy?

URL taxonomy is the structural pattern your URLs follow across the site — how location pages, service pages, blog posts, and product pages each get a canonical shape. At a multi-location operator, the taxonomy has to handle corporate-template URLs, per-location overrides, per-vertical variants, and per-jurisdiction compliance overlays without collisions.

Why does URL taxonomy drift during a multi-location site migration?

Most multi-location sites have been touched by three or four agencies over the years. Each agency shipped its own URL pattern — /locations/city/service, /city-service, /service-in-city, /our-locations/city. By the time a replatform starts, the production URL set is agency-soup. The migration team picks one template and ships, but 30% of pages 301-redirect to the new structure, 20% of incoming link equity is lost to bad redirect chains, and dozens of URLs collide silently.

How does this differ from Screaming Frog, Sitebulb, OnCrawl, DeepCrawl/Lumar, Botify, or ContentKing?

Those tools audit URLs that already exist. They are excellent on the diagnostic side. URL hierarchy authoring is the authoring side — the template library, the per-location override workflow, the collision check that runs before migration ships, the canonical-tag coordination, and the per-location canary that lets you roll out staged migrations instead of cutting over the whole site at once.

What is link-equity preservation in a URL migration?

When URLs change, every inbound link from off-site (and every internal link from on-site) has to land on a one-hop redirect, not a chain. Equity preservation coordinates redirect-chain compression, canonical-tag management, and the new URL authoring so the link graph stays consistent across the migration. The goal is to keep ranking trajectory uninterrupted — not recover it six weeks later.

What is a per-location canary migration?

Migrate one or two locations to the new URL hierarchy first. Watch crawl, ranking, conversion, and redirect health for two to four weeks. If the canary stays green, roll out the rest in cohorts. If anything degrades, you contained the blast radius to two locations instead of fifty.

How many URL collisions are typical mid-migration?

At a 50-location operator with mixed agency history, a pre-migration collision check usually surfaces 40-80 conflicts — duplicate slugs across locations, corporate pages colliding with location pages, blog URLs that match category URLs. Surfaced before migration, each one is a 30-second fix. Surfaced after migration, each one is a 404 burning equity.

Hire the agent that authors the hierarchy

The internal-link-orchestration agent owns URL taxonomy authoring, canonical pattern enforcement, redirect-chain compression, and per-location canary coordination. It runs the pipeline that keeps your migration from burning equity.

Hire the link-graph agent

We scope on the call and send a private checkout link after.

Related reading: Multi-location SEO architecture · Multi-location reporting