Rebuilding a URL Map After a Platform Change

Challenge

Same client, the previous chapter. The site had been moved onto that proprietary platform some time before, and Search Console was still reporting a list of 404 errors that was getting longer rather than shorter, despite redirects already being in place. A 404 count that keeps climbing after a redirect import is almost never a redirect problem. It means something on the live site is still manufacturing the dead links.

Solution

We threw out the existing map and rebuilt it from the source. We exported every 404 Google held on file, pulled a fresh inventory of live URLs, and matched one against the other. That produced 177 dead URLs, and they were not one problem repeated. They sorted into 17 distinct failure classes: trailing-slash duplicates of pages that were live without the slash, orphaned taxonomy paths left behind by the previous CMS, retired blog posts, page-template URLs that had leaked into the index, an abandoned city URL scheme, pagination, asset paths, and a handful that were genuinely gone with nothing equivalent to point at.

Every proposed mapping was scored high, medium or low confidence, 105 / 67 / 5, so the client could see which ones were mechanical and which were a judgment call about the nearest relevant page. Twenty-three of the URLs Google was reporting as broken were in fact live, which is worth knowing before anyone writes a rule for them. The ones with no honest destination were left to return a proper 404 rather than being pointed at the homepage, which is the shortcut that converts a clean error into a soft 404 and loses the equity anyway.

Two further passes did the real work. First, we HEAD-checked every destination on the live site after import, because a redirect map is only as good as its targets, and several targets had themselves been renamed at some point. Second, we crawled the site backwards to find the pages still linking to dead URLs, which is what had been regenerating the 404s all along: 42 internal links pointing at hard 404s, and another 64 pointing at URLs that only resolved through a redirect, quietly building two-hop chains inside the client's own content. Each came back as a fix list with a direct editor link.

We also found that the platform's blog engine served its own path space ahead of its redirect engine, so 93 mirror rules had to be written for the /blog/ prefix or those redirects would never have fired at all. That is in no documentation anywhere. You find it by testing.

Result

Of the 177 URLs, 167 now resolve to a live page, 157 by redirect and 10 that had recovered on their own. Two return a deliberate 404. The validation loop is what earned that number: the first pass left 11 redirects pointing at destinations that were themselves dead, the second left 7, the third left 3. Nobody catches those by reading the import file.