Relaunched your site but search still shows the old pages?

If search engines still show your old pages after a website relaunch, the usual cause is that the old addresses answer “not found” instead of redirecting to the new pages. A “not found” tells a search engine the page is dead, not moved, so it keeps the stale result it already has. The first check is to request a few old addresses the way real visitors and crawlers do, and look at what the server answers: it should be a redirect to the right new page.

Here is how that happened to us, with a list of 140 redirects already written and checked.

You relaunch your website. The design is new, the copy is new, and a few days later you search for your own company on Bing and the result is a page from the old site, with the old wording, for a company you have stopped being.

That is what happened to us. Everything about a relaunch is judged on whether the addresses the world already knows lead to the right new places. If they do not, the new site is a second site that happens to share a domain with the old one, and every link other people built to you is answered with nothing.

We knew that. We wrote the list of old-to-new addresses before the switch, built from the old site’s own inventory of pages joined against a hundred and eighty days of Search Console data, so the busiest addresses came first. We checked that every target answered before writing anything. A hundred and forty entries. Then we switched over, and for days afterwards a search on Bing returned the old page, as though nothing had happened.

What was actually going on

It is easy to read a stale result as the search engine being slow, and all the obvious explanations would have led us to wait. What settled it was checking the thing the engine was asking for, not the thing it was returning.

The address Bing held was the old page without a slash on the end. Our list held it with one.

The new site puts a slash on every real page address. When a browser asks for a page without it, the server notices a folder of that name exists and sends the visitor to the slashed version automatically. That is why the no-slash form of every live page works, and why we never noticed the gap.

An old address has no folder. Nothing on the server was called that. So the server had no reason to add a slash, the request never matched our list, and it fell through to a plain “not found”. Every entry had been written with a slash because that is how the old site wrote its own addresses. Search engines hold whichever form they first met, and a decade of links, directory listings and pasted addresses includes plenty without one.

What we changed

A “not found” is not a neutral answer. For a search engine it is information, and the wrong information: it says the address is dead, not that it moved. So the engine keeps the title, description and snippet it already has and tries again later. The stale result survives precisely because the server said nothing useful.

A redirect says the opposite. It hands the old address’s identity to the new page. On one address the access log shows eighteen “not found” answers, then ten redirects. Same crawler, same address, a different answer, because in between we changed what the server said.

We found a second fault in the same list while fixing this. It matched on the full address including anything after a question mark, so any old address arriving with tracking parameters on the end, which is most of those from anywhere other than a plain link, did not match either. Both faults share one fix: tidy the address once before looking it up, so the slash and the parameters stop mattering, while leaving alone anything that is a file, so the sitemap address still matches.

The most important address we had been failing was the sitemap. The old one, which Google and Bing both had on file, used an underscore; ours uses a hyphen. An engine asking for a sitemap is asking to be told what exists, and we answered “not found” to that specific request for days while wondering why discovery was slow.

What it did not fix

Nothing recovers the days in which the old result stood. The engines re-check on their own schedule, and the fix could only change what they were told from then on.

The list we wrote before the switch was tested the way we wrote it, not the way an engine would ask. That was the mistake.

How to check your own relaunch

1. Take ten of your busiest old addresses from your analytics or Search Console, and request each one three ways: as written, without the slash on the end, and with tracking text added after a question mark.
2. Each should answer with a permanent redirect to the right new page. A “not found”, or a redirect to the home page, is a fault.
3. Request the old sitemap address too. An engine asking for a sitemap is asking what exists.
4. Read the server log for “not found” answers after launch. The crawlers will tell you which addresses they still believe in. Ours were asking for the old services page, the old hiring page, the old home address, the category pages and the old feed, and each was a link somebody had built to us, answered with nothing.
5. Ask whoever built the site to make the three-way test part of every launch. Ours reads the list off the server and runs on the current list of 141 entries and 420 requests in seconds. It would have caught this before the switch rather than a week after it.

That is the cheapest repair available, because the demand already exists. You are not trying to earn attention. You are trying to stop throwing away attention you already have.

Where this ends up

An address list is a migration artefact like any other, and it earns the same treatment as the data: a check that runs on every rehearsal rather than a spreadsheet somebody read twice. That is how cutovers are handled in the work described under enterprise modernisation.