# Cât durează, de fapt, până te vede Google | Newark Digital

> Google a dat timpii a 23 de procese din Search: indexare în ore, titlu nou în 1-2 zile, migrare în 1-3 luni, ieșire din core update în 3-6 luni.

Sursa: https://www.newark.ro/blog/cat-dureaza-pana-te-vede-google/

EP/037 5 NOIEMBRIE 2026 25 min de citit De Mihai Neacșu

# Cât durează, de fapt, până te vede Google

„Am rezolvat. Și când se vede?" Pe 2 octombrie, la Barcelona, Google a arătat cât durează 23 de procese din Search, de la descoperirea unui URL nou până la ieșirea dintr-un core update. Am pus cifrele lângă documentația oficială și lângă studiile făcute pe mii de site-uri, ca să știi ce aștepți, cât și din ce moment ai voie să te îngrijorezi.

SEO Algoritm

Cuprins

„Am rezolvat. Și când se vede?“

Dacă ai lucrat vreodată cu o agenție de SEO, sau ai fost agenția, știi întrebarea. Vine după fiecare migrare, după fiecare titlu rescris, după fiecare pagină scoasă din noindex. Până de curând, răspunsul cinstit era „depinde“, spus cu jumătate de gură, pentru că nimeni nu avea cifre de la sursă.

Pe 2 octombrie, la Barcelona, Google le-a pus pe masă. Gary Illyes a arătat cât durează 23 de procese din Search, în cazul tipic și în cel mai lent: de la descoperirea unui URL nou până la ieșirea dintr-un core update. Datele vin din analiza internă a Google, nu din estimările cuiva.

Am luat tabelele, le-am pus lângă documentația oficială și lângă studiile independente făcute pe mii de site-uri. Am încercat să răspund la două întrebări. Pentru specialist: ce aștepți, cât, și din ce moment ai voie să te îngrijorezi. Pentru antreprenor: ce înseamnă toate astea în răbdare, în bugete și în deciziile pe care le iei luna asta.

**23** de procese din Search, cronometrate de Google

**~30 de zile** până revine robotul, tipic, pe o pagină deja cunoscută

**3-6 luni** recuperarea tipică după un core update

**523 de zile** media recuperării traficului după o migrare de domeniu (892 de cazuri)

## Ce a arătat Google, cifră cu cifră

Pe scurt

O pagină bună intră în index în câteva ore, un titlu nou apare în 1-2 zile, o migrare se așază în 1-3 luni, iar ieșirea dintr-un core update durează 3-6 luni. Restul e nuanță, dar nuanța e exact locul în care se pierd banii.

Contextul contează. [Search Central Live Deep Dive Europe](https://developers.google.com/search/events) a ținut trei zile la Barcelona, între 30 septembrie și 2 octombrie, organizat de echipa Search Relations de la Google. Prima zi a fost despre crawling, a doua despre indexare, a treia despre servirea rezultatelor. Sesiunea cu timpii s-a numit simplu „How long does it take to…?“ și a fost susținută de Gary Illyes în ultima zi.

La data primelor articole despre eveniment, slide-urile nu apăreau pe pagina oficială de evenimente Google. Cifrele au ajuns la noi prin [recap-ul lui John Campbell](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/) (ROAST), unul dintre vorbitorii din comunitate, preluat apoi de [Search Engine Journal](https://www.searchenginejournal.com/google-crawling-indexing-recovery-timing-ranges/591829/). Pentru fiecare proces, Google a dat un timp minim, unul tipic și unul maxim, din analiza lor internă. Recap-ul a păstrat doar tipicul și maximul.

### Crawling: cât durează până vine robotul

**Robotul vine în ore, dar poate întârzia săptămâni sau să nu mai vină deloc** De la începutul cazului tipic până la capătul celui mai lent, pe scară logaritmică. Unde Google a spus doar „săptămâni" sau „luni", bara e așezată aproximativ (2 săptămâni, 3 luni); „niciodată" nu se poate desena.

Proces

Tipic

Cel mai lent

Descoperirea unui URL nou

~20 ore

săptămâni sau niciodată

Revenirea pe un URL deja cunoscut

~30 zile

săptămâni sau niciodată

Procesarea sitemap-ului

~24 ore

până la 14 zile sau niciodată (calitate)

Preluarea unui robots.txt modificat

~24 ore

25 ore

Ajustarea capacității de crawl

4 ore-2 săptămâni

1-3 săptămâni (la revenire)

Ajustarea cererii de crawl

~20 ore

săptămâni-luni

Sursa: Gary Illyes, Search Central Live Deep Dive Barcelona, 2 octombrie 2026, prin [recap-ul ROAST](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/)

### Indexare: cât durează până pagina „există“ pentru Google

**Indexarea durează o oră și jumătate; o mutare de site, luni** De la începutul cazului tipic până la capătul celui mai lent, pe scară logaritmică. „Ore", „săptămâni" și „luni" sunt așezate aproximativ (2 ore, 2 săptămâni, 3 luni).

Proces

Tipic

Cel mai lent

Randare (JavaScript)

secunde de randare, ore de așteptare la coadă

zile-săptămâni

Procesarea meta tag-urilor

45-90 minute

1-4 zile

Procesarea linkurilor

minute-3 săptămâni

luni

Indexare cap-coadă

~1,5 ore

luni sau niciodată (calitate)

Scoaterea din index

1-3 săptămâni

luni

Schimbarea paginii canonice

1-3 săptămâni

luni (semnale contradictorii)

Mutarea site-ului

1-3 luni

6 luni-peste 1 an

Actualizarea datelor structurate

ore-2 săptămâni

săptămâni sau niciodată (calitate)

Imagini

ore-zile

săptămâni-luni

Video

ore-zile

săptămâni-luni

Sursa: Gary Illyes, Search Central Live Deep Dive Barcelona, 2 octombrie 2026, prin [recap-ul ROAST](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/)

### Rezultate și recuperări: cât durează până se vede în SERP

**Un titlu nou se vede în zile, o recuperare după core update în luni** De la începutul cazului tipic până la capătul celui mai lent, pe scară logaritmică. „Câteva săptămâni-luni" și „luni" sunt așezate aproximativ, la 3 luni.

Proces

Tipic

Cel mai lent

Ștergere urgentă din Search Console

~2 ore

24 ore

Snippet nou afișat

1-2 zile

câteva săptămâni-luni

Titlu nou afișat

1-2 zile

câteva săptămâni-luni

Imaginea din rezultatul text

1-2 săptămâni

câteva săptămâni-luni

Ridicarea unei acțiuni manuale

1-2 săptămâni

4-6 săptămâni, mult mai mult la site-urile inactive

Recuperare după core update

3-6 luni

6 luni-1 an (la următorul core update)

Efectul unui spam update

1-2 săptămâni (continuu)

luni (recalculări în loturi)

Sursa: Gary Illyes, Search Central Live Deep Dive Barcelona, 2 octombrie 2026, prin [recap-ul ROAST](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/)

Un core update se lansează în 2-4 săptămâni, un spam update în 1-2 zile. Nu confunda durata lansării cu durata recuperării: sunt lucruri diferite și le iau pe rând mai jos.

Două avertismente cinstite înainte să construiești planuri pe ele. Google n-a spus pe câte site-uri, în ce perioadă și cum definește „tipic“. Și sunt cifre pentru tot web-ul la grămadă: un site de prezentare cu 20 de pagini și un publisher cu 2 milioane de URL-uri intră în aceeași medie, cum bine a observat [Campbell](https://weareroast.com/news/how-often-does-google-recrawl-pages-real-data-roast/). Sunt repere, nu termene.

## Crawling și indexare: rapid când merge, „niciodată“ când nu merită

Pe un site sănătos, o pagină nouă e descoperită în aproximativ 20 de ore și indexată în cam o oră și jumătate după ce robotul a ajuns la ea. Cuvântul care contează însă în tabel e altul: „niciodată“. Apare de cinci ori la timpii maximi, iar de trei ori are lângă el, în paranteză, „calitate“.

E prima lecție și e mai importantă decât toate cifrele. Cum a rezumat și Campbell, „niciodată“ e de obicei legat de calitate. O pagină care nu mai intră deloc în index a fost, de regulă, văzută și cântărită de Google, care a decis că nu merită locul. Un sitemap retrimis nu schimbă verdictul.

### Revenirea robotului: media de 30 de zile ascunde tot

Google spune că revine pe o pagină deja cunoscută, tipic, cam o dată la 30 de zile. ROAST a verificat asta pe propriul site, imediat după eveniment. Au interogat zilnic, timp de 30 de zile, toate cele 178 de URL-uri prin URL Inspection API: 5.306 măsurători în total.

Rezultatul e mai interesant decât media. [Datele lor](https://weareroast.com/news/how-often-does-google-recrawl-pages-real-data-roast/) arată:

- homepage-ul era revizitat aproape zilnic, cu o vechime medie a ultimei vizite de 1,6 zile;
- secțiunea de cariere stătea în medie 73,8 zile de la ultima trecere a robotului;
- doar 6 din 14 secțiuni aveau sub 20 de zile, și toate erau pagini legate din meniu sau footer pe fiecare pagină a site-ului;
- politica de confidențialitate, deși legată de peste tot, avea 41,3 zile: dacă pagina nu se schimbă, Google vine tot mai rar.

**Aceeași medie de 30 de zile, de la 1,6 la 73,8 zile pe un singur site** Vechimea medie a ultimei vizite a robotului, pe secțiuni ale site-ului ROAST: 178 de URL-uri, interogate zilnic 30 de zile (5.306 măsurători)

Secțiune

Zile de la ultima vizită

Homepage

1,6

Tipic, după Google

30

Politica de confidențialitatelegată de pe fiecare pagină

41,3

Secțiunea de cariere

73,8

Sursa: [ROAST](https://weareroast.com/news/how-often-does-google-recrawl-pages-real-data-roast/), URL Inspection API, octombrie 2026; „tipic" din prezentarea lui Gary Illyes

Pentru un antreprenor, traducerea e directă. Dacă rescrii descrierea unei categorii vechi, schimbarea stă la coadă până revine robotul. Pe o secțiune pe care Google o vizitează o dată la o lună și ceva, ai pierdut o lună înainte ca munca să conteze măcar.

### Capacitatea de crawl: cade în secunde, revine în săptămâni

Google are un singur sistem de crawling pentru Search, Ads, Shopping și Images, iar limita de capacitate pe host e comună tuturor. La Barcelona, Cherry Prommawin a explicat că robotul încetinește când cresc timpul de conectare, timpul până la primul byte sau numărul de răspunsuri 429 și 5xx. [Documentația de crawl budget](https://developers.google.com/crawling/docs/crawl-budget) confirmă: orice site pornește de la aceeași limită, prudentă, și o primește mai mare doar dacă rămâne stabil.

Tabelul lui Illyes adaugă partea dureroasă: capacitatea poate scădea în câteva secunde când serverul se chinuie, iar revenirea durează 1-3 săptămâni. Unul dintre scenariile jucate în prima zi a fost chiar acesta: în timpul unei reduceri, firewall-ul confundă robotul cu un atac și îi servește erori 429 și 503, iar crawl-ul pe tot domeniul scade cu 90%.

Black Friday e la un pas. Dacă ai Cloudflare sau orice protecție anti-bot, verifică acum că Googlebot verificat trece fără provocări. O pagină de CAPTCHA care întoarce cod 200 e văzută ca pagină goală, adică soft 404, și consumi crawl pe nimic exact când ai cea mai mare nevoie de el.

### Cererea de crawl și „vecinii“ paginii tale

Un detaliu din prima zi pe care îl consider aur pentru magazinele online: când Google nu știe încă nimic despre calitatea sau popularitatea unui URL, folosește media folderului părinte. Apoi a folderului de deasupra, și tot așa.

Altfel spus, o pagină nouă pornește cu reputația vecinilor. Dacă /blog/ e plin de articole subțiri scrise pentru volum, articolul bun pe care îl publici mâine intră într-o coadă mai lentă. Curățenia în secțiunile vechi e, de fapt, infrastructură.

### Sitemap, robots.txt, randare

Sitemap-ul e procesat tipic în 24 de ore, dar poate dura până la 14 zile sau deloc, din nou din motive de calitate. Google citește lastmod doar dacă data e constant corectă. Un CMS care pune data de azi pe toate URL-urile la fiecare rebuild îl învață pe Google să ignore câmpul.

Un robots.txt modificat e preluat în aproximativ 24 de ore, maximum 25. Dacă ai blocat din greșeală ceva important, repari și în cel mult o zi Google vede corecția. E una dintre puținele greșeli care se repară repede.

Randarea JavaScript durează secunde, dar pagina poate aștepta ore la coadă și, în cazurile lente, zile sau săptămâni. Erin Sparling de la Google a dat un detaliu practic: robotul încarcă pagina într-un viewport de circa 10.000 de pixeli înălțime și nu face scroll, nu dă click. Produsele încărcate doar la scroll sau după un buton „Încarcă mai multe“ pot rămâne invizibile pentru el.

### Linkurile au și ele timpul lor

Procesarea linkurilor durează de la câteva minute la trei săptămâni, iar în cazurile lente luni de zile. Asta schimbă felul în care evaluezi un articol sponsorizat sau un backlink nou. Dacă după o săptămână nu vezi nimic, nu e un semn că linkul n-a contat. Probabil nici n-a fost încă procesat.

### Când chiar ai o problemă de crawl budget

Google e clar în documentație: dacă paginile tale sunt crawlate în aceeași zi în care le publici, nu ai o problemă de buget. Ghidul avansat e pentru site-uri de peste 1 milion de pagini care se schimbă săptămânal, pentru cele de peste 10.000 de pagini care se schimbă zilnic, sau pentru cele cu multe URL-uri „Descoperite, momentan neindexate“.

Un magazin de câteva mii de produse probabil nu atinge pragurile de mărime. La al treilea criteriu se ajunge însă ușor, din cauza filtrelor care generează mii de combinații de URL-uri. Acolo regulile sunt simple:

- consolidezi duplicatele, nu le lași să concureze;
- blochezi în robots.txt combinațiile de filtre fără valoare, nu le pui noindex (cu noindex, Google tot le cere și le aruncă după);
- dai 404 sau 410 paginilor șterse definitiv, nu le lași blocate, pentru că URL-urile blocate rămân mai mult în coada de crawl;
- suporți răspunsul 304 Not Modified, ca robotul să nu descarce de fiecare dată ce n-ai schimbat.

## Titluri, snippet-uri, canonical: de ce „am schimbat ieri“ nu înseamnă nimic

Un titlu nou apare în rezultate tipic în 1-2 zile. Dar ceasul ăsta pornește abia după ce robotul revine pe pagină, iar pe o pagină vizitată o dată pe lună asta poate însemna patru săptămâni de așteptare înainte de cele 1-2 zile. Și chiar și atunci, Google decide singur dacă folosește titlul tău.

### Titlul îl scrii tu, dar îl afișează Google

Google rescrie de mult titlurile, iar studiile sugerează că o face tot mai des. [Cyrus Shepard (Zyppy)](https://zyppy.com/seo/google-title-rewrites/) a analizat 80.959 de titluri de pe 2.370 de site-uri și a găsit că 61,6% erau rescrise cel puțin parțial. Cele mai stabile erau cele între 51 și 60 de caractere, cu doar 39-42% rescrieri.

În primul trimestru din 2025, [John McAlpin](https://searchengineland.com/google-changed-76-of-title-tags-in-q1-2025-heres-what-that-means-454847) a repetat exercițiul pe primele 20 de rezultate și a ajuns la 76%. Cea mai frecventă modificare: Google scoate numele brandului, în 63% din titlurile schimbate.

Practic, când titlul nou nu apare în rezultate, întrebarea corectă nu e „când“, ci „dacă“. Un titlu clar, care seamănă cu H1-ul și nu e îndesat cu cuvinte cheie, are cele mai mari șanse să rămână cum l-ai scris.

### Canonical: două săptămâni minimum, luni dacă te contrazici singur

Schimbarea paginii canonice durează tipic 1-3 săptămâni. Din iulie 2026, [documentația Google](https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting) spune explicit că, după ce repari conținutul, paginile pot rămâne grupate ca duplicate până la două săptămâni. Se separă mai repede dacă diferența dintre ele e clară și consistentă.

Cazul lent, cel de „luni“, are în tabel o explicație între paranteze: semnale contradictorii. Tag-ul canonical spune A, sitemap-ul listează B, linkurile interne trimit spre C. Google nu alege ce vrei tu, alege ce i se pare mai credibil din tot ce îi transmiți.

În eCommerce, asta se vede la variantele de produs. Zece culori ale aceluiași tricou, cu aceeași descriere copiată, ajung în același cluster indiferent ce scrie în canonical. Dacă vrei ca fiecare variantă să se claseze separat, trebuie să fie suficient de diferită încât să merite.

### Date structurate: niciodată o problemă, nici o garanție

Actualizarea datelor structurate durează de la câteva ore la două săptămâni, iar cazul lent are din nou „niciodată (calitate)“. Ryan Levering, inginer la Google, a spus la Barcelona că datele structurate nu sunt niciodată un minus, potrivit [recap-ului din a doua zi](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-2-recap/). Textul din schema e trecut ca context și către AI Overviews și AI Mode, nu doar către rich results.

Reversul: dacă îți schimbi prețurile în schema pentru Black Friday, nu te baza că Google le afișează din prima zi. Pune-le cât mai devreme și ține-le consecvente cu ce vede clientul pe pagină.

## Migrările: Google le procesează în 1-3 luni, traficul are alt calendar

O mutare de site se așază tipic în 1-3 luni, iar în cazurile lente durează între 6 luni și peste un an. Un site mic poate termina în câteva săptămâni. Dar atenție la ce măsoară cifra asta: cât îi ia lui Google să proceseze mutarea, nu cât îți ia ție să recuperezi traficul.

Diferența e uriașă, iar datele independente o arată clar. [Dan Taylor](https://www.searchenginejournal.com/study-how-long-should-seo-migration-take/492050/) a strâns 892 de migrări de domeniu și a măsurat, cu instrumente terțe, cât i-a luat domeniului nou să ajungă la traficul organic estimat al celui vechi:

- în medie, 523 de zile;
- cele mai rapide cazuri au durat 19, 22, 23 și 33 de zile;
- 17% dintre migrări nu își recuperaseră traficul nici după 1.000 de zile;
- în versiunea anterioară a studiului, pe 171 de migrări, media fusese de 229 de zile, iar 42% nu își reveniseră deloc.

Sunt estimări din instrumente terțe, nu date din Search Console, deci le iau cu prudență. Dar direcția e limpede: procesarea tehnică se termină în câteva luni, iar recuperarea completă poate dura mult peste un an.

### Legătura care explică întârzierea

O ipoteză din comunitate, citată de Taylor, leagă durata de profilul de backlinkuri: ca traficul să revină, linkurile externe trebuie recrawlate și redirecționările lor procesate. Taylor a verificat-o pe date și a găsit o oarecare corelație cu numărul de domenii de referință, dar cu multe excepții, probabil din cauza felului în care s-a făcut fiecare migrare.

Tabelul lui Illyes confirmă indirect ipoteza. Procesarea linkurilor durează până la 3 săptămâni în cazul tipic și luni în cel lent. Iar paginile care primesc acele linkuri trebuie, la rândul lor, revizitate. Fiecare etapă o așteaptă pe cea dinainte, iar întârzierile se adună.

### Ce spune Google că funcționează

[Ghidul oficial de mutare](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) are câteva reguli pe care le-aș lipi pe monitorul oricui pregătește o migrare:

Înainte și după migrare

- **Schimbi un singur lucru o dată.** Domeniu nou, platformă nouă și design nou în aceeași noapte înseamnă trei variabile și niciun diagnostic posibil.
- **Muți în perioada de minim sezonier.** Pentru majoritatea magazinelor, asta exclude categoric noiembrie și decembrie.
- **Pregătești serverul:** după migrare, Google crawlează site-ul nou mai intens decât de obicei.
- **Redirecționezi 301 fiecare URL vechi către echivalentul lui**, nu totul spre homepage. Redirecționările în masă spre o pagină irelevantă pot fi tratate ca soft 404.
- **Eviți lanțurile:** Googlebot urmează până la 10 salturi, dar Google recomandă ideal maximum 3.
- **Păstrezi redirecționările cel puțin un an**, pentru că abia atunci Google a transferat toate semnalele.
- **Folosești Change of Address** în Search Console dacă schimbi domeniul.

O mutare e considerată încheiată abia după ce Googlebot a vizitat cel puțin o dată fiecare URL, vechi și nou. Iar dacă după migrare vezi încă pagini vechi într-o căutare site:, nu intra în panică. John Mueller a explicat la Barcelona că Google păstrează versiunile alternative în același cluster, ca să nu piardă semnalele.

### Schimbarea platformei e tot o migrare

Când un magazin trece de pe o platformă de eCommerce pe alta, aproape întotdeauna se schimbă structura URL-urilor. Pentru Google, asta e o mutare de site cu toate consecințele, chiar dacă domeniul rămâne același.

Google cere explicit să incluzi în mapare și imaginile, PDF-urile și celelalte fișiere găzduite, pentru că pot avea deja trafic și linkuri. La un magazin, adaugă pe listă paginile de filtre care aduc trafic și URL-urile vechi de campanie. Tot ce are trafic sau linkuri trebuie să ajungă undeva.

Un ultim lucru, pentru antreprenor. Bugetează de la început 1-3 luni de fluctuații și ține o rezervă în Google Ads pentru categoriile care îți aduc banii. E o asigurare ieftină pe perioada în care Google încă reconstruiește harta site-ului tău, nu un semn de neîncredere în migrare.

Și ca să nu rămână doar partea grea: consolidarea, făcută bine, poate să iasă excelent. Martyna Ağanoğlu a prezentat la Barcelona o fuziune de două branduri în care site-ul a coborât de la 2.000 la 100 de pagini, fără scădere de trafic și cu venituri mai mari.

## Core update: 3-6 luni, iar uneori aștepți calendarul Google

Recuperarea după un core update durează tipic 3-6 luni, iar în cazul lent între 6 luni și un an. În tabel, cazul lent are o explicație scurtă: „următorul core update“. Practic, recuperarea vine atunci când sistemele Google te reevaluează.

[Documentația oficială](https://developers.google.com/search/docs/appearance/core-updates) spune același lucru, mai pe larg. Unele îmbunătățiri se văd în câteva zile, dar sistemelor le pot trebui câteva luni ca să confirme că site-ul, în ansamblu, produce constant conținut util. Dacă după câteva luni nu s-a mișcat nimic, s-ar putea să aștepți următorul core update. Între timp, Google face și update-uri mai mici, neanunțate, care pot aduce și ele urcări.

### Cât de des vine „următorul core update“

Am pus cap la cap istoricul din [Search Status Dashboard](https://status.search.google.com/products/rGHU1u87FJnkP6W2GwMi/history). Din martie 2024 până în mai 2026, Google a lansat nouă core update-uri.

**De la ultimul core update au trecut deja 166 de zile** Zile între începutul a două core update-uri consecutive, din martie 2024 până pe 3 noiembrie 2026. Recuperarea tipică după un core update: 3-6 luni. Ultimul rând e intervalul încă deschis: niciun core update anunțat după 21 mai 2026.

Interval

Zile

mar 2024 → aug 2024

163

aug 2024 → nov 2024

88

nov 2024 → dec 2024

31

dec 2024 → mar 2025

91

mar 2025 → iun 2025

109

iun 2025 → dec 2025

164

dec 2025 → mar 2026

106

mar 2026 → mai 2026

55

mai 2026 → azi

166

Sursa: [Google Search Status Dashboard](https://status.search.google.com/products/rGHU1u87FJnkP6W2GwMi/history), istoricul actualizărilor de ranking · 9 core update-uri, martie 2024-mai 2026

Intervalul dintre ele a variat între 31 și 164 de zile, iar cele [două din 2026](https://www.newark.ro/blog/google-core-update-martie-2026/) s-au lansat în aproximativ 12 zile fiecare. De la [cel din 21 mai](https://www.newark.ro/blog/google-core-update-mai-2026/) au trecut însă 166 de zile, cel mai lung interval din martie 2024 încoace. Dacă site-ul tău a scăzut în mai și ai făcut corecțiile în vară, faptul că încă nu vezi recuperarea nu înseamnă că munca a fost degeaba.

### Cum citești corect o scădere

Google recomandă să aștepți cel puțin o săptămână întreagă după finalizarea update-ului, apoi să compari săptămâna de după cu cea de dinainte de lansare. Apoi faci diferența între tipuri de scădere:

- o scădere mică, de pe poziția 2 pe 4, nu cere măsuri drastice, iar Google recomandă explicit să nu modifici conținutul care deja performează;
- o scădere mare, de pe 4 pe 29, cere o evaluare serioasă a paginilor afectate;
- „reparațiile rapide“, gen scoaterea unui element pentru că ai auzit că e rău pentru SEO, nu ajută;
- ștergerea de conținut e ultima soluție, nu prima.

La Barcelona, Gary Illyes a adăugat o nuanță pe care o consider esențială pentru diagnostic: core update-urile evaluează conținutul la nivel de pagină, nu de domeniu. De aceea, după același update, unele pagini ale tale urcă și altele coboară. Analiza se face pe pagini și pe grupuri de pagini, nu pe „site-ul a scăzut“.

### Ce înseamnă „calitate“, în cuvintele Google

Duy Nguyen, analist de calitate la Google, a trimis sala la ghidurile pentru evaluatorii de calitate, care sunt publice. Calitatea e definită acolo prin patru lucruri: efort, originalitate, talent sau pricepere și acuratețe (am scris mai pe larg despre [E-E-A-T](https://www.newark.ro/blog/ce-inseamna-e-e-a-t-si-cum-ne-poate-ajuta-in-procesul-de-optimizare-seo/)). Exemplul lui de conținut bun a fost o recenzie de pantofi cu măsurători proprii, fotografii proprii și documentare serioasă.

Gary Illyes a dat și contextul: Google filtrează zilnic 40 de miliarde de pagini spam, iar [conținutul generat la scară](https://www.newark.ro/blog/safe-detectorul-de-spam-ai-al-google/) devine o problemă mai mare decât spamul de linkuri. Dacă strategia ta de conținut se bazează pe volum, asta e partea din articol pe care merită s-o recitești.

### Spam update-urile au alt ritm

Efectul unui spam update se vede tipic în 1-2 săptămâni, pentru că filtrele rulează continuu, dar recalculările în loturi pot dura luni. Lansarea în sine a fost în 2026 de obicei scurtă: 19 ore și jumătate în [martie](https://www.newark.ro/blog/google-spam-update-martie-2026/), două zile în [iunie](https://www.newark.ro/blog/google-spam-update-iunie-2026/), aproape trei în [august](https://www.newark.ro/blog/google-spam-update-august-2026/). Cel din septembrie a durat însă 13 zile și 16 ore. Încă o dovadă că și intervalele Google sunt repere, nu promisiuni.

## Acțiuni manuale și ștergeri urgente: singurele lucruri cu adevărat rapide

O acțiune manuală e ridicată tipic în 1-2 săptămâni după cererea de reconsiderare, maximum 4-6 săptămâni. Excepția din tabel: site-urile inactive, unde poate dura mult mai mult. Iar o ștergere urgentă cerută din Search Console se aplică în aproximativ 2 ore, cel mult o zi.

### Reconsiderarea: totul sau nimic

[Pagina de ajutor Google](https://support.google.com/webmasters/answer/9044175) are câteva reguli pe care merită să le știi înainte să apeși „Request review“:

- repari problema pe toate paginile afectate; o reparație parțială nu aduce o revenire parțială;
- cererea bună explică problema exactă, pașii făcuți și rezultatul lor;
- cererile legate de linkuri durează de obicei mai mult;
- nu retrimiți cererea până nu primești decizia pe cea în curs;
- la linkuri nenaturale, un disavow aplicat orbește pe toate linkurile, fără încercări reale de eliminare, poate duce la respingere.

De ce durează mai mult la site-urile inactive, Google nu a explicat. Lectura mea: un site care nu se mai actualizează e vizitat rar de robot, iar verificarea corecțiilor depinde de recrawl. E același mecanism ca la cererea de crawl, aplicat unei situații în care chiar ai nevoie de viteză.

Un caz practic pentru cine cumpără domenii expirate: [ghidul de migrare](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) recomandă explicit să verifici imediat dacă domeniul are acțiuni manuale de la fostul proprietar și ștergeri de URL-uri rămase active. Dacă găsești ceva, Google spune să menționezi în cererea de reconsiderare că ai preluat recent domeniul.

### Ștergerea urgentă e temporară

Instrumentul Removals din Search Console e rapid, dar [ascunde un URL doar aproximativ șase luni](https://support.google.com/webmasters/answer/9689846). Nu îl scoate din index și nu oprește robotul. Ca ștergerea să fie definitivă, ai nevoie și de unul dintre pașii de mai jos:

- pagina întoarce 404 sau 410;
- accesul cere parolă;
- pagina are [noindex](https://www.newark.ro/blog/ce-este-x-robots-tag-si-de-ce-conteaza/), varianta pe care chiar Google o numește mai puțin sigură.

Google precizează și că robots.txt nu e o metodă de blocare a indexării. Iar dacă doar ai șters pagini vechi care întorc 404, nu ai nevoie de instrument: ies singure din rezultate pe măsură ce sunt recrawlate. În tabelul lui Illyes, scoaterea din index durează tipic 1-3 săptămâni.

Unul dintre scenariile din prima zi a fost exact acesta: un subdomeniu de staging fără parolă, descoperit printr-un link uitat în codul de producție, cu 50.000 de URL-uri crawlate. Răspunsul lui John Mueller: instrumentul de eliminare din Search Console. Apoi, evident, parola pe staging.

## Lanțul: de ce întârzierile se adună

Illyes a insistat pe un singur avertisment: procesele sunt legate. O pagină nu poate fi indexată înainte să fie crawlată, nu poate primi un titlu nou în rezultate înainte să fie reindexată. Așa că într-un plan pui timpii tipici, iar primul lucru de aflat e cât de des vine robotul pe pagina ta.

**Fiecare etapă o așteaptă pe cea dinainte, iar la mijloc stă o poartă de calitate.** Lanțul simplificat de la URL la rezultat, cu timpii prezentați de Gary Illyes la Barcelona, pe 2 octombrie 2026:

1. **1\. Descoperirea URL-ului** Tipic ~20 ore; lent: săptămâni sau niciodată.
2. **2\. Vizita robotului (crawl)** Revenire tipic ~30 zile; lent: săptămâni sau niciodată.
3. **3\. Randare și procesare** Secunde de randare, ore la coadă; lent: zile-săptămâni.
4. **Poarta: merită indexată?** Dacă nu, pagina rămâne în afara indexului: „niciodată (calitate)" apare de 3 ori în tabelul Google.
5. **4\. Indexare** Tipic ~1,5 ore; lent: luni.
6. **5\. Canonical și linkuri** 1-3 săptămâni; lent: luni (semnale contradictorii).
7. **6\. Afișare în rezultate** Titlu și snippet: 1-2 zile; lent: săptămâni-luni.
8. **7\. Reevaluare de calitate** Core update: 3-6 luni; lent: următorul core update.

Paginile trec prin aceleași etape, în ordine, iar la poarta de calitate unele nu mai trec deloc. Orice întârziere de sus se mută automat în toate etapele de jos.

### Un calcul realist

Să zicem că pe 1 decembrie rescrii conținutul duplicat de pe 200 de pagini de categorie și corectezi canonicalurile. Adunând timpii tipici:

- robotul trebuie să revină pe fiecare pagină, tipic în circa 30 de zile, mai rar pe paginile adânci;
- după crawl, indexarea durează în jur de o oră și jumătate;
- Google poate ține paginile grupate ca duplicate încă până la două săptămâni;
- titlurile și snippet-urile noi apar în 1-2 zile.

Pentru ultimele pagini din lot, asta înseamnă cam 6-7 săptămâni până când schimbarea se vede complet. Adică pe la jumătatea lui ianuarie, nu „de săptămâna viitoare“. Iar dacă problema de fond era una de calitate, verdictul final vine abia cu următorul core update.

### O regulă simplă pentru raportare

Din tabelele Google se poate construi o regulă simplă pentru momentul în care trebuie să spui dacă ceva „merge“ sau „s-a blocat“. Cât timp ești în intervalul tipic, aștepți. Când l-ai depășit, verifici. Când ai depășit și cazul lent, ai o problemă reală de găsit.

Ce am schimbat și când am voie să mă îngrijorez

Alege tipul schimbării și spune câte zile au trecut de atunci. Termenele vin din tabelele prezentate de Google.

Ce ai schimbat

Zile trecute de la schimbare

La câte zile trece robotul pe pagină (contează la titlu și canonical)

Termen tipic, în zile de la schimbare

Ce faci acum

Cazul lent, după Google

Fără JavaScript: dacă ai schimbat ceva pe o pagină existentă (titlu, canonical), adună zilele până revine robotul cu capătul de sus al intervalului tipic din tabelele de mai sus. Până acolo aștepți; după, verifici; după cazul lent, cauți problema.

Estimare, nu termen. Termenul tipic e capătul de sus al intervalului tipic din tabelele Google: pagină nouă ~20 ore până la descoperire plus ~1,5 ore de indexare; titlu 1-2 zile și canonical 1-3 săptămâni, ambele după vizita robotului; robots.txt ~24 ore; link minute-3 săptămâni; acțiune manuală 1-2 săptămâni de la cererea de reconsiderare; migrare 1-3 luni; core update 3-6 luni. Unde Google a dat cazul lent doar în cuvinte („luni", „niciodată"), calculatorul nu dă al treilea verdict.

O migrare care nu s-a așezat după trei luni e la capătul de sus al intervalului tipic: e momentul să cauți redirecționări greșite și erori în Search Console. Un canonical care nu s-a schimbat după trei săptămâni de la recrawl îți spune aproape sigur că semnalele se contrazic. La o pagină nouă neindexată după câteva săptămâni, întrebarea utilă e ce aduce în plus față de ce există deja.

## Ce faci concret cu cifrele astea

Cifrele Google nu te ajută dacă nu știi când a trecut robotul pe la tine. De acolo începe tot: măsori de la data vizitei, nu de la data publicării.

Pentru echipa tehnică

- **Măsoară-ți propriul ritm de crawl.** URL Inspection API întoarce data ultimei vizite a robotului pentru fiecare URL, cu o limită de 2.000 de inspecții pe proprietate pe zi. ROAST a publicat un Google Sheet gratuit care face asta; la fel de bine îl construiești intern, cu un script care rulează zilnic.
- **Rezervă „Request indexing“ pentru paginile critice.** Funcția are cotă, iar Google însuși recomandă s-o folosești doar pentru URL-urile cele mai importante.
- **Verifică acum firewall-ul și CDN-ul.** Googlebot verificat nu trebuie să primească 429, 503 sau pagini de CAPTCHA, mai ales în perioadele de vârf. Capacitatea de crawl cade în secunde și revine în 1-3 săptămâni.
- **Urmărește timpul de răspuns al serverului și erorile 5xx.** Sunt semnalele după care Google decide cât de repede are voie să crawleze.
- **Pune lastmod corect sau deloc.** O dată falsă, actualizată la fiecare rebuild, îl învață pe Google să ignore câmpul.
- **Curăță secțiunile slabe.** Paginile noi pornesc cu reputația folderului din care fac parte.
- **Aliniază toate semnalele canonice:** tag canonical, sitemap, linkuri interne, hreflang. Un singur semnal contradictoriu poate transforma 1-3 săptămâni în luni.
- **Nu ascunde conținutul după scroll sau click.** Robotul nu derulează și nu apasă butoane, deci produsele și linkurile trebuie să existe în HTML.
- **Notează data fiecărei schimbări.** Search Console are [adnotări](https://support.google.com/webmasters/answer/16530728) direct pe graficul de performanță, până la 200 pe proprietate. Fără ele, peste trei luni nu mai separi efectul muncii tale de un update.

Pentru antreprenor

- **Întreabă „când a trecut robotul?“, nu „când ai schimbat?”.** Data care contează e vizita lui Google, nu data din CMS.
- **Planifică pe calendarul Google, nu pe al tău.** Pagina de campanie pe care o vrei vizibilă organic o publici cu săptămâni înainte și o ții pe același URL de la an la an, ca să-și păstreze istoricul.
- **Bugetează realist:** 1-3 luni de fluctuații la o migrare, 2-6 săptămâni pentru o acțiune manuală, 3-6 luni pentru o recuperare după core update.
- **Nu repara ce merge.** După o scădere mică, Google recomandă explicit să nu atingi conținutul care deja performează.
- **Cere un plan cu date în el.** Un plan bun de recuperare după un core update are trecută în el și data probabilă a reevaluării, nu doar lista de modificări.
- **Cere raportare pe etape:** crawl, indexare, afișare, poziții, vânzări. Fiecare are ceasul ei, iar raportul bun îți arată la care dintre ele s-a ajuns.

## Timpul e singura resursă pe care n-o poți cumpăra

Până acum, „durează“ era un răspuns pe care trebuia să-l crezi pe cuvânt. De acum are cifre, iar cifrele vin chiar de la Google. Pentru oricine face SEO, e o veste bună: discuția cu clientul se poate muta de la promisiuni la calendare.

Mai e un motiv să le iei în serios. Gary Illyes a închis cele trei zile spunând că funcțiile AI din Google Search folosesc exact aceleași procese ca rezultatele clasice. Google Search, AI Overviews și AI Mode se bazează pe același Googlebot. Așa că ceasul din articolul ăsta e și ceasul [răspunsurilor AI](https://www.newark.ro/blog/optimizarea-geo-generative-engine-optimization/): o pagină pe care robotul n-a mai văzut-o de o lună apare acolo în versiunea de acum o lună.

Pentru antreprenor, concluzia e una singură. Bugetul de reclame îl poți dubla mâine. Cele 30 de zile până revine robotul, cele două săptămâni ale unui canonical sau cele câteva luni până la următorul core update nu le scurtezi cu bani. Cine începe mai devreme câștigă, pentru că timpul e singurul lucru din SEO care nu se vinde.

Dacă vrei să vezi cum arată ceasul ăsta pe site-ul tău, cu datele tale de crawl și indexare, scrie-ne. Ne uităm împreună.

## Surse

**Evenimentul și datele lui Gary Illyes**

- [Google Search Central Live Deep Dive, Barcelona, Day 3 Recap](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-3-recap/) (John Campbell, ROAST, 2 octombrie 2026): tabelele complete
- [Day 1 Recap: crawling](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-1-recap/) și [Day 2 Recap: indexare](https://weareroast.com/news/google-search-central-live-deep-dive-barcelona-day-2-recap/) (ROAST)
- [Google Shows How Long Crawling, Indexing & Recovery Can Take](https://www.searchenginejournal.com/google-crawling-indexing-recovery-timing-ranges/591829/) (Matt G. Southern, Search Engine Journal, 4 octombrie 2026)
- [How Often Does Google Recrawl Pages? Real Data from the ROAST Website](https://weareroast.com/news/how-often-does-google-recrawl-pages-real-data-roast/) (ROAST, 7 octombrie 2026)

**Documentație Google**

- [Google Search’s core updates and your website](https://developers.google.com/search/docs/appearance/core-updates)
- [How to move a site](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)
- [Fix canonicalization issues](https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting) și [Google Says Canonical Re-Evaluation Can Take Up to Two Weeks](https://www.searchenginejournal.com/google-says-canonical-re-evaluation-can-take-up-to-two-weeks/582053/) (SEJ, 10 iulie 2026)
- [Optimize your crawl budget](https://developers.google.com/crawling/docs/crawl-budget)
- [Manual actions report](https://support.google.com/webmasters/answer/9044175)
- [Removals and SafeSearch reports tool](https://support.google.com/webmasters/answer/9689846)
- [Search Console annotations](https://support.google.com/webmasters/answer/16530728)
- [Google Search Status Dashboard, istoricul actualizărilor de ranking](https://status.search.google.com/products/rGHU1u87FJnkP6W2GwMi/history)

**Studii independente**

- [How Long Should An SEO Migration Take? \[Study Updated\]](https://www.searchenginejournal.com/study-how-long-should-seo-migration-take/492050/) (Dan Taylor, SEJ, ianuarie 2025)
- [Google Rewrites 61% of Page Title Tags](https://zyppy.com/seo/google-title-rewrites/) (Cyrus Shepard, Zyppy)
- [Google changed 76% of title tags in Q1 2025](https://searchengineland.com/google-changed-76-of-title-tags-in-q1-2025-heres-what-that-means-454847) (John McAlpin, Search Engine Land)

Întrebarea episodului Vrei să știi când a trecut robotul pe site-ul tău? [Hai să ne uităm împreună](https://www.newark.ro/contact/)

## Citește și

[Toate articolele →](https://www.newark.ro/blog/)

[EP/036 AI · GEO · 12 min Ce tip de mențiune te face vizibil în AI](https://www.newark.ro/blog/ce-tip-de-mentiune-te-face-vizibil-in-ai/)[EP/035 AI · SEO · 14 min ChatGPT după GPT-6: traficul n-a dispărut, a devenit invizibil](https://www.newark.ro/blog/chatgpt-gpt-6-trafic-invizibil/)[EP/034 AI · GEO · 21 min Citările din AI se schimbă zilnic. Ce măsori, de fapt?](https://www.newark.ro/blog/citarile-ai-se-schimba-zilnic/)