Răspuns scurt: pentru publisheri, diagnosticul trebuie să verifice dacă articolul, headline-ul, autorul, data, internal links și paywall/public boundary rămân robuste. Google documentează crawling, rendering și indexing pentru JavaScript. OpenAI documentează crawlere cu roluri distincte. Niciuna nu oferă un scor universal de AI crawlability.

Failure mode 1: article body este client-only

HTML-ul inițial conține shell, iar textul apare după API. Dacă rendering-ul eșuează, pagina devine aproape goală.

Failure mode 2: headline metadata nu corespunde

Title, H1, canonical și structured data pot fi injectate inconsistent.

Failure mode 3: author profile se încarcă separat

Byline-ul poate exista, dar author URL lipsește sau nu este crawlable.

Failure mode 4: infinite scroll este singura cale spre arhivă

Articolele vechi trebuie să aibă URL-uri individuale și discovery robust.

Failure mode 5: related-content links sunt event handlers

Google recomandă linkuri <a href> crawlable pentru navigația importantă.

Failure mode 6: soft 404 pentru articole retrase

SPA returnează 200 și mesaj generic.

Failure mode 7: paywall boundary este confuz

Public preview, abonament și conținut complet trebuie să urmeze politica reală fără leak sau blocare accidentală a paginii publice.

Failure mode 8: consent manager blochează body

Un script terț poate întârzia sau împiedica rendering-ul conținutului principal.

Failure mode 9: ads rup hydration

Third-party ad code poate produce erori care afectează restul paginii.

Failure mode 10: canonical depinde de client state

Rutele cu parametri pot primi canonical greșit.

Failure mode 11: bot policies sunt copiate fără context

Googlebot, OAI-SearchBot și GPTBot au roluri documentate distinct. Verifică intenția fiecărei reguli.

Failure mode 12: AI-readiness score înlocuiește testul

Un scor nu compensează lipsa body text sau linkuri robuste.

Decision tree reproducibil

  1. Statusul HTTP este corect?
  2. Canonical este stabil?
  3. Headline/body sunt disponibile robust?
  4. Byline/profile sunt accesibile?
  5. Links importante sunt crawlable?
  6. Archive discovery funcționează fără infinite scroll exclusiv?
  7. Paywall boundary este intenționat?
  8. Consent/ad failures nu elimină conținutul?
  9. Soft 404 sunt tratate?
  10. Structured data reflectă pagina?
  11. Bot policies sunt deliberate?
  12. Testul se reproduce pe mai multe templates?

Benchmark tehnic

Pentru article, live blog, category, author și archive templates salvează status, canonical, HTML, rendered text, links, errors și timestamp.

Publisher-specific checks

Verifică datePublished/dateModified, author, headline, article body, category și links către surse unde sunt relevante. Nu actualiza dateModified doar pentru schimbări tehnice minore fără policy editorială.

Paywall și privacy

Nu ocoli autentificarea sau paywall-ul. Testează suprafața publică și conturi sintetice/staging acolo unde este autorizat.

Third-party resilience

Blochează în staging ads, analytics sau widgeturi și verifică dacă body-ul rămâne lizibil.

Cum măsori

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

Search indexation și AI citations sunt outcomes externe.

Criteriu de oprire

Auditul intră în monitorizare când template-urile prioritare au baseline, P0/P1 sunt închise și release-urile trec regression tests.

Cum tratezi live blogs și paginile actualizate frecvent

Live blogs pot modifica DOM-ul și datele des. Verifică dacă intrările au URL sau anchors stabile, dacă headline-ul principal rămâne clar și dacă actualizările nu schimbă canonical-ul accidental. Data modificării trebuie să urmeze politica editorială, nu fiecare refresh tehnic.

Cum tratezi syndication

Un articol poate apărea pe parteneri sau platforme externe. Păstrează attribution și strategia canonicală potrivită cazului. Nu presupune că toate copiile vor reda author/profile metadata la fel. Auditul trebuie să distingă problema first-party de limitarea unei platforme terțe.

Paywall test matrix

Testează utilizator anonim, abonat sintetic/staging și crawler policy conform autorizării. Verifică ce text este public, ce metadata este expusă și ce nu trebuie să fie accesibil fără autentificare. Un test de crawlability nu justifică ocolirea paywall-ului.

Archive discoverability

Pentru arhive mari, paginarea și category hubs trebuie să ofere trasee robuste către articole mai vechi. Infinite scroll poate rămâne pentru UX, dar nu trebuie să fie singura metodă de discovery. Verifică linkurile la mai multe niveluri, nu doar prima pagină.

Third-party failure matrix

În staging, blochează pe rând ads, consent, recommendation widget și analytics. Body, headline, author și navigation trebuie să rămână inteligibile. Dacă un vendor rupe hydration, separă fixul aplicației de problema vendorului și păstrează evidence-ul.

Regression pack

Păstrează câte două-trei URL-uri pentru article, category, author, live blog și archive. Rulează status, canonical, HTML-vs-rendered body, crawlable links și JS errors după release-urile frontend. Un PASS este legat de versiunea testată, nu devine dovadă permanentă.

Criteriu de maturitate

Publisherul ajunge la monitorizare normală când template-urile prioritare au baseline, paywall boundaries sunt explicite și third-party failures nu elimină conținutul critic. Search sau AI visibility rămân outputs externe, nu criteriul tehnic de acceptare.

Claim ledger

  • FACT/EVIDENCE: Google documentează crawling, rendering și indexing pentru JavaScript.
  • FACT/EVIDENCE: Google recomandă linkuri HTML crawlable și tratează dynamic rendering ca workaround.
  • FACT/EVIDENCE: OpenAI documentează OAI-SearchBot și GPTBot separat.
  • NOT PROVEN: un scor universal de AI crawlability sau garanție de citare.

Concluzie

În publisheri, JavaScript este risc când body-ul, autorul sau navigarea depind de o cale fragilă. Diagnosticul bun leagă failure-ul de template și release, nu de un scor generic.

Surse revizuite

Articole conexe