Short answer: for publishers, the diagnostic should verify that the article, headline, author, date, internal links and paywall/public boundary remain robust. Google documents crawling, rendering, and indexing for JavaScript. OpenAI documents crawls with distinct roles. None provide a universal AI crawlability score.

Failure mode 1: article body is client-only

The original HTML contains the shell and the text appears after the API. If the rendering fails, the page becomes almost blank.

Failure mode 2: header metadata does not match

Title, H1, canonical and structured data can be injected inconsistently.

Failure mode 3: author profile is loaded separately

The byline may exist, but the author URL is missing or not crawlable.

Failure mode 4: infinite scroll is the only way to the archive

Legacy articles must have individual URLs and robust discovery.

Failure mode 5: related-content links are event handlers

Google recommends crawlable <a href> links for important navigation.

Failure mode 6: soft 404 for retired items

SPA returns 200 and generic message.

Failure mode 7: paywall boundary is confused

Public preview, subscription and full content must follow the actual policy without leaking or accidentally blocking the public page.

Failure mode 8: consent manager blocks body

A third-party script may delay or prevent the main content from rendering.

Failure mode 9: ads break hydration

Third-party ad code can produce errors that affect the rest of the page.

Failure mode 10: canonical depends on client state

Routes with parameters can receive the wrong canonical.

Failure mode 11: bot policies are copied without context

Googlebot, OAI-SearchBot, and GPTBot have separately documented roles. Check the intent of each rule.

Failure mode 12: AI-readiness score replaces the test

A score does not make up for a lack of body text or robust links.

Reproducible decision tree

  1. Is the HTTP status correct?
  2. Is Canonical stable?
  3. Are headline/body available robust?
  4. Are bylines/profiles accessible?
  5. Are important links crawlable?
  6. Does archive discovery work without infinite scroll exclusively?
  7. Is the paywall boundary intentional?
  8. Don't consent/ad failures remove content?
  9. Are soft 404s handled?
  10. Does structured data reflect the page?
  11. Are bot policies deliberate?
  12. Is the test reproduced on several templates?

Technical benchmark

For article, live blog, category, author and archive templates save status, canonical, HTML, rendered text, links, errors and timestamp.

Publisher-specific checks

Check datePublished/dateModified, author, headline, article body, category and links to sources where relevant. Do not update dateModified only for minor technical changes without editorial policy.

Paywall and privacy

Do not bypass authentication or paywall. Test public surface and synthetic/staging accounts where authorized.

Third-party resilience

Block in staging ads, analytics or widgets and check if the body remains readable.

How do you measure

Critical-content parity, crawlable-link coverage, soft-404 rate, hydration errors, third-party failure rate and template coverage.

Search indexation and AI citations are external outcomes.

Stop criterion

The audit enters monitoring when the priority templates have a baseline, P0/P1 are closed and releases pass regression tests.

How do you handle live blogs and frequently updated pages

Live blogs can change the DOM and data often. Check that entries have stable URLs or anchors, that the main headline remains clear, and that updates don't accidentally change the canonical. The modification date must follow the editorial policy, not every technical refresh.

How do you deal with syndication

An article may appear on partners or external platforms. Keep attribution and canonical strategy appropriate. It does not assume that all copies will render author/profile metadata the same. The audit must distinguish the first-party issue from the limitation of a third-party platform.

Paywall test matrix

Test anonymous user, synthetic subscriber/staging and crawler policy according to authorization. It checks what text is public, what metadata is exposed, and what should not be accessible without authentication. A crawlability test does not justify bypassing the paywall.

Archive discoverability

For large archives, pagination and category hubs must provide robust paths to older articles. Infinite scroll can remain for UX, but it doesn't have to be the only method of discovery. Check links at multiple levels, not just the first page.

Third-party failure matrix

In staging, block ads, consent, recommendation widget and analytics in turn. Body, headline, author and navigation must remain intelligible. If a vendor breaks hydration, separate the app fix from the vendor issue and keep the evidence.

Regression pack

Keep two or three URLs each for article, category, author, live blog and archive. Run status, canonical, HTML-vs-rendered body, crawlable links and JS errors after frontend releases. A PASS is linked to the tested version, it does not become permanent proof.

Maturity criterion

The publisher reaches normal monitoring when priority templates have a baseline, paywall boundaries are explicit and third-party failures do not remove critical content. Search or AI visibility remain external outputs, not the technical criteria for acceptance.

Claim ledger

  • FACT/EVIDENCE: Google documents crawling, rendering, and indexing for JavaScript.
  • FACT/EVIDENCE: Google recommends crawlable HTML links and treats dynamic rendering as a workaround.
  • FACT/EVIDENCE: OpenAI documents OAI-SearchBot and GPTBot separately.
  • NOT PROVEN: a universal AI crawlability score or citation guarantee.

Conclusion

In publishers, JavaScript is a risk when body, author, or navigation depend on a fragile path. Good diagnostics link failure to template and release, not to a generic score.

Sources reviewed

Related insights