Somebody out there is still linking to a blog post you deleted years ago. Every reader who clicks that link lands on your 404 page, and any value the link could pass to your site goes nowhere.
I work on Jogos do Rei, a Brazilian online card game platform (Buraco, Tranca, Truco and others) that has been running since 2010. The blog is nearly as old. It started on Blogger, moved to WordPress, and changed its permalink structure more than once, so there are a lot of dead URLs behind it.
On September 28 I spent a day finding the dead URLs that still mattered and giving them proper 301s. Along the way I found a CSS bug that caused a 404 on every page view. This post covers what I did, how I checked it, and what I left alone on purpose.
Your sitemap only lists live URLs. To get the historical list, the Wayback Machine's CDX API is the cheapest option:
For our domain this returned 40,005 URLs. After I dropped assets, search pages, API calls, player profiles and querystring variants, 2,862 candidate pages were left. I requested the 1,580 on the main and blog hosts with curl -L (nearly all of the other 1,282 sit on retired subdomains that no longer resolve in DNS). 473 returned 200 (directly or through an existing redirect) and 1,107 returned 404.
Most of those 1,107 don't deserve a redirect. The next step was finding the ones that do.
The Wayback Machine shows what existed, not who links to it. I used three sources: External links. The Common Crawl web graph lists linking domains, not pages. It showed a few dozen domains linking to us in its 2026 releases. For each one, I looked for the specific page with the link and then checked the status of the exact href. The 404 log. The redirect plugin keeps a week of 404s. I dropped bots, my own requests and security probes, then read the referrers. History. Wayback capture counts are a rough popularity signal. One old Truco rules URL had 47 captures.
That gave me a short list. Two third-party pages, a Brazilian games blog and a card-game publisher's blog, linked to posts that now return 404. Eleven Tranca strategy posts now had a different date in their permalinks, with the same slug. In our case WordPress kept no record of the old date, so the old URLs weren't redirected and readers following old links got a 404. The rest were old URLs that kept appearing in the 404 log or had a strong Wayback history.
This approach has gaps. Common Crawl is a sample and misses real links. Search Console's URL Inspection reported the dead URL I knew had an external link as "URL is unknown to Google". I don't claim I found every link.
Don't send every dead URL to the home page. Google tends to treat an off-topic redirect as a soft 404, and the reader doesn't get the article they clicked for.
My rule was to redirect only when a live page covers the same topic: The old "history of Buraco" post that a games blog still links to → the current history of Buraco article. The 11 Tranca posts → the same slug with its current date, a clean 1:1 mapping. Old Truco rules posts → the Truco rules page. An old password-recovery post → the support page.
I fetched every destination live (200, no hop) and checked the of the topic-matched ones.
Here's what I skipped: posts with no live equivalent (crosswords, 2011–2012 announcements, monthly ranking posts), about 270 Blogger-era URLs and about 130 old archive and tag pages that had no external links, and one legacy URL that the web server rejects before WordPress ever sees it.
That regex creates a loop. WordPress already redirects /blog// to the current dated URL. The regex would also match the live dated URLs and send them to the undated form, and WordPress would send them straight back.
So every rule is an exact match, one per URL. They're all 301s, they ignore the querystring when matching (so ?utmsource=... still matches) and they match with or without a trailing slash. All of them share one title, which makes rollback easy.
The precheck asked three questions about each rule: Does the source return 404 both with and without the slash? If not, something else is already handling it. Does the destination return 200 with no hop? If not, the new rule would create a redirect chain. Is the destination also a source? If so, it's a loop.
I created one rule, the history-of-Buraco redirect, as a canary and verified it end to end. After that, a script created the rest one at a time through the plugin's REST API. It refused to run if a precondition failed. After each rule, it tested three variants:
The script also recorded the x-redirect-by header to show whether the plugin answered or something upstream did, and every result went to a JSONL log.