Moving house without losing your reach

Moving your website is a good moment. The old shop looked dated, the new system is faster, the product pages are finally clear, and on the day of the switch everything looks better than before. A few weeks later someone notices that fewer visitors arrive from Google. Not dramatically, but steadily, and nobody can quite say why.

The answer almost always lies with the old addresses. Over the years Google has learned which URL leads to which product, which guide and which category. Customers have shared links, partners have linked to you, bookmarks sit in browsers. Build the new structure and simply let the old addresses expire, and you send all those visitors into nowhere and give away reach you worked hard for. The good news: with a little care before the move, this can be avoided almost entirely.

The forgotten inventory

The first step happens before anything moves, and it is the one most often missing: a complete list of every address under which the old site can be reached. The most important source is the old sitemap, if there is one. Add the pages Google Search Console knows as indexed or linked, and the server logs that show which addresses are actually requested. In our experience the list is longer than expected, because systems like to offer several routes to the same page, such as with and without an extension, with a different language prefix, or via an old overview page.

For each address it pays to note down right away what was there: title, description, and for articles the date and keywords too. It costs hardly any time while you pull the list, and it is worth its weight in gold later. After the move the old site is switched off, and six months on nobody remembers what a cryptic address like "03-old-product.html" was actually about. When we moved this website, the old sitemap held 110 addresses spread across some thirty actual pages, and it was exactly these notes that made the mapping possible later on.

Some of these addresses sit in places you can no longer touch after the move. Old social media posts on LinkedIn or Instagram, newsletters already sent, PDFs, slide decks and QR codes on printed material keep pointing to the old structure, and hardly anyone goes back to edit a post from three years ago. Yet it is often exactly these posts that reliably bring visitors for years, because they are shared, saved and rediscovered. For them, a redirect is the only way to arrive. A look at the server logs shows which old addresses are still requested through such sources.

Every old address gets a destination

The inventory turns into a mapping table: for each old address it states where it should lead from now on. For most pages that is simple, because there is a clear successor, such as the same product page under a new address or the same category under a new name. Harder are the pages that no longer exist as such, for example discontinued products, or guides that have not been rewritten for the new site yet.

These cases need a conscious decision rather than chance. If there is a page on the same topic, such as the category the old product belonged to, it makes a good destination. If there is none, it is more honest to report the page as removed than to send visitors to an arbitrary place. What matters is that no address is forgotten and every decision is written down somewhere.

/products/coffee-grinder-classic.html
  → 301 /shop/grinders/classic

# successor still open
/shop/item-1234.html
  → 302 /shop/category/accessories

# removed on purpose
/shop/discontinued-2019.html
  → 410

# article to follow
/guides/what-does-a-gmbh-cost.html
  → 302 /guides

Neither the inventory nor the redirects should be made by hand. A small script reads the old sitemap, requests every address once and records the status code, title, description and canonical tag. Through the canonical tag, the many variants of the same page can be merged into one entry automatically. The mapping then lives as data in the code of the new site, and the redirects are generated from it instead of being maintained one by one in a server configuration. Automated tests check on every change that every old address redirects, that every destination actually exists, and that no old address hides a new page. Only what truly needs judgement stays manual: deciding which new page takes over an old topic. With more than a hundred addresses, that is exactly the difference between a list that is right and one missing three entries that only show up weeks later in Search Console.

aws s3api put-object \
  --bucket redirects-old-shop \
  --key products/coffee-grinder-classic.html \
  --website-redirect-location \
    https://example.com/shop/grinders/classic

301 or 302?

Technically, a redirect is a short answer from the server: "the page now lives elsewhere", together with the new address. The status code says what kind of redirect it is, and two of them matter most for a move. The code 301 means "moved permanently". Search engines transfer the signals of the old address to the new one and, over time, take the new address into the index. The code 302 means "temporarily elsewhere". Search engines then keep an eye on the old address for the time being, because they assume it will come back.

One detail is often overlooked: browsers remember a 301, frequently without an expiry date. Anyone who has requested an old address once goes straight to the stored destination next time, without asking the server at all. If you change the destination later, the change no longer reaches those visitors. That leads to a simple rule of thumb. Use a 301 only when the destination is truly settled. As long as it is still open where an old page should finally lead, a 302 to the matching overview is the better choice.

For completeness, both codes have a younger variant, 308 for permanent and 307 for temporary. The only difference is that a browser keeps the method when a form is submitted, instead of turning the submission into a plain page request. For ordinary page requests they behave like 301 and 302.

Why 404 and soft 404 cost reach

The obvious trap is the hard 404: the old address answers "not found". For Google that means the page has gone, and after a while it drops out of the index. Every link ever set to that address now leads nowhere, and the signals it brought are lost. For visitors it is even more disappointing, because after clicking a search result they are faced with an error page.

The less obvious trap is the soft 404. This is a page that says "not found" in its content but technically answers with 200, pretending everything is fine. Google often judges the well-meant attempt to redirect every old address to the home page in the same way. Fifty former product pages that all point to the same home page are not a move for a search engine, but fifty vanished pages. Search Console reports such cases explicitly as soft 404, and the hoped-for effect does not happen.

For pages that are gone on purpose, the status code 410 is the most honest signal. It says "removed on purpose" rather than "not found", and Google usually drops such pages from the index a little faster. The order of choice is therefore clear: first a real successor with a 301, then an overview on the same topic, and if neither exists, an honest 410 instead of a redirect to anywhere.

The metadata moves too

Besides the addresses there is a second layer that often gets lost in a move: the metadata in the head of every page. Title and description decide how a page appears in search results. The canonical tag states which address is authoritative when the same page can be reached under several, for example with filter or tracking parameters. On multilingual sites, hreflang links the language versions to each other, so Google shows the German page to a reader in Vienna and the English one to a reader in London.

Then there are the details for sharing, following the Open Graph protocol. They define the title, description and image a link shows in LinkedIn, Slack or a messenger. Without them, every platform picks something on its own, often the logo at stamp size or a random snippet of text. Finally, structured data describes content in a machine-readable way, such as breadcrumbs, frequently asked questions or the company itself. It helps search engines, and increasingly AI-powered search, to place a page correctly.

The same applies to old posts. Platforms such as LinkedIn cache the preview of a shared link, often for quite a while. A post from before the move therefore still shows the title and image of the old page, even though the link has long led to the new one through the redirect. LinkedIn and Facebook offer their own inspection tools that let you have the preview of an address reloaded, and for the most important posts this small step after the move is worth it.

The most important principle here is unspectacular: all of this should be generated from the same data as the visible page, not maintained by hand. When the structured questions come from the same entries as the visible questions, and the sitemap from the same navigation as the menu, nothing can drift apart. Every new page brings its metadata along automatically, and nobody has to remember to update a second list.

Announce the new structure

Redirects make sure old addresses arrive. For Google to learn the new structure quickly and completely, it pays to announce it actively. The basis is an up-to-date sitemap.xml that lists every page that should be found, and only those. Pages that are deliberately kept out of the index do not belong in it. The sitemap is named in robots.txt and submitted in Google Search Console, where you can then also see how many of the listed pages are actually indexed.

# robots.txt
User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Less well known is that Search Console accepts an RSS or Atom feed alongside the sitemap, and Google explicitly recommends using both. They complement each other. The sitemap is the complete directory of all pages and is fetched rather rarely. A feed contains only the latest content, is small, and is therefore read more often. Especially after a move, when new articles or product pages appear one by one, the feed makes sure new things are found quickly while the sitemap covers the whole. Why RSS is an underrated tool beyond search engines is the subject of our article RSS isn’t dead, just quiet.

Keep watching after the move

The work is not quite done once you switch over. In the first weeks, Search Console shows whether the plan works: old addresses that still answer with 404 turn up there, pages judged as soft 404, and new pages that have been found but not yet indexed. A short weekly look at these reports is enough to close gaps in the mapping table before they cost reach.

A slight up and down in ranking right after the move is normal, because Google first has to process the new addresses. What counts is the trend after a few weeks. And the redirects stay in place for good, because old links and bookmarks do not disappear just because the site has moved.

What this means for you

A move does not give away reach because of the new design, but because of the addresses nobody thought of. Take a complete, automated inventory before the switch, give every old address a deliberate destination, generate and test the redirects from it, use 301 and 302 with care, and actively announce the new structure with sitemap and feed, and you take your ranking with you instead of having to rebuild it. If a move is coming up for you, we are happy to look at the redirects together before it goes live.