Could the format of your internal links be killing your crawl budget?

Is this statement consistent with field observations?

Yes, but with a significant nuance: Google is improving its crawling of JavaScript, and many poorly configured SPA sites still end up indexed. Splitt's message remains valid in theory, but practice shows that Google often compensates for developers' mistakes. The real issue isn’t so much "crawled or not crawled", it’s the delay and cost in crawl budget.

A site that forces Google to execute JS to discover its internal links consumes more resources. The result: fewer pages crawled per session, slower indexing of updates, reduced priority on deep pages. For a small blog, it’s manageable. For e-commerce with 50,000 products, it’s a structural bottleneck.

What nuances should be added regarding descriptive anchors?

A "descriptive" anchor doesn’t mean over-optimized. Stuffing an internal link with "cheap men's running shoes free shipping" is counterproductive — it reeks of manipulation and degrades user experience. A natural and contextual anchor is more than sufficient.

A second point: the anchor alone doesn’t do everything. If 90% of your internal links to a page use the same exact anchor, you’re creating an artificial pattern. Vary your formulations, alternating exact anchors with semantically close anchors. Google has the means to understand that "running sneakers" and "running shoes" point to the same thematic universe.

In which cases does this rule not strictly apply?

For certain interface elements — filters, sorting, pagination — JavaScript links with client-side state management remain relevant, provided there’s a crawlable HTML fallback. A pure JS pagination link with no HTML alternative is a mistake. A hybrid system with by default and progressive enhancement in JS is the right approach.

[To be verified]: Google claims to crawl JS "like a modern browser", but indexing delays remain opaque. No public metrics allow precise quantification of the crawl budget penalty related to JS-only links. Field tests show enormous variations based on sites, their authority, and update frequency.

If you’re using a modern JS framework, switch to Server-Side Rendering (SSR) or Static Site Generation (SSG). Next.js for React, Nuxt for Vue, Angular Universal — all offer turnkey solutions to generate pre-rendered HTML with native links. The implementation cost is real, but the impact on crawling is immediate.

Intermediate solution: implement a dynamically pre-rendering system (Rendertron, Prerender.io) that serves static HTML to bots and JS to users. It’s less clean conceptually, but it works if your architecture doesn’t allow for a quick overhaul. Ensure that the content served to bots and users remains identical to avoid any suspicion of cloaking.

What best practices should be adopted for internal link anchors?

Favor contextual and natural anchors, integrated into a complete sentence rather than isolated. "Check out our complete guide on internal linking" is better than "click here" or a keyword-stuffed anchor. The context around the anchor also matters — Google analyzes adjacent words to refine thematic understanding.

Vary your formulations: if you are linking 10 times to your page /seo-technique/, alternate "technical SEO optimization", "on-site optimization techniques", "advanced technical SEO", etc. Avoid generic anchors ("learn more", "read more") unless the surrounding context compensates. And most importantly, ensure that the anchor truly reflects the content of the target page — no surprises for the user who clicks.

• Crawl the site with JavaScript disabled to identify invisible links
• Check that all critical links use tags in the source HTML
• Implement SSR/SSG or dynamic pre-rendering for JS frameworks
• Audit the link anchors: ban "click here" and favor varied descriptive formulations
• Check in Google Search Console for discovered but not explored pages
• Test crawlability with GSC's URL inspection tool