Does Google count JavaScript-rendered links? In 2026 it renders JS but defers it, caps it at 2MB, and AI crawlers ignore it entirely. The link-equity risks, a three-render diagnostic, and the fixes.
| TL;DR In March 2026 Google removed the JavaScript warning from its SEO docs, and the industry read that as ‘JS links are fine now.’ The load-bearing caveat — ‘provided rendering completes successfully’ — is exactly where backlink counting still breaks.Google only reliably counts a link that is a real <a> element with an href. Buttons, onclick handlers, span-links and router-links without a real href are not parsed as links — rendered or not.Rendering is deferred (a render queue of seconds to days), capped (a 2MB fetch limit), and not guaranteed. A link that exists only after JavaScript runs is best-effort and slow, not certain.The bigger 2026 shift: AI crawlers — GPTBot, ClaudeBot, PerplexityBot and the rest — render no JavaScript at all. A JS-only backlink is invisible to the fastest-growing discovery channel.Two directions matter: links on your pages bleeding equity, and backlinks you earned that sit on a publisher’s JS-rendered page and may never be counted as pointing to you.Run the Three-Render Link Test, then ship the link-crawlability audit at the end as your Monday-morning deliverable. |
For a decade the safe assumption was that JavaScript and search engines did not mix, and SEOs treated any link that depended on JS with suspicion. Then in March 2026 Google quietly removed the long-standing JavaScript caution from its official documentation, and a chunk of the industry concluded that the problem was solved: Google renders JavaScript, so JS links must be fine. That conclusion is half right and, for link building specifically, dangerously incomplete. The phrase Google actually stands behind is that links are crawlable when inserted by JavaScript ‘as long as it uses the HTML markup shown’ and the rendering completes successfully. Every word of that caveat is doing work.
Here is what gets missed when people stop reading at ‘Google renders JavaScript.’ Rendering is deferred, not immediate: a freshly discovered URL can sit in a render queue from seconds to days before its rendered state is processed, and links that exist only in that rendered state are discovered late, if at all. Rendering is capped: Google fetches only the first 2MB of an HTML document, and anything past that cutoff is never processed. And rendering is conditional: only a real anchor element with a resolvable href is reliably parsed as a link in the first place. Pile those three facts together and you get the uncomfortable reality of JavaScript backlink crawling in 2026 — Google can count a JS-dependent link, but it is slower, less certain, and conditional on implementation details most publishers never check.
Then there is the part that did not exist when the old advice was written. The crawlers shaping discovery are no longer just Googlebot and Bingbot. GPTBot, ClaudeBot, PerplexityBot, Bytespider and Meta-ExternalAgent now pull the web to power AI answers — and none of the major AI crawlers execute JavaScript. For them, a link that only appears after JS runs simply does not exist. So a backlink you earned, rendered client-side on a publisher’s page, can be invisible to Google’s render queue for days and invisible to AI search permanently. This article is the link-builder’s guide to what Google — and increasingly everyone else — misses, how to test for it in minutes, and how to stop building links that nobody counts.
The gap between the 2026 consensus and the evidence is wide enough to tabulate:
| What practitioners now believe | What the 2026 evidence shows |
| Google removed the JS warning, so JS links are fine | The removal kept the caveat ‘provided rendering completes successfully’ — that is where link counting breaks |
| If a user can click it, Google can crawl it | Google follows href attributes, not clicks; onclick and button ‘links’ are not parsed as links |
| Rendered = counted | Render is deferred (queue of seconds to days), capped at 2MB, and not guaranteed |
| SEO is just about Google now | AI crawlers render zero JavaScript; JS-only links are invisible to AI search entirely |
| A link is a link wherever it lives | A backlink on a publisher’s client-side page may never be counted as pointing to you |
Why the existing JavaScript-SEO guides miss the link question
Search the topic and the strongest results are genuinely good — but they are about the wrong thing for a link builder. The authoritative pieces walk through how Google’s Web Rendering Service handles JavaScript, the two-wave model, the 2MB limit and the doc-warning removal, and the best developer-focused write-ups teach you to ‘View Source’ to see whether your content is visible. All useful. None of them answer the question that decides whether your link building paid off: is this specific link counted, by whom, and when.
Four gaps run through the entire field, and they are exactly what this guide closes. First, the existing guides conflate content visibility with link counting — but a page can render its text perfectly and still ship its links as uncrawlable click handlers. Second, they treat the problem as one-directional (your own site) and ignore the harder case: backlinks you earned that sit on someone else’s client-side-rendered page. Third, they mention AI crawlers in passing without connecting the dots — that a JavaScript-only link is not merely slow for Google but permanently invisible to AI search. Fourth, almost none give a link-specific diagnostic you can run in a minute and at scale. The Three-Render Test and the audit below exist to fix all four.
The Three-Render Link Test: who actually counts your link
Before any fix, you need a way to see a link the way each crawler sees it. Every link that matters can be checked at three layers, and where it first appears tells you precisely who will count it. This is the diagnostic spine of the whole article — run it on any link you are about to build, buy or rely on, and you will know in under a minute whether it is real.
| Layer | How to see it | If the link appears here, it is counted by… |
| 1. Raw HTML | View Source / curl (pre-JavaScript) | Everyone — Googlebot, Bingbot, and all AI crawlers (GPTBot, ClaudeBot, etc.) |
| 2. Rendered DOM | DevTools Elements / headless render (post-JavaScript) | Google — but only after the render queue, eventually, best-effort. Not AI crawlers. |
| 3. Markup type | Inspect the element: is it <a href> or a button/onclick/span? | Only a real <a> with a resolvable href counts as a link at all |
The hierarchy is unforgiving. A link in raw HTML as a proper anchor is counted by everything, immediately. A link that only appears in the rendered DOM is on Google’s slow, best-effort path and invisible to AI crawlers. A ‘link’ that is a button or an onclick handler is counted by nobody, no matter how it renders. The sections below explain why each layer behaves this way, then turn the test into an audit you can run at scale. If you only build one thing, skip to the link-crawlability audit at the end.
How Google crawls and counts links in 2026
Google’s pipeline is two-wave, and the distinction is the root of every JavaScript link problem. In the first wave, Googlebot fetches the raw HTML and immediately extracts the links it finds there, adding them to the crawl queue. The page then goes into a render queue, where the Web Rendering Service executes the JavaScript and CSS with an evergreen headless Chromium and produces the final DOM. Any links that appear only after that render are extracted in the second wave and added back to the crawl queue — later. As technical analyses of the render queue have long shown, a URL can wait from a few seconds to several days for that second wave, which means a JS-injected link is discovered on a delay you do not control.
Two hard limits sit on top of this. The first is the 2MB fetch cap: as Gary Illyes detailed in Google’s 2026 explainer on how crawling works, only the first 2MB of an HTML document is processed, with external scripts and stylesheets fetched separately under their own limits. A link buried past that cutoff — common on bloated pages that inline huge scripts — is never seen. The second is conditionality: pages that return non-200 status codes, or that are set to noindex, may not be rendered at all, so any links they would have produced never materialise.
Underneath the rendering question is a more basic one that no amount of rendering fixes: what counts as a link. Google’s own link documentation, updated at the end of 2025, is blunt — Google can generally only crawl a link that is an <a> element with an href attribute, and most other formats are not parsed or extracted. A button that navigates via JavaScript, an onclick handler on a span, a framework router-link with no real href, or an href=”javascript:…” are all, in Google’s wording, not recommended and not reliably followed. Martin Splitt has made the same point for years: use proper link markup and the links will be found. Rendering can build a proper anchor dynamically and Google will accept it — but if the rendered output is still a button or a scripted click, rendering changes nothing. If you want the deeper fundamentals of what actually makes a backlink count, that is the upstream reading; here we are concerned with whether the link is even seen.
It is worth separating two things the industry routinely blurs: discovery and counting. Google may attempt to request a URL it finds in a malformed ‘link’ — it is aggressive about discovery — but discovering a URL is not the same as recognising a link, attributing its anchor text, or passing equity through it. A scripted pseudo-link might get the destination crawled while contributing nothing as a ranking signal, which is the worst of both worlds: you think you have a link, the destination is in the index, and no authority flows. For link building, counting is what matters, and counting requires the real anchor. This is also why the old ‘100 links per page’ worry is obsolete — Google retired that guideline long ago, and the live concern is not how many links a page has but whether each one is a crawlable anchor carrying the equity you intended.
Two directions of the problem: links you place and links you earn
‘JavaScript and links’ bundles two problems that behave differently and need separating, because one is about your own architecture and the other is about pages you do not control.
Direction A — links on your own pages bleed equity
This is the internal case, and it is where most sites lose authority without noticing. Modern frameworks make it trivial to ship a main navigation, a related-posts module or a footer as client-side components that only become real anchors after hydration — or never, if they are wired as click handlers. When a main navigation is JavaScript-only, it stops being useful for passing link equity, and deep pages that depend on it for discovery risk being crawled late or orphaned entirely. Every internal link is a vote you are casting for your own pages; rendering them client-side casts those votes slowly and quietly drops some on the floor. This is a foundational concern for any internal linking and site-architecture strategy, and it is invisible unless you test the raw HTML.
Direction B — backlinks you earned that the source renders client-side
This is the backlink-counting white space the rest of the industry skips. You run an outreach campaign, earn a placement on an industry publication, and the link is right there in the live page — but the publisher runs a JavaScript-heavy CMS or theme that injects the article body, or your specific link, client-side. To Google, that backlink enters the render queue and is counted late and best-effort. To every AI crawler, it does not exist. You earned a link that is real to a human reader and partially or wholly invisible to the systems that decide rankings and AI citations. This is why placement verification has to include a rendering check, especially for guest posts and editorial placements, where you have no control over how the host renders its pages. A link you cannot see in the source is a link you cannot fully bank.
The AI-crawler blind spot: the cost that did not exist before
The single biggest change to this topic since the old JavaScript advice was written is that Google is no longer the only reader that matters. AI crawlers now index the web to feed chatbot answers and AI search, and the testing is consistent: the major AI crawlers do not execute client-side JavaScript. GPTBot, ClaudeBot, PerplexityBot, Bytespider and Meta-ExternalAgent read the raw HTML and stop. There is no render queue, no second wave, no eventual catch-up — what is in the source is all they ever see.
For link building this reframes the stakes. A backlink’s value in 2026 is no longer only the ranking signal it passes to Google; it is also whether it helps you show up in AI-generated answers and whether the citing page can even be associated with you by an AI system. A JavaScript-only link contributes nothing to that second channel, because the AI crawler never sees it. The same logic that governs ranking in classic search now governs whether your brand surfaces in AI answers and featured-snippet-style results: the content and the links have to be in the HTML the crawler actually fetches. If your link-building and content are quietly client-side rendered, you are opting out of the discovery channel growing fastest, and you will not see it in any Google report because Google is not the one ignoring you.
This is also why a JavaScript audit now belongs inside your AI Share-of-Voice work, not in a separate technical silo. The pages you most want cited in AI answers — your data studies, your definitive guides, the linkable assets your outreach is built around — are worthless to an AI crawler if they ship client-side. The brutal version: you can run a flawless digital-PR campaign, earn the perfect citation, and contribute nothing to AI visibility because either your page or the citing page renders the link in JavaScript. The crawlers that build AI answers took a snapshot of raw HTML and moved on. Auditing for this is no longer a developer nicety; it is a prerequisite for showing up in the answers that increasingly sit above the classic ten blue links.
What this changes for how you value a link
Once you accept that a link’s reach now spans two channels — classic search and AI answers — a single backlink stops having a single value. The same placement can be worth full value (a real anchor in raw HTML, counted by everyone immediately), partial value (a real anchor that only appears after render, counted by Google late and by AI never), or near-zero value (a scripted pseudo-link counted by no one). The domain authority of the host tells you none of this; only the render layer does.
The practical consequence is that rendering status deserves a column in your link tracking, right next to anchor and rel attribute. When you evaluate a prospective placement or buy, the question is no longer just ‘is this a strong site’ but ‘will this link sit in the raw HTML.’ A mid-authority publisher that server-renders its articles can be a better link than a higher-authority site that renders everything client-side, because the first link is counted by every system on day one and the second is on the slow path for Google and invisible to AI. Feeding that distinction back into target selection — favouring server-rendered hosts for the links that matter most — is one of the highest-leverage, least-practised moves in technical link building, and it costs nothing but a raw-HTML check before you commit.
The diagnostic in practice: seeing what each crawler sees
The Three-Render Test becomes concrete with three quick checks, escalating from a one-line shell command to a proper raw-versus-rendered diff. Reproducibility metadata sits above the substantive snippet, per this site’s standing rule for any piece that ships code.
Check 1 — Is the link in the raw HTML? (the AI-crawler view)
This is the most important single check, because raw HTML is what every crawler, including AI bots, sees before any JavaScript runs. If your target link is not here, it is invisible to AI search regardless of what Google eventually renders.
| # Does the backlink exist in the raw HTML, as a real anchor? curl -sL “https://publisher.example/article” \ | grep -oiE ‘<a[^>]*href=”[^”]*yourdomain\.co\.uk[^”]*”[^>]*>’ || echo “NOT IN RAW HTML” # Quick scan for non-crawlable ‘links’ on your own page: curl -sL “https://yoursite.co.uk/” \ | grep -oiE ‘(onclick=|href=”#”|href=”javascript:)’ | sort | uniq -c |
If the first command prints NOT IN RAW HTML but the link is visible in a browser, it is JavaScript-injected: best-effort for Google, invisible to AI crawlers. The second surfaces the click-handler and placeholder ‘links’ on your own pages that no crawler will follow.
Check 2 — Find uncrawlable anchors in the rendered page (browser console)
Paste this into the browser console on any page to list anchors that have no real, resolvable href — the ones that look like links to a user but are dead ends to a crawler.
| // Browser console: list anchors a crawler cannot follow document.querySelectorAll(‘a’).forEach(a => { const href = a.getAttribute(‘href’); if (!href || href === ‘#’ || href.startsWith(‘javascript:’)) { console.log(‘UNCRAWLABLE:’, a.textContent.trim().slice(0, 40), ‘|’, a.outerHTML.slice(0, 90)); } }); |
Check 3 — Raw-vs-rendered link diff (what Google sees late, and AI never sees)
To audit at scale, compare the set of real anchor links in the raw HTML against the set in the rendered DOM. Anything that appears only after rendering is your ‘Google-late, AI-never’ set — the links most at risk.
| Reproducibility Python 3.11+. Libraries: httpx (raw fetch), Playwright with Chromium (render). Pin exact versions in requirements.txt. Google’s WRS uses an evergreen headless Chromium, so a current Chromium render approximates — never perfectly equals — what Google sees. Tested: June 2026. |
| # Raw vs rendered link diff — finds JS-only links (Google-late, AI-never) import asyncio, httpx from selectolax.parser import HTMLParser from playwright.async_api import async_playwright def anchors(html: str) -> set: return {a.attributes.get(“href”) for a in HTMLParser(html).css(“a[href]”) if (a.attributes.get(“href”) or “”).strip() not in (“”, “#”) and not (a.attributes.get(“href”) or “”).startswith(“javascript:”)} async def raw_links(url: str) -> set: async with httpx.AsyncClient(timeout=20, headers={“User-Agent”: “lbj-render-audit/1.0″}) as c: r = await c.get(url, follow_redirects=True) return anchors(r.text) async def rendered_links(url: str) -> set: async with async_playwright() as p: browser = await p.chromium.launch() page = await browser.new_page() await page.goto(url, wait_until=”networkidle”, timeout=30000) # wait for hydration html = await page.content() await browser.close() return anchors(html) async def audit(url: str) -> dict: raw, rendered = await asyncio.gather(raw_links(url), rendered_links(url)) return { “url”: url, “in_raw_html”: len(raw), # seen by everyone, incl. AI crawlers “js_only_links”: sorted(rendered – raw), # Google-late, AI-never -> the risk set “lost_after_render”: sorted(raw – rendered), # present in source, gone after JS (rare, investigate) } |
The js_only_links set is the deliverable: those are the links a JavaScript-dependent page is asking Google to discover slowly and AI crawlers to ignore. The fix is to get them into the raw HTML. The lost_after_render set is rarer and worth investigating — usually a script rewriting or removing links after load.
A worked example: the placement that looked live but did not count
Make it concrete. A UK fintech earns a contextual link in a feature on a respected industry publication — exactly the kind of editorial placement a good outreach campaign is built to win. The link is visible on the page, the anchor is right, and the team reports it as a win. Three months later the page still has not moved the needle and the brand is not turning up in AI answers about the topic, despite the citation sitting on an authoritative source.
Running the Three-Render Test takes a minute. View Source on the article and search for the fintech’s domain: nothing. The link is not in the raw HTML. Inspect the rendered page and it is there — the publisher migrated to a JavaScript-heavy CMS that injects the article body client-side after load. So the link exists only in the rendered DOM. The diagnosis writes itself: Google will discover the link, but on the slow render-queue path rather than the immediate first wave, and every AI crawler — which never renders — will never see it at all. The placement is real to a human and worth perhaps a third of what the team assumed.
There is no fix on the fintech’s side, because they do not control the publisher’s stack — but the diagnosis changes the decisions. It tells them to weight that placement lower in reporting, to ask the publisher whether the article can be server-rendered or the link added to a server-rendered summary, and, most importantly, to bias future outreach targets toward publishers whose content appears in raw source. The lesson generalises: a rendering check belongs in placement verification, because a link you cannot see in the source is a link you cannot fully bank — however prestigious the domain.
The fixes: get the link into the HTML the crawler fetches
Every remedy reduces to the same principle — the links that matter must be real anchors present in the HTML a crawler receives, ideally before any JavaScript runs. In priority order:
- Server-side render or statically generate the pages that carry important links. SSR and SSG put real anchors in the initial HTML, which serves Google’s first wave and every AI crawler at once. Google’s settled 2026 guidance treats SSR/SSG as the foundation and dynamic rendering as a migration workaround, not a new build strategy.
- Use real <a href> markup, always. If you need JavaScript behaviour on a link, attach it to an anchor that already has a resolvable href as its fallback — never an onclick on a button or span. This is the cheapest, highest-leverage fix and it is entirely in your control.
- Keep critical links above the 2MB cutoff. Move heavy inline scripts to external files so your important anchors are well inside the first 2MB of HTML Google fetches.
- Do not block JS and CSS resources in robots.txt. If the WRS cannot fetch the scripts a page needs, it cannot render the links those scripts create. Let Google fetch what it needs to render.
- Verify with the URL Inspection tool. Use Search Console’s URL Inspection to view the rendered HTML Google actually produced, and confirm your links are in it. This is the closest thing to seeing through Google’s eyes.
For backlinks you are earning rather than building, you cannot change the publisher’s stack — but you can choose targets wisely and verify. Favour publishers whose articles appear in raw source (most established editorial sites still server-render their content), and run the raw-HTML check on any high-value placement before you count it. The crawl and audit tools that make this routine sit in the link-building tools round-up.
The cost at scale: render budget and where to spend your fixes
Unlike an AI-workflow audit, the cost here is not measured in API tokens — it is measured in crawl and render budget, and in engineering time. Every JavaScript-dependent page costs Google more to process: it must be fetched, queued, rendered with a headless browser, and re-extracted, which is materially more expensive than reading static HTML. On a large site that render budget is finite, and pages that are cheap to crawl get crawled more often. So client-side rendering does not just risk individual links — it slows how quickly your whole site’s links and updates are discovered.
The practical implication is triage, not a full rebuild. You rarely need to server-render an entire site to fix link counting; you need to ensure the pages and modules that carry link equity — your main navigation, your money pages, your most-linked content, and any page hosting backlinks you care about — put real anchors in the raw HTML. Run the raw-vs-rendered diff across your top templates, rank the offenders by the value of the links they carry, and fix the highest-value JavaScript-only links first. A UK SaaS with a React marketing site usually gets 90% of the benefit by server-rendering its navigation and a dozen key templates, leaving low-value interactive widgets client-side. The benchmark data behind these prioritisation calls lives in the statistics hub.
Failure thresholds and cheaper fallbacks
- Reach for the full Playwright diff only when the raw-HTML curl check is ambiguous; for a single link, the one-line check answers it for free.
- Server-side render only the templates carrying meaningful link equity; if a page hosts no important links, leave it client-side rather than paying to SSR everything.
- If a page must stay client-side, prerender or statically snapshot it as the fallback so a crawler still receives real anchors in the HTML.
Where this breaks in production
The diagnostic above is the happy path. Here is what produces false readings at scale, and how to avoid being fooled.
Hydration timing false negatives
If your headless render reads the DOM before hydration finishes, real links look missing and you raise a false alarm. Wait for network-idle or a specific selector before extracting, and treat a not-found in the rendered set as ‘investigate’, not as confirmed link loss.
Render-queue delay misread as ‘Google ignored it’
A JS-only link not yet showing in Search Console is often simply still in the render queue, which can take days. Do not conclude Google has rejected a link until well past the second wave — and remember the fix (get it into raw HTML) removes the wait entirely.
The 2MB cutoff hiding the real fault
A link can be a perfect anchor and still be invisible because it sits past the 2MB HTML limit on a script-bloated page. If a clearly valid link is not crawled, check its byte position before blaming rendering.
Blocked resources and noindex pages
If robots.txt blocks the scripts a page needs, the WRS cannot build the links; if a page is noindex or returns a non-200, it may never be rendered at all. A ‘missing link‘ is sometimes a blocked resource or an unrenderable page, not a markup problem.
Render drift between your tools and Google
Your local Chromium is not Google’s WRS — versions, timeouts and resource limits differ. Use the result as a strong signal, then confirm anything high-stakes with the URL Inspection tool’s rendered HTML, which shows what Google actually produced rather than what your machine did.
Your Monday-morning deliverable: the link-crawlability audit
Pull the three checks into one repeatable pass you can run this week against your own templates and your highest-value backlinks. The point is not a one-off cleanup; it is a habit that stops you building links nobody counts.
| The audit, step by step Raw-HTML check. Run the curl command on each money page and each high-value placement. Any important link missing from raw HTML is flagged.Console anchor scan. On the same pages, run the querySelectorAll snippet to catch buttons, span-links and javascript: hrefs masquerading as links.Raw-vs-rendered diff. Run the Python audit across your top templates; collect the js_only_links set and rank it by the value of the links it contains.Confirm with URL Inspection. For the highest-value offenders, check Search Console’s rendered HTML to see what Google actually produced.Fix in priority order. Convert click-handlers to real anchors, server-render the templates carrying the most equity, and re-run the diff to confirm the links now sit in raw HTML. |
Wire this into your monthly technical pass and your placement reporting, and the JavaScript link problem stops being an invisible tax on your link building. You will know — not assume — that the links you place and the links you earn are present in the HTML the crawlers actually fetch, which in 2026 means present for Google’s first wave and for every AI crawler at once.
Frequently asked questions
Does Google count links that are added with JavaScript?
It can, but only if the JavaScript inserts a proper anchor element with a resolvable href, and only after the rendering step — which is deferred to a render queue that can take from seconds to days. The link is best-effort and slow, not guaranteed. A click handler, a button, or a router-link without a real href is not counted as a link at all, rendered or not.
Why did Google remove the JavaScript warning from its docs in 2026?
Google removed the blanket caution because its rendering has genuinely improved and it wanted to stop discouraging modern frameworks. The qualifier it kept — that links and content are processed ‘provided the rendering completes successfully’ — is the part that still matters for link counting, because successful, timely rendering is not guaranteed for every implementation.
Do AI crawlers like GPTBot and ClaudeBot render JavaScript?
No. Testing through 2026 consistently shows the major AI crawlers — GPTBot, ClaudeBot, PerplexityBot, Bytespider and Meta-ExternalAgent — do not execute client-side JavaScript. They read the raw HTML and stop, so any link or content that only appears after JavaScript runs is invisible to AI search.
How do I check if a backlink will actually be counted?
View the source of the page (not Inspect Element) or run a curl request and search for your link. If the link is a real anchor with your URL in the href and it appears in the raw HTML, it is counted by everyone. If it only appears when you inspect the rendered page, it is JavaScript-injected — slow for Google, invisible to AI crawlers.
Is server-side rendering necessary for link building?
Not for the whole site, but for the pages and modules that carry link equity it is the safest choice. Server-side rendering or static generation puts real anchors in the initial HTML, serving Google’s first wave and every AI crawler at once. Reserve client-side rendering for interactive widgets that carry no important links.
Does a JavaScript link pass link equity?
Only if it resolves to a real, crawlable anchor that Google renders successfully — and even then it is on the slow path. A main navigation or internal-linking module rendered as JavaScript-only click handlers passes little or no equity, because Google never parses those as links. Use real anchor markup if you want the link to vote for the destination.
How long does Google take to render and count a JavaScript link?
There is no fixed figure. A link found in the raw HTML is queued for crawling immediately, but a link that only appears after JavaScript runs waits in the render queue, which can take anywhere from a few seconds to several days depending on the site’s crawl priority and Google’s capacity. Because the timing is outside your control, the reliable fix is to put important links in the raw HTML so they never depend on the render queue at all.
Part of Cluster AD, the advanced technical-SEO series for link equity. The headline for 2026 is not ‘Google can’t do JavaScript’ — it plainly can. It is that link counting depends on real anchors, timely rendering and the 2MB cutoff, and that an entire new class of AI crawlers sees only the raw HTML. Build links that live in the source, and you are counted by everyone, immediately. Audit the rest, fix the highest-value offenders first, and treat ‘is it in the raw HTML’ as the first question you ask of any link you place or earn.
