Schema markup automat în WordPress: generare, validare și prevenirea afirmațiilor false

Schema markup poate fi generat automat în WordPress fără afirmații false numai dacă fiecare proprietate provine dintr-o sursă de adevăr declarată și poate fi regăsită în pagina vizibilă. Un generator sigur nu pornește de la întrebarea „ce JSON-LD ar arăta complet?”, ci de la „ce fapte avem voie să exprimăm, cine le deține și cât timp rămân valabile?”.

Această diferență schimbă întregul proiect. Modelul AI poate recunoaște că o pagină seamănă cu un articol, un produs sau un eveniment și poate semnala câmpurile lipsă. Nu trebuie însă să inventeze autorul, prețul, ratingul, disponibilitatea, data sau relația dintre entități. Automatizarea matură compilează adevărul editorial; nu îl completează probabilistic.

Schema markup este o interfață factuală

Google definește datele structurate ca un format standardizat pentru informațiile despre o pagină și clasificarea conținutului ei. Așadar, markupul este o a doua reprezentare a aceleiași realități, nu un text promoțional ascuns.

Contractul corect este simplu: cititorul vede afirmația, WordPress păstrează valoarea autoritativă, generatorul o transformă într-un tip cunoscut, iar HTML-ul public conține aceeași informație. Dacă una dintre aceste legături lipsește, proprietatea nu intră automat în producție.

Inventarul public vine înaintea generatorului

Începem prin a extrage toate blocurile application/ld+json, atributele Microdata și RDFa din pagini reprezentative. Scanarea trebuie făcută pe HTML-ul public, nu doar în editor: tema, pluginurile, blocurile, custom fields și serviciile externe pot emite fiecare propriul markup.

Pentru fiecare nod notăm tipul, @id, proprietățile, ownerul probabil, pagina și condiția de apariție. Căutăm duplicate, valori contradictorii, identificatori instabili și markup prezent numai pe unele template-uri. Fără baseline, un generator nou poate crea două organizații, doi autori sau două obiecte principale pentru aceeași pagină.

Un singur owner răspunde pentru fiecare nod

Ownershipul nu înseamnă că tot graful trebuie produs de o singură componentă. Înseamnă că un nod sau un set de proprietăți are o autoritate clară. Tema poate deține infrastructura globală, iar modulul editorial poate deține obiectul articolului, dar ambele trebuie să folosească aceleași @id-uri și reguli de îmbinare.

Politica declară ce păstrăm, ce completăm și ce eliminăm. Dacă o componentă existentă nu poate fi coordonată, generatorul nu publică un duplicat „mai bun”. Emite un conflict, cu sursele și diferențele, pentru remediere.

Tipul pornește din scopul vizibil al paginii

Nu alegem tipul după feature-ul cel mai atractiv. Alegem cea mai specifică descriere susținută de conținutul principal. Ghidul general Google cere ca markupul să reprezinte fidel conținutul paginii și să nu fie irelevant ori înșelător.

Catalogul funcțiilor acceptate de Google se schimbă, deci galeria oficială de structured data devine o dependență versionată. Vocabularul Schema.org poate descrie mai multe lucruri decât produce Google ca rich result; cele două contracte nu trebuie confundate.

Contractul de fapte face automatizarea verificabilă

Pentru fiecare proprietate definim: câmpul sursă, tipul, transformarea, caracterul obligatoriu sau opțional, ownerul, regula de prospețime și dovada vizibilă. De exemplu, dateModified poate proveni dintr-un eveniment editorial aprobat, nu din orice salvare tehnică a postării.

Comparația dintre plugin, REST API și WP-CLI arată cum păstrăm contractul indiferent de canalul WordPress ales. Bundle-ul schimbării reține versiunea mappingului, valorile de dinainte și după, testele și autorizarea, astfel încât același input să producă același graf.

Absența unei valori este o stare validă

Un câmp lipsă nu este invitație pentru completare creativă. Politica lui poate fi omit, block sau editorial_task. O proprietate opțională fără sursă se omite. Un câmp obligatoriu pentru feature blochează eligibilitatea. O informație importantă, dar recuperabilă, devine task pentru owner.

Această ramificare împiedică sistemul să transforme un gol de date într-o afirmație. Google recomandă mai puține proprietăți complete și corecte în locul multor valori aproximative. Completitudinea este bună numai după adevăr.

Modelul AI poate clasifica, nu certifica

Un model poate sugera tipul probabil, identifica o dată în text sau observa că lipsește un autor. Rezultatul lui rămâne candidat cu citat, poziție și scor, nu fapt. Câmpurile sensibile — identitate, bani, rating, disponibilitate, eligibilitate legală — cer o sursă structurată sau confirmare editorială.

Arhitectura agentului AI pentru WordPress separă plannerul de executorul determinist. Pentru schema, această separare este critică: modelul poate explica golul, dar numai policy-ul și mappingul aprobat produc valoarea publicată.

Modelul intermediar este tipizat înainte de serializare

Nu generăm direct un șir JSON-LD. Construim mai întâi un obiect intern cu tipuri explicite: URL normalizat, dată cu fus orar, număr, monedă, identificator, listă sau relație. Fiecare valoare păstrează provenance: source field, versiune, transformare și momentul citirii.

Recomandarea W3C JSON-LD 1.1 definește serializarea Linked Data în JSON. Modelul intern ne permite să tratăm separat adevărul factual, graful și forma finală. Astfel, o schimbare de ordine a cheilor nu pare schimbare semantică.

JSON-LD este produs determinist și sigur

Serializerul primește numai obiectul validat, ordonează stabil nodurile și proprietățile, elimină valorile nule conform politicii și folosește codificarea JSON a platformei. WordPress oferă wp_json_encode(), care este preferabil construirii manuale a unui script prin concatenare.

Nu permitem comentarii, fragmente de JavaScript, HTML arbitrar sau context remote necunoscut în valorile publicate. Outputul este un bloc application/ld+json derivat dintr-un model, nu cod executabil compus din input.

Validarea are patru întrebări diferite

Prima întrebare este dacă JSON-LD poate fi parsată. A doua este dacă tipurile și proprietățile aparțin vocabularului și au intervalele corecte. A treia este dacă obiectul îndeplinește cerințele funcției Google vizate. A patra este dacă fiecare afirmație corespunde paginii vizibile și sursei autoritative.

Google recomandă Rich Results Test pentru funcțiile sale și Schema Markup Validator pentru validarea generică Schema.org. Un singur rezultat verde nu răspunde tuturor celor patru întrebări.

Sintaxa validă nu dovedește vocabularul corect

Parserul detectează virgule, ghilimele, tipuri JSON și documente imposibil de citit. Validatorul Schema.org verifică apoi tipurile, proprietățile și relațiile. O valoare poate fi JSON perfect valid, dar plasată pe o proprietate care cere alt tip de obiect.

De aceea testele unitare folosesc exemple pozitive și negative. Un generator care trece doar „happy path” nu dovedește că respinge moneda fără preț, un @id relativ instabil sau o dată fără timezone.

Eligibilitatea Google este un contract separat

Google poate cere proprietăți obligatorii și poate recomanda altele pentru un anumit rezultat. Documentația Search Console separă erorile de câmp lipsă, tip de obiect greșit și dată fără fus orar. Mappingul nostru urmărește versiunea documentației și data ultimei verificări.

Rich Results Test arată itemuri, erori și avertismente folosind sursa randată. El dovedește eligibilitatea tehnică observată la test, nu garantează că rezultatul îmbogățit va apărea.

Concordanța vizibilă oprește afirmațiile false

Validatorul semantic extrage din pagină afirmația corespondentă sau verifică un câmp public autoritativ. Ratingul trebuie să aparțină unui sistem real de recenzii; prețul și disponibilitatea trebuie să fie actuale; autorul trebuie să fie identificat; întrebările FAQ trebuie să fie vizibile cititorului.

Regula nu este „valoarea pare plauzibilă”, ci „avem dovadă exactă”. Politicile Google interzic marcarea informației ascunse, irelevante sau înșelătoare. Dacă diferența nu poate fi decisă mecanic, change set-ul intră la aprobare.

Faptele temporale primesc termen de valabilitate

Prețurile, stocul, evenimentele, joburile și ofertele se pot strica fără nicio editare a template-ului. Fact contract-ul include observed_at, sursa, TTL și comportamentul la expirare. După termen, proprietatea se revalidează, se omite sau blochează publicarea.

Jobul de monitorizare caută și imposibilități: dată finală înaintea începutului, ofertă expirată declarată disponibilă, fus orar absent sau monedă incompatibilă. Prospețimea nu se rezolvă prin regenerarea aceluiași input vechi.

Identificatorii stabili leagă graful fără a dubla entități

@id-ul este identitatea nodului, nu o etichetă decorativă. Organizația, autorul, articolul și breadcrumb-ul trebuie să reutilizeze identificatorii canonici atunci când se referă la aceleași entități. URL-urile sunt normalizate după canonical și limbă.

Scanarea de duplicate compară atât @id, cât și semnături semantice. Două noduri fără identificator pot descrie tot aceeași organizație. Înainte de write, sistemul decide merge, ownership sau conflict; nu lasă crawlerul să ghicească.

WordPress publică printr-o singură cale controlată

Implementarea poate păstra modelul în meta tipizat și îl poate reda server-side în front-end. register_meta() permite declararea tipului, schemei REST, sanitizării și autorizării. Hookul wp_head poate tipări date în secțiunea head, dacă tema îl expune corect.

Alternativ, un bloc poate deține markupul unei componente vizibile. Indiferent de cale, există un singur renderer canonic. Nu scriem simultan același graf în conținut, meta, temă și cache. HTML-ul public, nu configurația salvată, este rezultatul de acceptanță.

Permisiunile sunt mai înguste decât accesul editorial general

Executorul are identitate dedicată, acces numai la postările și câmpurile necesare și capability verificat pe obiect. WordPress permite verificarea edit_post pentru ID-ul exact. Un generator nu are nevoie să instaleze pluginuri, să editeze tema sau să schimbe utilizatori.

Permission envelope-ul pentru WordPress explică separarea între read, propose și write. Pentru schema, accesul la valori sensibile este permis numai dacă ele sunt surse declarate; logurile nu copiază inutil date personale.

Diff-ul arată schimbarea semantică, nu doar textul JSON

Un diff util spune: nod adăugat sau eliminat, proprietate schimbată, valoare veche și nouă, sursă, motiv, severitate și efectul asupra eligibilității. Reordonarea cheilor și formatarea sunt ignorate. Reviewerul vede și pasajul public care justifică afirmația.

Politica human-in-the-loop poate preaproba actualizări deterministe cu sursă stabilă, dar cere aprobare pentru tip nou, identitate, rating, ofertă, relație între entități sau schimbare cu rază mare.

Canary-ul include și cazuri care trebuie respinse

Testăm întâi template-uri și stări reprezentative: articol complet, câmp opțional absent, pagină cu markup existent, conținut localizat, obiect expirat și valoare contradictorie. Cazurile negative sunt dovada că policy-ul se închide sigur.

Stagingul, dry-runul și readbackul păstrează secvența generală. Pentru schema adăugăm snapshotul tuturor nodurilor publice, validatorii multipli și circuit breaker dacă apar duplicate, diferențe de template ori o rată neobișnuită de respingere.

Readbackul se face din URL-ul public

După write, recitim meta și răspunsul API, apoi solicităm pagina ca vizitator delogat. Extragem toate formele de structured data din HTML-ul randat, reconstruim graful și comparăm nodurile, valorile, identificatorii și numărul de apariții cu manifestul aprobat.

Dacă markupul este injectat dinamic, Google recomandă testarea URL-ului și verificarea HTML-ului randat. Cache-ul, condițiile temei sau alt plugin pot schimba outputul după ce WordPress a acceptat operația.

Rollbackul revine la graful anterior verificat

Snapshotul conține modelul semantic, versiunea mappingului, HTML-ul public extras și hashurile. Rollbackul verifică starea curentă înainte de revenire. Dacă un editor a schimbat între timp sursa de adevăr, sistemul nu reinstalează orbește un preț ori o dată veche.

Strategia de rollback și audit trail separă restore-ul de reconciliere. După revenire, aceiași validatori și același readback public trebuie să treacă; succesul bazei de date nu este verdict final.

Monitorizarea combină scanarea completă cu Search Console

Scannerul propriu verifică toate URL-urile țintă după release și periodic: noduri lipsă, duplicate, proprietăți expirate, discrepanțe vizibile și schimbări de template. Rapoartele Rich Results din Search Console arată itemuri, nu pagini, și oferă un eșantion, deci nu înlocuiesc inventarul intern.

Pentru URL-uri absente din raport folosim URL Inspection și teste punctuale. Alertele sunt deduplicate după tip, template și versiune de mapping, astfel încât o singură eroare de renderer să nu devină sute de tichete independente.

Măsurarea separă sănătatea de rezultatul comercial

Metricile operaționale sunt acoperirea paginilor eligibile, validitatea pe fiecare strat, conflictele, timpul până la remediere, expirările prinse, readbackurile reușite și rollbackurile. Metricile de Search pot urmări itemuri valide, impresii și clickuri acolo unde rapoartele permit.

Nu atribuim automat rankingul sau traficul markupului. Google precizează că implementarea corectă nu garantează afișarea unui rich result. Matricea pentru optimizări tehnice automate păstrează intervenția, riscul și rezultatul ca elemente distincte.

Politica finală compilează numai ceea ce poate demonstra

Un sistem sigur inventariază markupul public, stabilește ownerii, alege tipul din scopul vizibil, mapează fiecare proprietate la o sursă, păstrează provenance, omite golurile, construiește un model tipizat și serializează determinist. Apoi validează sintaxa, vocabularul, feature-ul și adevărul, prezintă diff-ul, publică printr-o singură cale și recitește URL-ul public.

Schema markup automat nu este o fabrică de câmpuri, ci un compilator cu porți de calitate. Dacă sistemul nu poate arăta de unde vine o afirmație, unde o vede cititorul și cine răspunde pentru ea, nu o publică. Această limită produce mai puțin markup decât o completare fără reguli — și un graf mult mai demn de încredere.