Changing your url structure without losing SEO

Every url change is a small site move: Google has to recrawl the old url, follow the redirect and transfer what it knew to the new one. Its site move documentation covers path changes on one domain as a move with url changes and says to expect temporary ranking fluctuation. So change urls for a reason — not because a new cms prefers another pattern.

Good reasons: urls with dates that make evergreen content look old, ids instead of words, a folder hierarchy that no longer matches the site, a mix of languages, or capitals and underscores that cause duplicates. Google’s url structure guidelines recommend readable words over long ids and hyphens over underscores, and note that urls are case-sensitive. A relaunch is the cheapest moment to fix these, because the redirect map has to be built anyway.

The question is whether the change can be described as a rule. If it can, write the rule. If every url needs its own decision, it needs its own row.

Most real restructures are a mix: two or three folders move as a whole, and inside them a few dozen pages also get new slugs. The pattern rule handles the folder; the renamed pages need rows of their own on top.

A wildcard rule has one advantage nothing else has: it covers urls you never found. A post that is in no sitemap and linked from nowhere still gets redirected, because the rule matches its prefix, not its name. The notation is different on every platform:

Order matters. When a specific row and a wildcard both match a url, the platform has to pick one, and not every platform picks the more specific rule. Put the one-to-one rows first and the wildcards last, then test a renamed url to see which rule wins. Squarespace, for example, uses the first line that matches (squarespace url mappings).

Check the targets. A wildcard writes targets that nobody looked at. /blog/(.*) → /journal/%1 is only right if every post really exists at /journal/ under the same slug; for each one that does not, the rule produces a redirect to a 404, which looks handled and is not.

In Silentfrog a directory rule does both checks before export: it shows how many crawled pages it affects and which resulting targets do not exist on the new site — those land in needs review instead of being exported (whole directories at once). Ticked as a wildcard, it is written as one line in each importer’s notation, and written out row by row for Shopify and plain pairs. That one line replaces every row below the folder, including renamed pages you re-mapped by hand: if a folder has renamed pages, leave the wildcard unticked so every row is written individually, or add the renamed rows above the wildcard line yourself.

renamed slugs — the rule moves /blog/seo-tipps to /journal/seo-tipps, which does not exist. Only a comparison of old and new pages — by slug, title and headline — finds that the target is /journal/seo-checklist.

merges and splits — when five pages become one, each old url needs the merged page as its target. When one page becomes three, pick the one that answers what the old page ranked for.

query-string urls — /product.php?id=417 identified a page by its parameter, and most redirect engines match on the path alone. These need server rules that read the query string, or a row per id where the platform can express it.

This is where automated matching earns its keep. Silentfrog crawls the old and the new structure, pairs identical paths, and scores the rest on slug, title and h1, so a renamed page is found even when its path has nothing in common with the old one (how matching works). The first 50 old pages are free.

Redirects catch everyone arriving from outside. Inside the site there should be nothing left to catch. Google’s move guide lists updating internal links, canonical tags and hreflang annotations as part of the move:

• internal links — navigation is usually generated and changes by itself; links typed into body text, buttons and cms rich-text fields do not. Crawl the new site and look for internal links that answer 301.
• canonical tags — every page should name its own new url. A template that still builds the canonical from the old pattern tells Google to index a url that only redirects.
• hreflang — every language version lists its alternates by url; each of them has to use the new pattern, in every language.
• everything else that names a url — structured data, open graph tags, pdfs, email templates, ads and your own social profiles.

The new sitemap lists only new urls — no redirecting urls, no 404s. Submit it in Search Console on launch day. Google’s move guide also suggests submitting a sitemap of the old urls at first: Google then recrawls them, sees the redirects, and the indexed count of the old sitemap falls toward zero while the new one rises. Once that has happened the old sitemap can be removed.

No Change of Address request is needed for a restructure on one domain — Google’s Change of Address help says the tool does not handle path-level moves.

• before launch, run the old url list against the staging site with the rules in place, if the platform allows it.
• on launch day, request every old url: each should answer 301 and land on a 200 in one hop.
• test the edge cases by hand — a trailing slash, capitals, a url with a query string, a renamed page inside a wildcard folder.
• keep the rules. Google says at least a year; on the same domain, there is rarely a reason to ever remove them.

Google’s redirect documentation treats a permanent server-side redirect as the signal that the target should be canonical — use 301 or 308, not a temporary redirect or a javascript one.

• Change urls for a reason; each change is a small site move with temporary fluctuation.
• Folder moves get one wildcard rule, which also covers urls no crawl found.
• Renamed, merged and split pages get one-to-one rows, placed before the wildcards.
• Check that every target a wildcard produces actually exists.
• Update internal links, canonicals, hreflang and the sitemap to the new pattern.
• No Change of Address request for path changes; keep the redirects for at least a year.