There is a particular kind of regret that arrives just after a “clean up” deploy: the new addresses look beautiful, but old links from search results, bookmarks, newsletters, and documentation now fall into 404 pages. The formatting was improved; the route people already trusted was erased.

A URL is an identifier before it is an SEO accessory. Make new ones readable and durable. Change an existing one only for a defensible reason, and treat that change as a migration of accumulated references—not a text-editing exercise.

First ask whether the URL is actually broken

  • Worth repairing: accidental spaces or encoding problems, inconsistent host/protocol variants, unsafe characters, exposed session IDs, a temporary CMS pattern that cannot remain stable, or routes that routinely confuse users.

  • Usually leave alone: an indexed URL that is merely longer than you would choose today, contains a harmless numeric ID, or lacks an exact-match keyword.

  • Investigate before acting: query parameters used for filtering, pagination, locale, tracking, faceting, or application state. Parameters are valid URL components; deleting all of them can collapse distinct resources or break the application.

  • Never promise a ranking jump: readable paths help people understand and share an address, but a slug rewrite is not a guaranteed ranking improvement. Migration risk can outweigh a cosmetic gain.

Write addresses for humans, parsers, and time

  • Use meaningful words that describe the resource, without repeating a keyword or mirroring the entire title.

  • Prefer lowercase paths by convention. URL paths may be case-sensitive depending on the server, so /Docs and /docs must not accidentally serve competing copies.

  • Use hyphens between words. Google explicitly recommends hyphens rather than underscores as word separators in URLs.

  • Use UTF-8 when non-ASCII characters are genuinely appropriate, and ensure links are correctly percent-encoded. Do not hand-edit % escape sequences or decode reserved delimiters into different semantics.

  • Keep identifiers stable when a headline, year, product label, team, or navigation hierarchy changes. Avoid dates unless date identity is intrinsic to the resource.

  • Choose one consistent trailing-slash policy. Search engines can handle either form, but your server, canonical, sitemap, and internal links should agree.

  • Do not place fragments such as #setup in a server redirect source: the fragment is handled by the user agent and is not sent in the HTTP request.

Query strings need rules, not a purge

A parameter can select real content, change sort order, carry campaign attribution, or create an effectively unlimited crawl space. Those cases demand different decisions. Document each parameter by whether it changes the primary resource, presentation only, tracking only, or session state.

  • Keep functional parameters when the application contract requires them; make crawlable combinations intentional.

  • Strip or ignore known tracking parameters when generating canonical URLs, but preserve them through a redirect when downstream analytics still needs them.

  • Never put session IDs, secrets, reset tokens, or personal information in indexable URLs. URLs leak through logs, history, analytics, screenshots, and referrers.

  • For faceted navigation, decide which useful combinations deserve indexable pages. Control links and canonicalization deliberately instead of assuming robots.txt will consolidate duplicates.

  • Use stable parameter order in generated links to avoid needless variants, while remembering that a server may assign semantics to repeated keys or ordering.

Canonical and redirect solve different problems

  • A permanent HTTP redirect sends users and crawlers to the replacement address. Use it when the old resource has truly moved.

  • A rel="canonical" link is a strong hint about the preferred representative among duplicate or near-duplicate pages; it does not forward a visitor.

  • Google recommends redirects and canonical annotations as strong signals, while sitemap inclusion is weaker. Aligning these signals is clearer than making them contradict one another.

  • A canonical should be an absolute, indexable destination that returns success. Do not canonicalize to a redirect, error, blocked page, or materially different content.

  • For content negotiation or legitimate variants, a blanket redirect may be wrong. Preserve each necessary resource and use the appropriate alternate/canonical relationship.

document-head.htmlhtml
<link rel="canonical" href="https://example.com/url-migration/">

A self-referencing absolute canonical for the final indexable address.

What this one line promises

  • rel="canonical" describes the relationship; it is not an instruction to a browser to navigate.

  • The absolute HTTPS URL avoids ambiguity across hosts and deployment environments.

  • Render this value from the resolved production URL rather than accepting an untrusted request host.

  • The snippet is standards- and documentation-reviewed; it was not deployed to a separate production property for this rewrite.

Make a migration inventory before touching routing

  1. Export known URLs from the CMS, sitemap, analytics, access logs, backlink reports, and Search Console or Bing Webmaster Tools.

  2. Create an explicit one-to-one map from every retiring URL to the closest equivalent destination. Redirect to a category or home page only when it genuinely replaces the old intent.

  3. Record query-string behavior, fragments used by important links, locale alternates, canonicals, structured-data URLs, images, feeds, and downloadable assets.

  4. Crawl a staging representation and test collisions, loops, chains, soft 404s, mixed protocols, case variants, and encoded paths.

  5. Capture a baseline: indexed pages, organic landing traffic, top queries, backlinks, server errors, and crawl statistics. Without that evidence, “traffic feels lower” is hard to diagnose.

Express redirects as data you can review

redirect-map.jsonjson
[
  {
    "sourcePath": "/old-url-format/",
    "destination": "/url-migration/",
    "statusCode": 308,
    "preserveQuery": true
  }
]

A small declarative mapping that can be collision-tested before it reaches the edge or application router.

The redirect record is a contract

  • sourcePath is an exact retired path, not a loose substring replacement that can catch unrelated routes.

  • destination should be the final canonical route so the request completes in one hop.

  • 308 means permanent redirection while preserving the request method. 301 is also a permanent redirect, but historical user-agent behavior can change POST to GET; understand the application before choosing. Bing explicitly documents 301 for permanent moves, while Google supports both 301 and 308.

  • preserveQuery is a product decision. It can retain useful campaign information, but blindly carrying sensitive or obsolete parameters is unsafe.

  • This is the Payload-style model used by Lynxbee, not a universal web-server configuration file.

There is also no need to weaken a correct migration out of fear that a permanent redirect inherently “loses PageRank.” Google says permanent server-side redirects do not cause PageRank loss. That does not excuse mismatched destinations, redirect chains, or broken content; it simply removes one persistent myth from the decision.

Test the HTTP behavior, not only the final pixels

Terminalbash
curl --head https://example.com/old-url-format/
curl --head https://example.com/url-migration/
HTTP/2 308
location: https://example.com/url-migration/

HTTP/2 200

Read these headers with healthy suspicion

  • --head requests headers, which makes status and Location easy to inspect; some applications handle HEAD incorrectly, so confirm with a normal GET when results differ.

  • The old route should return one permanent redirect and an absolute or correctly resolved Location.

  • The destination should return 200, be indexable, declare itself canonical, and contain equivalent content.

  • The shown example.com output is illustrative. No external property was mutated or represented as execution-tested.

Update every signal you control in the same release

  • Change navigation, body links, breadcrumbs, pagination, feeds, image references, alternate links, Open Graph URLs, and structured-data identifiers to the new address. Do not rely on internal redirects forever.

  • Emit only canonical, successful URLs in XML sitemaps and submit the updated sitemap to Google Search Console and Bing Webmaster Tools.

  • For international pages, update each hreflang cluster so alternates reference current reciprocal URLs, including an x-default entry when the strategy uses one.

  • Update backlinks you directly control, paid-campaign destinations, email templates, app deep links, QR codes, and API consumers where applicable.

  • Keep the old hostname verified in search tools during a domain move. A domain move also needs DNS, TLS, host-level redirects, ownership, and change-of-address planning beyond path redirects.

Deploy in a way that leaves footprints

  1. Back up content and routing data, version the mapping, and define who can roll it back.

  2. Test representative GET and non-GET routes, encoded paths, query strings, mobile/desktop templates, authentication boundaries, and CDN behavior in staging.

  3. Deploy redirects and updated destinations together. Avoid a window where old URLs fail or new URLs lack canonical content.

  4. Crawl both URL sets immediately after release and inspect real response headers rather than trusting configuration syntax.

  5. Monitor old-path requests, 404/5xx rates, redirect latency, sitemap processing, indexing, landing-page traffic, and conversions by page group—not just site-wide totals.

  6. Keep redirects for as long as old references can reasonably exist. Google recommends retaining site-move redirects generally for at least a year; users and external links may justify much longer.

When the numbers wobble after launch

  • Old URL returns 200: the duplicate remains live. Confirm route precedence, caches, and whether the CMS still publishes it.

  • Redirect chain appears: a historic destination moved again. Flatten mappings so every known legacy URL reaches the current page directly.

  • New page is “Duplicate, Google chose different canonical”: compare redirects, internal links, sitemap entries, canonical markup, content equivalence, protocol, host, and trailing slash.

  • Many URLs become soft 404s: destinations may be generic, empty, or mismatched. Restore specific equivalents or return honest not-found responses.

  • Query traffic disappears: check whether parameters selected valuable indexable resources before they were stripped or canonicalized.

  • International pages vanish: validate return links and locale mappings across the entire hreflang cluster.

  • Traffic shifts temporarily: discovery and reprocessing take time. Compare affected URL cohorts and queries against the baseline before reverting on emotion alone.

The quiet success condition

A good URL migration becomes boring. People following an eight-year-old link arrive exactly where they expected. Crawlers see one destination, your own templates point there directly, and the redirect map waits quietly for references you do not control.

That is a more useful ambition than making every address look perfect. The URL does not need to impress another SEO tool; it needs to keep its promise to the person who saved it.

Continue with the surrounding evidence

Primary references