The list without which a relaunch is blind

There is one question that has to be answered before every rebuild of an existing website, and it sounds more harmless than it is:

Which addresses does your site actually have?

Not which pages are in the menu. Not which ones you built. But which addresses exist through which someone arrives at your site today — from a search engine, from a bookmark, from a link on someone else's site, from an email from three years ago.

Whoever does not have this list cannot tell after the rebuild whether something is missing. They can only wait until someone complains.

Why one source is not enough

The obvious place to reach for is Search Console. It says which addresses show up in the search results.

That is a good source and an incomplete one. It only knows what Google knows, and of that it mainly shows what had clicks or impressions. An address that for years has only been opened through a link in a forum is not there. A page that was never meant to rank but is linked in an invoice is not there either.

That is why you collect from several directions. Each knows a different slice:

Search Console — what occurs in search.

The redirects already set up — and this is the one almost everyone forgets. On a site that was rebuilt once before, old redirects are in place. Whoever does not collect them builds the new ones on top: an old address points to a middle-aged one, which points to the new one. Two hops instead of one, for good.

The visitor statistics — over as long a period as possible, a year or more. They also know what never came through a search engine.

The logs of the server or the delivery network — they record what was actually fetched. That is the most honest source, because it interprets nothing.

Tools for incoming links — they show what is linked to from outside. An address with a good external link is valuable, even if it has hardly any visitors.

A crawl of the existing site — it finds what is linked internally. What is linked nowhere and still exists, it does not find — which is why it is listed here and not on its own.

The list becomes a decision

The list is not yet an answer. It only becomes useful when next to every address it says what should happen to it. There are exactly three options:

It stays. The address does not change; afterwards the page can be reached at the same address. That is the cheapest case, and it should be chosen more often than is usual in relaunches.

It is redirected. There is a successor that fits in content. The important words are in content: a redirect to the home page just so that no error arises is no answer to the visitor's question.

It disappears. There is no successor, because the content is deliberately dropped. Then it is more honest to say so than to fake a redirect.

The decision is made on four things that should stand in the same row: how often the address was opened, whether there are external links to it, whether the content is still right, and whether the address even fits the content. Addresses whose name has nothing to do with their content are almost always legacy baggage.

The list is a living document

One point that matters in practice: this list is made early and revised several times.

Early means: as soon as the content is on the staging site, not only shortly before switching over. Not because the first version is already right — it is not — but because it creates a basis for comparison. If someone on the staging site changes an address afterwards, it shows against this version. Without it, it does not show at all.

On a staging site where several people work, addresses change. That is normal. It must not go unnoticed.

And then it becomes the check

The real value of the list shows after the switch-over, and that is the part that most often gets skipped.

You take the old addresses — not the new ones — and fetch them all. Not clicking, but letting a tool run through them that records what the server answers.

Exactly three answers may come back, and they are the same three decisions from above:

• Reachable for everything that was meant to stay
• Permanently redirected for everything that has a successor
• Deleted for everything that is deliberately dropped

If anything else comes back, it is a finding:

A “not found” answer means a redirect was forgotten. That is the expensive case — everyone arriving through this address lands in nothing.

A chain — a redirect pointing to a redirected address — means the old redirects were not collected. It works and is still wrong.

A redirect where “reachable” should be means an address changed without anyone noticing.

Without the list, none of these three checks is possible. You can crawl the new site and find what is broken on it. What is missing you never find that way — because an address that no longer exists is not linked anywhere on the new site either.

That is the core: the new site cannot tell you what you lost. Only the old list can.

What it costs and what it saves

Putting the list together is plain work. Download several exports, put them into one table, remove duplicates, add columns. For a small site a morning, for a grown one considerably more.

What it saves you only notice when you have it. Otherwise missing redirects do not show on switch-over day, but over weeks — as slowly falling numbers for which there are many explanations and whose real cause nobody looks for any more.

It is exactly the kind of work nobody sees and whose absence nobody can pin on a single error.

If you are in the middle of a rebuild

If a relaunch is running right now or has just happened and this list does not exist, that is not a lost cause.

The sources are still there retroactively: Search Console keeps its data for a while, so do the visitor statistics, and external links do not disappear. What is missing is time — Search Console's data only goes back so far.

So if something needs doing here, sooner rather than later.

Sources

• Udemy, Der perfekte Webseiten-Relaunch, phase 1 and phase 2 — that the data basis is put together from several exports, among them the well-performing addresses from Search Console, the weak ones from the visitor statistics, the internal links and the incoming links; that for every address it is decided whether it stays reachable, is redirected or deleted, and that this decision depends on clicks, impressions, incoming links and whether the address name even fits the content; that an existing redirect has to be recognised and resolved instead of putting another one in front of it.
• Udemy, Der perfekte Webseiten-Relaunch, phase 4 — that the same list is fetched in list mode after the switch-over and that exactly three answers are allowed; that a “not found” answer points to a forgotten redirect; and the observation from the worked example that forgotten redirects and one superfluous redirect were indeed found.
• Sitebulb webinar Website Migrations & Redirect Mapping Dos & Don'ts, November 2024, panel of four practitioners — that a single source is not enough and addresses are gathered from Search Console, the redirects stored in the system, the delivery network, the visitor statistics over a longer window and from link tools; that the existing redirects are collected first, because otherwise chains arise; that a first version of the mapping is made as early as possible, as soon as the content is on the staging site, and is revised several times afterwards; and that this early version serves to notice changes to the address structure that others make on the staging site.
• Own practice — the order of the sources, the note that a redirect to the home page is not an answer in content, the classification of the effort, and the note that the data sources only reach back so far and a missing list is therefore better made up sooner rather than later.