Indexarea Google nu se repară prin retrimiterea repetată a aceluiași URL. Mai întâi afli unde se rupe traseul: Google nu cunoaște pagina, nu o poate accesa, nu are voie s-o indexeze, alege alt URL canonic sau consideră că nu merită încă păstrată în index.
„Nu apare în Google” este un simptom, nu un diagnostic. O pagină poate fi descoperită, dar necrawluită; crawl-uită, dar exclusă; indexată sub alt URL canonic; eligibilă tehnic, dar absentă pentru interogarea verificată. Raportul Page indexing explică și un lucru ușor de ratat: nu orice URL neindexat reprezintă o eroare. Redirecturile, duplicatele, filtrele și paginile excluse intenționat pot rămâne în afara indexului fără să necesite reparație.
Urmează arborele de mai jos în ordine. Fiecare ramură are un test și o remediere. Dacă vrei explicația etapelor, nu doar procedura, începe cu ce este SEO tehnic.
Cum verifici dacă Google îți vede paginile
Pentru un URL important, deschide URL Inspection în Search Console. Verifică două stări diferite:
- versiunea indexată: ce știe Google din ultima procesare;
- testul live: dacă pagina poate fi accesată acum.
Diferența contează. Poți fi reparat pagina azi, dar raportul indexat să arate încă eroarea veche. Testul live confirmă implementarea; indexarea ulterioară confirmă că Google a reprocesat URL-ul.
Documentația oficială URL Inspection precizează că raportul despre versiunea indexată vine din informația deja deținută de Google, în timp ce testul live verifică dacă instrumentul poate accesa acum pagina pentru indexare. Testul live nu prezice ce canonical va selecta Google și nu verifică toate condițiile de apariție în rezultate.
Înregistrează pentru fiecare URL cele patru câmpuri de bază:
- starea indexată și data ultimei accesări raportate;
- rezultatul testului live și codul HTTP final;
- canonical declarat de pagină și canonical selectat de Google;
- sursa descoperirii: link intern, sitemap, redirect sau referință externă.
Aceste câmpuri separă o întârziere de propagare de o configurație încă greșită. Dacă versiunea live trece, dar cea indexată arată eroarea veche, reparația trebuie recitită. Dacă testul live eșuează, solicitarea de indexare nu poate înlocui remedierea.
Folosește operatorul site: doar ca verificare rapidă, nu ca inventar exact. Pentru proprietăți mari, rapoartele Search Console și exporturile sunt mai potrivite.
Ghidul Google pentru depanarea unei singure pagini recomandă verificarea URL-ului complet și separă eligibilitatea de apariția efectivă. Pentru o pagină critică, confirmă și URL-ul public, fără parametri sau fragmente accidentale, apoi urmărește raportul de performanță după recrawl.
| Rezultat | Întrebarea următoare |
|---|---|
| URL necunoscut | este legat intern și inclus în sitemap? |
| accesarea live eșuează | serverul, redirectul sau robots îl blochează? |
| accesarea reușește, indexarea interzisă | există noindex? |
| URL duplicat | ce canonical a ales Google și ce ai declarat tu? |
| crawled/discovered, neindexat | pagina este distinctă, utilă și legată intern? |
Citește motivul, apoi eșantionul
Raportul agregat grupează URL-uri după motive. Nu repara un motiv doar pentru că numărul este mare. Deschide exemplele și întreabă dacă acele URL-uri trebuie, în realitate, indexate. Un magazin poate avea multe combinații de filtre excluse intenționat; un site de servicii nu ar trebui însă să găsească paginile principale în aceeași categorie.
| Motiv observat | Eșantion minim de control | Întrebarea de business |
|---|---|---|
Discovered — currently not indexed | pagini noi din mai multe șabloane | sunt legate intern și merită crawl prioritar? |
Crawled — currently not indexed | pagini cu conținut și rol diferit | oferă răspuns distinct sau repetă alt URL? |
Duplicate without user-selected canonical | perechi de URL și variante cu parametri | ce versiune vrem să primească semnalele? |
Alternate page with proper canonical | câteva alternate și canonicele lor | excluderea este intenționată și coerentă? |
Blocked by robots.txt | pagini importante și resurse asociate | regula blochează ceva necesar? |
Pentru fiecare categorie păstrează numărul total doar ca dimensiune a investigației. Dovada remedierii vine din URL-urile reprezentative și din dispariția cauzei la nivel de șablon, nu din colorarea unui grafic.
Ce rol are sitemapul și cum îl trimiți corect
Sitemapul este lista URL-urilor pe care le consideri importante. Ajută descoperirea și poate comunica data actualizării ori variantele lingvistice, dar Google spune în documentația despre sitemap că trimiterea lui este numai un indiciu și nu garantează crawlingul sau indexarea.
Checklist:
- deschide URL-ul sitemapului și confirmă că răspunde;
- păstrează doar URL-uri canonice, indexabile și cu răspuns corect;
- elimină redirecturi, erori și pagini marcate
noindex; - trimite sitemapul în raportul Sitemaps din Search Console;
- compară numărul și exemplele de URL-uri cu structura reală a site-ului.
Multe CMS-uri generează automat sitemapul. Nu instala încă un plugin înainte să verifici ce există deja. Un sitemap curat exprimă preferința; nu compensează pagini orfane sau conținut slab.
Sitemapul trebuie să reflecte versiunea canonică a arhitecturii. Dacă un URL redirecționează, are noindex, răspunde cu eroare sau declară alt canonical, includerea lui trimite semnale contradictorii. Pentru diagnostic, exportă lista și adaugă cel puțin codul HTTP, indexabilitatea, canonicalul și numărul de linkuri interne.
| Câmp din controlul sitemapului | Valoare urmărită | Ce declanșează investigația |
|---|---|---|
| răspuns sitemap | 200 și XML parseabil | 3xx, 4xx, 5xx, HTML sau timeout |
| URL listat | variantă canonică absolută | parametri, HTTP, subdomeniu sau slash inconsistent |
| răspuns URL | conținut final accesibil | redirect, soft 404 sau eroare server |
| indexabilitate | fără noindex și fără blocaj accidental | meta robots ori X-Robots-Tag contradictoriu |
| canonical | autoreferențial sau intenționat | canonical către alt URL fără justificare |
| legături interne | cel puțin o cale relevantă | pagină prezentă numai în sitemap |
Folosește lastmod numai când reprezintă o schimbare semnificativă a paginii. Actualizarea automată a tuturor datelor la fiecare build reduce valoarea semnalului. Nu adăuga în sitemap URL-uri doar pentru a forța indexarea; lista trebuie să fie un inventar al paginilor pe care vrei să le menții publice și căutabile.
Ce poate bloca indexarea fără o eroare evidentă
Robots.txt și noindex rezolvă probleme diferite. Robots controlează în principal accesarea crawlerului; nu este mecanismul corect pentru eliminarea sigură a unei pagini din rezultate. Introducerea Google în robots.txt descrie regulile de crawl, iar ghidul pentru blocarea indexării cu noindex cere ca crawlerul să poată accesa pagina pentru a vedea directiva. Un URL blocat în robots poate apărea totuși dacă este descoperit prin linkuri, fără conținutul unui snippet normal.
| Cauză | Test | Remediere |
|---|---|---|
| robots.txt blochează calea | test live / raport robots | restrânge regula, dacă blocarea nu e intenționată |
meta noindex | sursă HTML / URL Inspection | elimină directiva și permite crawlingul |
header X-Robots-Tag | răspuns HTTP | corectează configurația serverului |
| autentificare/parolă | test live eșuează | fă publică pagina care trebuie indexată |
| eroare server | cod 5xx sau timeout | repară stabilitatea serverului |
| redirect | URL-ul nu mai returnează conținut | verifică dacă ținta este cea corectă |
Nu combina Disallow și noindex la întâmplare: dacă Google nu poate accesa pagina, poate să nu vadă directiva noindex. Decide întâi dacă vrei să controlezi accesarea, apariția în rezultate sau accesul utilizatorilor.
Ce controlează fiecare mecanism
| Scop | Mecanism potrivit | Ce trebuie verificat după implementare |
|---|---|---|
| reduci crawlingul unei căi neimportante | regulă robots.txt precisă | URL-urile comerciale și resursele lor rămân accesibile |
| excluzi o pagină publică din rezultate | meta robots sau X-Robots-Tag noindex | pagina este crawlabilă până când directiva este procesată |
| muți definitiv un URL | redirect permanent către ținta relevantă | ținta răspunde corect și primește linkurile interne |
| restricționezi conținut confidențial | autentificare / control de acces | pagina nu este publică, nu doar ascunsă de crawler |
| consolidezi duplicate utile | canonical coerent | pagina preferată apare în sitemap și în linkurile interne |
Verifică și răspunsurile non-HTML. Un PDF poate primi X-Robots-Tag din configurația serverului, iar o regulă aplicată la nivel de director poate afecta mai multe tipuri de fișiere decât arată CMS-ul. Cere headerul public, nu captura din panoul de administrare.
Semantica răspunsurilor HTTP din documentația Google explică felul în care redirecturile și erorile influențează procesarea. Pentru un URL important, notează lanțul complet, nu doar codul primei cereri; testul live urmează redirectul și poate arăta o țintă diferită de cea intenționată.
Când paginile duplicate îți diluează vizibilitatea
Un canonical indică versiunea preferată dintre URL-uri duplicate sau foarte similare. Este un semnal puternic, nu o obligație absolută. Ghidul Google pentru consolidarea URL-urilor duplicate explică ierarhia semnalelor și faptul că Google poate alege altă versiune când declarațiile sunt contradictorii.
Pentru URL-ul dorit, aliniază:
- redirecturile către versiunea preferată, când duplicatul nu trebuie păstrat;
rel="canonical"către URL-ul corect, inclusiv autoreferențial;- includerea în sitemap;
- linkurile interne;
- protocolul, subdomeniul și forma slashului.
Documentația Google descrie redirectul și rel="canonical" ca semnale puternice, iar includerea în sitemap ca semnal slab. Dacă sitemapul spune A, canonical spune B și linkurile duc la C, nu ai o preferință coerentă.
Nu folosi canonical pentru pagini care nu sunt, în esență, duplicate. Două servicii locale sau două categorii cu intenții diferite au nevoie de conținut și semnale proprii. Dacă le canonizezi către o singură pagină, îi spui motorului că variantele nu merită tratate separat. Dacă vrei ca una să înlocuiască definitiv alta, redirectul este de regulă mai clar.
Auditul unei familii de duplicate
- enumeră toate variantele: protocol,
www, slash, litere, parametri și filtre; - verifică răspunsul și canonicalul fiecăreia;
- compară canonicalul declarat cu cel selectat de Google pentru exemple;
- verifică ce variante primesc linkuri interne și apar în sitemap;
- decide ce URL rămâne accesibil și ce URL trebuie redirecționat;
- actualizează sursele interne, nu te baza numai pe canonical;
- testează din nou după recrawl.
| Semnal | Preferință coerentă | Contradicție frecventă |
|---|---|---|
| redirect | duplicatul merge la URL-ul preferat | lanț către o țintă intermediară |
rel=canonical | indică URL-ul final indexabil | indică URL cu redirect, eroare sau noindex |
| sitemap | conține URL-ul preferat | listează toate variantele |
| link intern | folosește forma canonică | meniul și articolele trimit spre duplicate |
| hreflang, dacă există | indică variante canonice reciproce | leagă URL-uri necanonice sau inexistente |
Când Google selectează alt canonical, nu modifica o singură etichetă și nu retrimite imediat. Controlează familia întreagă. Semnalele convergente sunt mai ușor de procesat decât o succesiune de corecții locale.
Cum ceri indexarea unei pagini noi
După publicare:
- leagă pagina dintr-un loc relevant și accesibil;
- include URL-ul canonic în sitemap;
- testează versiunea live în URL Inspection;
- dacă testul trece, folosește „Request indexing” pentru URL-ul important;
- evită retrimiterile repetate și urmărește starea.
Google precizează că solicitarea nu garantează includerea imediată. În ghidul pentru pagini lipsă, recomandarea este să acorzi cel puțin o săptămână după trimiterea sitemapului sau a cererii înainte să presupui automat că există o problemă. Raportul Page indexing notează că, pentru unele site-uri, descoperirea și crawlingul pot dura până la câteva săptămâni. Pentru multe URL-uri, folosește sitemapul; instrumentul de inspecție este pentru verificări punctuale.
Solicitarea de indexare este ultima etapă tehnică, nu prima. Dacă pagina răspunde cu redirect, este blocată, declară alt canonical sau nu are o cale internă, cererea nu înlătură cauza. Nici nu există o comandă prin care să cumperi prioritate organică.
Fișa unei pagini nou publicate
- URL final și canonical identic;
- răspuns 200 și conținut vizibil fără autentificare;
- meta robots permisiv și cale neblocată accidental;
- link intern dintr-o pagină relevantă deja cunoscută;
- sitemap actualizat cu URL-ul final;
- test live salvat cu data;
- cerere trimisă o singură dată după verificări;
- control ulterior al versiunii indexate și al impresiilor.
O pagină nouă are nevoie și de context intern. Aplică checklistul SEO on-page și leag-o din paginile care explică subiectul părinte.
Cum urmărești că remedierea a funcționat
Nu marca problema „rezolvată” doar pentru că ai schimbat setarea în CMS.
| Moment | Test | Dovadă |
|---|---|---|
| imediat după remediere | test live | pagina poate fi accesată și indexarea este permisă |
| după recrawl | URL Inspection | starea indexată reflectă schimbarea |
| după indexare | Performance / căutare | apar impresii relevante, dacă există cerere |
| lunar | Page indexing | tiparul nu reapare pe șablon |
Păstrează URL-ul, cauza, data, schimbarea și rezultatul. Dacă problema afectează un șablon întreg, verifică un eșantion din toate tipurile de pagini, nu un singur URL. Un audit SEO pune aceste constatări în ordinea impactului.
Separă dovada tehnică de efectul comercial. Indexarea confirmă că pagina poate intra în competiție; nu dovedește că există cerere sau că pagina răspunde bine interogării. După ce URL-ul este indexat, urmărește impresiile, interogările și paginile de destinație în Google Search Console, apoi leagă leadurile în sistemul de măsurare.
| Nivel de dovadă | Ce confirmă | Ce nu confirmă |
|---|---|---|
| test live | implementarea publică este accesibilă și pare indexabilă | selecția canonicalului și includerea finală |
| versiune indexată | Google a procesat pagina și raportează o stare | apariția pentru orice interogare |
| impresii în Search Console | URL-ul a fost afișat pentru interogări eligibile | calitatea leadurilor sau venitul |
| analytics / CRM | vizite și acțiuni măsurate | că indexarea a fost singura cauză a schimbării |
Pentru dovada internă Amplify, materialele disponibile nu includ numărul site-urilor diagnosticate în 2025–2026, distribuția cauzelor sau ponderea paginilor afectate. Articolul nu inventează o cauză dominantă. Registrul necesar ar trebui să păstreze site-ul anonimizat, tipul de șablon, motivul din Search Console, cauza confirmată, numărul URL-urilor și starea după recrawl.
Arbore de diagnostic în șase ramuri
Pornește arborele cu URL-ul complet, nu cu domeniul. Dacă Google nu îl cunoaște, verifică descoperirea. Dacă îl cunoaște, dar nu îl poate accesa, verifică serverul, redirecturile și robots. Dacă îl accesează, verifică noindex și canonicalul. Abia când toate aceste controale sunt coerente analizezi diferențierea conținutului și timpul de reprocesare.
Ramurile nu sunt alternative perfecte. Același URL poate avea mai multe probleme: poate fi absent din linkurile interne, listat greșit în sitemap și canonizat către altă versiune. Păstrează cauza tehnică separată de motivul afișat în Search Console. Motivul este o observație a sistemului; cauza este configurația sau proprietatea paginii pe care ai confirmat-o.
| Ramură | Test de confirmare | Acțiune |
|---|---|---|
| sitemap | URL absent sau necanonic | corectează lista |
| robots.txt | accesarea este blocată | corectează regula |
| canonical | Google și site-ul aleg URL-uri diferite | aliniază semnalele |
| noindex | directiva apare pe pagina publică | elimină dacă e accidentală |
| duplicat/subțire | pagini aproape identice | consolidează sau diferențiază |
| pagină nouă | toate testele trec, dar nu a fost reprocesată | leagă, trimite și așteaptă recrawl |
Ordinea de lucru pentru un șablon afectat
- Alege trei până la cinci exemple din categoria raportată, inclusiv o pagină comercială importantă.
- Exportă URL-ul, starea, canonicalul și data ultimei accesări.
- Rulează testul live și verifică răspunsul public în afara CMS-ului.
- Compară sursa HTML și headerul pentru directive robots.
- Verifică sitemapul și toate linkurile interne către forma canonică.
- Corectează șablonul, nu fiecare URL manual, dacă tiparul este comun.
- Repetă testul pe eșantion și trimite validarea ori recrawlul potrivit.
- Urmărește categoria până când exemplele noi nu mai reproduc cauza.
Nu extinde eșantionul doar cu URL-uri care arată aceeași stare. Include pagini din marginea problemei: o pagină care a fost indexată, una exclusă și una nouă. Comparația poate izola diferența de link intern, canonical, conținut sau răspuns server.
Când escaladezi către programator
Escaladează când problema vine din template, header HTTP, router, reguli de server, randare JavaScript sau generarea automată a canonicalului și sitemapului. Ticketul trebuie să conțină exemple bune și rele, rezultatul live, răspunsurile complete și comportamentul dorit. „Google nu indexează” nu este un criteriu de acceptare suficient.
Un criteriu verificabil poate fi: URL-urile de serviciu returnează 200, nu au noindex, declară canonical autoreferențial, apar în sitemap și primesc link intern din categoria relevantă. După publicare, aceleași câmpuri trebuie confirmate pe URL-ul public.
Pentru implementarea tehnică și monitorizare continuă, serviciul SEO Amplify tratează indexarea ca sistem, nu ca intervenție izolată.
Protocolul Sitemaps descrie formatul fișierului, iar RFC 9309 definește standardul robots.txt; niciunul nu transformă descoperirea într-o garanție de indexare. Pentru limbajul și tiparele întâlnite pe piața locală, ghidul SEO Max despre indexare tratează împreună crawlingul, robots, sitemapul și canonicalul, pe care diagnosticul de aici le separă în controale distincte.
Întrebări frecvente
De ce nu îmi indexează Google paginile noi?
Poate să nu le fi descoperit încă, accesarea poate fi blocată, indexarea poate fi interzisă, Google poate alege alt canonical sau pagina poate fi prea similară cu una existentă. URL Inspection stabilește ramura corectă.
Cât durează până apare o pagină trimisă la indexare?
Google indică de regulă de la câteva zile la câteva săptămâni pentru crawling; solicitarea nu garantează includerea. Verifică testul live, legăturile interne și sitemapul înainte să retrimiți.
Pot ascunde o pagină din Google doar cu robots.txt?
Nu în mod sigur. Google poate indexa URL-ul fără conținut dacă îl găsește prin alte linkuri. Pentru excludere folosește noindex pe o pagină accesibilă crawlerului sau protecție cu parolă, după scop.
Canonical și redirect sunt același lucru?
Nu. Redirectul mută utilizatorul și crawlerul către alt URL; canonical păstrează pagina accesibilă, dar indică versiunea preferată pentru consolidare.
Un sitemap trimis cu succes înseamnă că paginile sunt indexate?
Nu. Starea de succes arată că Google a putut procesa fișierul, nu că fiecare URL a fost crawl-uit sau indexat. Compară URL-urile listate cu raportul Page indexing și inspectează separat paginile importante.
Ce fac dacă Google alege alt canonical decât cel declarat?
Verifică familia de duplicate: redirecturi, canonicaluri, sitemap, linkuri interne și conținut. Aliniază toate semnalele către versiunea dorită și urmărește selecția după recrawl; retrimiterea singură nu obligă alegerea.
Repară mai întâi cauza, apoi cere recitirea
Ordinea eficientă este: inspectează, identifică ramura, repară, testează live, solicită recitirea și urmărește starea indexată. Retrimiterea fără diagnostic doar repetă aceeași problemă.
Pentru fiecare incident, închide bucla cu o fișă scurtă: URL, motiv raportat, cauză confirmată, remediere, test live și stare după recrawl. Această disciplină transformă indexarea dintr-o succesiune de încercări într-un proces care poate fi repetat pe orice șablon.
Indexarea este condiția tehnică de intrare, nu întregul proces descris în ce este SEO. După ce pagina poate fi procesată, relevanța, structura, autoritatea și măsurarea rămân necesare pentru vizibilitate și rezultate comerciale.