How do you fix redirects after a website rebuild?
Recover the old URL list from a crawl, the old sitemap, Search Console, analytics and server logs, then sort by traffic — that ordering tells you which mapping errors matter. Replace any launch-night catch-all to the homepage with real destinations, because it hides the problem rather than fixing it.
Recover the old URL list first
You cannot audit a mapping without knowing what was there before. Sources, in order of reliability:
- A crawl of the old site, if it still exists on staging or a backup
- The old sitemap, from the Wayback Machine if necessary
- Search Console — the old property still holds historic URL data
- Analytics landing page reports from before the launch
- Server access logs from the weeks around the change
Analytics is the most useful of these, because it ranks the old URLs by how much traffic they actually had. That tells you which mapping errors matter.
Test the mapping
Run every recovered URL and record where it lands:
while read u; do
echo "$(curl -sIL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}' "$u") <- $u"
done < old-urls.txt
Four failure patterns come out of this:
404s. URLs nobody mapped. Fix in traffic order.
Everything landing on the homepage. A catch-all rule written on launch night to stop the 404s. It hides the problem rather than solving it and should be replaced with real mappings.
Chains. Old URL to an interim URL to the current one, common when the rebuild itself changed URLs twice.
Wrong destinations. A pattern rule that matched more than intended.
Watch for the platform's own rules
A new CMS usually adds redirects of its own — trailing slash handling, lowercase enforcement, www normalisation, HTTPS upgrade. Each is reasonable alone, but stacked on top of your migration rules they turn one hop into three.
Check that your rules point at the final, normalised form: correct protocol, correct host, correct trailing slash. Getting that right removes an entire hop from every redirect on the site.
Do not forget what is not a page
Rebuilds routinely break things that are not HTML:
- Image URLs referenced by other sites
- PDFs — price lists, spec sheets, brochures
- Feed URLs
- Anything linked from an email campaign or a printed piece
For a Katy contractor or retailer, a PDF price list linked from a supplier's site is a real referral source that nobody thinks to map.
Confirm the domain layer
If the business owns variant domains — a former trading name, a common misspelling, a campaign domain — confirm each still forwards, and forwards to a real page rather than a parked holding screen.
Give it time, then check again
After fixing, resubmit sitemaps and watch 404 reporting weekly for two months. Redirect problems surface gradually, and the ones that show up in week six are usually the ones with the most value attached.
Frequently asked questions
How do I find the old URLs after a rebuild?
A crawl of the old site or a backup, the old sitemap via the Wayback Machine, historic data in Search Console, analytics landing pages from before launch, and server logs. Analytics is most useful because it ranks by traffic.
What is wrong with redirecting everything to the homepage?
It stops the 404 reports but functions as a soft 404 for visitors and search engines alike. It hides the mapping problem rather than fixing it, and should be replaced with real destinations.
Why do redirects get longer after a platform change?
The new CMS adds its own normalisation — trailing slashes, lowercase, www, HTTPS. Stacked on your migration rules, one hop becomes three. Point your rules at the final normalised form.
What non-page URLs break in a rebuild?
Images referenced by other sites, PDFs like price lists and spec sheets, feed URLs, and anything linked from email campaigns or printed material. A supplier-linked PDF is a real referral source nobody maps.
How long should I monitor after fixing?
At least two months, checking 404 reporting weekly. Redirect problems surface gradually, and the ones appearing in week six often have the most value attached.