Reference reading

Framework articles

Step-based technical guides for the parts of a migration that are easy to underestimate and expensive to get wrong.

Where should a migration plan actually start?

Not with the new homepage design. It should start with an inventory of what already exists: which pages are indexed, which ones bring in traffic, and which ones can quietly disappear without a redirect because nothing links to them anymore. The articles below are organized roughly in the order this inventory work tends to happen, from mapping through to post-launch monitoring.

Building a redirect map in a spreadsheet before touching anything

Every existing indexed URL gets a row. Every row gets a destination, a redirect type, and a note on why it moved. This becomes the contract between whoever built the old site and whoever is building the new one. Development should reference the sheet, not guess at it.

A redirect map built after launch is really just a bug list. Built before, it is a plan.

An open notebook with a handwritten pre-launch migration checklist next to a laptop showing a spreadsheet

What belongs on a pre-launch checklist

Robots.txt rules, sitemap paths, canonical tags, and structured data all need a second look before launch day, not during it.

What a staging environment is, in plain terms

  • A private, often password-protected copy of the site
  • Blocked from search engine crawling with a noindex rule or authentication
  • Used to test redirects, layout, and forms before launch
  • Discarded or repurposed once the live site is confirmed stable

Free tools for monitoring rankings mid-migration

No paid subscription required

Google Search Console remains the most direct signal, but log file review and manual query checks catch things Search Console reports days later.

The cost of testing changes on the live domain

Testing "live" means every crawl during that window sees a half-finished site. Search engines do not wait politely. They index whatever they find, including broken redirects and missing pages, and that snapshot can linger in cached results.

A dashboard on a monitor showing an organic traffic line chart with a visible dip shortly after a site migration

Reading a traffic dip without panicking

A short dip after launch is common even in careful migrations, while crawlers re-discover moved pages. A dip that keeps widening after two or three weeks deserves closer inspection.

Common questions about the framework

Ideally, yes, for anything that was ever indexed or received a backlink. Pages with no traffic, no links, and no index history can sometimes be left to return a proper 404, but that decision should be intentional, recorded in the redirect map, not accidental.

There is no fixed number that fits every project. What matters is that every redirect rule, every template, and every form has been checked at least once by a person who was not the one who built it.

Search Console's Coverage report tends to surface crawl and indexing problems earliest, often before a ranking change is visible anywhere else.

Only when the underlying source material was already public and attributed. Where a source discusses a situation without naming the site, this publication keeps it unnamed as well.