Links are not crawlable: 5,272 homepage anchors, and not one javascript: href

FIELD TEST · 2026-08-28 · 27 homepages · single crawl · 5,272 anchors parsed

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-28 at 11:37 (+0800) with a browser user agent and no JavaScript execution. Every <a> element in the delivered HTML was recorded with its href, its visible text and its attributes; the saved bytes were then grepped again for the three markup patterns Google names as unparseable.

When Lighthouse reports that links are not crawlable, it is pointing at a failure that this panel has almost stopped producing. Across 5,272 anchors on 27 homepages, zero carry a javascript: href, zero use routerLink, and zero put an href on a <span>. What is left is 58 anchors with no href attribute at all, and 51 of those 58 sit on two sites.

How we measured it

One HTTP request per site, no rendering, no retries. The inclusion rule was fixed before the run: final status 200, decoded body of at least 10,000 bytes, body containing <body. Three of the 30 failed it — stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 27, the same three exclusions as the last five batches.

Each anchor was sorted into one bucket by looking at the href alone: missing attribute, present but empty, fragment-only, mailto:, tel:, javascript:, or an address a crawler can send a request to. Then the 27 saved HTML files were searched a second time, in raw bytes, for routerLink=, for <span> elements carrying an href, and for <a> elements that have an onclick but no href.

What "links are not crawlable" actually flags

Google's rule is one sentence, and it is about markup rather than intent. From Make your links crawlable, retrieved 2026-08-28: "Generally, Google can only crawl your link if it's an <a> HTML element (also known as anchor element) with an href attribute." The same page lists the shapes it will not reliably parse: <a routerLink="products/category">, <span href="https://example.com">, <a onclick="goto('https://example.com')">, and an href whose value is javascript:goTo('products').

Those four shapes are the whole warning. Here is how often each appears in 5,272 anchors:

The three empty ones are on github.com, and all three read "Reload" — an error-state control that was never meant to be a destination.

Where the 58 hrefless anchors are, and what they do

They are menus. On www.framer.com, 28 anchors have no href, and they carry visible text like Platform, Solutions, Resources and Product: these are the things you hover to open a dropdown, not the things inside it. On substack.com, the six hrefless anchors are the app's own nav rail — Home, Subscriptions, Chat, Activity, Profile — each with a matching aria-label.

Twenty-two of the 27 sites have none of this at all. The remaining pattern is concentrated rather than widespread, and on two of the four sites it is attached to controls that were never links in the first place.

The other 5,214 anchors

5,132 anchors — 97.3% of the panel — carry an href that resolves to an address a crawler can request. Another 72 are fragment-only links that jump within the page, and 7 are mailto:. No site used tel: on its homepage.

The fragment links cluster too: 38 of the 72 are on webflow.com, six on discord.com. A homepage carries a median of 161 anchors here, from 27 on substack.com to 428 on www.framer.com.

What this means for you

If you are auditing a site in 2026, the hand-written javascript: link is not where your missing pages are going. Check the two places this panel still shows a gap.

1. Menu triggers. If a dropdown trigger has no href, the pages inside it need a real <a href> somewhere else — in the footer, in a sitemap, or in the dropdown's own markup.
2. Controls dressed as links. An anchor with no href and no text, like the 23 on one site here, is a button. Google's page says the element it looks for is an anchor with an href; anything else is a guess it may or may not take.

And run the check against your delivered HTML, not your source. The whole point of this measurement is that it looks at the bytes a crawler receives. For the layer above it — whether the response arrives at all — the AI crawler accessibility check answers a different question on the same page.

What this run cannot tell you

Three things. We fetched each page once and executed no JavaScript, so any anchor a framework inserts after load is invisible here — Google's own page says those links are crawlable as long as they end up as <a href> markup, and we did not test whether they do. We also do not know what the 23 hrefless, textless anchors on one site are for; the delivered HTML gives no text, no aria-label and no image to go on. And a resolvable href is not a working link: we did not request any of the 5,132 addresses, so this says nothing about how many of them return 200.

Common questions

How did you measure this?

One fetch per homepage on 2026-08-28 with a desktop browser user agent, parsing the delivered HTML with a tolerant parser, then a second pass over the same saved bytes with plain regular expressions for the three markup shapes. Counting twice was the point: the parser normalises, and the byte-level grep does not.

Does a link without href pass any value?

Google's documentation says it can only crawl an anchor with an href, and that other tags acting as links "won't be parsed and extracted". It does not describe a partial case, and this run measured markup, not outcomes.

Are fragment links a problem?

They were not treated as one here. A #section link is a jump inside the page you are already on, which is what anchor link SEO covers on the same panel, and it does not point at a page a crawler would otherwise miss.

What should I do with an anchor that has no text?

That is the other half of the same element, and it is a much bigger number than 58. The method sits in how to write anchor text, published alongside this run.