Penalizare manuală pe date structurate

Contextul

Magazin online mid-market, câteva mii de produse, WordPress cu WooCommerce. Notificare de acțiune manuală în raportul de acțiuni manuale din Search Console, pe date structurate.

Ce s-a întâmplat de fapt — și de ce mecanismul contează

Aici e partea pe care majoritatea articolelor despre penalizări o încurcă, așa că merită spusă clar.

O acțiune manuală pe date structurate nu te scoate din index și nu îți retrogradează direct paginile. Ce face este să elimine rich results: stelele dispar din rezultate. Paginile rămân exact unde erau, pe aceleași poziții, doar că rândul lor în SERP devine dintr-o dată mult mai sărac decât al concurenților care încă au stele.

De acolo pornește un lanț care se vede în trafic:

CTR-ul scade pentru că același rând, fără stele, culege mult mai puține click-uri. Traficul scade proporțional și imediat. Iar în timp, pe măsură ce scad și semnalele de interacțiune, pot aluneca și pozițiile — dar ăsta e efect secundar, nu penalizarea în sine.

Efectul e disproporționat pe site-urile mici. Un retailer mare are brand search și volum care amortizează pierderea. Un magazin mid-market, care trăiește exclusiv din căutări comerciale nebranduite, ia lovitura la plin. Aceeași penalizare, același procent de CTR pierdut, impact complet diferit asupra business-ului.

Simptomul

Cădere bruscă de trafic organic, într-o singură zi — nu o alunecare graduală pe parcursul unei săptămâni.

Asta e prima bifurcație de diagnostic și merită reținută: updateul de algoritm arată ca o pantă, acțiunea manuală arată ca o prăpastie. Dacă graficul cade vertical într-o zi, nu pierde timp cu analiză de conținut — du-te direct în Search Console, la Acțiuni manuale. Dacă acolo nu e nimic, nu e penalizare manuală și cauți în altă parte.

Ce am verificat prima dată — și de ce nu era acolo

Reflexul normal la o penalizare pe date structurate e să te duci la schema de produs. Am făcut-o:

• Product pe paginile de produs: JSON-LD valid, proprietăți obligatorii prezente, trecea Rich Results Test fără erori.
• Organization: fără neconcordanțe cu Product, fără dubluri, fără identificatori contradictorii.
• Fără amestec de formate — doar JSON-LD, fără microdata sau RDFa peste el.

Din perspectiva validatorului, site-ul era curat. Și exact aici pierd oamenii săptămâni: validatorul verifică sintaxa, nu onestitatea. Un markup poate trece toate testele Google și să încalce în același timp ghidul general pentru date structurate, pentru că testul nu compară niciodată ce declari cu ce vede utilizatorul.

Așa că am lăsat schema și m-am uitat la site.

Diagnosticul: trei probleme suprapuse

1. Markup de recenzii pentru conținut invizibil

Paginile de produs declarau AggregateRating — notă medie și număr de recenzii. Pe pagină, utilizatorul nu vedea nici stele, nici note, nici o singură recenzie.

Regula Google e explicită: datele marcate trebuie să fie vizibile utilizatorului pe pagina respectivă. Marcarea unui conținut ascuns este, prin definiție, markup înșelător.

2. Zona de recenzii exista — dar era ascunsă în CSS

Aici a devenit interesant. Secțiunea de recenzii era în cod, complet funcțională. Cineva o setase pe display: none.

Detaliul contează mai mult decât pare, din două motive. Primul: explică de ce nimeni din echipă nu observase — în CMS recenziile existau, în editor totul arăta corect. Al doilea, mai grav: conținut prezent în HTML dar ascuns vizual e o problemă în sine, dincolo de datele structurate. Un site care ascunde text în CSS se apropie de alte categorii de încălcări, chiar dacă intenția a fost pur estetică.

Concluzia practică: când auditezi date structurate, nu te uita doar la ce trimite serverul. Uită-te la ce vede omul, delogat, pe mobil. Sunt lucruri diferite.

3. Cireașa: rating agregat pe categorii și homepage

Paginile de categorie și homepage-ul declarau AggregateRating, calculat prin comasarea recenziilor de la toate produsele din categoria respectivă.

Asta e o încălcare separată și mai serioasă decât primele două. Conform documentației pentru review snippets, recenzia trebuie să fie despre elementul specific de pe pagina respectivă. O pagină de categorie nu este un produs; nu are recenzii proprii. O medie construită din notele produselor din ea nu descrie nimic real — descrie o entitate care nu există.

Iar homepage-ul cu AggregateRating e cazul cel mai clar: e o notă pe care site-ul și-o acordă singur, pentru o entitate nedefinită.

Greșit — pe pagina de categorie:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Categorie: Scaune de birou",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "1842"
  }
}

Corect — pe pagina de produs, cu recenziile efectiv vizibile:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://exemplu.ro/produs/scaun-ergonomic-x1#product",
  "name": "Scaun ergonomic X1",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "reviewCount": "37",
    "bestRating": "5"
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "Andrei M." },
    "datePublished": "2026-03-14",
    "reviewRating": { "@type": "Rating", "ratingValue": "5" },
    "reviewBody": "Reglajul lombar chiar face diferența după 8 ore."
  }]
}

Pe categorie: CollectionPage sau ItemList, fără niciun aggregateRating.

Cauza: pluginul, nu omul

Nimeni din echipa clientului nu scrisese acel markup cu mâna. Venea dintr-un modul de date structurate al unui plugin WordPress, activat global, care genera automat rating agregat pe paginile de arhivă — inclusiv pe categorii și pe homepage, unde nu avea ce căuta.

Ăsta e tiparul, nu excepția. Pe WordPress și WooCommerce, cele mai multe penalizări de acest tip nu vin din intenție, ci dintr-un modul activat cu setările implicite, de care nimeni nu s-a mai uitat după instalare. Verifică ce generează efectiv markup-ul înainte să acuzi pe cineva că a vrut să păcălească Google — de obicei nu a vrut nimeni nimic.

Intervenția

În ordinea în care a fost livrată:

1. Zona de recenzii, făcută vizibilă la nivel de produs, cu recenziile reale afișate — nu doar media, ci recenziile individuale, cu autor și dată.
2. AggregateRating eliminat de pe toate paginile de categorie și de pe homepage. Categoriile au rămas cu markup de listare, fără note.
3. Modulul de schema al pluginului, reconfigurat să nu mai emită rating pe arhive.
4. Regula de consistență, aplicată peste tot: fiecare valoare declarată în JSON-LD are un corespondent vizibil pe pagină. Dacă nu se vede, nu se declară.
5. Revalidare în Rich Results Test și în Schema Markup Validator, plus verificare pe versiunea mobilă — indexarea mobile-first citește pagina mobilă, iar diferențele de template între desktop și mobil sunt un loc clasic în care fixul se aplică pe jumătate.

Rezultatul

• O săptămână de la implementare și trimiterea cererii de reconsiderare: acțiunea manuală ridicată, stelele revenite în rezultate.
• Două luni: circa 70% din trafic recuperat.

Recuperarea nu a fost totală și rareori este. Perioada fără rich results lasă urme — concurenții preiau click-urile, iar revenirea la nivelul anterior cere timp și semnale noi.

Cererea de reconsiderare: partea pe care o ratează toată lumea

Fixul tehnic e jumătate din muncă. Cealaltă jumătate e cererea de reconsiderare, unde majoritatea site-urilor scriu două propoziții de tipul „am reparat, vă rugăm să reevaluați" și primesc refuz.

O cerere care trece răspunde la patru întrebări, în ordinea asta:

1. Ce era greșit, concret. Nu „probleme cu datele structurate", ci: AggregateRating declarat pe pagini de categorie și homepage prin agregarea notelor de la produse; markup de recenzii pe pagini unde secțiunea era ascunsă în CSS.
2. Cum s-a ajuns acolo. Aici e cheia credibilității. Google vrea un mecanism, nu o scuză — iar mecanismul trebuie să fie cel real și verificabil. În cazul de față: modulul de schema al unui plugin, activat global, care injecta rating pe arhive. Dacă mecanismul pe care îl descrii nu se susține la verificare, pierzi și cererea, și credibilitatea pentru următoarea încercare.
3. Ce ai schimbat, exact. Listă, cu URL-uri pe care le pot verifica: o pagină de categorie fără rating, o pagină de produs cu recenzii vizibile.
4. Ce împiedică repetarea. Modulul dezactivat pe arhive, validare de schema la publicare, cine e responsabil.

Verifică-ți site-ul în zece minute

• Ai AggregateRating sau Review pe vreo pagină de categorie, listare sau homepage? Scoate-l azi.
• Deschide o pagină de produs cu rating în schema. Vezi recenziile pe pagină, ca vizitator delogat? Dacă nu, ai aceeași problemă.
• Caută în CSS după display: none aplicat pe containere de conținut, nu doar pe elemente de interfață.
• Verifică ce plugin sau temă generează markup-ul, și ce produce pe alte tipuri de pagină decât cele pentru care a fost gândit.
• Verifică versiunea mobilă separat. Fixul aplicat doar pe desktop nu contează.
• Rulează Rich Results Test — dar nu te opri acolo. Testul confirmă sintaxa; comparația cu ce vede utilizatorul o faci tu.

Despre autor

Dragoș Mihai Drăgoi

12+ ani în SEO, SEO tehnic la scară enterprise. Scrie despre GEO/AEO și schema markup din experiență directă, nu din research generic.

Vezi profilul complet →