Ce optimizări tehnice SEO pot rula automat și care au nevoie de aprobare

O problemă SEO poate fi detectată automat fără ca remedierea ei să fie automat sigură. Un crawler poate demonstra că un URL răspunde 404, dar nu poate deduce întotdeauna destinația corectă. Un validator poate găsi un canonical lipsă, dar alegerea canonicalului schimbă semnalele de indexare. Diferența dintre observație și autoritate este centrul unei automatizări responsabile.

C13-014 a definit traseele generale automat, sample, approval și block. Aici le aplicăm concret taskurilor tehnice: ce poate rula singur, ce poate fi corectat numai într-o allowlist și ce trebuie prezentat ca diff unei persoane care înțelege efectul asupra site-ului.

Separă detectarea de remediere

Detecția citește starea și produce dovezi: status HTTP, canonical observat, directive robots, linkuri, sitemap, hreflang, schema, dimensiuni media și performanță. Ea poate rula frecvent și pe un volum mare dacă respectă rate limits și nu alterează ținta. Rezultatul este un finding versionat, nu o comandă de editare.

Remedierea scrie în WordPress, configurație, template, server sau CDN. Ea trebuie să declare starea dorită, obiectele afectate, raza maximă, precondiția, metoda de revenire și verificarea. Arhitectura planner–executor–verifier din C13-010 păstrează această separare chiar când aceeași platformă orchestrează întregul flux.

Patru trasee sunt mai utile decât regula „automat sau manual”

Traseu	Exemple	Control minim
Detectare automată	404, lanțuri de redirect, canonical inconsistent, schema invalidă	read-only, dovezi, deduplicare
Remediere limitată	regenerare sitemap, completare atribut tehnic determinist, purge după release	allowlist, limită, precondiție, rollback
Aprobare pe diff	redirect nou, noindex, canonical, hreflang, template, proprietate factuală	preview exact, owner, expirare, readback
Blocare	destinație inventată, regulă regex neverificată, modificare în masă fără snapshot	fără write; escaladare

„Automat” nu înseamnă fără aprobare organizațională. Înseamnă că o politică aprobată anterior acoperă o clasă îngustă de cazuri. C09-002 explică de ce autorizația este legată de o versiune și de condiții; matricea de aici stabilește ce clase pot primi acea autorizație anticipată.

Un task intră pe traseul automat numai dacă intenția este deterministă

Starea corectă trebuie să poată fi calculată dintr-o sursă de adevăr, nu ghicită din asemănări. Dacă un registru intern spune că attachmentul 42 aparține postării 17, reluarea relației poate fi deterministă. Dacă sistemul caută „cea mai apropiată pagină” pentru un URL dispărut, intenția rămâne semantică și cere revizuire.

Adaugă alte condiții simultane: target allowlistat, un singur tip de câmp, rază mică, operație idempotentă, before hash exact, rollback testat și verificare publică. Dacă lipsește una, taskul se mută spre aprobare sau blocare. Scorul de încredere al unui model nu înlocuiește aceste probe.

Linkurile rupte se detectează automat, dar destinația nu se ghicește

Un crawler poate verifica hrefurile și poate grupa 404, timeouturi, bucle și redirecturi multiple. Google documentează forma linkurilor crawlable; validatorul poate verifica elementul, URL-ul rezolvabil și răspunsul fără să modifice nimic.

Corecția poate rula automat numai când mappingul vechi–nou provine dintr-un registru aprobat și anchorul rămâne adevărat în context. Alegerea unei pagini doar după cuvinte comune, eliminarea linkului sau rescrierea anchorului schimbă sensul editorial. Sistemul pregătește propunerea și pagina-sursă, iar reviewerul decide.

Sitemapul acceptă regenerare, nu selecție editorială oarbă

Regenerarea unui sitemap din obiecte publicate, indexabile și canonicale poate fi o operație automată dacă regulile sunt stabile. Google cere URL-uri absolute și recomandă includerea URL-urilor canonicale dorite în rezultate. Verifică encodingul, statusul, limitele fișierului și referințele din index.

Nu elimina automat un URL doar fiindcă traficul lui a scăzut sau un audit îl numește „thin”. Indexabilitatea este o decizie editorială și comercială. Sistemul poate semnala discrepanța dintre status, canonical, robots și sitemap; schimbarea politicii de includere cere aprobare.

Canonicalul este un semnal semantic cu impact mare

Google descrie redirectul și rel=canonical drept semnale puternice, iar includerea în sitemap drept semnal mai slab. Un validator poate găsi canonical lipsă, relativ, neindexabil, redirectat sau diferit de sitemap. Acest diagnostic este sigur de automatizat.

Alegerea URL-ului reprezentativ nu se face automat doar după similaritate textuală. Produse, filtre, localizări și articole actualizate pot părea duplicate, dar au intenții diferite. Scrierea canonicalului cere mapping aprobat, diff, verificarea semnalelor care trebuie să converge și plan de rollback.

Redirecturile simple pot avea mapping preaprobat

Google separă redirecturile permanente de cele temporare și recomandă variante server-side când sunt disponibile. Detectarea lanțurilor, buclelor, hopurilor și destinațiilor care nu răspund poate rula automat.

Un redirect unu-la-unu poate fi aplicat automat dacă sursa și destinația vin dintr-un plan de migrare semnat, nu există conflict și raza este limitată. Redirecturile regex, regulile care ating directoare, schimbarea 302 în 301 și destinațiile alese semantic cer aprobare. O regulă scurtă poate muta mii de URL-uri.

Statusurile HTTP se măsoară automat, semnificația lor se aprobă

Documentația Google explică efectul statusurilor HTTP și al erorilor de rețea asupra crawlingului și indexării. Monitorizarea poate distinge 200, redirect, 404, soft 404, 5xx și timeout, poate compara template-ul și poate deschide un incident.

Nu transforma automat orice 404 în 200 sau redirect. Un URL eliminat intenționat poate trebui să rămână 404/410; o eroare temporară poate necesita repararea serviciului, nu mascarea ei. Schimbarea codului de răspuns intră pe approval când alterează ciclul de viață al conținutului.

robots.txt poate fi validat automat, dar scrierea în producție este sensibilă

robots.txt gestionează în principal traficul crawlerelor; nu este un substitut sigur pentru eliminarea unei pagini din index. Sistemul poate valida sintaxa, fetch-ul, content type-ul, dimensiunea și efectul regulilor asupra unui set de URL-uri test.

O linie greșită poate bloca un site întreg sau resurse necesare randării. Orice modificare în fișierul de producție cere preview al regulilor înainte/după, test pe URL-uri critice, owner tehnic și rollback imediat. Template-urile de staging pot fi automate numai cu o barieră care împiedică propagarea lor în producție.

Noindex și X-Robots-Tag cer aprobare explicită

Directivele robots meta și X-Robots-Tag controlează indexarea și prezentarea, iar crawlerul trebuie să poată accesa pagina pentru a le citi. Auditul poate detecta directive contradictorii, duplicate sau neașteptate.

Adăugarea ori eliminarea `noindex`, `nofollow`, `nosnippet` sau a limitelor de preview schimbă distribuția conținutului. Chiar și pe un singur URL, write-ul cere aprobare. Pentru batch, reviewerul vede lista completă, motivele, traficul sau rolul paginilor și efectul estimat, nu doar numărul de erori „rezolvate”.

Hreflang poate fi reparat automat doar dintr-un registru de traduceri

Google cere ca fiecare versiune localizată să se enumere pe sine și toate alternativele. Sistemul poate verifica reciprocitatea, codurile, URL-urile absolute, statusurile și canonicalele fiecărei rute.

Dacă registrul de localizare este sursă canonică și toate rutele au fost publicate, completarea unei legături reciproce poate fi policy-approved. Dacă o traducere lipsește, limba este incertă sau canonicalul traversează localele, nu inventa perechea. Plasa de siguranță din C13-013 trebuie să verifice setul complet după write.

Structured data separă sintaxa de adevărul proprietăților

Un validator poate corecta automat JSON invalid, escapingul ori un câmp tehnic derivat exact. Dar regulile Google cer ca structured data să fie relevantă, actuală și reprezentativă pentru conținutul vizibil. Un test verde nu confirmă că prețul, autorul, ratingul sau disponibilitatea sunt adevărate.

Proprietățile factuale se sincronizează automat numai dintr-o sursă de adevăr autorizată, cu timestamp și mapping explicit. Schimbarea tipului principal, introducerea unui review, a unei oferte sau a unei relații organizaționale cere aprobarea ownerului datelor. Nu genera schema ca să umpli câmpuri recomandate.

Titlurile și descrierile necesită control semantic

Google recomandă titluri descriptive și concise, iar snippeturile pot proveni din conținut sau din meta description. Auditul poate găsi lipsuri, duplicate, lungimi neobișnuite și template-uri defecte automat.

Rescrierea la scară schimbă promisiunea paginii. Chiar dacă o formulă produce text unic, nu dovedește că diferențiază intenția. Sistemul poate genera variante, verifica duplicarea și arăta preview-ul, dar aprobarea editorială rămâne necesară până când o regulă îngustă are rezultate stabile și eșantionare continuă.

Imaginile permit optimizări binare mai sigure decât rescrieri contextuale

Compresia lossless, eliminarea metadata inutilă, generarea dimensiunilor standard sau regenerarea unui derivat lipsă pot rula automat dacă originalul este păstrat, dimensiunile sunt allowlistate și comparația vizuală trece. Modificarea fișierului original, cropul focal și schimbarea formatului global cer testare și aprobare.

Alt textul nu este o etichetă tehnică generică. El depinde de rolul imaginii în pagină, iar imaginea decorativă poate avea alt gol. Propunerea automată este utilă, dar publicarea unui text contextual cere review sau o sursă editorială exactă. Păstrează separat operația media de schimbarea conținutului.

Core Web Vitals se monitorizează automat, codul nu se repară orb

Core Web Vitals măsoară experiența reală pentru încărcare, responsivitate și stabilitate vizuală. Colectarea datelor, gruparea template-urilor, detectarea regresiilor și deschiderea unui incident sunt taskuri automate bune.

Eliminarea unui script, schimbarea ordinii CSS, lazy-loadingul hero-ului sau mutarea componentelor poate afecta analytics, consimțământul, accesibilitatea și conversia. Agentul poate reproduce problema și pregăti patchul în staging; schimbarea de cod ori template se aprobă după teste funcționale și vizuale.

Internal linkingul automat are nevoie de reguli editoriale

Detectarea paginilor orfane, a linkurilor către redirect și a anchorilor repetați este automatizabilă. O legătură poate fi inserată automat într-o componentă navigațională deterministă, dacă taxonomia și ordinea sunt surse de adevăr. În corpul editorial, relevanța depinde de argument și de locul exact.

Nu înlocui fiecare mențiune cu un link și nu optimiza anchorii doar după keyword. Propunerile trebuie deduplicate, limitate per pagină și verificate în context. Legăturile inserate au Change ID, astfel încât efectul lor să poată fi măsurat și retras fără a atinge editări umane ulterioare.

Template-urile, pluginurile și cache-ul nu au aceeași clasă de risc

Un purge de cache după un release cunoscut poate fi automat și idempotent. O modificare de template, plugin, hook, reguli de rewrite sau configurare CDN poate schimba sute de rute. C09-005 tratează WordPress ca strat de execuție cu primitive explicite; nu comprima toate efectele într-un generic „optimize site”.

Schimbările globale cer staging, test de regresie, owner tehnic, fereastră de release și restore verificat. Dacă executorul nu poate identifica exact fișierele, opțiunile, cache-urile și paginile afectate, taskul este blocat, nu promovat automat pe baza unui scor.

Raza de efect poate muta același task într-o categorie mai strictă

Corectarea unui atribut determinist pe un URL și aplicarea aceleiași reguli pe 20.000 de URL-uri nu sunt același risc. Limitele includ număr de obiecte, procent dintr-un tip de conținut, trafic cumulat, template-uri atinse și timp maxim. Un circuit breaker oprește jobul la primul pattern neașteptat.

Pentru batch, rulează canary pe un subset, verifică readback și suprafața publică, apoi extinde treptat. Execution Bundle-ul din C09-004 păstrează manifestul, versiunea, dovezile, limitele și rollback pointerul necesare pentru această decizie.

Permisiunile executorului trebuie să reflecte matricea

Un scanner nu are nevoie de drept de editare. Un executor pentru media nu trebuie să poată modifica users, plugins ori options. Separă identitățile și scope-urile pe clase de acțiune, nu acorda administrator unui agent fiindcă uneori are nevoie de un câmp protejat.

Permission envelope-ul din C13-012 leagă identitatea, operația, ținta, volumul și timpul. Traseul „aprobare” nu compensează credențiale excesive: după aprobare, executorul trebuie să poată face numai mutația autorizată.

Readbackul decide dacă operația s-a terminat cu adevărat

REST Posts permite actualizarea și recitirea câmpurilor unui post, iar WP-CLI expune operații explicite de update. Un răspuns 200 la write nu dovedește că valoarea a rămas, că pluginurile nu au rescris-o sau că pagina publică o livrează.

După fiecare mutație, execută un GET nou, normalizează valoarea și compară hashul așteptat. Verifică apoi URL-ul delogat: status, H1, canonical, robots, link, schema și asset relevant. Dacă nu corespund, oprește batchul și pornește recovery-ul documentat în C13-015.

Politica finală trebuie să poată fi executată și auditată

Pentru fiecare tip de task, registrul precizează: detectorul, sursa de adevăr, traseul implicit, câmpurile permise, raza maximă, reviewerul, SLA-ul, testele, rollbackul și probele de închidere. Excepțiile nu se scriu în prompt; devin versiuni de policy cu owner și dată de expirare.

OWASP recomandă loguri de aplicație consistente și protejate împotriva modificării neautorizate. Regula practică: automatizează larg observația, automatizează îngust mutația, aprobă orice schimbă sensul ori indexarea și blochează ce nu poate fi explicat, limitat și recuperat.