Runbook
Site migration backlinks: a runbook for linked URLs
A migration is the one moment when the pipes you built meet the inlets you do not control. Treat every URL that earned a link as load-bearing.
Moving platforms or changing URL schemes puts your external links at risk, and the risk is concentrated. A few URLs hold most of the referring domains.
Those URLs get a hand-built redirect, never a pattern rule. Learn which ones they are with the inlet method. The rest can follow patterns.
Here is our runbook. It uses a link export to decide what is sacred. It ends with a check, against Search Console, because redirects that look right in a spreadsheet can still behave strangely in production. For the structure behind the sacred URLs, read about entry pages.
The runbook, in order
- 1
Freeze and snapshot
Record the date, export
toppagesandrefdomainsfor the old domain, and save both files. - 2
Mark the sacred URLs
Every URL with external links gets a row in the redirect map with a named, relevant destination.
- 3
Handle parameter variants
Decide which query strings change content. Redirect or canonicalise the ones that do not.
- 4
Avoid chains
Old URL to final URL in one hop. Re-point any earlier redirects that now lead through two.
- 5
Ship, then crawl
Crawl the old URL list against the new site and confirm status codes before announcing anything.
- 6
Compare snapshots
After the next index refresh, export again and diff the entry list against the first snapshot.
Pre-launch gate
- Every entry page from the export has a destination in the redirect map.
- No destination is a 404, a login page or a blanket redirect to the home page.
- HTTP to HTTPS and www to non-www rules run before the map, not after it.
- Old sitemap entries are replaced, not left to rot.
- robots rules on the new site do not block redirected paths.
- A person other than the author has spot-checked twenty rows.
A diff-friendly snapshot
Run on the old domain before launch, and again after the next monthly refresh. Compare the two files.
curl -s "https://linkisflow.com/api.php?action=toppages&q=old-site.com&per=1000&key=sk_live_..." > toppages-2026-10-29.json
curl -s "https://linkisflow.com/api.php?action=refdomains&q=old-site.com&per=1000&key=sk_live_..." > refdomains-2026-10-29.jsonWhat redirects cannot rescue
A 301 is a forwarding address, not a transfusion. If the new page has a different topic from the old one, the link may stop counting, which is why destinations should be relevant.
Links from sites that never update will keep pointing at the old address, so keep the redirects live. How long is a question for your own risk appetite; we state no period here.
Anchors are another trap. If an inlet arrived with the words of a product you have since removed, the new destination should still make sense of them.
After the snapshot comparison, any entry page that has dropped out deserves a manual look. A monthly refresh can lag behind real changes, so check Search Console as well.
Real events show why care pays off: Google's December 2022 link spam update and the later March 2024 core update both reminded site owners that links are judged on their source and context, not just their count. SpamBrain, Google's spam system, is the name to know.
Migration questions we hear
Do I need to redirect every old URL?
No. Redirect every URL that has external links, and every URL that gets real visits. The long tail of thin or duplicate pages can return a clean 404 or 410 without costing you much.
How do I handle crawl bloat from parameters after the move?
Decide which parameters change content, canonicalise or redirect the rest, and keep internal links pointing at the clean version. Then crawl the new site to confirm no parameter variants remain in your own navigation.
Can I check which of my old URLs had links?
Yes. Call toppages on the old domain before you switch anything. It costs 2 credits per call and returns up to 1,000 rows, enough for most small sites in one request.
Is a redirect to the home page acceptable?
Only as a last resort. A generic destination tells search engines little, so link the old URL to the closest relevant page instead.