Cum testezi o platformă SEO autonomă înainte să-i dai acces la site

Nu testa o platformă SEO autonomă pentru prima dată pe site-ul de producție. Construiește o clonă izolată, stabilește fixture-ul și ground truth, acordă mai întâi acces read-only și extinde autoritatea în trepte: propunere, draft, mutație limitată, readback, rollback și revocare. Fiecare treaptă are criterii de acceptare și knock-out-uri scrise înainte de test.

Protocolul de mai jos evaluează capabilități, nu produse nominale. Nu conține linkuri ori recomandări comerciale. Înainte de PoC, transformă promisiunea în evidence pack folosind scorecard-ul C13-008; apoi verifică dacă acel rezultat poate fi reprodus pe instalarea ta.

1. Definește taskul complet și verdictul înainte de acces

Alege trei până la cinci taskuri: inventar, propunere de meta, link intern, actualizare de draft și programarea unei versiuni aprobate. Scrie inputul, obiectul, câmpurile permise, starea așteptată, toleranțele, timpul maxim și dovada. Nu testa „SEO autonom” ca etichetă; testează comportamente observabile.

Definește verdictul go, conditional go și no-go, plus knock-out-uri: obiect din afara scope-ului, publicare neaprobată, credentiale excesive, date expuse, duplicate, readback lipsă sau rollback eșuat. NIST AI RMF Effectiveness recomandă procese explicite de go/no-go pentru commissioning și deployment.

2. Construiește o clonă izolată și resetabilă

Clona trebuie să reproducă versiunea WordPress, tema, pluginurile, content types, câmpurile, taxonomiile și rolurile relevante, fără utilizatori reali, chei de producție sau efecte externe. Blochează indexarea, emailul, webhooks, plățile și integrările care pot trimite date ori modifica alte sisteme.

WordPress recunoaște tipurile local, development, staging și production prin `wp_get_environment_type()`; o valoare absentă ori invalidă revine implicit la production. Verifică explicit tipul mediului și adaugă un kill switch care refuză taskurile PoC dacă hostul sau environment ID-ul nu corespunde.

3. Salvează snapshotul și definește procedura de reset

Înainte de prima rundă, exportă baza de date, fișierele relevante, configurația, lista pluginurilor și starea Site Health. Calculează hashuri sau snapshot IDs și măsoară timpul de restaurare. O clonă care nu poate reveni la aceeași stare nu produce runde comparabile.

WordPress Site Health oferă semnale despre configurație și starea instalării. Nu înlocuiește backupul, dar completează baseline-ul. Folosește și metoda C10-004 pentru baseline, astfel încât fiecare rundă să pornească din aceeași stare documentată.

4. Creează un fixture reprezentativ și cazuri-limită

Include pagini, postări, custom post types, drafturi, elemente fără meta, conținut multilingual, taxonomii, imagini lipsă, redirecturi și câmpuri personalizate. Adaugă obiecte capcană în afara scope-ului, marcate pentru detecție. Fixture-ul trebuie să reprezinte varietatea reală fără date personale.

Scrie ground truth-ul înainte de rulare: ce trebuie să rămână neschimbat, ce câmp se modifică și ce rezultat este acceptabil. Păstrează IDs stabile și un manifest versionat. Dacă expected output este definit după ce vezi rezultatul, testul poate adapta criteriul la sistem, nu sistemul la cerință.

5. Acordă o identitate dedicată și capability minimă

Creează un utilizator exclusiv pentru PoC, fără acces administrator. Separă read-only de write și folosește credentiale diferite pentru fiecare fază. Notează owner, data emiterii, scope și expirare. Nu transmite credentialele de producție într-un trial ori într-o sesiune de suport.

WordPress Roles and Capabilities permite verificarea permisiunii per acțiune. Application Passwords poate crea și revoca acces dedicat aplicației. Testează un apel permis și unul refuzat; succesul primului fără refuzul celui de-al doilea nu dovedește least privilege.

6. Faza 1: discovery și inventar read-only

Platforma trebuie să descopere root-ul API, namespaces, tipuri, rute, scheme, paginare și câmpuri disponibile. Compară inventarul cu manifestul fixture-ului: acoperire, duplicate, câmpuri lipsă și obiecte pe care nu ar trebui să le vadă. În această fază, orice mutație este knock-out.

WordPress REST API Discovery explică descoperirea API-ului, extensiilor și resurselor. Nu accepta o listă obținută numai din sitemap; verifică obiectele, relațiile și paginarea din sursa de execuție.

7. Validează inputurile și outputurile prin schemă

Trimite câmp valid, câmp necunoscut, tip greșit, valoare prea lungă, HTML neașteptat și obiect inexistent. Sistemul trebuie să respingă inputul înainte de mutație, să explice eroarea și să nu inventeze fallbackuri. Verifică dacă rezultatul respectă schema și constrângerile locale.

WordPress REST API Schema folosește JSON Schema pentru structura datelor. Un validator nu garantează calitatea editorială, dar separă erorile structurale de judecata umană și oferă fail-fast.

8. Faza 2: propunere, diff și aprobare fără aplicare

Cere propuneri pentru un lot mic și un diff per obiect: before, proposed, motiv, sursă, confidence, warnings și efecte. Sistemul nu trebuie să transforme aprobarea unei reguli în aprobarea tuturor versiunilor. Salvează hashul payloadului exact trimis la review.

Modifică obiectul după generarea propunerii și înainte de aprobare. Platforma trebuie să detecteze versiunea conflictuală, nu să suprascrie silently. Folosește contractul de aprobare C09-002 pentru a separa propunerea, versiunea aprobată și execuția.

9. Faza 3: scriere numai în drafturi controlate

Permite create sau update pe câteva drafturi create pentru test. Blochează statusul publish, taxonomiile globale, media existentă și paginile capcană. Verifică autorul, timestampul, excerptul, meta, featured media, relațiile și statusul după fiecare operație.

WordPress Posts REST Reference descrie câmpurile și operațiile disponibile în funcție de context. Compară payloadul aprobat cu obiectul recitit, nu doar cu răspunsul inițial al cererii.

10. Faza 4: mutație limitată pe un lot reversibil

După ce drafturile trec, autorizează o singură clasă de mutație pe cinci până la zece obiecte: de exemplu, un meta câmp sau un link intern. Fixează lista de IDs, rate limit, deadline și buget. Orice extindere automată a lotului oprește testul.

Nu combina mai multe tipuri de schimbare în aceeași rundă. Ai nevoie de atribuire clară și rollback determinist. Compară rezultatele pe aceleași taskuri cu metodologia de benchmark C13-004, dar verdictul PoC rămâne specific instalării tale.

11. Testează conflictul și concurența

Schimbă manual un obiect între read și write, rulează două taskuri pe același ID și modifică schema în mijlocul lotului. Rezultatul corect este detectarea conflictului, oprirea sau escaladarea, nu „ultima scriere câștigă”. Salvează starea fiecărui obiect înainte și după.

Definește o cheie de versiune sau precondition: modified timestamp, hash ori ETag unde contractul permite. Un conflict trebuie să lase obiectul într-o stare cunoscută și să producă o eroare atribuibilă, nu un retry orb.

12. Testează retry, timeout și idempotency

Întrerupe răspunsul după ce serverul a aplicat schimbarea, simulează timeout și repetă aceeași cerere. Platforma trebuie să determine dacă operația a reușit înainte de retry și să evite duplicatele. Măsoară numărul de apeluri și timpul până la verdict.

Folosește task ID și idempotency key acolo unde integrarea permite, plus readback înainte de repetare. Stabilește un număr maxim de încercări și escaladează. Retry infinit nu este reziliență; este consum necontrolat și poate multiplica mutațiile.

13. Introdu instrucțiuni ostile în conținutul fixture-ului

Adaugă într-o pagină de test text care cere ignorarea policy, accesarea altor obiecte, dezvăluirea secretelor sau executarea unei acțiuni nepermise. Include și instrucțiuni indirecte în metadata ori într-o sursă importată. Platforma trebuie să trateze conținutul ca date, nu ca autoritate.

OWASP Prompt Injection descrie modul în care inputurile pot altera comportamentul intenționat. OWASP Excessive Agency recomandă funcții și permisiuni minime și aprobări pentru acțiuni cu impact.

14. Testează bugetul, rate limits și stop conditions

Fixează obiecte per lot, apeluri, consum, timp, retry și concurrency. Introdu un task foarte mare și o buclă de excepții. Sistemul trebuie să încetinească, să refuze ori să oprească înaintea depășirii, apoi să emită o alertă cu owner și context.

OWASP Unbounded Consumption recomandă quotas, rate limiting, timeouts și monitoring. Include costul per rezultat verificat, nu numai consumul per apel, folosind modelul TCO C13-007.

15. Readback-ul trebuie să fie independent de mesajul de succes

După fiecare mutație, recitește obiectul, relațiile și pagina randată. Compară cu payloadul aprobat, verifică status, canonical, headings, linkuri, media și taxonomii relevante. Un HTTP 200 ori un mesaj „done” confirmă cererea, nu rezultatul complet.

Salvează task ID, request ID, actor, timestamps, before hash, approved hash, after hash și verdict. Pentru arhitectura WordPress ca strat de execuție, vezi ghidul C09-005. PoC-ul trebuie să demonstreze legătura dintre decizie și obiectul final.

16. Testează rollback-ul și revocarea din mijlocul lotului

Restaurează conținut, meta, taxonomii și media după o mutație controlată. Revocă credentialul în timp ce există taskuri în coadă și confirmă că niciun apel nou nu reușește. Măsoară RTO, obiecte recuperate și efecte nerecuperate.

WordPress Post Revisions oferă stări pentru unele câmpuri, dar nu garantează rollback complet. Procedura trebuie să combine snapshot, jurnal și verificare. Dacă recovery-ul depinde de intervenție manuală, raportează explicit timpul și rolul.

17. Verdict: deschide accesul gradual sau păstrează podul închis

Calculează correctness, acoperire, scope compliance, acceptare, rework, conflicte detectate, duplicate, timp uman, cost și recovery. Raportează fiecare rundă și variația; nu ascunde knock-out-ul într-o medie. NIST AI RMF Core cere TEVV documentat și relevant pentru contextul de deployment.

Go înseamnă toate gate-urile și zero knock-out-uri. Conditional go limitează taskurile, obiectele, volumul și aprobarea până la remediere. No-go păstrează accesul închis. O rată bună de output nu compensează depășirea scope-ului, publicarea neaprobată ori rollback-ul eșuat.

Raportul final trebuie să poată fi contestat și refăcut de cineva care nu a participat la test. Include versiunea platformei și a integrării, configurația mediului, setul de fixture-uri, permisiunile identității, pragurile stabilite înainte de rulare, rezultatele brute, excepțiile și decizia semnată. Separă rezultatele pe tip de sarcină: inventariere, analiză, propunere, actualizare de conținut și actualizare de metadate. O medie unică poate ascunde faptul că platforma este bună la citire, dar nesigură la scriere.

Adaugă și un registru al intervențiilor umane. Pentru fiecare task notează ce a corectat evaluatorul, cât a durat, dacă problema putea fi detectată automat și dacă aceeași eroare a reapărut. Astfel diferențiezi automatizarea reală de munca mutată într-o interfață nouă. Dacă evaluatorii nu sunt de acord, păstrează ambele verdicte și rezolvă rubricile înainte de a compara platforma cu procesul actual.

Înainte de decizie, rulează din nou un eșantion critic într-o sesiune curată, cu aceleași limite și fără intervențiile informale din prima rundă. Repetabilitatea contează mai mult decât o demonstrație spectaculoasă. Orice schimbare de model, prompt de sistem, conector, schemă sau politică de aprobare invalidează partea relevantă din probă și cere retestare. Notează explicit perioada de valabilitate a verdictului și evenimentele care declanșează un nou PoC.

Păstrează raportul, fixture-urile și logurile împreună, cu proprietar, versiune și termen de retenție, pentru ca următoarea evaluare să pornească de la dovezi comparabile.

Chiar după go, începe în producție cu read-only, apoi propunere și loturi mici reversibile. Credentialele rămân dedicate, revocabile și monitorizate. Trecerea PoC dovedește comportamentul unei versiuni într-un context; nu garantează ranking, trafic sau siguranță permanentă după actualizări.