Case study · Technical SEO · Migration · Search Console
One visit in nine
ended on a 404.
The new site was faster and cleaner than the old WordPress one. Google, and a lot of visitors, were still arriving at the old addresses.
- 11%
- of a month’s pageviews landing on the 404
- 157 → 259
- redirect rules, every one validated
- 53%
- of redirects cut from two hops to one
Summary
Problem
11% of a month's pageviews landed on the 404 page, and the site was telling Google that every page's real address was one that redirected away.
Solution
A redirect map checked by code, canonical and hreflang tags that agree with the sitemap, and page titles that say what people actually search for.
The 404s nobody was looking at
While explaining a month of traffic I noticed 11% of the month’s pageviews on paths with no language prefix and zero engagement: the 404 page. The redirects written at launch worked, but whole families of old URLs had never been mapped: old event pages, dated blog permalinks, old per-location pages.
- Before redirecting 105 old event URLs, I checked them against the current events. None still existed, so one rule to the events page was right, not 105 guesses.
- Old blog dates went to the blog, with the three posts that survived under new names mapped first. Order matters: the first match wins.
/PRIVACY-POLICY/needed its own rule, because path matching is case-sensitive.- WordPress login probes deliberately left as 404s. They're bots, and a redirect would only add fake pageviews.
Then I validated the whole file programmatically: no malformed lines, no duplicates, no rule shadowed by an earlier wildcard, and every destination a real page. Along the way two old location URLs turned out to be sending visitors to the homepage instead of their own pages.
The redirect that broke the images
A week later a colleague noticed every event card showing a broken image. The new events rule also caught the images stored under the same folder, redirecting each one to an HTML page. I moved the images to their own folder rather than weakening a redirect that was correct, and wrote the rule down so they don't get moved back.
Canonicals pointing at redirects
Search Console showed the same pages under two addresses, and the wrong one winning. The site serves every page with a trailing slash, but the canonical, hreflang and breadcrumb tags were built without it. Every page was telling Google “my real address is one that redirects away from me”. More than half of the redirects also took two hops for the same reason.
I wrote the tests first, one shared helper for every URL the layout emits, and checked the production build: zero canonicals without the slash left on any page.
Pages losing to their own homepage
The meeting-rooms page ranked below the homepage for “meeting rooms Málaga”, consistently, day after day. Its title didn't contain the word “Málaga” at all. The homepage's did. The title now carries the full search phrase, the heading a shorter version that still reads well at display size. Earlier, a homepage title already at position 8 for “coworking malaga” but getting no clicks was rewritten around the one thing no competitor's title mentioned: two locations, the historic centre and the seafront.
Search Console flagged three lead-form URLs as “indexed though blocked by robots.txt”. The textbook fix would let Google crawl endless form variations to find a noindex tag. At this site's size, a few bare URLs in the index cost nothing. I logged the decision so nobody investigates it again.
“A migration isn't finished when the new site goes live. It's finished when the old addresses stop arriving.”