Orphan pages on this site still get crawled: six articles with zero internal links drew the same bot traffic as linked ones

An orphan page is a page that no other page on its own site links to, so a visitor who starts at the homepage and only clicks links can never reach it. On this site, seven article pages were unreachable that way as of the October 6, 2026 build, the finished copy of the site published that day, and six of the seven had no internal links pointing at them at all.¹ Seven of 190 pages. Bots still requested those six at a median of 1.64 times a day, against 1.70 for linked articles of the same age.² On this site, the crawler log, the record of which bots requested which pages, did not separate orphans from linked pages, so finding orphans takes a link map you build yourself.

Six articles on this site had zero internal links pointing at them, and bots still requested them at a median of 1.64 times a day, against 1.70 for linked articles of the same age.

What is an orphan page, and why can’t a crawler log find one?

An orphan page is a page that no other page on its own site links to. A crawler log, the record of which bots requested which addresses, cannot mark one, because a page listed in a sitemap, a file of addresses the site wants crawled, is requested like any other page. On this site, the log did not separate orphans from linked pages.

A crawler is a program that visits web addresses and records what it finds. RSS is a feed file that lists a site’s recent items in a form programs can read, and llms.txt is a plain-text index some sites publish for AI agents.

Any of these lists can hand a crawler a page that no link points to. The log then records a request, and the page looks healthy. For what happens when a search engine cannot fetch one of those lists, see the article on sitemap “Couldn’t fetch” status.

How did I count orphan pages on this site?

I counted orphans by mapping every internal link on brandonlazovic.dev across the 190 pages of the October 6, 2026 build. Each page was a point, and each link from one page to another on the site, navigation menu and footer included, was a connection. Click depth, the fewest clicks needed to get from the homepage to a page, came from walking that map outward from the homepage.¹

The crawl numbers come from a separate source. The site runs on Cloudflare’s free plan, which keeps no access log, meaning no record of every request, so a script pulls daily bot request counts from Cloudflare’s analytics API instead. Human browsers are excluded by a keyword rule on the user agent, the label a visitor sends to say what software it is.

One file runs from July 21 to October 5, 2026 and sums requests across every bot the rule kept, with 75 dates present. A second file splits the same counts by user agent for 16 dates, from September 20 to October 5.²

User agents in that second file are claimed, not verified. The free plan cannot check which network sent a request, so a row labeled GPTBot means requests identifying as GPTBot. Joining the two sources gives each page a count of inbound links, a click depth and a crawl rate.

Of the 190 pages, 183 could be reached from the homepage by following links. That leaves seven.

Which seven articles can’t be reached from the homepage?

Seven articles on brandonlazovic.dev could not be reached by following links from the homepage as of the October 6, 2026 build. Six had zero internal links pointing at them. The seventh, local-model-api-crossover, had one, from another of the seven. All seven are one-off articles that belong to no topic series, and the site has no hub page, a page that lists a group of articles together, for them.¹

The table lists them with publish dates, inbound internal links and bot requests per day while live, with one summary row for the linked articles. Bot requests per day is each article’s requests from its publish date through October 5, 2026, divided by the calendar days it was live, counting the publish day.²

Article	Published	Inbound internal links	Bot requests per day
core-web-vitals-floor-not-bar	2026-07-23	0	1.21
conversational-analytics-verify	2026-08-01	0	1.68
prompting-practices-that-survived	2026-08-20	0	1.72
local-model-api-crossover	2026-08-21	1, from another unreachable article	1.72
preferred-sources-ask-the-reader	2026-09-02	0	1.59
gsc-query-report-conversation-turns	2026-09-03	0	2.58
duckdb-has-a-landlord	2026-09-04	0	1.50
34 linked articles, same publish window	2026-07-20 to 2026-09-04	one or more	median 1.70, range 0.85 to 23.69

The table here links all seven, so as of this article’s publication they are no longer orphans by the strict definition. The counts above describe the October 6 build, before this article published. The site still has no hub page for these articles, and linking to them from here does not create one.

The hand-check on conversational-analytics-verify shows how an orphan stays visible. No other HTML page in the build links to it. It still appears in sitemap-0.xml, the main RSS feed and llms.txt.¹

Do orphan pages get crawled less than linked pages?

Orphan pages on brandonlazovic.dev were crawled at about the same rate as linked pages of the same age. Six articles with zero inbound internal links, published between July 23 and September 4, 2026, drew a median of 1.64 bot requests per day while live. Thirty-four linked articles from the same window drew a median of 1.70. The comparison is directional, a small-sample reading that suggests a pattern without proving one.²

Those two medians count requests from every bot the keyword rule kept, so they describe crawling in general and not one crawler’s visits. The orphans ran from 1.21 to 2.58 requests a day. The linked articles ran from 0.85 to 23.69, a far higher top end, and I did not test what drives it.

Googlebot, Google’s search crawler, tells a thinner story by claimed user agent. Across the 16 days from September 20 to October 5, the orphans had a median of one Googlebot request, and three of the six had none. The linked articles had a median of zero, and 25 of the 34 had none.² Those counts are too small to show orphans drawing more Googlebot visits, so the most I can say is that they drew no fewer.

Suspected, not tested: the sitemap and the feeds keep the orphans in the log. The sitemap index drew 966 bot requests across all 75 dates, and the main RSS feed drew 60 requests on 38 of them.² A page named in lists that bots keep reading does not need a link to be requested.

Whether the six orphans are indexed, meaning stored in a search engine’s database, or whether they rank, was not measured. I did not check Search Console, Google’s free reporting tool for site owners, so this article says nothing about either.

Does click depth explain crawl frequency on this site?

Click depth, the fewest clicks from the homepage to a page, could not be tested on brandonlazovic.dev, because no reachable page sits more than three clicks deep. Of the 190 pages, one sits at depth zero (the homepage), 18 at depth one, 109 at depth two and 55 at depth three. The 55 at depth three are 54 pages from the site’s Pulse section, its daily news-digest pages, and one article.¹

A site that shallow gives click depth almost no range to show an effect across. Every page sits within a few clicks of the homepage, so there is no deep group to compare against a shallow one.

The measurement did surface a disagreement between two kinds of depth. Folder depth, the number of slashes in a URL, and click depth are different properties of the same page. Eight pages sit two folders down but one click from home. Fifty-five sit two folders down and three clicks away, and 18 sit three folders down but only two clicks away.¹

An audit that sorts pages by URL folder would file those pages in the wrong place. Click depth lives only in the link map.

How do you find orphan pages on your own site?

To find orphan pages on a website, compare two lists. The first holds every URL the site publishes, taken from the build output (the finished site files) or the sitemap. The second holds every URL that at least one other page links to, taken by reading the internal links on each page. Any URL in the first list and missing from the second is an orphan.

Run these five steps in order.

1. List every page the site publishes, from the build folder if the site is static (its pages are prebuilt files), or from a full crawl of the site if it is not.
2. Read every internal link on each page, navigation and footer included, and count the inbound links each URL receives. Decide up front whether navigation links count, and keep the rule the same on every page.
3. Mark any URL with zero inbound links as an orphan candidate.
4. Walk outward from the homepage by following links, and list every page the walk never touches.
5. Compare the lists from steps three and four.

Step four exists because step three has a gap. A page whose only inbound link comes from another orphan passes a zero-inbound check but is still unreachable from the homepage. local-model-api-crossover is that case, with one inbound link from another of the seven.¹

Do not use the crawler log as the first step. The six orphans here appeared in it at the same rate as their linked neighbors, so the log would have shown nothing wrong.

After you have the list, the repair is to add a link from a page that is itself reachable. A hub page that groups related articles is the obvious home for it. On this site that hub page does not exist as of the October 6 build, and this article does not create one.