Planning a Website Migration Without Losing Search Visibility

Migration planning goes wrong in a predictable way: everyone treats it as a build project and nobody treats it as a redirection project. The new site gets designed, built, populated and signed off, and in the last fortnight somebody discovers there are four thousand old URLs and no mapping between them and the new ones. At that point the only options are bad — a blanket redirect that sends every visitor to the homepage, or a launch followed by a search visibility decline that takes months to unwind.

The fix is unglamorous and mostly happens before the new site exists. This is the order in which I would run it.

First, establish which migration this actually is

“We’re moving the website” covers at least four jobs with different risks, and conflating them is how scope becomes unmanageable.

• A platform change. Same content, same URLs, new system underneath. Lowest risk, because the URL structure does not change and there is nothing to map.
• A replatform with structural change. New system and different URL patterns — for instance a flat marketing site replacing a section-based one. Medium risk, and this is where most planning effort belongs.
• A redesign with stable structure. Same URLs, new design and new content. The risk here is content loss and template regressions, not redirections.
• A consolidation. Several sites or subdomains merging into one. Highest risk, because authority is split across hosts and the merge has to redistribute it deliberately.

Say which one it is, in writing, because the plan for each is different. A consolidation needs host-level planning, careful handling of analytics and search console properties, and a decision about which domain becomes canonical. A redesign with stable URLs needs a content freeze and a redirect audit.

If the underlying reason is a codebase nobody wants to maintain any more, that is a modernisation conversation and the migration plan should sit inside it rather than beside it.

The inventory that nobody makes

You need a list of every URL that has ever been meaningfully linked to, plus everything the current site generates. Three sources, and all three are necessary because each misses what the others find.

Server and CDN logs give you what is actually being requested, including URLs nobody put in a navigation menu and several nobody remembers. Analytics give you the subset that matters commercially, which is a much shorter list and the one you will use when you have to choose. Search console data gives you the indexed set, which is not the same as either of the others — it tends to include a tail of old parameter combinations and a handful of stray URLs from years ago.

Pull all three into a single table with the current URL, the status code, whether it receives links from elsewhere, whether it is indexed, and its approximate traffic. That last pair of columns is what lets you prioritise later, and gathering them takes a day at most. Skipping this step is the single most expensive shortcut in the whole process.

While you have the data, check the backlinks. External links are the part of your visibility you do not control, and the URLs they point at are not necessarily the ones you think. If the inventory is coming from an unfamiliar estate, this is where our full website audit work pays for itself, because it produces the inventory as a by-product.

URL mapping is the actual project

Take the inventory and assign every URL one of a small number of destinations: the same content at a new equivalent URL, content merged into a different existing page, content removed with no equivalent, or a decision pending. Every row gets filled in before the new site is populated.

Two mappings deserve particular care. A merge means choosing a surviving URL, and it needs a judgement about which one, not a coin toss — usually the URL with external links, or the older one, or the one that reads most clearly to somebody who has not seen the site. A removal needs a reason: if the old URL had links and there is no equivalent, sending it to the homepage is a poor substitute that visitors will recognise immediately.

The output is a mapping file that can be loaded as redirects, and the discipline that makes it work is to treat every row as needing a decision. Rows left blank are where the losses come from, because an unresolved row becomes either a 404 or a homepage redirect, depending on which script gets run.

One practical note: keep the mapping file outside the content repository. If it lives in the same place as the site, the next time somebody reorganises the codebase it disappears, and you will not find out until a customer reports a dead link.

Redirects have to live in infrastructure

This is where the shortcut usually gets taken. Redirects added as plugins, or as rows in a CMS redirect table, or as a JavaScript file in a template, are all fragile. They depend on the application working, on a plugin staying installed, on the template not being replaced by the next release. When the site breaks, the redirects break with it, and they tend to break in a way that turns a 301 into a 200 with a soft error page — which is worse than no redirect, because search engines treat it as the destination having no redirect at all.

Put them in the web server or CDN layer instead. That is where they execute before anything else touches the request, they keep working if the application is being redeployed, and they cannot be lost in a database migration. It also means they are testable in isolation with a single command.

This is the recommendation SmartEdge IT Solutions makes in almost every migration review, and it is occasionally unpopular because it means touching configuration that somebody considers out of bounds. That discomfort is the correct response to a decision this consequential.

Then test them properly. Fetch a sample of old URLs and follow the whole chain, not just the first hop. A chain of two hops where one would do passes most casual checks and slows every visitor who follows it. Confirm the status code is a genuine permanent redirect rather than a temporary one, and confirm the destination actually returns the expected content rather than a soft 404 with a success code.

The specific chains that break

Watch out for a small number of predictable failures. Some hosts apply their own HTTPS redirect and their own www canonicalisation on top of whatever you configure, and the combination occasionally produces a loop or a chain that alternates between hosts. Some staging environments share the redirect file with production, so a debugging redirect gets promoted by accident. And a plugin-based redirect table is silently discarded by a content import that replaces rows it does not recognise — which is why a scheduled re-check of a sample of old URLs is worth having for the first year.

Templates, parameters and the crawl trap

Every site has a family of URLs that it can generate but should not expose. Product listings with arbitrary filters, paginated archives, search results, printable variants, category pages with query parameters sorting the same content four ways. During a migration these are the ones that cause trouble, because they were often indexed before anybody realised they existed, and they may be linked from elsewhere.

Three things need to happen together. The old site should stop generating them, or at least respond to them in a way that does not encourage crawling. The mapping should decide, explicitly, whether each family is redirected to a clean equivalent or removed. And the new site’s own generation rules need to be written down, because a fresh build frequently reintroduces the same problem through a different component — a new filter implementation that produces a new infinite URL space.

Faceted navigation is where this becomes expensive. If the old site had a working pattern and the new one does not, the crawl problem returns within weeks of launch, along with the duplicate content and the diluted internal signals that came with it. Agree the rule before launch: which parameters are canonical, which combinations are disallowed, and what a disallowed combination returns.

Deciding what does not come across

Migration planning usually assumes full carry-over, and full carry-over is often the wrong answer. Old content accumulates — landing pages from campaigns four years old, thin service stubs, blog posts that duplicate something else, a downloads section with three files and a broken link. Moving it all means moving the problems.

The useful exercise is to classify the inventory by value and let low-value rows be dropped deliberately, with a redirect to the nearest sensible equivalent. This is a business decision as much as a technical one, and it should be made with whoever owns the content, not by the build team. Our app consulting and strategy engagements often end with exactly this kind of inventory review, because it is where a lot of the schedule risk disappears.

On a commerce migration the same question has an added dimension: what happens to the URLs of discontinued products. Redirecting them to a category page is sometimes right and sometimes visibly wrong. Decide the rule per category rather than globally.

Staging has to be honest and invisible

Two requirements, frequently traded off against each other and both necessary. Staging must be a real copy — same data volume where possible, same redirects, same server configuration, same templates — otherwise it proves nothing about the things most likely to break. And it must not be reachable by a search engine, which means access control at the server layer plus a directive that the crawler will actually read.

The classic failure is a staging host that resolves publicly, returns 200 to everyone, contains the full site including the paths that will 404 on launch, and has no crawler directive. Indexing a staging copy is slow to undo. If staging has to be public-facing for review, put it on a separate subdomain, keep it out of the site map, and remember that anything already indexed will need removal rather than just blocking.

Build the redirect mapping into staging as part of the build pipeline rather than applying it by hand at cutover. That is what deployment pipelines are for: it makes the redirect layer something you test continuously instead of something you trust on the night.

Rollout, rollback and the weeks afterwards

Launch at a time when the most people can act on problems. Not at the end of a long week, and not when the only people who can deploy are asleep. Freeze content for a short window before cutover so the inventory and the live site agree — a page published on Thursday and migrated on Friday is a mapping row nobody filled in.

Cut over by DNS if the hosting changes, with the previous version still deployable for a few days so you can reverse. If you cannot reverse quickly, then the migration is not ready, and the sensible response is to wait rather than to monitor it anxiously.

Afterwards, watch a small number of things daily for several weeks: server logs for 404s at volume, crawl behaviour for the pages you care about, indexation of the new structure, and whether the redirect chains still resolve. Set the previous analytics property up properly before launch rather than after, because without it you will not be able to compare, and comparison is the only way to tell a small dip from a real loss.

The pattern that means stop and investigate

One signal is worth naming because people routinely talk themselves out of it. A steady climb in 404s on URLs nobody has ever linked to is usually not a problem — it is a crawler finding a hole, and it stops on its own. A sudden step change on a set of URLs that used to return content, alongside flat numbers for the new pages, is different. That is the shape a broken redirect layer or a failed content import produces, and it is worth stopping the rollout for.

Another is worth naming because it is boring and easy to miss: nothing at all happening. No errors, no 404s, no complaints, and traffic down. That is usually a template that was never populated, or a canonical tag pointing at a page that does not exist, and it is invisible in server logs because every request succeeds.

One last practical point. Monitoring and backup for the old environment should stay alive through this period, not be decommissioned on cutover. If something needs to be compared against, or restored from, the previous platform needs to still exist. Deciding that early is cheaper than recreating it.

Our app migration and upgrade work follows this sequence because the ordering is the part that protects visibility. If you want it walked through against a specific estate, send SmartEdge IT Solutions the current URL and what is changing, and the first conversation will be about which of these four kinds of migration you are actually doing.