SEO ecommerce avansat: cum afli care URL-uri îți consumă indexarea într-un catalog de mii de produse

SEO ecommerce avansat înseamnă, în practică, o singură operațiune: afli care dintre miile tale de URL-uri sunt în starea greșită de indexare și de ce, în loc să aplici tactici la întâmplare peste un catalog pe care nu îl vezi. Instrumentul e raportul Indexare pagini din Search Console, iar întrebarea la care răspunde nu e „ce pun pe pagină”, ci „unde văd că nu e pus corect”.

Înainte de orice, poarta: dacă paginile tale noi apar în Google în aceeași zi în care le publici, documentația Google spune explicit că nu ai nevoie de ghidul de buget de parcurgere. Ține sitemapul la zi, verifică periodic raportul de indexare, și du-te să lucrezi la altceva. Restul articolului e pentru cazul în care ai deja simptome.

Ce ține acest articol și ce nu:

• ține: cum citești raportul de indexare pe un catalog mare, ce faci când semnalele de canonic se contrazic, de ce noindex și Disallow se anulează reciproc, ce consumă parcurgerea și în ce ordine repari;
• nu ține: ce mecanism pui pe filtre, pe paginare și pe variante, cât text pui pe categorie, ce faci cu descrierile de la furnizor sau cu produsele fără stoc. Toate sunt tratate, cu documentația la spate, în articolul despre ce mecanism pui pe filtre, paginare și variante.

Împărțirea nu e stilistică. Un magazin cu 40.000 de URL-uri are două probleme diferite — una de prescripție, alta de diagnoză — iar cea de-a doua nu se rezolvă citind încă o listă de bune practici.

Cum știi dacă problema asta e a ta

Documentația Google numește trei tipuri de situri pentru care ghidul de parcurgere e scris. Le reproduc cu calificarea pe care o pune sursa însăși, pentru că fără ea cifrele circulă ca praguri și devin false:

Interpretarea tabelului e în chiar textul sursei: cifrele de mai sus sunt, în cuvintele documentației, „a rough estimate to help you classify your site”, nu praguri exacte. Un magazin cu 8.000 de URL-uri și un catalog care se schimbă de trei ori pe zi are problema; unul cu 30.000 de pagini statice, care se indexează în aceeași zi, nu o are.

Al treilea rând e cel pe care merită să te sprijini, pentru că nu depinde de o cifră. Deschide raportul Indexare pagini, uită-te la câte URL-uri stau în starea „Discovered – currently not indexed” raportat la câte ai în total, și compară cu ce te-ai fi așteptat. Dacă publici o categorie nouă cu 200 de produse și, după două săptămâni, 180 dintre ele sunt încă „descoperite, dar nevizitate”, ai răspunsul — indiferent câte pagini are situl.

Mai e o precizare de perimetru care schimbă calculul la magazinele cu subdomenii: Google definește situl, în contextul parcurgerii, ca hostname unic. https://www.example.com/ și https://code.example.com/ sunt tratate ca situri separate, cu bugete separate. Dacă ai mutat blogul, imaginile sau varianta mobilă pe subdomenii, nu ai un buget mare împărțit; ai mai multe bugete mici, fiecare cu propria capacitate.

Cele șase tipuri de URL și starea în care ar trebui să fie fiecare

Un catalog mare nu are un tip de pagină, are șase. Fiecare are o stare corectă în raport și un semnal de alarmă propriu. Tabelul de mai jos e instrumentul de lucru al articolului: îl parcurgi filtrând raportul pe tipar de URL și verifici, pentru fiecare tip, dacă starea observată e cea așteptată.

Numele stărilor sunt reproduse în forma din documentația Google. Le folosesc ca atare pentru că e și forma în care le găsești când le cauți, iar o traducere aproximativă te-ar face să cauți ceva ce nu există.

Coloana a patra nu e o scăpare de redactare, e arhitectura: cinci din cele șase mecanisme sunt deja scrise, cu citate din documentație, în articolul despre ce mecanism pui pe filtre, paginare și variante. Ce adaugă tabelul de aici e coloana a doua și a treia — starea în care trebuie să găsești fiecare tip și abaterea care îți spune că mecanismul nu a prins.

Un avertisment care scutește o săptămână de muncă inutilă: documentația spune direct că nu trebuie să te aștepți ca toate URL-urile de pe site să fie indexate, ci doar paginile canonice. Un raport în care majoritatea URL-urilor apar ca neindexate poate fi un raport sănătos, dacă acele URL-uri sunt filtre blocate intenționat și variante care trimit corect către canonicul lor. Numărul singur nu spune nimic; compoziția lui spune tot.

Ce citești în raportul Indexare pagini când ai zeci de mii de URL-uri

Aici e diferența dintre un magazin mic și unul mare, și e o diferență de metodă, nu de efort. Raportul are o limită pe care puțini o știu și care schimbă complet felul în care se folosește: lista de URL-uri exemplu e limitată la 1.000 de elemente pentru fiecare stare, și nu garantează că le arată pe toate, nici măcar când sunt mai puțin de 1.000.

Consecința e brutală pentru un catalog de 40.000 de URL-uri: raportul nu e un inventar. Nu îl poți epuiza, nu îl poți bifa, nu poți exporta „toate paginile cu problema X”. În episodul din 16 iulie 2026 al podcastului Search Off the Record, echipa Google Search Relations formulează asta ca model de lucru: raportul nu e o listă de reparat și nici un inventar de monitorizat, ci un instrument în care cauți tipare și abateri de la ce te așteptai să se întâmple.

Ordinea de citire care funcționează pe un catalog mare:

1. te uiți la evoluția pe stare, nu la numărul absolut — o creștere bruscă într-o stare e semnal, un total mare nu e;
2. verifici dacă evoluția corespunde cu ce ai făcut tu: dacă ai pus redirectări săptămâna trecută și crește „Page with redirect”, raportul confirmă că a funcționat, nu semnalează o problemă;
3. deschizi starea care te miră și te uiți la tiparul de URL din exemple, nu la URL-urile individuale;
4. dacă tiparul e un parametru, o secțiune sau un tip de pagină, ai găsit deja cauza pentru toate instanțele lui;
5. abia la final folosești inspecția URL, pe un singur exemplu, ca să confirmi diagnosticul.

Două stări se confundă permanent și înseamnă lucruri diferite. „Discovered – currently not indexed” spune că Google știe că pagina există, dar nu a vizitat-o încă — de obicei pentru că vizita a fost reprogramată ca să nu suprasolicite situl. „Crawled – currently not indexed” spune că a vizitat-o și a decis să nu o indexeze. Prima e o problemă de capacitate și de prioritate; a doua, la scară, e mai des o problemă de calitate a paginilor decât una tehnică.

Încă două limite ale instrumentului, ca să nu pierzi timp căutând funcții care nu există: nu poți căuta și nu poți filtra după URL în raport — pentru un URL anume folosești inspecția; iar raportul afișează doar URL-urile care au returnat 404 în ultima lună, ca să nu crească la infinit. Dacă ai șters 5.000 de produse acum trei luni, absența lor din raport nu înseamnă că Google le-a uitat.

Când ai reparat ceva, îl poți valida din raport, iar documentația dă și trucul care scurtează așteptarea: creezi și trimiți un sitemap care conține doar paginile importante, filtrezi raportul pe acel sitemap, și abia apoi ceri validarea. O validare pe un subset se termină mai repede decât una pe tot situl. Ce nu se vede în inspecția live e la fel de important: testul live nu verifică toate problemele din raport, și în mod special nu testează condițiile de duplicare și de canonic. O pagină care „arată bine” la inspecția live poate fi în continuare eliminată ca duplicat.

Când semnalele tale de canonic se contrazic între ele

Un magazin mare trimite, fără să vrea, semnale contradictorii despre care URL e cel bun: o redirectare pusă acum doi ani, un rel="canonical" generat de temă, un sitemap produs de un plugin care listează toate variantele. Google nu le tratează egal și publică ordinea.

Fraza de interpretare e și regula de igienă: metodele se cumulează și devin mai eficiente combinate, dar numai dacă spun același lucru. Un URL trimis în sitemap și un altul declarat canonic pentru aceeași pagină nu se adună, se anulează. Documentația adaugă un echilibru pe care merită să îl citezi când cineva cere canonic pe fiecare pagină din catalog: niciuna dintre metode nu e obligatorie, iar majoritatea siturilor funcționează fără să declare o preferință.

Când semnalele se contrazic, apar exact două stări în raport, și ele nu înseamnă același lucru:

• „Duplicate without user-selected canonical” — pagina e duplicat, tu nu ai indicat un canonic, iar Google a ales altul. Nu e o eroare; e sistemul funcționând așa cum a fost proiectat. Devine problemă doar dacă pagina aleasă de Google nu e cea pe care voiai să o vinzi;
• „Duplicate, Google chose different canonical than user” — tu ai declarat un canonic, iar Google a preferat altul. Aceasta e cea care merită investigată, pentru că e o divergență de opinie, nu o absență de instrucțiune.

Pe a doua, procedura e scurtă: inspectezi URL-ul, citești ce canonic a ales Google, îl compari cu al tău și cauți motivul în diferența dintre cele două pagini — de obicei una are linkuri interne, cealaltă nu, sau una e în sitemap și cealaltă nu. Dacă pe multe pagini Google alege un canonic aparent aleatoriu, cauza e adesea altundeva: o pagină servită diferit crawlerului, un interstițial, un blocaj soft care strică ce vede robotul. Când problema vine dintr-o mutare de domeniu sau dintr-o restructurare, harta de redirectări e locul de început — lanțurile care ies din ea produc exact acest tip de confuzie.

noindex plus Disallow: greșeala care se anulează singură

Combinația asta e cea mai frecventă cauză a lui „am pus noindex și nu s-a întâmplat nimic”, și motivul e mecanic: ca să vadă eticheta noindex, Google trebuie să ceară pagina. Dacă robots.txt îi interzice să o ceară, nu o vede niciodată.

Documentația e explicită pe amândouă capetele. Regula noindex scrisă în robots.txt nu e suportată de Google. Iar când o etichetă noindex pusă în pagină nu are efect, una dintre cauzele numite direct e că fișierul robots.txt blochează URL-ul pentru crawlere, „so they can’t see the tag” — iar soluția scrisă e să editezi robots.txt, adică să deblochezi.

Aici se corectează și o convingere larg răspândită în sens invers: blocarea în robots.txt nu garantează că pagina nu va fi indexată. Dacă Google găsește destule informații despre ea fără să o încarce, există o șansă mică să o indexeze oricum — iar raportul are o stare dedicată pentru asta, „Indexed, though blocked by robots.txt”. Documentația își repetă concluzia: ca să fii sigur că o pagină nu e indexată, scoți blocajul din robots.txt și pui o directivă noindex. Ceea ce dă, în două rânduri, singura schemă corectă de care ai nevoie:

Tabelul se citește pe coloana a treia: cele două instrumente nu se completează, se exclud. Cele trei ieșiri corecte, în funcție de ce vrei de fapt:

1. Vrei să economisești parcurgere pe URL-uri care nu trebuie să existe în index — filtre de sortare, combinații de parametri, căutare internă. Blochezi în robots.txt și accepți că un număr mic pot rămâne indexate din linkuri externe. Nu pui noindex, pentru că nu va fi citit.
2. Vrei garanția că o pagină nu apare în rezultate. Lași URL-ul accesibil crawlerului și pui noindex în pagină sau în antetul HTTP, prin X-Robots-Tag — varianta obligatorie pentru resurse care nu sunt HTML, cum ar fi PDF-urile de fișă tehnică.
3. Vrei amândouă, în ordine. Pui noindex, aștepți să fie citit și paginile să iasă din index, și abia apoi blochezi în robots.txt. E singura secvență care funcționează, și e și cea mai rar aplicată, pentru că cere răbdare.

Răbdarea are un cost măsurabil: în funcție de importanța paginii pe web, poate dura luni până Googlebot o revizitează, deci până noindex-ul are efect. Pe un număr mic de pagini importante, poți cere reparcurgerea din instrumentul de inspecție URL. Pe zeci de mii, nu poți, și ordinea din varianta 3 devine un proiect de trimestru, nu o sarcină de după-amiază.

Ce înghite parcurgerea într-un catalog mare

Bugetul de parcurgere nu e un buton. E rezultatul a două lucruri: cât suportă serverul tău, ceea ce documentația numește crawl capacity limit, și cât de mult vrea Google să te parcurgă, adică crawl demand. Primul urcă dacă situl răspunde constant și repede și coboară la erori de server sau la răspunsuri 429. Al doilea depinde de dimensiune, frecvență de actualizare, calitate și popularitate — iar factorul pe care îl controlezi cel mai bine e ceea ce documentația numește „perceived inventory”: câte URL-uri crede Google că merită parcurse la tine.

Ce le înghite, în ordinea în care le găsești de obicei într-un magazin:

• duplicatele — versiuni sortate diferit ale aceleiași colecții, combinații de filtre, parametri de urmărire. Se consolidează sau se blochează, nu se ignoră;
• soft 404-urile — pagini care spun „nu am găsit nimic” dar răspund cu 200. Continuă să fie parcurse și consumă buget la nesfârșit. Categoriile golite și rezultatele de căutare internă fără rezultate sunt fabrica principală;
• URL-urile șterse care răspund greșit — pentru pagini eliminate definitiv, un 404 sau un 410 e un semnal puternic să nu mai fie parcurse. Un URL blocat, în schimb, rămâne mult mai mult în coada de parcurgere și e reluat imediat ce blocajul dispare;
• lanțurile de redirectări — documentația le numește explicit ca având efect negativ asupra parcurgerii;
• paginile lente — cu cât se încarcă mai repede, cu atât Google poate citi mai mult conținut în același interval.

Interpretarea listei, pentru cine trebuie să aleagă de unde începe: primele trei rânduri sunt despre câte URL-uri intră în coadă, ultimele două despre cât costă fiecare. Într-un catalog mare, prima categorie e aproape întotdeauna de zece ori mai profitabilă decât a doua.

Două contraintuitive care merită reținute exact așa cum sunt scrise. Primul: nu folosi noindex ca să economisești parcurgere — Google va cere pagina oricum și abia apoi va vedea eticheta, deci vei fi plătit costul integral. Al doilea: robots.txt nu e un instrument de realocare temporară a bugetului. Blocarea unor pagini nu mută automat bugetul către celelalte, decât dacă situl chiar atingea limita de capacitate.

Pe partea de eficiență, o singură setare tehnică plătește disproporționat: suportul pentru 304 (Not Modified). Dacă o pagină nu s-a schimbat de la ultima parcurgere, răspunsul 304 îi spune lui Google să refolosească versiunea din cache, iar tu economisești lățime de bandă și resurse de server — adică exact intrările din formula de capacitate.

Sitemapul la scară: fișier index, lastmod și ce nu rezolvă el

La zeci de mii de produse, sitemapul încetează să fie un fișier și devine o structură. Limitele sunt fixe și publicate.

Regula de decizie din tabel: împărțirea pe fișiere nu e o formalitate administrativă, e felul în care obții informație. Dacă ai un sitemap separat pentru categorii, unul pentru produse și unul pentru conținut editorial, raportul de indexare se poate filtra pe fiecare, iar starea „câte produse sunt indexate” devine o cifră pe care o poți urmări săptămânal în loc de o estimare.

Ce nu face sitemapul, și e important într-un articol despre duplicare: nu decide canonicul. E semnalul cel mai slab din cele trei, iar un sitemap care listează și varianta cu parametru, și varianta curată, nu ajută — dimpotrivă, adaugă zgomot exact în locul unde ai nevoie de claritate.

De unde începi luni dimineață

Ordinea de mai jos e cea pe care o folosim, și e ordonată după un singur criteriu: ce e ieftin de verificat înainte de ce e scump de reparat.

1. Deschide raportul Indexare pagini și notează compoziția, nu totalul: câte URL-uri în fiecare stare, ca pondere. Asta e linia de bază față de care vei măsura orice altceva.
2. Compară cu ce te așteptai. Ai blocat filtrele acum două luni? Atunci „URL blocked by robots.txt” ar trebui să fie mare și în creștere. Dacă nu e, blocarea nu a prins.
3. Ia stările care te miră și caută tiparul de URL în exemple. Un parametru, o secțiune, un tip de pagină. Nu URL-uri individuale — sunt maximum o mie și nu sunt reprezentative prin construcție.
4. Verifică cele două stări de duplicat separat. Cea fără canonic declarat e adesea normală; cea în care Google a ales altceva decât tine e o divergență și cere inspecție.
5. Caută combinația noindex plus Disallow pe orice secțiune pe care ai încercat să o scoți din index și nu a ieșit. E cauza cea mai frecventă și cea mai ieftin de reparat.
6. Deschide raportul Statistici de accesare cu crawlere și verifică starea gazdei pe ultimele 90 de zile. Dacă ai avut probleme de disponibilitate, nu ai o problemă de indexare, ai una de infrastructură, iar restul e consecință.
7. Abia acum atinge mecanismele de pe pagină — canonice, blocări, redirectări — și doar pe tipul de URL pe care diagnoza l-a izolat.

Primele șase puncte nu cer nicio modificare în cod. Asta e și ideea: într-un catalog mare, cea mai scumpă greșeală nu e o etichetă pusă prost, ci o săptămână de implementare pe un diagnostic greșit. Când ajungi la punctul 7 și schimbările depășesc ce poate face echipa internă, implementarea SEO tehnic la scară e exact partea care se externalizează cel mai bine, pentru că are criterii de verificare obiective. Iar dacă concluzia diagnozei e că filtrele tale trebuie regândite din perspectiva cumpărătorului, nu doar a crawlerului, discuția se mută spre filtrele care ajută cumpărătorul, nu doar motorul de căutare.

Întrebări frecvente

Cum rezolv conținutul duplicat într-un magazin online?

În doi pași, în ordinea asta. Întâi afli ce tip de duplicat ai — filtre, parametri, variante, paginare sau descrieri identice — filtrând raportul Indexare pagini pe stările „Duplicate without user-selected canonical” și „Duplicate, Google chose different canonical than user”. Apoi aplici mecanismul potrivit tipului, iar mecanismele sunt prescrise cap-coadă în articolul despre ce mecanism pui pe filtre, paginare și variante. Ordinea inversă — aplici mecanisme și apoi verifici — e cea care consumă trimestre.

Ce înseamnă „Duplicate without user-selected canonical”?

Că pagina e considerată duplicat al alteia, că tu nu ai indicat o pagină canonică preferată, și că Google a ales singur altă pagină pe care să o afișeze. Documentația precizează explicit că nu e o eroare, ci comportamentul normal al sistemului. Devine problemă doar când pagina aleasă de Google nu e cea pe care voiai să o vinzi — și atunci se verifică prin inspecția URL-ului, care îți arată ce canonic a ales.

Cât timp trece până Google reindexează după o corecție?

Depinde de importanța paginii și nu are un termen garantat. Pentru conținut nou pe un sit existent, documentația vorbește despre câteva zile; pentru un sit sau o pagină complet nouă, despre cam o săptămână; iar pentru revizitarea unei pagini existente, poate dura luni. Poți grăbi pe un număr mic de URL-uri cerând reparcurgerea din instrumentul de inspecție, iar pentru o corecție la scară poți valida remedierea filtrată pe un sitemap redus. Cronologia completă a rezultatelor SEO e în articolul despre cât durează până se vede o corecție.

Ar trebui să pun toate produsele în sitemap?

Pui produsele pe care vrei să le parcurgă Google, nu tot ce generează platforma. Un sitemap cu variante, filtre și URL-uri cu parametri nu ajută la canonicalizare — includerea în sitemap e semnalul cel mai slab dintre cele trei — și în schimb îți strică singurul instrument prin care poți măsura, pe segmente, câte pagini de produs sunt efectiv indexate.

Contează dacă am și www, și versiunea fără www?

Da, mai mult decât se crede. Google definește situl, la parcurgere, ca hostname unic, deci www.example.com și example.com sunt două situri cu bugete separate. Același lucru e valabil pentru orice subdomeniu — blog, imagini, versiune mobilă. Dacă ai conținut real pe mai multe hostname-uri, nu ai un buget mare, ci mai multe bugete mici, și fiecare trebuie tratat separat. Ce înseamnă indexarea și de ce se comportă așa e explicat de la zero în articolul despre ce înseamnă de fapt indexarea.

Un catalog mare se conduce prin excepții

Modelul de reținut e că, peste câteva mii de URL-uri, nu mai poți conduce catalogul prin enumerare. Raportul îți dă maximum o mie de exemple pe stare și nu îți promite că sunt reprezentative, iar inspecția URL merge pe câte una. Singura metodă care scalează e să declari din timp ce stare ar trebui să aibă fiecare tip de URL, și apoi să te uiți doar la ce iese din declarație.

De aici vine și decizia de resurse pe care o vezi rar formulată: într-un magazin mare, munca de SEO tehnic nu e „să optimizezi paginile”, ci să menții spațiul de URL-uri suficient de mic și de previzibil cât să încapă în bugetul pe care ți-l alocă un motor de căutare. Fiecare filtru nou, fiecare parametru de urmărire, fiecare variantă de sortare adaugă o linie în coadă. Cine nu are pe cineva care să spună „nu” la etapa de produs plătește diferența în ani de curățenie.

Iar dacă ai citit până aici și te-ai recunoscut doar la primul H2, concluzia onestă e cea de la început: nu ai problema asta. Ține sitemapul curat, uită-te la raport o dată pe lună și investește restul în ce chiar te limitează. Dacă însă compoziția raportului tău nu seamănă deloc cu ce te așteptai, cere un diagnostic — începem prin a ne uita la ce ai deja în index, nu la ce ar trebui să adaugi. Așa lucrăm și cu magazinele online în general: întâi ce e stricat, apoi ce e nou.