Google a încheiat spam update-ul din septembrie 2026 pe 8 octombrie, după aproape 14 zile de rulare, potrivit Search Engine Journal. Gary Illyes a prezentat intervale orientative pentru crawling, mutarea unui site și recuperarea după un core update, iar Search Console permite acum filtrarea pe mai multe țări simultan. Rămâne o întrebare centrală pentru orice echipă de SEO din România: ce faci concret cu aceste informații, fără să confunzi zgomotul din tool-uri cu un rezultat real în trafic și în vânzări.

Ce s-a întâmplat de fapt în ultima săptămână SEO

Sursa consemnează cinci subiecte care merită tratate separat, nu amestecate într-un singur val de panică. Primul: spam update-ul din septembrie 2026 s-a încheiat pe 8 octombrie, după o rulare începută pe 24 septembrie, adică aproximativ 13 zile și 16 ore, aproape de intervalul de maxim două săptămâni anunțat inițial. Celelalte trei update-uri de spam din acest an s-au încheiat în mai puțin de trei zile fiecare, deci durata aceasta iese din tipar. Al doilea: SEOmonitor relatează că, din 26 septembrie, tool-urile de rank tracking au înregistrat schimbări bruște de poziții pe care utilizatorii care căutau în Google nu le vedeau, ceea ce platforma atribuie datelor incomplete și inexacte returnate de Google către instrumentele automate. Al treilea: Gary Illyes a prezentat la Barcelona, pe 2 octombrie, intervale de timp pentru crawling, indexare, mutarea unui site și recuperarea după un core update, cifre preluate dintr-un rezumat al lui John Campbell de la ROAST. Al patrulea: Search Console a extins filtrele din raportul de performanță, astfel încât poți combina traficul din mai multe țări sau de pe mai multe dispozitive. Al cincilea: ghidul Google despre conținut util avertizează acum explicit împotriva profilurilor de autor fabricate, inclusiv poze generate de AI, nume inventate și credențiale false.

Fiecare dintre aceste puncte are o caracteristică comună, semnalată chiar de sursă: eticheta spune mai puțin decât pare. Un număr din tool nu e neapărat realitatea din SERP. Cuvântul „tipic" dintr-un rezumat de conferință nu are definiție operațională. Un status „Couldn't fetch" nu înseamnă neapărat un fișier stricat.

Intervalele de crawling și recuperare: folosește-le ca reper, nu ca termen

Rezumatul citat de sursă indică, pentru mutarea unui site, un interval tipic de una până la trei luni, iar în cazurile cele mai lente, de la șase luni la peste un an. Pentru recuperarea după un core update, intervalul tipic ar fi de aproximativ trei până la șase luni, iar în situațiile cele mai lente, între șase luni și un an. Sursa notează explicit o limită importantă: rezumatul nu precizează dimensiunea eșantionului, perioada analizată sau ce înseamnă exact „tipic".

Aici e locul unde mulți marketeri greșesc. Ei transformă un interval dintr-o prezentare într-un termen de livrare. Nu este. Un interval fără metodologie publicată este un reper de comparație, nu o promisiune. Dacă un client întreabă dacă mutarea site-ului e încă în curs sau e blocată, intervalul îți dă un cadru de discuție, îți permite să spui că la trei luni ești spre limita superioară a intervalului tipic. Nu îți permite să spui că sigur se rezolvă în trei luni.

Ce verifici tu, ca operator, înainte de a comunica orice concluzie: acoperirea indexării în Search Console, dacă URL-urile noi primesc crawl, dacă redirectările sunt corecte și consistente, dacă sitemap-ul reflectă structura nouă, dacă semnalele interne (linkuri, navigare, canonical) sunt coerente. Abia după ce aceste elemente sunt curate are sens să te întrebi dacă Google „se mișcă prea încet". Un audit automat care raportează o problemă nu dovedește că mutarea a eșuat.

Spam update: fereastra de comparație și capcana tool-urilor

Faptul că rularea s-a încheiat îți oferă o fereastră clară: 24 septembrie până 8 octombrie. Aceasta este perioada în care compari performanța din Search Console înainte, în timpul și după update, pe măsură ce datele se acumulează. Sursa notează, prin SEOmonitor, că schimbările reale de spam update tind să persiste pe zile consecutive și se văd de obicei în impresii și clicuri, nu doar în poziții.

Traducerea practică: înainte să declari că un client a fost lovit de update pe baza unei scăderi în rank tracker de la finalul lui septembrie, verifică Search Console. Dacă impresiile și clicurile sunt stabile, iar doar tool-ul arată o cădere, probabil te uiți la un artefact de colectare a datelor, nu la o penalizare. Aceasta este o distincție care poate salva relația cu clientul, pentru că eviți să vinzi o „criză" inexistentă sau, invers, să ignori o problemă reală.

Recomandarea mea de proces, pentru agenții și echipele interne: stabilește două surse de adevăr, Search Console pentru trafic și un tool de rank tracking pentru poziții, apoi documentează discrepanțele în loc să alegi una dintre ele pe criterii de confort. Dacă un tool și-a schimbat comportamentul, notează asta în raportul intern, ca să nu reinterpretezi date vechi cu reguli noi.

Search Console: raportare pe grupuri de piețe

Schimbarea din raportul de performanță, anunțată de Google Search Central pe LinkedIn pe 6 octombrie, permite selectarea mai multor țări sau dispozitive pentru a vedea datele combinate. Opțiunea de comparare rămâne limitată la două elemente puse alături, iar filtrarea pe mai multe tipuri de apariție în căutare nu este posibilă.

Pentru echipele care raportează pe grupuri de piețe, asta simplifică mult munca. Nu mai agregi manual, din două în două țări, cifre pe care apoi le lipești în spreadsheet. Scoți o singură valoare combinată pentru grup și o prezinți clientului. Atenție însă la un risc de interpretare: dacă un număr din raport reprezintă acum totalul mai multor piețe, nu îl mai compari direct cu o perioadă în care piata era raportată separat. Consistența metodologiei de raportare contează mai mult decât eleganța graficului.

Autori falși, crawlere AI și erori de sitemap

Ghidul Google despre conținut util, axat pe oameni, include acum un paragraf care avertizează împotriva profilurilor de creator fabricate. Sunt numite explicit pozele de profil generate de AI, numele inventate și credențialele false, atunci când sunt folosite ca să facă un conținut să pară scris de experți umani. Formularea din sursă este tranșantă: orice formă de înșelăciune este un semnal de pagină de calitate scăzută. Ghidul pentru evaluatorii calității din Search includea deja informațiile înșelătoare despre creatorii unui site ca tip de înșelăciune.

Consecința pentru site-urile din România este imediată: dacă ai pagini de autor cu poze de stock ambigue, nume fără persoană reală în spate sau credențiale pe care nu le poți susține, ai o vulnerabilitate editorială, nu doar una de imagine.

Pe partea tehnică, John Mueller a explicat, într-un episod din 1 octombrie al podcastului Google, că crawlerele de antrenare AI de obicei nu oferă un mod de a submite un sitemap. El sugerează un nume implicit, cum ar fi sitemap.xml, sau un feed RSS pentru site-urile care vor ca aceste crawlere să le găsească conținutul, și spune că a văzut astfel de crawlere accesând sitemap-ul și fișierele RSS în propriile log-uri de server. Pentru sitemap-urile valide care arată „Couldn't fetch", el a indicat două cauze: încărcarea pe host și cererea de crawl, aceasta din urmă bazată foarte des pe calitatea percepută a site-ului. Pagina de ajutor a raportului de sitemap-uri din Search Console listează și ea cererea redusă de crawl între motivele pentru care un sitemap nu poate fi preluat.

Citește asta cu atenție: ambele cauze sunt în afara fișierului. Deci dacă sitemap-ul tău e valid și tot apare eroarea, nu rescrie fișierul de zece ori. Verifică host-ul și întreabă-te ce semnale de calitate trimite site-ul. Verificarea unui audit tehnic incomplet nu dovedește că sitemap-ul e stricat.

Dacă lucrezi pe zona de vizibilitate în sistemele AI, merită să corelezi aceste observații cu ce spunem despre Google și GEO, cum ajungi să fii citat de LLM-uri și cu discuția despre context ca barieră reală în automatizările AI. Ambele au aceeași concluzie operațională: fără date curate și context clar, nici tool-ul, nici modelul nu livrează.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Dacă ai un magazin online sau un business de servicii care depinde de trafic organic, săptămâna aceasta îți dă trei sarcini concrete, nu trei motive de panică.

Prima: deschide Search Console și construiește comparația pe fereastra 24 septembrie până 8 octombrie, cu perioadele dinainte și de după. Separă impresiile, clicurile și CTR-ul pe grupurile de piețe relevante pentru tine. Dacă vinzi și în afara României, folosește noua filtrare pe mai multe țări ca să ai o singură cifră de grup.

A doua: verifică paginile de autor. Dacă ai un blog de ecommerce cu byline-uri, asigură-te că fiecare nume corespunde unei persoane reale, cu o poză reală și cu o descriere pe care o poți susține. Aici nu e vorba de estetică, e vorba de un semnal de calitate pe care ghidul Google îl tratează acum ca înșelăciune.

A treia: nu lua decizii de buget pe baza unui singur tool. Dacă un rank tracker arată o cădere bruscă, iar Search Console nu confirmă nimic, așteaptă datele. Dacă ai un site mutat recent, folosește intervalele orientative ca reper de discuție cu clientul, nu ca termen contractual. Și dacă lucrezi cu email marketing pe lângă SEO, merită să te uiți la practicile pentru abandoned cart email care reduc pierderile, pentru că acolo ai control direct asupra conversiei, spre deosebire de un update de algoritm.

FAQ

Spam update-ul din septembrie 2026 a fost mai lung decât celelalte din acest an? Da, potrivit sursei. Rularea a durat aproximativ 13 zile și 16 ore, de la 24 septembrie la 8 octombrie, în timp ce celelalte trei update-uri de spam din 2026 s-au încheiat în mai puțin de trei zile fiecare.

Cât durează mutarea unui site sau recuperarea după un core update? Rezumatul citat de sursă indică una până la trei luni pentru mutarea tipică a unui site și trei până la șase luni pentru recuperarea după un core update, cu cazuri lente care ajung la șase luni sau peste un an. Sursa notează că rezumatul nu precizează eșantionul sau perioada, deci intervalele sunt repere, nu termene.

Un status „Couldn't fetch" pe un sitemap valid înseamnă că fișierul e stricat? Nu neapărat. Mueller a indicat două cauze, încărcarea pe host și cererea de crawl bazată pe calitatea percepută a site-ului, ambele în afara fișierului. Verifică host-ul și semnalele de calitate înainte să modifici sitemap-ul.

Concluzia ALLSoft Agency

AI-ul ajută la analiză și planning: poate agrega mai repede ferestre de comparație din Search Console, poate semnala discrepanțe între tool-uri, poate schița un plan de verificare pentru un site mutat. Dar interpretarea rămâne umană. Un media buyer sau un SEO senior decide dacă o scădere în rank tracker e zgomot sau semnal, dacă o pagină de autor trebuie rescrisă, dacă un sitemap are nevoie de altceva decât de o reîncărcare. Niciun tool nu își asumă decizia și niciunul nu răspunde în fața clientului.

Pasul concret îl face ALLSoft Agency: verified, măsurat, raportat transparent. Dacă vrei o comparație pe fereastra de update și un plan de verificare tehnică pentru site-ul tău, începe de la ALLSoft Agency.