Category: SEO

A client calls because the site will not load. The browser shows a “too many redirects” error and says the page redirected too many times. Nothing was deployed, nobody touched the theme, and it worked yesterday.

Three weeks later the same site is fine. Every page loads, nobody is calling, and one URL is taking three hops before it reaches the page. Nobody will ever call about that one.

Same underlying fault, two very different experiences. One is an outage with a loud alarm. The other is a quiet detour that only shows up if you go looking.

Short answer: a loop is a redirect sequence with no end, so the browser gives up. A chain is a sequence that does end, just not on the first hop. Both are diagnosed the same way: request the URL from outside with redirects turned off, follow each hop by hand, and record the status code and the Location header at every step. The hop where the destination stops making sense is the layer that is misconfigured.

What this post is, and is not: this is an outside-in tracing method you can run against any URL you are allowed to test, plus the three configuration conflicts that cause most loops. It is not a guide to any one CDN’s rule screen, and it does not measure what a chain costs in rankings or load time, because that cannot be read from one site.

A Loop And A Chain Are The Same Bug

Both start the same way: more than one thing on the request path believes it is responsible for deciding the canonical URL.

A chain happens when each of those things makes a different but compatible decision. The server upgrades to HTTPS. WordPress adds the www. A redirect plugin maps the old slug to the new one. Each hop is individually correct, and the visitor still arrives at the right page after several round trips.

A loop happens when two of those decisions point in opposite directions. The server sends www to the bare domain. WordPress, whose siteurl option still has www in it, sends it back. Neither is wrong on its own. Together they never end, and the browser stops after its own limit and shows an error.

You do not need two diagnostic routines. The same trace finds both. For what a chain does to a link audit, and why a clean 200 can hide it, see why a 404 is the easy half of a link check. This post stays on finding the hop.

Trace Every Hop From Outside

The whole diagnosis is one habit: stop letting your tools follow redirects for you.

A browser follows the chain silently and shows you the final page. A checker that reports “200 OK” has already walked every hop and thrown the evidence away. You want the hops, one at a time.

Request the URL with redirect following off, and record four things for each hop:

1. The URL you requested.
2. The status code that came back.
3. The exact Location header, including protocol, host, path and query string.
4. Whether the Location is absolute or relative.

With curl, a header-only request does not follow redirects by default:

curl -sI http://example.com/path

Then request the Location value and repeat, until you reach a non-redirect status or a URL you have already recorded. A repeat is the definition of a loop, and the URL that repeats tells you where the cycle closes. To let curl do the walking and stop it from running forever, cap the hops and print the count:

curl -sIL --max-redirs 10 -o /dev/null -w '%{num_redirects} %{url_effective}n' http://example.com/path

If the cap is hit, curl reports that the maximum number of redirects was followed, which is a loop. Use this only on URLs you are authorised to test.

Run the trace against four variants of the same page, because the variants are where the disagreements live:

• http://example.com/path
• http://www.example.com/path
• https://example.com/path
• https://www.example.com/path

A healthy result is that every variant reaches the canonical URL in one hop, or two when both the protocol and the host have to change. Three or more hops from any starting point means something is doing the same job twice.

Capture the status code at each hop as well. A 301 and a 302 are both redirects, but they say different things about intent, and a chain that mixes them was probably assembled by more than one person. MDN’s page on 301 Moved Permanently and 302 Found is the quickest way to check what each one promises.

The Three Usual Culprits

Most loops and many long chains come from one of three conflicts. Check them in this order.

The first is the classic loop. Four combinations of protocol and host exist. Three of them must redirect to the fourth, and that rule should live in one place. WordPress keeps its own opinion in the siteurl and home settings, and its redirect_canonical() function redirects requests toward that address. If the server holds a different opinion about the canonical host, the request bounces between the two. The WordPress documentation on changing the site URL explains the settings, and the wp-config reference covers the WP_HOME and WP_SITEURL constants that can override them.

The second is the classic chain. A redirect plugin maps /old-page to /new-page, and the server separately enforces a trailing slash, so the visitor goes to /new-page and then to /new-page/. Both rules are right. Together they add a hop to every request that path ever gets.

The third is the one that wastes an afternoon, because the trace shows a hop that exists nowhere you can read on the server. A CDN rule runs before the request reaches your origin, so it is invisible from inside. Cloudflare documents one well-known version: an SSL mode that makes the CDN talk to the origin over plain HTTP while the origin insists on HTTPS, which loops. Its guide to too many redirects errors is the reference. The way to see it is to compare a request made through the CDN with a request made straight to the origin. If the hop appears in one and not the other, you have found the layer.

A redirect can also be cached. That means a rule you already removed may still be served to some visitors from somewhere. The WordPress page cache header lies explains why the header you would check to confirm a cached response is not conclusive on its own, so test with a cache-busting request before you declare it fixed.

Watch Out For Browser Memory

One thing breaks the method quietly. Browsers remember some redirects, especially permanent ones, and a browser that remembers a 301 will skip the hop you are trying to observe.

So trace with curl or another client that keeps no memory, or use a private window and clear site data between attempts. If the browser still shows a loop while curl shows a clean path, the difference is stored on the visitor’s side: a cached redirect or a cookie. That is a useful finding on its own, because it explains why one person sees the loop and the next does not.

Two Outside Views

A tutorial and a forum thread. Neither is an endorsement.

Guides by Leonard’s tutorial on the WordPress too many redirects error goes through a short checklist: clear the browser cache and cookies, clear the CDN cache, make sure the WordPress Address and Site Address settings match and use the same protocol, deactivate plugins one by one, regenerate the .htaccess file by re-saving permalinks, and use an online redirect checker to see the path. It is a good first pass. It can clear a loop, and it does not say which layer caused it, which is what the trace in this post is for.

A beginner tutorial on the WordPress too many redirects error: clear caches, match the two URL settings, test plugins, regenerate .htaccess, then check the redirect path with a tool.

Guides by Leonard, “Fix WordPress Error Too Many Redirects (2026 Easy Guide)” on YouTube, 21 Feb 2026

On Reddit, an r/Wordpress thread describes a wp-admin redirect loop after login while the front end still loads normally. The replies were not available for this post, so it does not summarise them. The title is a useful reminder that a loop can sit on one path only, such as the login, which is why a trace should cover more than the homepage.

“WordPress wp-admin infinite redirect loop after login while frontend still works normally”

r/Wordpress, “WordPress wp-admin infinite redirect loop after login while frontend still works normally”

Fixing It Without Creating The Next One

Once you know which layer is adding the hop, the repair is short. Keeping it fixed is harder.

Decide the canonical form once and write it down. Protocol, host and trailing slash, in one line of the site’s documentation. Most of these faults exist because two people made the same reasonable decision in two places six months apart.

Enforce it in exactly one layer. Server rule, or CDN rule, or WordPress. Not two, and never a split where each handles part of the decision. The split works right up until one side is edited.

Point old rules at the final destination. When /a redirects to /b and /b later moves to /c, update the first rule to point at /c. Adding a second rule is faster today and is how long chains are born.

Re-trace after every change. The fix is not “the rule was edited”. The fix is “the four variants now resolve in one hop”, and only the trace proves it.

Take a restore point before you touch rewrite rules on a live site, because a bad rule can lock you out of the admin as well as the front end. If you have a staging copy, test the change there first, and remember that staging drifts from live in exactly the settings that matter here: the site URL, the CDN and the cache.

What Tracing Redirects Does Not Solve

A clean redirect map is real work with a real payoff. It is also a narrow fix, and claiming more for it is how these audits lose credibility with clients.

A trace cannot tell you whether:

• the destination is a good answer to the request, since a 301 to a loosely related page is technically clean and useless to the visitor;
• rankings changed because of it, because too many things move at once on a live site to credit one change;
• a crawler has re-processed the new path yet, as that happens on a schedule you do not control;
• every rule in the list is still needed, because a rule for a URL nobody has asked for in years still costs evaluation time; or
• the page at the end of the chain is reachable from anywhere a visitor would actually start.

The broader limit: a trace tells you what happens to a URL you already know about. It cannot find the URLs you have not thought to test. Finding those means crawling the site and tracing what the crawl turns up, which is the routine in the WordPress crawl audit on our own site. Redirects also belong next to the other checks, as in the technical SEO audit playbook post, rather than being scored on their own. If the redirects you are chasing started as 404s, which 404s actually cost you covers deciding what deserves a redirect in the first place.

Sources And Further Reading

• Google Search Central: Redirects and Google Search
• MDN: Redirections in HTTP
• Cloudflare docs: Too many redirects
• WordPress.org: Changing the site URL
• WordPress developer reference: redirect_canonical()
• Fix WordPress Error Too Many Redirects (2026 Easy Guide): Guides by Leonard on YouTube, 21 February 2026.
• WordPress wp-admin infinite redirect loop after login while frontend still works normally: an r/Wordpress thread.

For the wider review this belongs to, see the playbooks page.

Do You Know How Many Hops Your Sites Take?

Every site you run has a canonical form, and most of them enforce it in more than one place, quietly, on every request.

Pick five sites. Trace the four variants of the homepage and two inner URLs on each. Write down the hop count and the longest chain. It takes an afternoon, and the results tend to be worse than anyone expects.

So, across the sites in your care: do you know which ones take an extra hop on every request, or only the ones where it got bad enough that somebody phoned you?

Short answer: wordpress open graph tags decide what appears when somebody shares a page in Slack, LinkedIn, WhatsApp or anywhere else. When they break, nothing on the site errors, nothing in the dashboard complains, and the first person to notice is your client posting their own campaign page.

That last part is why I treat this as a client-facing check rather than an SEO nicety.

What good looks like

2400×1260 are both the 1.91:1 ratio the major platforms crop to.*

Caveat: four sites, ours and three reference points. Not a claim about typical adoption, a calibration of what “good” looks like on sites we could verify directly.

Declaring og:image:width and og:image:height is the small win most sites skip. It lets a platform reserve the right space before the image downloads, which is why some previews render cleanly and others jump.

The six ways it breaks

the preview for a URL, so a correct fix appears to do nothing until you force a re-scrape.*

The duplicate-tag case is the most common one I find on WordPress specifically. An SEO plugin emits og:title, then a theme or a social plugin emits another. Platforms pick one, not always yours, and the site looks completely fine.

Check for duplicates explicitly:

curl -s https://example.com/ | grep -oiE 'property="og:title"' | wc -l

Anything other than 1 is a finding, and it is worth running against your own template library specifically, since duplicates almost always trace back to two plugins both left active from an old migration rather than anything a single developer would knowingly ship.

Checking WordPress Open Graph tags properly

or at an image behind a rule that blocks unknown user agents, produces a blank preview and no error on the site.*

That firewall case is worth calling out. Social crawlers are not browsers and do not carry a normal user agent. A security rule that blocks unrecognised agents will block the preview crawler too, and the page will look perfect to you and blank to everybody sharing it.

The failure mode nobody lists, because it only exists for a few minutes

While writing this post I found a seventh failure that belongs next to the six above, and it is specific to a site architecture more agencies are shipping now: a headless frontend that renders pages on demand and caches the result, exactly the kind the crawl audit post warned catches you out mid-crawl.

I published a post to protuno.com and checked its Open Graph tags within minutes:

curl -s -o /dev/null -w '%{http_code}n' https://protuno.com/blog/wordpress-sitemap-audit
curl -s https://protuno.com/blog/wordpress-sitemap-audit | grep -oE 'property="og:title"[^>]*'

404
<meta property="og:title" content="Protuno · Super Agents For WordPress Automation"/>

The page had not finished its first render, so the frontend answered 404, and a 404 still carries a full, valid set of Open Graph tags: the site’s tags, not the post’s. Title, description and image all point at the homepage. None of that is a bug in the ordinary sense. It is the site’s fallback behaving correctly for a page that does not exist yet from the frontend’s point of view, even though the content is live in the CMS.

The consequence is narrow but real: share that URL in the first few minutes after publishing, before the frontend has rendered and cached it, and the preview card shows your homepage’s title and image instead of the post’s. Miss that window and the exact same link, pasted a few minutes later, produces the correct preview. I confirmed it by checking the same URL again a few minutes after the first request and watching the response settle.

The practical rule this adds to the checklist above: on a headless or ISR-backed WordPress frontend, do not share the URL the moment you hit publish. Wait for the page to return 200 first, exactly the same wait the crawl-audit post recommends before trusting a fresh URL’s status code at all, and the two checks are worth running together since they are testing the same underlying render-and-cache gap from two different angles.

Verifying the pixels, not just the declared numbers

og:image:width and og:image:height are declarations. Nothing forces the number in the tag to match the file it points at, so I downloaded the image and checked.

curl -s -o og.png https://protuno.com/og.png
file og.png

og.png: PNG image data, 1200 x 630, 8-bit/color RGB, non-interlaced

Declared 1200 by 630, actual file 1200 by 630, 72KB on disk. That is not a given. A resized template, an image swapped out without updating the meta tags, or a CDN that serves a different crop at the same URL would all produce a mismatch here while the tag itself still validates as well-formed markup. The file command, or identify from ImageMagick if it is installed, takes the same few seconds as any of the other checks in this post and catches a class of error none of them do: the tag was telling the truth about a file that no longer matches it.

Twitter reads its own tags first, and falls back quietly when they are missing

Everything so far has been Open Graph, the og: prefix Facebook originated and most platforms now read. X, still branded twitter: in its own meta tag namespace, is not required to use those tags at all. It defines a parallel set, twitter:card, twitter:title, twitter:description, twitter:image, and reads those first when they exist.

curl -s https://protuno.com/blog/wordpress-robots-txt-blocking | grep -oE '<meta[^>]*name="twitter:[^"]*"[^>]*>'

<meta name="twitter:card" content="summary_large_image"/>
<meta name="twitter:title" content="Discourage Search Engines WordPress: What It Really Does"/>
<meta name="twitter:description" content="Discourage search engines does not add Disallow slash to robots.txt..."/>
<meta name="twitter:image" content="https://protuno.com/blog/media/2026/09/wordpress-robots-txt-blocking-2.png"/>

Ours declares all four explicitly, which is the safer of two valid approaches. The card falls back to the matching og: tag for anything left undeclared, twitter:title to og:title, twitter:image to og:image, and the specification documents that fallback as intentional rather than an error state. A site that only ships Open Graph tags and no twitter: block at all is not necessarily broken on X. It is trusting a fallback path instead of testing it.

The distinction is worth a minute of checking rather than assuming, because the fallback applies per field, not as an all-or-nothing switch. A site that declares og:title and og:image but a bare twitter:card with no twitter:image, a pattern I have seen on WordPress installs where a theme hardcodes the card type and a separate SEO plugin handles everything else, still gets a working preview through the fallback. The one worth actually watching for is a mismatched image ratio between the two: og:image sized for the 1.91:1 ratio most link previews use, alongside an explicit twitter:image pointing at something square or portrait left over from an older template, produces a preview that looks fine on LinkedIn and cropped strangely on X, because the platform found its own tag and used it instead of falling back to the one you actually tested.

Testing the firewall case directly, rather than trusting it is fine

The six-failure table earlier names a WAF or security rule blocking preview crawlers as a cause, without proof it applies to any site in particular. Proof is one curl flag away, so I ran it against our own site instead of leaving it as a theoretical risk.

for ua in "facebookexternalhit/1.1" "LinkedInBot/1.0" "Twitterbot/1.0" "Slackbot-LinkExpanding 1.0"; do
  curl -s -o /dev/null -w "%{http_code}  $uan" -A "$ua" https://protuno.com/blog/wordpress-robots-txt-blocking
done

All four pass cleanly on protuno.com today. That is not a universal result, it is one site’s answer to a question worth asking about every site you manage, particularly one sitting behind Cloudflare, a WAF appliance, or a security plugin with bot-blocking turned on. Those tools often ship a default rule list that treats any user agent it does not recognise as suspicious, and a preview crawler identifying itself honestly as LinkedInBot rather than pretending to be a browser is exactly the kind of request a strict allowlist can catch by accident.

Run the same four-line loop against a client site the next time a preview reports blank with no other explanation. If any of those four come back anything other than 200, or redirect to a challenge page, you have found the cause in under a minute, and it is a firewall misconfiguration rather than anything wrong with the Open Graph tags themselves. Checking the tags first and the firewall second, when the actual fault is the firewall, is how this specific failure ends up burning an afternoon that four curl commands would have closed immediately.

Where it fits

This belongs in the pre-launch pass and in the check after any migration, because both are where header and tag configuration quietly gets lost.

It also pairs with the indexing signals, since a page that tells search engines not to index it usually has an equally accidental story behind its social tags. Both are set once, forgotten, and invisible from the site itself.

And confirm the image is a sensible size while you are there. An og:image that happens to be a 794 KB PNG is downloaded by every platform that renders the preview.

Protuno’s free audit checks Open Graph tags from the domain alone, alongside the other things a crawler reads. Iris is live now.

Take the last campaign page a client asked you to build and paste it into a Slack message to yourself. That is the complete test, and it takes five seconds.

If it comes back blank or wrong, work the list in order: check the tags exist and are not duplicated, check the image resolves and matches its declared dimensions, check a preview crawler’s own user agent is not the thing being blocked, and only then blame the platform’s cache. Four checks, all of them a single curl command, and every one of them was tested on a real site while writing this post rather than described from memory.

Short answer: a wordpress sitemap not updating still returns 200 and still validates. The check is not whether it exists, it is whether its newest lastmod is more recent than your last publish, and whether the URLs inside it actually resolve.

What a healthy one looks like

is today rather than a date months in the past.*

That comparison is the entire health check. Newest lastmod against your most recent publish date. If the sitemap is older, something between WordPress and the served file has stopped.

Why a WordPress sitemap stops updating

problem; what it says is.*

The second row is the one I hit most often. Plenty of SEO plugins regenerate their sitemap on a scheduled event, so a site whose WP-Cron has stopped has a sitemap frozen at whatever date the scheduler died. The site publishes normally. The sitemap simply stops changing, and nothing anywhere reports it.

The third row is worth a specific check on any site with an SEO plugin installed. Core publishes /wp-sitemap.xml and most SEO plugins publish their own index. If both answer with different contents, you are sending search engines two contradictory maps.

The audit

actively asking search engines to crawl that does not return 200.*

Two things worth knowing about lastmod.

It should reflect when the content changed, not when the file was generated. Some setups stamp every entry with the build time, which makes every URL claim to have changed today and destroys the signal’s usefulness entirely.

And it is a hint, not an instruction. A correct lastmod helps a crawler prioritise; it does not compel anything. Sites that game it by touching every date achieve nothing except making their own diagnostics useless.

What should not be in it

A sitemap is a list of pages you want indexed. So it should not contain:

• URLs carrying a noindex, which is a direct contradiction and the same confusion behind

the discourage-search-engines setting

• Redirecting URLs, which waste crawl budget pointing at their own replacements
• Paginated archives and tag pages nobody intends to rank
• Anything disallowed in robots.txt, since a crawler cannot fetch it to read the sitemap’s advice

That last combination appears constantly on WordPress sites and is entirely self-inflicted.

The noindex row is not a hypothetical example picked for tidiness. It is the exact finding further down this post, caught on our own infrastructure rather than borrowed from somebody else’s audit: a sitemap that lists pages correctly marked not to be indexed, generated by a plugin doing exactly what it was configured to do, on a domain the sitemap check itself was never pointed at until writing this section made it worth checking.

I checked our own sitemap against the actual publishes of today

The freshness check earlier in this post is easy to state and easy to skip verifying, so I ran it against protuno.com’s own sitemap while several posts were being published today, rather than trust that the comparison works the way I described it.

curl -s https://protuno.com/sitemap-blog.xml | grep -o "<loc>[^<]*</loc>\|<lastmod>[^<]*</lastmod>"

Six posts republished within roughly twenty-two minutes of each other show six distinct lastmod timestamps, each within a minute or two of the actual edit, while a post nobody touched sits at a date ten days old. That is what a sitemap doing its job looks like: the timestamp tracks the edit, not the last time someone regenerated the file wholesale, and a stale entry stands out immediately next to fresh ones instead of blending in with a site-wide regeneration date that moves for every URL at once.

That last distinction is worth being specific about, because it is the difference between a useful lastmod and the meaningless kind described earlier in this post. If every URL in a sitemap shared the same timestamp, down to the second, that would be a signal the file was regenerated on a schedule rather than updated per edit, and it would tell a crawler nothing about which pages actually changed. Six different timestamps, each matching a real edit, is the opposite of that failure mode, confirmed on the file this post itself just caused to update.

The noindexed pages sitting in our own sitemap

The earlier section on what should not be in a sitemap names noindexed URLs first. I went looking for one on our own infrastructure rather than assume the rule only applies to other people’s sites, and found one within a few requests.

Protuno’s frontend at protuno.com is headless, served by Next.js, with its own sitemap system entirely separate from WordPress. The WordPress install behind it, at cms.protuno.com, is a second, independent web server, and it runs Rank Math, which generates its own sitemap the moment the plugin is active, whether or not anyone intends the CMS domain itself to be crawled:

curl -s https://cms.protuno.com/robots.txt
# Sitemap: https://cms.protuno.com/sitemap_index.xml

curl -s https://cms.protuno.com/sitemap_index.xml

That index lists a post-sitemap.xml containing 23 URLs, all on the cms.protuno.com domain rather than protuno.com, one per published post, plus the CMS homepage. I requested one of them directly:

Every individual page correctly declares noindex, nofollow, which is right: the CMS domain is infrastructure, not a page meant to rank, and the actual public copy lives at protuno.com/blog/.... But the sitemap listing those same URLs is not blocked, is not marked in any way as a duplicate, and carries no canonical tag pointing a crawler at the real, indexable version. It is, byte for byte, the exact contradiction named earlier in this post: a sitemap advertising URLs that explicitly ask not to be indexed, on a domain search engines can reach freely because nothing in robots.txt stops them from requesting the sitemap file itself.

The practical risk is narrower than it sounds, because noindex is respected on every one of those 23 pages individually, so none of them should actually enter a search index. What the finding shows is not “our content is at risk of appearing twice.” It is that a plugin turned on for one purpose, in this case Rank Math handling on-page SEO fields for the editorial team, ships a sitemap generator nobody asked for as a side effect, and that side effect produces the exact anti-pattern this post has been describing the whole way through, on infrastructure I did not think to check until writing this section. A Disallow on /sitemap_index.xml and /*-sitemap.xml in cms.protuno.com‘s robots.txt, or turning the sitemap module off entirely since the CMS domain is not the canonical source for anything, closes it. Neither has happened yet, so this is a finding, not a fix, exactly in the spirit of the still-open items in the crawl audit post.

The check worth taking away, if a site of yours runs a similar headless setup: the sitemap to audit is not only the one your visitors’ browsers ever see. Any WordPress SEO plugin running on a backend that a frontend has replaced is still generating its own sitemap unless someone has explicitly told it to stop, and that sitemap answers requests on its own domain whether or not anyone remembers it exists.

The sitemap file itself can be cached, on top of everything above

One more layer worth checking, because it interacts with the freshness comparison rather than replacing it: the sitemap XML file is itself a URL, and a URL can sit behind a CDN like any other page.

curl -sI https://protuno.com/sitemap-blog.xml | grep -iE "cache-control|cf-cache-status"

cache-control: public, max-age=0, s-maxage=3600, stale-while-revalidate=86400
cf-cache-status: DYNAMIC

The header declares up to an hour of edge caching, s-maxage=3600. DYNAMIC on this particular request means Cloudflare answered from the origin rather than a cached copy, which is why the lastmod values in the earlier table lined up with the actual edit times to within a minute or two rather than lagging by up to an hour. Had that request come back HIT instead, the freshness comparison earlier in this post would still run and still look sensible, just against whatever snapshot of the file the edge happened to be holding, which could be anywhere up to an hour stale relative to the newest publish.

This is the same gap the page cache header post describes for ordinary pages, applied to one specific URL that happens to be your sitemap rather than a landing page: a passing signal on its own, 200 and well-formed XML, sitting on top of a caching layer that can silently be serving something older than what WordPress or your frontend actually generated most recently. Checking cf-cache-status or the equivalent header on the sitemap URL itself, alongside the lastmod comparison, is the difference between trusting a number and trusting a number you have confirmed was not served from an hour-old edge copy.

Where it fits

Sitemaps are a low-effort, low-drama check that fails silently and gets audited once at launch. The failure is invisible because the file is still there and still valid, which is the same category as a caching plugin that caches nothing.

Protuno’s free audit checks whether a sitemap is published and reachable from the domain alone, alongside robots.txt and the other crawl signals. Iris is live now.

Run command two on the client site that publishes most often. If the newest lastmod is older than their last post, you have found something worth an hour.

Then run the same three commands against whatever sits behind the site you can see, if there is one: a headless backend, a staging copy, a subdomain nobody remembers is still live. The finding earlier in this post did not turn up on the domain anyone actually visits. It turned up on the one nobody thought to check.

Reading the report that the checks in this post feed into

A sitemap that is fresh and correct is only useful once Google actually indexes what it points to. This walks through the Search Console report that tells you whether that happened.

Short answer: a wordpress broken link checker that only looks for 404s finds the least interesting failure. Soft 404s return 200, redirect chains return 200, and a page whose entire content has since changed still returns 200. All three break the reader’s experience and none of them appear in a status-code report.

Starting with our own work

Before ever auditing anybody else’s site I checked mine first, carefully.

every time. It is that a citation which quietly 404s makes every other claim on the page harder to believe.*

That matters more on a blog like this one than on a brochure site. Every post here leans on primary sources, and a dead citation is a claim the reader cannot verify.

Extending the check to every citation across this blog, not just three posts

The original check covered three posts and seventeen links. I extended it while expanding this post, pulling every genuine external citation from every post published so far, not the placeholder example.com URLs used inside code samples, and checking each one the same way: status, redirect count, and byte size together.

grep -ohE "https?://[a-zA-Z0-9./_?=#-]+" posts/*.md | grep -v "protuno.com|example.com"
for url in $(cat citations.txt); do
  curl -s -o /dev/null -w '%{http_code} redirects:%{num_redirects} size:%{size_download}n' -L "$url"
done

Twelve genuine citations across a different, later set of posts than the original check: Action Scheduler’s own admin and FAQ pages, two developer.wordpress.org cron references, the Content Signals and llms.txt specification pages, a WordPress core AI-team page, the Patchstack whitepaper this blog cites for its removed-plugin statistic, a survey page, a WordPress.tv talk, PHP’s own supported-versions page, and one YouTube video. All twelve returned 200, zero redirect hops, plausible byte sizes matching real content rather than a small styled error page.

Combined with the original seventeen, that is twenty-nine real citations checked across this blog’s own published output, all clean. Worth stating precisely what that does and does not prove: it is not evidence that link rot is rare in general, twenty-nine links checked days to weeks after publication is far too soon for the kind of drift this post describes to have had time to happen. It is evidence that the citation discipline this blog has tried to hold itself to, quoting the specific claim relied on rather than a bare link, linking to stable specification and documentation pages rather than a blog post likely to be rewritten, has not yet produced a single broken reference. Whether that holds up in a year is exactly the kind of thing worth re-checking again, on a schedule, rather than assuming from a clean result today.

The three failures a 404 check misses

found” served with a success status is invisible to a status-code check.*

I hit a live example of the soft 404 while researching a different post. Checking several sites for an llms.txt file, four returned 200 with bodies of 399 KB, 146 KB and similar. Those were not files. They were the sites’ normal HTML error pages, served with a success status.

The lesson generalises: read the status, the size and the content type together. Any one of them alone will tell you something confidently wrong.

The fourth row deserves honesty too. No tool can tell you that a URL you cited two years ago now points at a rewritten page saying something different. That is a human job, and the practical mitigation is to quote the specific sentence you relied on, so a reader can tell whether the source still says it.

The soft-404 example in this post no longer reproduces, and that is worth saying

This post’s own soft-404 illustration comes from checking several sites for an llms.txt file and finding styled HTML error pages served with 200. I re-ran that specific check against the same category of site while expanding this post, and it no longer reproduces the same way.

curl -s -D - -o /dev/null https://siteb.example/llms.txt | grep -i content-type
curl -s -D - -o /dev/null https://sitec.example/llms.txt | grep -i content-type
curl -sI https://woocommerce.com/llms.txt | grep -i location

content-type: text/plain; charset=utf-8      (siteb.example, 120,105 bytes)
content-type: text/plain; charset=utf-8      (sitec.example, 212,742 bytes)
location: https://woocommerce.com/wp-content/uploads/llms.txt   (301, then a real 10,148-byte file)

All three sites now serve genuine text/plain content at that path, woocommerce.com via a correct 301 redirect to the actual file rather than a soft 200. Whatever produced the styled error pages this post originally caught, most likely the file simply not existing yet on sites that had not adopted the format when this post first checked, has been resolved, and llms.txt adoption itself has clearly moved forward in the meantime.

That is a genuinely good outcome, and it belongs in this post for the same reason every other re-check on this blog reports both directions: a soft-404 example that quietly stopped being true would otherwise sit in a published post indefinitely, describing a problem that no longer exists as though it still does. The mechanism this post teaches, checking content-type and size alongside the status code, is exactly what caught both the original finding and its later resolution, which is the strongest argument this post can make for running the check again rather than trusting either a stale finding or a stale all-clear.

Redirect chains

http://protuno.com and http://www.protuno.com both reach the canonical HTTPS URL in a single hop, which is what you want.*

One hop is correct and unavoidable: HTTP to HTTPS, or www to apex. Two or more means somebody added a rule without checking what already existed, usually during a migration.

Chains are worth fixing not because they break anything but because each hop is a round trip the visitor waits through, and because the chain tends to grow. Three hops today becomes five after the next redesign.

Running a WordPress broken link checker across a portfolio

Internal links and external links are different jobs.

Internal links are your responsibility and should never break, because you control both ends. A crawl finds them, and it is how I found a 404 linked from every page of our own site.

External links rot on somebody else’s schedule. A quarterly pass is enough for most sites, and the highest-value target is your most-trafficked content rather than everything.

row is why the 404 on our own site mattered more than usual: it sat in the footer, so one broken link appeared on every page at once.*

Two practical notes. Rate-limit the checker, or you will get blocked and record false failures on perfectly healthy sites. And send a real user agent, because plenty of hosts refuse unknown ones, which produces the same false result.

That second point is worth taking seriously: a link checker that reports failures on sites that are actually fine is the same false-positive problem as an alt-text audit counting lazy-load placeholders. A report full of noise is a report nobody reads, and then the real finding arrives and is ignored with the rest.

The one that costs money

There is a category of broken link that deserves separate treatment, and it rarely appears in an SEO report because it is not on a page at all.

Links inside transactional email. The order confirmation pointing at a tracking page that moved. The password reset URL built from a stale site address. The invoice link to a document store that was migrated. These break exactly like page links and nobody crawls them, because they live in templates rather than in HTML anybody visits.

The check is manual and worth doing once per client: trigger each transactional email on a staging copy and click every link in it. On a store that is the order confirmation, the shipping notification and the password reset at minimum. It takes half an hour and it is the only way these are ever found, short of a customer reporting one.

The same reasoning applies to anything a form sends after submission: the reply nobody reads is also the reply nobody has checked the links in.

What to do about a broken link

Fix, redirect, or remove, in that order of preference.

If the target moved, update the link. If it is gone but the point still stands, find an equivalent source rather than deleting the sentence. If neither is possible, remove the link and keep the claim only if you can support it another way.

What not to do is leave it. A broken link in an old post is a small thing; a page full of them tells a reader the content is unmaintained, which is a judgement about everything else on the site too.

Protuno’s free audit checks the crawl-visible link health of a site from the domain alone. Iris is live now.

One habit that removes most of this work permanently: link to canonical, stable URLs in the first place. A link to a documentation homepage outlives a link to a specific anchored heading on it. A link to a specification outlives a link to somebody’s summary of the specification. You cannot stop the web from changing, but you can choose the targets least likely to move.

Run the loop above on your three most valuable pages. Not the whole site, just the three that earn money. That is twenty minutes and it covers the links that actually matter.

Then run it again next quarter, on the same pages, and compare the result to this one rather than treating either a clean pass or a finding as the final word. Link rot and its opposite, a broken destination quietly getting fixed, both happen on somebody else’s schedule, and the only way to know which direction a given page has moved is to have checked it more than once.

The same check, walked through end to end

A recent, practical run-through of finding and fixing broken links, covering the same ground as the loop above from the SEO-impact side rather than the raw HTTP-status side.

Short answer: an orphan page exists on the site and has zero internal links pointing at it. Finding them for orphan pages seo work needs two separate sources, a page inventory and a crawl, because a crawl by definition cannot report a page it never reached.

What the distribution actually looks like

I crawled our own site and counted every single internal link pointing at every page.

with a single inbound link.*

Caveat: one site, one crawl, one day. The distribution shape (a handful of huge numbers, a long tail near one) is a general pattern of site link graphs, not a claim about what your own numbers will be. Run the crawl on your own site rather than assume this one transfers.

That kind of distribution is entirely normal and it is far more useful than a binary orphan check. Header and footer links produce genuinely enormous counts. Content pages sit somewhere in the middle. And a small tail of pages are reachable from exactly one place.

A page with one inbound link is one navigation change away from being an orphan, and nothing will tell you when that happens. On our site, the signup page is in that tail, which is worth knowing given what it is for.

Re-crawling turned up the exact trap this post warns about, from the crawl tool itself

I ran a fresh crawl of protuno.com while expanding this post and asked the tool’s own orphan-detection feature for its summary before reading anything else. It reported 194 of 209 pages as orphans, every single page except fifteen.

That is not a plausible number for a working site with real internal navigation, and reading the same crawl’s raw per-page data rather than trusting the summary confirmed why:

pages = {p['url']: p for p in export['pages']}
for u in ['/blog', '/contact', '/privacy', '/blog/llms-txt-wordpress']:
    print(u, len(pages[u]['linked_from']))

Every one of them has real, recorded inbound links sitting in the same crawl’s own raw data. The orphan-detection summary and the underlying link graph disagreed with each other inside a single crawl run, and the raw data was the one telling the truth, exactly the same failure this blog already documented on a different crawl of this same site months earlier. Finding it again, independently, on a fresh crawl ID, is stronger evidence than the original catch alone: this is not a one-off fluke in the tool’s summary logic, it is a repeatable characteristic of how it aggregates orphan status, and anyone using this tool’s own orphan report as the final word would be told, wrongly, that this site’s navigation is almost entirely broken.

The only page in the flagged list that is a genuine orphan by the raw data is the homepage itself, linked_from: 0, which is the expected, harmless seed-URL convention: a crawl starting at a URL does not count arriving there as a followed link. Every other name on that 194-page list is a false positive, caught by doing exactly what this post’s own two-source method already argues for, not trusting a single automated summary as the final answer.

What orphan pages actually cost, in SEO terms and otherwise

unambiguously true. The ranking arguments are real but softer, and overstating them is how SEO advice loses credibility.*

I want to be careful here, because orphan pages get oversold. A page in your sitemap will usually be crawled and can rank perfectly well with no internal links at all.

The honest problem is simpler and worse: somebody wrote that page, and no visitor browsing the site can reach it. That is a wasted asset regardless of what any search engine does.

The single-link page named as fragile is still exactly that

This post’s opening table flags /auth/signup specifically: one inbound link, for a commercially important page, one navigation change away from becoming an orphan outright. The fresh crawl’s raw data shows it sitting at exactly the same count, still one, unchanged since the original reading.

That is worth taking as confirmation rather than a non-event. A page flagged as fragile that is still exactly as fragile months later means nobody has acted on the original finding, and it also means nothing has accidentally made it worse in the meantime, which is its own small piece of good news. /auth/login, the equivalent page in the signup flow, moved only slightly, 40 to 42 inbound links, essentially stable. /contact moved considerably more, from 48 down to 6, which is worth investigating rather than reading as decline on its face: a real drop that large usually traces to a specific structural change, a footer redesign, a navigation simplification, or a template that used to link to it from every post and no longer does, and finding out which is exactly the kind of question this post’s two-source method is built to answer rather than leave as a number that moved for unknown reasons.

Finding them without fooling yourself

are trying to measure. The inventory has to come from somewhere else.*

Two mistakes make this check useless.

Taking the inventory from the crawl. If you only know about pages the crawl reached, every orphan is invisible by construction. Use the sitemap, or a database export of published URLs.

Crawling while logged in. Admin navigation, draft previews and role-specific menus all appear, so pages look linked when no visitor can see the link. Crawl with no cookies, as a stranger would.

What to do with the list

Not every orphan should be fixed. Three outcomes, and two of them are not “add a link”.

Link to it, if the page still earns its place. From a relevant page in the same cluster, with an anchor that describes the destination rather than saying “click here”.

Redirect it, if it has been superseded. An old service page that a newer one replaced should point at the replacement rather than sitting in the sitemap competing with it.

Remove it, if it should not exist. Test pages, duplicate landing pages from an old campaign, a staging artefact that got published. Deleting these is a genuine improvement, and it is the outcome people resist because deleting feels like loss.

is a signal of navigation, not of importance, and it buries the pages that genuinely deserve prominence.*

Whichever you choose, keep the sitemap honest afterwards. A redirected or deleted URL that stays in the sitemap is exactly the contradiction that makes a sitemap useless.

The WordPress-specific sources

Four things generate orphans on WordPress specifically, and knowing them shortens the investigation.

Retired taxonomies. Delete a category and its posts survive, but the archive that linked them disappears. If those posts were only reachable through that archive, they are now orphaned.

Page builder templates. A template that generated a listing or a loop can be replaced during a redesign, taking a whole set of internal links with it while every target page remains published.

Attachment pages. WordPress creates a page per uploaded media item by default. They are almost never linked, almost never useful, and they can quietly form the largest group in an orphan report. Disabling them is usually the right call.

Old campaign landing pages. Published outside the navigation on purpose, linked only from an ad that stopped running two years ago. Technically orphans, and often genuinely finished work that somebody should decide about.

That last group is the reason to review an orphan list with the client rather than acting on it alone. Some of those pages exist deliberately.

Why this drifts

Orphans are almost always created by a change somewhere else. A navigation redesign drops a menu item. A category is retired. A plugin that generated a listing page is removed. In every case the page survives and its only route in does not.

So this is not a one-time audit. It is a check to run after every navigation or template change, and it is the same class of quiet, structural drift as a link that starts 404ing on every page at once.

Protuno’s free audit reads the sitemap and the crawl-visible structure of a site from the domain alone. Iris is live now.

There is a related check worth running in the same pass, and it finds more on most sites than the orphan list does: pages with exactly one inbound link. They are not orphans today and they are the population that becomes orphaned next. Sorting the crawl output by inbound count ascending gives you both lists at once, and the second one is where you can act before there is a problem rather than after.

Run the two-source diff on your largest client site. The list is usually short, and about half of it is content somebody forgot they had. That half is the return on the exercise: pages already written, already paid for, and one internal link away from being useful again.

The content that survives but stops earning its place

An orphan page has lost every internal link. Decayed content is the earlier stage of the same problem: still linked, still crawlable, quietly losing relevance while nobody notices until the traffic is already gone.