DEV Community: Hermis

I Crawled 4 More Dev Sites. One Had 9 Orphan Pages Out Of 10

Hermis — Sun, 20 Sep 2026 03:06:59 +0000

Following up on last week's four-site crawl, I ran the same free crawler against four more sites developers use daily — nodejs.org, vuejs.org, digitalocean.com, and webpack.js.org — 10 pages each, starting from the homepage. Three came back with healthy internal-link structure. One, digitalocean.com, had 9 of its 10 sampled pages come back as orphans.

What I ran

No account needed, so this is reproducible:

POST https://rankforge.cc/api/analyzer with {"seed_url": "..."}, then poll GET /api/analyzer/<id> until status is completed.
The crawler follows internal links breadth-first from the seed, caps at 10 pages for the anonymous tier, and runs a PageRank-style authority simulation restricted to the crawled subgraph.
Raw JSON for all four runs: content/analyzer_20260920_<host>.json.

The healthy three

nodejs.org came back with an average internal authority of 100 across the sample — every page the crawler reached was tightly cross-linked from the others, with /learn topping the authority table. 611 internal links found across 10 pages, only 1 hitting the weakest-20% bucket, 1 redirect.

webpack.js.org was close behind: average authority 79.32, 627 links, two pages (/concepts and /guides/getting-started) tied at the top of the authority table. Dense docs cross-linking, nothing orphaned.

vuejs.org landed in the middle: average authority 46.13, 873 links found, homepage naturally at 100 and /api/application.html next at 28.17. Normal shape for a docs site — a strong homepage feeding an internal hierarchy, no orphans, no redirect chains.

digitalocean.com: 9 of 10 crawled pages were orphans

This is the one worth a closer look. Starting from the DigitalOcean homepage, the crawler reached 10 pages, and 9 of them had zero internal links pointing to them from anywhere else in the crawled set — they were only reachable because something earlier happened to link to them once. All 9 were the same kind of page: old community tutorial-collection landing pages —

/community/tutorial-collections/how-to-install-magento
/community/tutorial-collections/how-to-install-the-mean-stack
/community/tutorial-collections/how-to-install-and-use-memcache
/community/tutorial-collections/how-to-install-wordpress-with-nginx
/community/tutorial-collections/how-to-install-mysql
/community/tutorial-collections/how-to-install-lamp
/community/tutorial-collections/how-to-set-up-ssh-keys
/community/tutorial-collections/how-to-install-apache-tomcat
/community/tutorial-collections/how-to-set-up-a-node-js-application-for-production

DigitalOcean's community section is enormous — this is a 10-page sample, not a site-wide audit, so it doesn't mean the whole tutorial library is 90% orphaned. What it does show is that whatever navigation path the crawler followed from the homepage lands in a cluster of tutorial-collections landing pages that don't link to each other or back into the main site nav. The average internal authority for the sample came back at 20.41, dragged down by that cluster, while the homepage itself held the maximum score of 100 and the strongest tutorial page (how-to-install-and-use-memcache) only reached 11.57.

Tutorial-collection or topic-hub pages like this are usually generated once from a template, linked from a single index or search result, and then never cross-linked to sibling collections again. They're not broken — a user who lands on one from Google gets useful content — but they're structurally isolated from the site's main internal link graph, which is exactly the kind of thing that caps how much authority flows into that whole content cluster.

Why this keeps showing up

Across eight sites now (four last week, four this week), the pattern repeats: large, well-maintained sites with real engineering teams still accumulate pockets of internally orphaned content — usually old campaign pages, supporter walls, or auto-generated topic-collection pages that were linked once and forgotten. None of it is catastrophic. All of it is invisible from a normal site walkthrough, and only shows up once you crawl the actual link graph and check what points to what.

Try it on your own site

Same checks (orphan pages, near-orphans, internal authority distribution, redirect chains) run in one pass, no signup: rankforge.cc/audit.

I Crawled 4 Major Dev Sites' First 10 Pages. Two Had Real Structural Bugs

Hermis — Sat, 19 Sep 2026 03:14:19 +0000

On 2026-09-19 I ran four well-known developer-facing sites through the free crawler on my own SEO tool — smashingmagazine.com, freecodecamp.org, tailwindcss.com, and mozilla.org — 10 pages each, starting from the homepage. I wasn't looking for anything specific, just comparing internal-link health across sites that presumably have real engineering teams behind them. Two of the four had a genuine structural bug in the crawled sample; the other two were clean.

What I ran

No account needed, so this is reproducible:

POST https://rankforge.cc/api/analyzer with {"seed_url": "..."}, then poll GET /api/analyzer/<id> until status is completed.
The crawler follows internal links breadth-first from the seed, caps at 10 pages for the anonymous tier, and runs a PageRank-style authority simulation restricted to the crawled subgraph.
Raw JSON for all four runs: content/analyzer_20260919_<host>.json.

The clean pair

tailwindcss.com was the healthiest of the four: 1,608 internal links found across the 10 pages, average internal authority 63.24, and only 1 of the 10 pages fell into the weakest-20%-authority bucket. Dense internal linking, nothing orphaned, nothing redirecting strangely.

smashingmagazine.com was solid too — 847 links, average authority 32.39, zero orphan or near-orphan pages in the sample. It does carry 9 internal redirects (mostly old article URLs 301'd to canonical ones), which cost a hop each but nothing broken.

freecodecamp.org: 8 of 10 crawled pages were orphans

This is the one that surprised me. Starting from the freeCodeCamp homepage, 8 of the 10 pages the crawler reached had zero internal links pointing to them — they were only reachable because something on an earlier page happened to link to them once, then nothing else in the crawled set linked back. All 8 were the same kind of page: old supporter/contributor "thank you" and wallpaper pages —

/news/freecodecamp-supporter-happy-2023-wallpaper
/news/thank-you-for-donating
/news/super-secret-supporter-wallpaper
/news/thank-you-for-being-a-supporter
/news/2025-supporter-wallpaper
/news/podcast-guest-checklist
/news/top-contributor-happy-2023-wallpaper
/news/2025-top-contributor-wallpaper

freeCodeCamp is enormous — this is a 10-page sample, not a site-wide audit, so it doesn't mean the whole site is 80% orphaned. What it does show is that whatever internal navigation path the crawler followed from the homepage dead-ends into a cluster of donor/supporter pages that don't link to anything else in the main content graph and aren't linked from each other. All 8 landed on the exact same authority score (12.82), which is what the simulation produces for pages that form an isolated cluster fed by identical inbound paths rather than genuine cross-linking — a distinct signature from a healthy content page that earns varied internal links from different sections of the site.

If you maintain a site with a similar "supporter wall" or campaign-page pattern, this is worth checking: pages like this often get created once, linked from a single sitewide footer or CTA, and never touched again. They're not broken, but they're structurally isolated from the rest of the site's internal link graph.

mozilla.org: pages that redirect to themselves

The odder result. Average internal authority for the mozilla.org sample came back as 0 — every page in the 10-page crawl showed up in the redirect audit instead of the normal authority table. The redirect audit flagged 9 of the 10 pages, and the entries look like this:

https://www.mozilla.org/en-US/about/manifesto
  -> redirects to: https://www.mozilla.org/en-US/about/manifesto  (2 hops, status 301)
https://www.mozilla.org/en-US/privacy/websites/cookie-settings
  -> redirects to: https://www.mozilla.org/en-US/privacy/websites/cookie-settings  (1 hop, status 301)
https://www.mozilla.org/en-US/products/vpn
  -> redirects to: https://www.mozilla.org/en-US/products/vpn  (1 hop, status 302)

Each URL's redirects_to field is identical to the URL itself. That reads as a locale/trailing-slash redirect loop that resolves back to the same canonical path — plausible causes are a www vs. non-www normalization step, an en-US locale rewrite, or a cookie-consent gate that 302s every request through itself once before serving content. Functionally it's harmless to a human visitor (the browser follows the hop instantly and lands on the right page), but it means every internal link on the site is spending a redirect hop it doesn't need to, and it's why the crawler's authority table came back empty — the simulation attributes authority to the final resolved URL, and here that bookkeeping collapsed the whole sample into the redirect audit instead.

Neither of these is a catastrophic SEO problem. freeCodeCamp's orphan cluster is old campaign pages that were probably never meant to rank on their own. Mozilla's self-redirect is a normalization quirk that costs milliseconds, not rankings. But both are the kind of thing that's invisible from a normal site walkthrough and only shows up once you crawl the actual link graph and check what points to what — which is the whole reason a link-structure crawl is worth running occasionally even on sites that already have dedicated engineering teams.

Try it on your own site

Same four checks (orphan pages, near-orphans, internal authority distribution, redirect chains) run in one pass, no signup: rankforge.cc/audit.

5 Sites, 3,671 Internal Links, and 2% Editorial at Best

Hermis — Thu, 17 Sep 2026 20:24:56 +0000

Every internal-linking guide ends with the same instruction: add more internal links. On 2026-09-07 I checked whether that was actually the problem. I ran five sites through the free analyzer on my own SEO tool and looked at one thing — not how many internal links each site had, but what kind.

None of them was short on links. Between them, 3,671 internal links on the crawled pages. The share classified as editorial — a link written inside body copy, pointing somewhere specific — topped out at 2%. On three of the five it rounded to zero.

What I ran

No account needed, so this is reproducible:

POST https://rankforge.cc/api/analyzer with {"seed_url": "..."}, then poll GET /api/analyzer/<id> until status is completed.
Anonymous tier, which caps each crawl at 10 pages. Every run came back with crawl_complete: false.
Five seeds, all run on 2026-09-07: ahrefs.com/blog, css-tricks.com, kubernetes.io/docs/home, rankforge.cc, www.thestackanalyst.com.

The 10-page cap matters, so I'm putting it up front rather than in a footnote. This is a sample of the pages nearest each seed — the homepage or hub, plus what it links to first. It is the top of a site, not the whole site.

That cuts in an interesting direction, though. The top of a site is where internal linking is supposed to be strongest and most deliberate. It's the friendliest place to go looking for editorial links, not the harshest.

The classifier sorts every internal link into four buckets: editorial (inside body content), navigational (menus, headers, breadcrumbs), list (archive and card grids), and boilerplate (footers and other site-wide furniture).

The numbers

Site	Internal links	Editorial	Navigational	List	Boilerplate	Nav-sat.
ahrefs.com/blog	1,276	0%	35.6%	31.2%	33.2%	yes
css-tricks.com	59	0%	83.1%	16.9%	0%	no
kubernetes.io/docs	1,335	0%	95.4%	4.6%	0%	yes
rankforge.cc	503	0.6%	14.3%	9.9%	75.1%	yes
thestackanalyst.com	498	2%	74.7%	22.7%	0.6%	yes

Four of five sites got flagged for weak internal linking. All five had plenty of links. None had many editorial ones.

Not one of these sites had an orphan page in the crawled sample — all five report orphan_pages_count: 0. Four of the five still got "Internal Link Strategy" flagged as their primary bottleneck.

Navigational links can't tell your pages apart

This is the part that changed how I read internal-link reports.

A menu link appears on every page and points at the same handful of destinations. In a PageRank-style model, that's a dense, near-uniform block of edges. It moves authority around, but it moves it the same way for everybody, so it can't express a preference. It has no opinion about which of your pages deserves to rank.

Editorial links are the only ones that carry an opinion. Somebody writing a paragraph decided this page was worth pointing at from that sentence. That's the signal.

When the navigational block dominates, the analyzer sets nav_saturated: true — and then warns you about its own output:

Navigation/footer links reach nearly every page, so authority differences between pages are largely structural (a byproduct of the menu), not a reliable signal of which pages are strategically under-supported.

I like tools that do this. A per-page "authority score" on a nav-saturated site is mostly measuring your template. Ranking your pages by it and "fixing" the bottom five is chasing a menu.

What it looks like on my own site

My own site came out worst on composition: 75.1% boilerplate, 0.6% editorial. That's a footer doing the work that body copy should be doing.

The analyzer proposed 7 specific in-body placements, each with a source page, a target, an anchor, and the sentence to put it in. It also simulates the result:

Metric	Value
Links modeled	7
Total authority before	922.34
Total authority after	922.34
`/docs/authority-flow` before	22.34
`/docs/authority-flow` after	77.66 (+247.7%)
Pages gaining	1
Pages losing	9

The two numbers I'd underline are the identical totals. Internal linking creates no authority. It's redistribution: one page went up 55 points, nine went down an average of 6.2 each. That's a fine trade when you know which page you want to win, and a pointless shuffle when you don't.

/docs/authority-flow was sitting at 22.34 on a site whose median page scores 98.93. It was reachable, indexable, in the footer — and structurally invisible.

The outlier worth looking at

Kubernetes docs is the extreme case: 95.4% navigational, and the docs sidebar is doing essentially all of the linking. Its homepage holds 49% of the internal authority in the sample and the median page sits at 11.57.

That is not a bug in their docs. A giant navigation tree is the correct interface for reference documentation, and their readers arrive from search on a specific page anyway. It's a good reminder that "editorial links are low" is a finding, not automatically a defect — the question is whether the pages you actually care about are getting any differentiation at all.

Check yours in about two minutes

# 1. queue a crawl (anonymous, no signup)
ID=$(curl -s -X POST https://rankforge.cc/api/analyzer \
  -H 'Content-Type: application/json' \
  -d '{"seed_url":"https://example.com/"}' | jq -r .id)

# 2. poll until it finishes
until [ "$(curl -s https://rankforge.cc/api/analyzer/$ID | jq -r .status)" = "completed" ]; do
  sleep 10
done

# 3. the only number this post is about
curl -s https://rankforge.cc/api/analyzer/$ID \
  | jq '.summary_metrics.link_quality | del(.pages_with_only_boilerplate_links)'

Real output from the thestackanalyst.com run:

{
  "editorial_pct": 2,
  "navigational_pct": 74.7,
  "boilerplate_pct": 0.6,
  "list_pct": 22.7,
  "total_internal_links": 498
}

The browser version of the same crawl lives at rankforge.cc/audit if you'd rather not shell out for it.

What I'm doing about it

Three changes, in the order I'd rank them:

Stop treating link count as the metric. 503 internal links and 0.6% editorial is a worse position than 60 links with 20 of them written on purpose.
Read nav_saturated before reading any per-page score. If it's true, per-page authority deltas are template noise and the ranked "weak pages" list is not a to-do list.
Write the links into the prose. Not a related-posts widget, not another footer column — a sentence that earns the link. That's the only bucket a template can't fake for you.

Run it on your own site and drop your editorial_pct in the comments. Mine was 0.6%, and I build SEO tooling for a living — I'd like to know whether I'm the outlier or the norm.

Crawls run 2026-09-07 via the public RankForge analyzer API, anonymous tier, 10 pages per site. Raw JSON for all five runs is saved alongside this post; every figure above comes from summary_metrics in those files.

I Crawled a Real Site With a Free Crawler and Found 2 Invisible Pages

Hermis — Mon, 14 Sep 2026 03:05:54 +0000

I spent about fifteen minutes on Monday crawling a site I don't own: thestackanalyst.com, a small independent SEO-tools blog. Not a client, not a competitor — I picked it because it's the kind of site most of us actually run. WordPress, a few dozen posts, one person maintaining it.

I wanted to answer one question with real data instead of vibes: if you crawl a small site with free tooling, what do you actually catch?

The answer, in this case: two orphan pages, one dead outbound link, and zero broken internal links. That last part matters — this site is in good shape. The point of this post isn't "look at this broken site." It's the method, run against a real example, so you can point it at your own domain this week.

The method: three steps, no paid tools

Every step here is something you can do with a free crawler and a spreadsheet. I used the free crawler at rankforge.cc, but the technique is tool-agnostic — anything that will fetch your URLs and record internal links works.

Step 1 — Crawl from the homepage

Start at the root and let the crawler follow internal links until it runs out. This gives you the set of pages that are reachable by following links. That distinction is the whole trick.

Step 2 — Diff that set against your sitemap

Your sitemap is the set of pages you say exist. Your crawl is the set of pages a crawler can find by walking your site. Anything in the sitemap but not in the crawl is an orphan: live, indexable, and structurally invisible. The diff, on this site:

$ crawl https://www.thestackanalyst.com | diff - sitemap.xml

> https://www.thestackanalyst.com/seo-tools     (0 internal links pointing at it)
> https://www.thestackanalyst.com/text-tools    (0 internal links pointing at it)

Both lines exist in the sitemap. Neither appears as the target of a single internal link anywhere in the crawl.

Step 3 — Check link statuses, internal and outbound

Same crawl, one extra pass. Internal 404s are self-inflicted damage. Outbound dead links are a different opportunity entirely — more on that at the end.

What the crawl actually found

Hard numbers, no rounding up:

Metric	Result
URLs fetched (crawl)	200
HTTP 200 responses	197
Non-200	2× `wp-json` oEmbed (400), 1× `xmlrpc.php` (403) — WP infrastructure, not user pages
Sitemap URLs declared	62
Broken internal links	0 (beyond those two WP endpoints)
Homepage internal links	53
Homepage external links	3
Orphan pages	2: `/seo-tools` and `/text-tools`
Outbound links checked (Top 100 listicle)	134, exactly 1 dead (`keywordshitter.com`)

Both orphans return HTTP 200. Both are in the sitemap. And across the entire 200-URL crawl — homepage, blog index, every post — zero internal links point to either one.

They're tool-hub pages. Someone built them, published them, submitted them in the sitemap, and never got around to wiring them into the nav.

They're two doors with no hallway leading to them.

I want to be completely fair here: this is exactly what almost every site looks like, mine included. Two orphans and no broken internal links on a site this size is a healthy result. The site owner is doing fine.

Why orphans are worth caring about

Three practical reasons, no statistics required.

No internal anchor text signals. Every internal link is a small statement about what a page is about. An orphan has none. Google has to guess from the page alone.

Discovery depends entirely on the sitemap. A sitemap is a hint, not a guarantee. When it's the only path to a page, you've removed every redundancy from that page's discoverability.

Link equity can't flow to it. That homepage with 53 internal links is distributing authority across the site. Orphans get zero of it, forever, no matter how good they are.

For /seo-tools and /text-tools, the sting is that these are hub pages — the page type that should be collecting internal links from every relevant post and passing authority down to individual tools.

What to do with each orphan

Don't reflexively delete. Run the page through three questions:

Is it good and still relevant? → Link it in. Not a footer dump — footer links are weak and readers ignore them. Put it in the main nav if it's a hub, and add contextual in-body links from the two or three posts most related to it. For /seo-tools, that means linking it from every post that mentions an SEO tool. Anchor text should describe the destination, not say "click here."

Is it redundant with a stronger page? → 301 redirect it to that stronger page and fold any unique content in. Neither thin page beats one solid page — merge them.

Is it necessary but not search-worthy? (thank-you pages, filtered views, internal utilities) → noindex, and remove it from the sitemap. An orphan you intend to be an orphan isn't a bug — but it shouldn't be sitting in your sitemap sending mixed signals.

The failure mode to avoid: leaving a page indexable, sitemapped, and unlinked.

The bonus you get for free: outbound link rot

Same crawl, extra pass. I checked the outbound links on their big "Top 100 Free SEO Tools" listicle — 134 tool links checked.

Exactly one was dead: keywordshitter.com (yes, real tool, real name — Dan Shure's free keyword tool). It timed out across http, https, and www variants. The other 133 resolved fine — for a listicle that size, a genuinely good ratio. But a dead link in a "here are the tools" post is a bad reader experience, and it's the kind of thing an author never notices because nobody re-clicks their own links.

Here's why this is worth your time beyond tidiness: it's the most honest outreach angle there is. You email the editor, name the dead link sitting in their list, and suggest a live alternative that does the same job. No pitch, no "I noticed you link to X, would you consider linking to me" dance. You're doing unpaid editorial QA on their most important page. Sometimes you get a link out of it. Often you just get a reply from a real person, which is worth more than most cold outreach ever produces.

Run this against any listicle in your niche and you'll find candidates — roundup posts rot constantly, and tools die quietly.

Fifteen minutes, this week

That's the whole exercise. One crawl, one sitemap diff, one link-status pass. Two orphan pages surfaced, one dead outbound link found, and a clean bill of health confirmed on everything else — on a site I'd never touched before.

You almost certainly have orphans right now. Not because you're careless, but because sites accumulate pages faster than they accumulate links. This one had two. Yours almost certainly has at least one.

If you want the fast version of step 2, the orphan page checker does the crawl-versus-sitemap diff for you and hands you the list. Then work the three questions above on each result: link it, redirect it, or noindex it.

Then go check that one listicle you keep linking to. I'd bet something on it is dead.

How to Find and Fix Orphan Pages Without Paying for a Crawler

Hermis — Sun, 13 Sep 2026 03:03:19 +0000

Orphan pages are pages on your site that no other page links to. Search engines
can't find them through crawling alone — the only way they get indexed is if a
search engine finds a link to them from outside your site, or if you submit
them directly. For most sites, orphans are quietly costing you money.

Why orphans are a problem

Every orphan page is a page your budget spent on but your site structure never
promoted. The symptoms are easy to mistake for something else:

Wasted crawl budget — if an orphan gets indexed, it still consumes crawl capacity with every crawl cycle.
Silent 404s — many orphans are old campaign pages, staging pages, or checkout-related URLs nobody decommissioned properly.
Lost internal-link equity — internal links are how PageRank-style signals flow around a site. Orphans are cut off from that flow by definition.
Confusing user journeys — if a visitor does land on an orphan (via a bookmark, a PPC ad, or an old email), there's no natural next step.

The free way to find them

The classic paid answer is a full site crawler. But for most sites under a few
hundred thousand URLs, you can get the same result for free:

Crawl your site. Use a free crawler that respects robots.txt and follows internal links. RankForge's free crawl does this for small and medium sites in a couple of minutes.
Collect every URL your crawler found — these are your "linked" pages.
Get your full URL list from your CMS or analytics. In Google Analytics (or GA4's page-path report) you'll see the pages people actually reached. In most CMSes, an XML sitemap export or a database export gives you the complete list of published pages.
Subtract. Any URL that exists in your CMS/sitemap but was never found by the crawl is an orphan — nothing internal links to it.

That's the whole method. No paid tool required.

What to do with each orphan

Not all orphans deserve the same treatment:

Fix and relink — if the page is genuinely useful (a guide, a product page, a comparison), add a contextual internal link from a related page. Don't just drop it in the footer; a contextual link from a relevant article passes more relevance than a site-wide link.
Redirect — if the page was replaced by a newer version, 301 it to the new URL so any existing equity (from external links or bookmarks) moves with it.
Deindex and leave — staging pages, printer-friendly versions, and parameter URLs that have no business being indexed: add noindex and leave them alone.
Delete — genuinely dead content can be removed, but only after checking that nothing external links to it. If external links exist, redirect instead.

Build it into your routine

Orphans accumulate faster than you think — every campaign page, every A/B
test landing page, every unlinked article adds to the pile. Run the check
monthly, or hook it into your deploy pipeline and audit after every release.

If you want a quick start, RankForge's free orphan-page checker does the crawl and the subtraction for you — no signup, no credit card.

Internal Linking Audit: 5 Free Checks That Take 5 Minutes

Hermis — Sat, 12 Sep 2026 03:10:11 +0000

Internal links are the plumbing of your site. They tell search engines what
matters, spread ranking signals between pages, and — more practically — they
are the single biggest free lever most sites ignore. Here are five checks
you can run right now with free tools.

1. Find orphan pages

Any page with zero internal links pointing to it is an orphan. It might be
indexed (if an external link found it), but it's getting no internal signal,
and it's invisible to your own navigation.

The check: crawl your site and diff the discovered URLs against your
sitemap/CMS export. Every URL in the export that the crawl never saw is an
orphan. RankForge's free crawler does the diff for you
in one step.

2. Count how many pages have no internal links at all

A page that's linked only from the sitemap is a de-facto orphan. Filter your
crawl for pages whose internal backlink count is zero, and you'll usually find
a mix of old articles, staging pages, and forgotten product pages.

3. Check your homepage's link budget

How many links does your homepage actually carry? A homepage bloated with
hundreds of links (footer, mega-menu, "as seen on" badges, social icons)
dilutes the signal it sends to your most important pages. If your money pages
aren't in the top 20 links from the homepage, that's a signal problem.

4. Find pages nobody links to with relevant anchor text

Anchor text matters. A page that only ever receives "click here" and "read
more" anchors is telling search engines nothing about its topic. Find pages
whose internal anchors are generic, and add one or two descriptive, contextual
links from related content. Natural anchors like "orphan page checker" or
"free SEO tools" tell both users and engines what the target is about.

5. Verify your pillars actually point at each other

If you use topic clusters, your pillar page should link to every cluster page,
and (ideally) cluster pages should link back to the pillar. A quick crawl
shows you which cluster members drifted out of the hub-and-spoke structure.

Why this matters more than new content

Most sites don't need more pages — they need their existing pages to work
together. Fixing internal linking is:

Free — no ad spend, no tool licenses
Fast — most fixes are adding one contextual link
Compounding — every fix improves how the whole site passes signal

Run these five checks once a month. In two or three cycles, the pattern of
links between your pages will look like a site someone actually maintains —
which is exactly what it should look like.

All five checks above are built into RankForge's free suite — crawler, orphan finder, and internal-link checker, no signup required.

5 Sites, 3,671 Internal Links, and 2% Editorial at Best

Hermis — Mon, 07 Sep 2026 09:53:52 +0000

What I ran

No account needed, so this is reproducible:

POST https://rankforge.cc/api/analyzer with {"seed_url": "..."}, then poll GET /api/analyzer/<id> until status is completed.
Anonymous tier, which caps each crawl at 10 pages. Every run came back with crawl_complete: false.
Five seeds, all run on 2026-09-07: ahrefs.com/blog, css-tricks.com, kubernetes.io/docs/home, rankforge.cc, www.thestackanalyst.com.

The numbers

Site	Internal links	Editorial	Navigational	List	Boilerplate	Nav-sat.
ahrefs.com/blog	1,276	0%	35.6%	31.2%	33.2%	yes
css-tricks.com	59	0%	83.1%	16.9%	0%	no
kubernetes.io/docs	1,335	0%	95.4%	4.6%	0%	yes
rankforge.cc	503	0.6%	14.3%	9.9%	75.1%	yes
thestackanalyst.com	498	2%	74.7%	22.7%	0.6%	yes

Four of five sites got flagged for weak internal linking. All five had plenty of links. None had many editorial ones.

Not one of these sites had an orphan page in the crawled sample — all five report orphan_pages_count: 0. Four of the five still got "Internal Link Strategy" flagged as their primary bottleneck.

Navigational links can't tell your pages apart

This is the part that changed how I read internal-link reports.

Editorial links are the only ones that carry an opinion. Somebody writing a paragraph decided this page was worth pointing at from that sentence. That's the signal.

When the navigational block dominates, the analyzer sets nav_saturated: true — and then warns you about its own output:

Navigation/footer links reach nearly every page, so authority differences between pages are largely structural (a byproduct of the menu), not a reliable signal of which pages are strategically under-supported.

I like tools that do this. A per-page "authority score" on a nav-saturated site is mostly measuring your template. Ranking your pages by it and "fixing" the bottom five is chasing a menu.

What it looks like on my own site

My own site came out worst on composition: 75.1% boilerplate, 0.6% editorial. That's a footer doing the work that body copy should be doing.

The analyzer proposed 7 specific in-body placements, each with a source page, a target, an anchor, and the sentence to put it in. It also simulates the result:

Metric	Value
Links modeled	7
Total authority before	922.34
Total authority after	922.34
`/docs/authority-flow` before	22.34
`/docs/authority-flow` after	77.66 (+247.7%)
Pages gaining	1
Pages losing	9

/docs/authority-flow was sitting at 22.34 on a site whose median page scores 98.93. It was reachable, indexable, in the footer — and structurally invisible.

The outlier worth looking at

Check yours in about two minutes

# 1. queue a crawl (anonymous, no signup)
ID=$(curl -s -X POST https://rankforge.cc/api/analyzer \
  -H 'Content-Type: application/json' \
  -d '{"seed_url":"https://example.com/"}' | jq -r .id)

# 2. poll until it finishes
until [ "$(curl -s https://rankforge.cc/api/analyzer/$ID | jq -r .status)" = "completed" ]; do
  sleep 10
done

# 3. the only number this post is about
curl -s https://rankforge.cc/api/analyzer/$ID \
  | jq '.summary_metrics.link_quality | del(.pages_with_only_boilerplate_links)'

Real output from the thestackanalyst.com run:

{
  "editorial_pct": 2,
  "navigational_pct": 74.7,
  "boilerplate_pct": 0.6,
  "list_pct": 22.7,
  "total_internal_links": 498
}

The browser version of the same crawl lives at rankforge.cc/audit if you'd rather not shell out for it.

What I'm doing about it

Three changes, in the order I'd rank them:

Stop treating link count as the metric. 503 internal links and 0.6% editorial is a worse position than 60 links with 20 of them written on purpose.
Read nav_saturated before reading any per-page score. If it's true, per-page authority deltas are template noise and the ranked "weak pages" list is not a to-do list.
Write the links into the prose. Not a related-posts widget, not another footer column — a sentence that earns the link. That's the only bucket a template can't fake for you.

Run it on your own site and drop your editorial_pct in the comments. Mine was 0.6%, and I build SEO tooling for a living — I'd like to know whether I'm the outlier or the norm.

I Crawled a Real Site With a Free Crawler and Found 2 Invisible Pages

Hermis — Sun, 06 Sep 2026 16:04:31 +0000

I wanted to answer one question with real data instead of vibes: if you crawl a small site with free tooling, what do you actually catch?

The method: three steps, no paid tools

Step 1 — Crawl from the homepage

Start at the root and let the crawler follow internal links until it runs out. This gives you the set of pages that are reachable by following links. That distinction is the whole trick.

Step 2 — Diff that set against your sitemap

$ crawl https://www.thestackanalyst.com | diff - sitemap.xml

> https://www.thestackanalyst.com/seo-tools     (0 internal links pointing at it)
> https://www.thestackanalyst.com/text-tools    (0 internal links pointing at it)

Both lines exist in the sitemap. Neither appears as the target of a single internal link anywhere in the crawl.

Step 3 — Check link statuses, internal and outbound

Same crawl, one extra pass. Internal 404s are self-inflicted damage. Outbound dead links are a different opportunity entirely — more on that at the end.

What the crawl actually found

Hard numbers, no rounding up:

Metric	Result
URLs fetched (crawl)	200
HTTP 200 responses	197
Non-200	2× `wp-json` oEmbed (400), 1× `xmlrpc.php` (403) — WP infrastructure, not user pages
Sitemap URLs declared	62
Broken internal links	0 (beyond those two WP endpoints)
Homepage internal links	53
Homepage external links	3
Orphan pages	2: `/seo-tools` and `/text-tools`
Outbound links checked (Top 100 listicle)	134, exactly 1 dead (`keywordshitter.com`)

Both orphans return HTTP 200. Both are in the sitemap. And across the entire 200-URL crawl — homepage, blog index, every post — zero internal links point to either one.

They're tool-hub pages. Someone built them, published them, submitted them in the sitemap, and never got around to wiring them into the nav.

They're two doors with no hallway leading to them.

Why orphans are worth caring about

Three practical reasons, no statistics required.

No internal anchor text signals. Every internal link is a small statement about what a page is about. An orphan has none. Google has to guess from the page alone.

Discovery depends entirely on the sitemap. A sitemap is a hint, not a guarantee. When it's the only path to a page, you've removed every redundancy from that page's discoverability.

Link equity can't flow to it. That homepage with 53 internal links is distributing authority across the site. Orphans get zero of it, forever, no matter how good they are.

What to do with each orphan

Don't reflexively delete. Run the page through three questions:

Is it redundant with a stronger page? → 301 redirect it to that stronger page and fold any unique content in. Neither thin page beats one solid page — merge them.

The failure mode to avoid: leaving a page indexable, sitemapped, and unlinked.

The bonus you get for free: outbound link rot

Same crawl, extra pass. I checked the outbound links on their big "Top 100 Free SEO Tools" listicle — 134 tool links checked.

Run this against any listicle in your niche and you'll find candidates — roundup posts rot constantly, and tools die quietly.

Fifteen minutes, this week

Then go check that one listicle you keep linking to. I'd bet something on it is dead.

Internal Linking Audit: 5 Free Checks That Take 5 Minutes

Hermis — Mon, 31 Aug 2026 08:13:09 +0000

1. Find orphan pages

Any page with zero internal links pointing to it is an orphan. It might be
indexed (if an external link found it), but it's getting no internal signal,
and it's invisible to your own navigation.

2. Count how many pages have no internal links at all

3. Check your homepage's link budget

4. Find pages nobody links to with relevant anchor text

5. Verify your pillars actually point at each other

Why this matters more than new content

Most sites don't need more pages — they need their existing pages to work
together. Fixing internal linking is:

Free — no ad spend, no tool licenses
Fast — most fixes are adding one contextual link
Compounding — every fix improves how the whole site passes signal

Run these five checks once a month. In two or three cycles, the pattern of
links between your pages will look like a site someone actually maintains —
which is exactly what it should look like.

All five checks above are built into RankForge's free suite — crawler, orphan finder, and internal-link checker, no signup required.

I Crawled My Own SEO Site and Found a Crawler Trap

Hermis — Sun, 30 Aug 2026 07:12:44 +0000

I run a small SEO tooling site, and on 2026-08-24 I pointed my crawler at it. The plan was routine: check internal health, check for orphans, move on.

The crawl returned zero orphan candidates. That result is why I'm writing this. It wasn't proof that the site was perfect; the audit had asked the wrong question. The broken links were a false alarm, and the green "everything is fine" result was the real bug.

What I ran, and what it actually measured

The setup was deliberately plain, so anyone can reproduce the shape of it:

Seed URL: https://rankforge.cc
Breadth-first traversal of internal links, respecting robots.txt
Requested page cap: 100
1 second delay between requests
Started 2026-08-24T09:04:12Z

Two details matter before the numbers. The requested cap was 100 but the script fetched 159 pages: after traversal, it performs bounded extra link checks. So "pages fetched" and "BFS budget" are different metrics.

The bigger issue: the orphan check fetched sitemap_index.xml and nothing else.

The numbers

Raw crawler output first, then a separate probe I ran immediately afterward. I'm keeping these visually separated on purpose, because mixing a tool's output with your own follow-up checks is how an audit quietly becomes fiction.

Metric	Value	Source
Crawl start time	2026-08-24T09:04:12Z	raw crawl
Pages fetched	159	raw crawl
Unique URLs queued	158	raw crawl
HTTP 200	147	raw crawl
HTTP 404	12	raw crawl
Total internal links recorded	4,883	raw crawl
Homepage internal links	53	raw crawl
Homepage external links	2	raw crawl
Broken-link entries (source → target pairs)	22	raw crawl
Unique broken targets	12	raw crawl
Sitemap URLs seen by crawler	0	raw crawl
Orphan candidates reported	0	raw crawl
`robots.txt`	HTTP 200	direct probe, immediately after crawl
`sitemap_index.xml`	HTTP 404	direct probe, immediately after crawl
`sitemap.xml`	HTTP 200, 142 `<loc>` entries	direct probe, immediately after crawl

robots.txt disallowed ten app prefixes, including /api/, /dashboard/, and /search-performance/. A robots-aware crawl correctly stayed out of them; compare that boundary with the sitemap before judging coverage.

The false alarm: 12 broken links that aren't broken links

Twelve 404s on a 159-page crawl looks like a real finding. It wasn't. Every single one was a Cloudflare email-obfuscation URL under /cdn-cgi/l/email-protection, linked from /contact, /pricing, /privacy, /terms, /security, and /docs/crawler. Cloudflare rewrites mailto links into that endpoint plus a hex-encoded fragment; browser JavaScript decodes it back into an address. A plain HTTP fetch of that path is supposed to fail. The site is behaving exactly as configured.

The 22-versus-12 gap is another small lesson: the crawler logs one entry per source→target pair, and ten entries recorded the source as ? because the target was found during the bounded extra-check phase. The same obfuscated addresses were counted from multiple pages. Reporting "22 broken links" would inflate a non-issue by nearly 2x.

The rule for any crawler: put infrastructure URLs in their own bucket. /cdn-cgi/*, analytics beacons, tracking pixels, and mailto:/tel: rewrites should be reported separately from content 404s. Dropping them hides regressions; mixing them into the headline trains you to ignore the report.

The real trap: `sitemap_index.xml` vs `sitemap.xml`

Here's the part that actually cost me something.

The orphan check works by diffing pages found in the sitemap against pages reached by crawling internal links. Anything in the sitemap but unreachable by link is an orphan candidate. Sound logic — and it depends entirely on having a sitemap to diff against.

My crawler only requested sitemap_index.xml. That's the WordPress/Yoast convention, and it's a reasonable default if you mostly audit WordPress sites. On my own site that URL is a 404. So the crawler recorded sitemap_url_count: 0, diffed 158 crawled URLs against an empty set, and reported zero orphan candidates.

Zero orphans was structurally impossible to avoid. The check couldn't have found anything.

The direct probe immediately afterward got https://rankforge.cc/sitemap.xml at HTTP 200 with 142 <loc> entries. There was a sitemap the whole time — the audit just never looked at it. Note carefully what this does and does not tell you: it does not mean the site has no sitemap, and the zero result does not mean the site has no orphans. It means the orphan check never ran. Those 142 URLs versus 158 crawled URLs is a diff I still owe myself, and the overlap is not something you can eyeball from the counts alone.

If your tool can't distinguish "I looked and found none" from "I couldn't look," every clean report is ambiguous.

The corrected workflow

1. crawl internal links from seed, robots-aware, record every URL + status
2. fetch robots.txt, parse ALL "Sitemap:" directives
3. if none: try /sitemap.xml AND /sitemap_index.xml AND /sitemap-index.xml
4. for each sitemap found:
     if it is an index -> recurse into every child <loc>
     else -> collect every <loc>
5. FAIL LOUDLY if total sitemap URL count == 0
     (do not emit "0 orphans" — emit "sitemap not discovered")
6. normalize both sets: scheme, host, trailing slash, case,
   strip fragments, decide on query params explicitly
7. diff: sitemap_urls - crawled_urls = orphan candidates
8. verify each candidate: fetch it, confirm 200, confirm no internal
   link actually points to it, check it isn't robots-disallowed

Step 5 is the whole fix. An empty discovery set must be an error state, never an input to a diff. Step 6 is where most homegrown orphan checkers leak false positives — https://site.com/page and https://site.com/page/ are the same page to you and different strings to a set difference.

What 4,883 internal links actually tell me

Not much about quality, and I want to be honest about that. 4,883 internal links across 159 pages averages ~31 links per page, which mostly reflects a shared header, footer, and nav. The homepage's 53 internal links and 2 external links are the same story: that's template, not editorial linking.

Link count is a volume metric. It says nothing about anchor relevance, placement, or whether a page has inbound links beyond the global nav. The crawl flagged the homepage as the only page with zero inbound internal links — an artifact of it being the BFS seed, not a finding.

So the next passes are specific: strip nav/footer links and recount in-body links only; check which of the 142 sitemap URLs are reachable only through nav; and run the corrected sitemap diff before I make any claim about orphans at all.

Takeaway

The dramatic result (12 broken links) was noise; the boring result (0 orphans) was the bug. When an audit returns nothing, ask whether the check ran. Then use the orphan page checker, while confirming which sitemap was fetched, how many <loc> entries it returned, and whether 404s are content or infrastructure.

Ever shipped a "clean" audit that was actually blind, not clean? Drop it below.

DEV Community: Hermis

I Crawled 4 More Dev Sites. One Had 9 Orphan Pages Out Of 10

What I ran

The healthy three

digitalocean.com: 9 of 10 crawled pages were orphans

Why this keeps showing up

Try it on your own site

I Crawled 4 Major Dev Sites' First 10 Pages. Two Had Real Structural Bugs

What I ran

The clean pair

freecodecamp.org: 8 of 10 crawled pages were orphans

mozilla.org: pages that redirect to themselves

Try it on your own site

5 Sites, 3,671 Internal Links, and 2% Editorial at Best

What I ran

The numbers

Navigational links can't tell your pages apart

What it looks like on my own site

The outlier worth looking at

Check yours in about two minutes

What I'm doing about it

I Crawled a Real Site With a Free Crawler and Found 2 Invisible Pages

The method: three steps, no paid tools

Step 1 — Crawl from the homepage

Step 2 — Diff that set against your sitemap

Step 3 — Check link statuses, internal and outbound

What the crawl actually found

Why orphans are worth caring about

What to do with each orphan

The bonus you get for free: outbound link rot

Fifteen minutes, this week

How to Find and Fix Orphan Pages Without Paying for a Crawler

Why orphans are a problem

The free way to find them

What to do with each orphan

Build it into your routine

Internal Linking Audit: 5 Free Checks That Take 5 Minutes

1. Find orphan pages

2. Count how many pages have no internal links at all

3. Check your homepage's link budget

4. Find pages nobody links to with relevant anchor text

5. Verify your pillars actually point at each other

Why this matters more than new content

5 Sites, 3,671 Internal Links, and 2% Editorial at Best

What I ran

The numbers

Navigational links can't tell your pages apart

What it looks like on my own site

The outlier worth looking at

Check yours in about two minutes

What I'm doing about it

I Crawled a Real Site With a Free Crawler and Found 2 Invisible Pages

The method: three steps, no paid tools

Step 1 — Crawl from the homepage

Step 2 — Diff that set against your sitemap

Step 3 — Check link statuses, internal and outbound

What the crawl actually found

Why orphans are worth caring about

What to do with each orphan

The bonus you get for free: outbound link rot

Fifteen minutes, this week

Internal Linking Audit: 5 Free Checks That Take 5 Minutes

1. Find orphan pages

2. Count how many pages have no internal links at all

3. Check your homepage's link budget

4. Find pages nobody links to with relevant anchor text

5. Verify your pillars actually point at each other

Why this matters more than new content

I Crawled My Own SEO Site and Found a Crawler Trap

What I ran, and what it actually measured

The numbers

The false alarm: 12 broken links that aren't broken links

The real trap: sitemap_index.xml vs sitemap.xml

The corrected workflow

What 4,883 internal links actually tell me

Takeaway

The real trap: `sitemap_index.xml` vs `sitemap.xml`