Google.com/goto schimbă traseul clickului: ce se poate rupe în rank tracking și monitorizarea SERP
Google confirmă extinderea redirectului /goto în rezultate. Vedem ce înseamnă pentru parsere, rank trackere, alerte false și măsurarea SEO.
Google confirmă extinderea linkurilor intermediare google.com/goto în rezultatele Search. Pentru utilizator, clickul poate ajunge la aceeași pagină ca înainte. Pentru un instrument SEO care presupune că atributul href conține direct URL-ul rezultatului, schimbarea poate produce domenii Google în locul destinațiilor, rezultate lipsă și alerte false de ranking.
Este genul de modificare care nu schimbă neapărat SERP-ul văzut de om, dar poate strica aparatul care îl măsoară. Dacă raportul spune brusc că zece competitori au dispărut, tentația este să căutăm un update de algoritm. Problema poate fi mult mai banală: parserul a citit intermediarul, nu destinația.
Google a confirmat la 26 august pentru Search Engine Roundtable că rollout-ul este real. Declarația companiei vorbește despre o istorie lungă de măsuri tehnice împotriva formelor de abuz și despre protejarea serviciilor și utilizatorilor. Google nu a publicat însă specificația redirectului și nu a spus că fiecare /goto există exclusiv pentru a bloca rank trackere. Asocierea exactă cu scrapingul aparține observatorilor și furnizorilor de tracking.
Ce s-a schimbat în traseul unui click
În forma familiară, un rezultat organic conține o legătură către pagina destinație. Un parser poate citi domeniul, calea și parametrii direct din HTML. În forma raportată acum, legătura poate indica un URL Google care funcționează ca passthrough. Serverul Google primește cererea și redirecționează utilizatorul către destinația finală.
Reprezentarea simplificată arată astfel:
- rezultatul vizual arată
exemplu.ro/pagina; - legătura tehnică indică
google.com/goto?...; - utilizatorul apasă;
- Google validează cererea și răspunde cu un redirect;
- browserul ajunge la
exemplu.ro/pagina.
Pentru om, hopul poate fi aproape invizibil. Pentru software, diferența este structurală. Un extractor care considera href drept adevărul final vede acum Google ca domeniu. Un al doilea extractor poate încerca să decodeze tokenul, deși acesta nu este documentat. Un al treilea urmează redirectul, dar se lovește de limitări, consimțământ, localizare sau protecții anti-abuz.
Patru erori care pot arăta ca pierderi SEO
1. Domeniul rezultatului devine google.com
Dacă parserul salvează hostname-ul din link, toate rezultatele împachetate pot părea că aparțin Google. Clasificarea organică se golește, competitorii dispar, iar share of voice cade artificial.
2. Rezultatul este eliminat ca duplicat
Unele sisteme deduplică după URL. Mai multe rezultate cu linkuri /goto pot fi considerate aceeași destinație sau aceeași familie, chiar dacă duc spre domenii diferite. Pozițiile următoare se deplasează și raportul nu mai corespunde paginii văzute.
3. Rezolvarea redirectului eșuează
Dacă sistemul încearcă să urmeze fiecare hop fără contextul corect, răspunsul poate fi refuzat sau schimbat. Rezultatul este marcat „missing”, deși utilizatorii îl văd și îl pot deschide.
4. URL-ul final nu este normalizat
Chiar după rezolvare pot apărea parametri, variante de protocol, slash final sau redirecturi proprii ale site-ului. Fără normalizare, aceeași pagină este înregistrată ca URL nou, iar istoricul se rupe.
| Simptom în raport | Cauză posibilă | Verificare înaintea concluziei SEO |
|---|---|---|
| Multe rezultate lipsesc simultan | Parserul nu recunoaște /goto |
Compară captura/HTML-ul cu destinațiile rezolvate |
| google.com apare ca domeniu organic | Se salvează hostname-ul intermediar | Separă URL-ul observat de URL-ul final |
| Pozițiile sar fără schimbare vizuală | Deduplicare greșită | Reconstruiește ordinea după blocurile de rezultat |
| Pagini „noi” pentru același client | Normalizare inconsistentă | Aplică redirectul site-ului și canonicalul separat |
| Scădere numai la un furnizor | Problemă de colectare | Compară cu GSC și o verificare manuală |
Niciunul dintre aceste simptome nu demonstrează singur că instrumentul este greșit. Demonstrează doar că, într-o zi cu schimbare de markup, diagnosticul trebuie să înceapă cu colectarea.
Ce a confirmat Google și ce rămâne interpretare
Este important să nu amplificăm știrea. Confirmarea publicată spune două lucruri: /goto este în rollout, iar Google folosește măsuri tehnice împotriva abuzului. Nu oferă o listă cu actorii vizați, nu descrie tokenul și nu declară că rank trackingul legitim este interzis prin această implementare.
Derek Perkins de la Nozzle a raportat aproape 100% rollout pe câțiva furnizori de IP rezidențial și a descris linkurile ca măsură anti-bot. Această observație este utilă pentru amplitudine, dar nu este un procent global. Nu putem spune „100% din Google folosește /goto” pe baza unui subset de infrastructură.
În iulie, când testul fusese observat dar Google nu răspunsese, atribuirea anti-scraping era și mai clar o interpretare. Articolul trebuie să păstreze cronologia: test raportat, extindere observată, confirmare a rollout-ului, explicație oficială generală despre abuz. Orice detaliu suplimentar trebuie etichetat ca observație tehnică.
De ce rankingul și indexarea nu ar trebui amestecate cu redirectul
google.com/goto apare în traseul dintre interfața Google și pagina externă. Nu este redirectul URL-ului indexat de site și nu schimbă automat canonicalul documentului. Google poate continua să înțeleagă și să afișeze aceeași destinație, chiar dacă clickul trece printr-un hop propriu.
Nu avem o bază factuală pentru afirmații precum:
- site-urile pierd autoritate deoarece linkul trece prin Google;
- canonicalul paginii devine
google.com/goto; - redirectul schimbă poziția organică;
- Search Console va raporta Google ca landing page;
- toate clickurile vor fi clasificate greșit în analytics.
Raportul Generative AI din Search Console precizează chiar că dimensiunea Pages grupează datele după URL-ul final legat de funcția AI, după redirecturi, iar cea mai mare parte a datelor este atribuită canonicalului. Aceasta nu este documentație specifică pentru /goto, dar arată că Google separă URL-ul intermediar de pagina căreia îi atribuie performanța.
Analytics și referrer: ce trebuie testat, nu presupus
Un redirect intermediar poate ridica întrebări despre referrer, parametri și atribuirea sesiunii. Răspunsul corect nu se obține dintr-o diagramă teoretică, ci din teste controlate pe trafic real.
Pentru fiecare browser și tip de rezultat urmărit, aș verifica:
- URL-ul final încărcat în bara browserului;
- lanțul de răspunsuri HTTP observabil în instrumentele browserului;
- referrerul primit de serverul destinație, acolo unde politica browserului îl transmite;
- sursa și mediul în analytics;
- păstrarea parametrilor proprii ai URL-ului final;
- diferențele între mobil, desktop, autentificat și neautentificat;
- eventualele variații după țară sau interfață.
Nu recomand modificarea trackingului site-ului pe baza unei singure capturi. Dacă Google organic rămâne atribuit corect și landing page-ul este cel real, nu există nimic de „reparat” în website.
O arhitectură robustă pentru monitorizare
Un sistem matur nu salvează o singură valoare numită URL. Păstrează separat ceea ce a văzut, ceea ce a rezolvat și ceea ce a normalizat.
| Câmp | Exemplu de rol | De ce se păstrează |
|---|---|---|
observed_href |
Linkul exact din rezultat | Audit și reproducerea colectării |
displayed_url |
URL-ul afișat utilizatorului | Comparație cu interfața vizuală |
resolved_url |
Destinația după redirect permis | Identificarea domeniului și paginii |
normalized_url |
Varianta stabilă pentru comparații | Istoric și deduplicare |
resolution_status |
direct, redirected, blocked, unknown | Separă lipsa datelor de lipsa rezultatului |
serp_position |
Ordinea blocului observat | Nu depinde de succesul rezolvării |
Principiul important este că eșecul de rezolvare nu trebuie transformat automat în „rezultatul nu există”. Poziția și identitatea pot avea niveluri diferite de încredere. O alertă bună spune „destinația nu a putut fi validată în 38% din colectări”, nu „clientul a pierdut 38% din rankinguri”.
Al doilea principiu este readback-ul. După schimbarea parserului, luăm un set fix de SERP-uri, păstrăm HTML-ul și rezultatele așteptate, rulăm noua logică și comparăm ordinea, domeniile și URL-urile. Numai după ce fixture-urile trec extindem monitorizarea.
Aceeași disciplină apare în auditul legăturilor JavaScript și al HTML-ului disponibil crawlerelor AI: mai întâi observăm documentul real, apoi separăm descoperirea, randarea și destinația. Dacă sistemul de monitorizare are nevoie de modificări, dezvoltarea software și integrarea trebuie făcute pe fluxul existent, cu teste de regresie.
Ce nu ar trebui să facă un furnizor SEO
Compatibilitatea nu este o licență pentru ocolirea protecțiilor Google. Un articol responsabil nu publică metode de decodare a tokenurilor, automatizări agresive sau tactici de evitare a limitelor. Google își poate schimba mecanismul tocmai pentru că încearcă să controleze abuzul.
Un furnizor are opțiuni mai sănătoase:
- folosește API-uri și furnizori care declară modul de colectare și limitele;
- tratează verificarea manuală ca eșantion, nu ca infrastructură clandestină;
- combină rank trackingul cu Search Console și datele de conversie;
- afișează starea colectării lângă starea rankingului;
- păstrează perioadele de schimbare tehnică drept ferestre de incertitudine;
- nu promite precizie pe care sursa datelor nu o poate susține.
Pentru AYSA, primul pas corect este un audit de compatibilitate al monitorizării existente: depinde sau nu de URL-ul direct din <a href>? Dacă da, trebuie adăugate fixture-uri pentru /goto, stări de rezolvare și protecție împotriva alertelor false. Descriu aceasta ca direcție tehnică de verificat, nu ca funcție deja disponibilă.
Cum separăm o schimbare reală de ranking de o eroare de colectare
Un diagnostic bun caută surse independente care ar trebui să se miște diferit. Dacă pagina pierde impresii și clickuri în Search Console, poziția verificată manual se schimbă, competitorii ocupă alte locuri și landing page-ul pierde sesiuni, ipoteza unei schimbări reale devine plauzibilă. Dacă numai furnizorul de rank tracking raportează dispariția, iar rata erorilor de colectare crește în aceeași oră, prima ipoteză trebuie să fie tehnică.
| Dovadă | Schimbare reală mai probabilă | Problemă de colectare mai probabilă |
|---|---|---|
| Search Console | Impresiile și clickurile se modifică în aceeași direcție | Rămân stabile în limita întârzierii normale |
| Verificare vizuală | Rezultatul nu mai este în poziția raportată anterior | Rezultatul este vizibil, dar parserul îl omite |
| Mai mulți furnizori | Semnal apropiat, cu diferențe normale | Un singur furnizor cade abrupt |
| Loguri colector | Rata de succes rămâne normală | Apar redirecturi necunoscute și time-out-uri |
| Distribuție | Schimbarea afectează anumite query-uri sau pagini | Multe domenii dispar simultan, fără logică semantică |
Există și o zonă gri: Google poate modifica simultan interfața și rankingurile. De aceea, nu căutăm o singură probă care să „închidă” cazul. Marcăm nivelul de încredere, păstrăm datele brute și reanalizăm după ce instrumentul este compatibil.
Aș introduce în orice dashboard un indicator de sănătate a colectării lângă graficul de poziții. Utilizatorul trebuie să vadă numărul de SERP-uri preluate, procentul de rezultate cu destinație validată, rata de redirect necunoscut și eventualele schimbări de markup. Altfel, o linie precisă grafic poate ascunde o sursă imprecisă.
Este și o problemă de responsabilitate comercială. O agenție nu ar trebui să ceară rescrierea paginilor sau să explice o scădere prin „update Google” înainte să verifice instrumentul. Clientul plătește pentru interpretare, nu pentru retransmiterea automată a unei alerte.
Checklist pentru următoarele 48 de ore
- Verifică un eșantion de rezultate în mai multe browsere și locații.
- Salvează separat linkul observat și URL-ul afișat.
- Caută apariții
google.com/gotoîn logurile de colectare. - Măsoară procentul de rezultate afectate pe fiecare sursă, nu global.
- Compară domeniile extrase cu o verificare vizuală.
- Blochează alertele de ranking dacă rata erorilor de parsare depășește pragul normal.
- Testează normalizarea pe URL-uri cu parametri și redirecturi proprii.
- Verifică separat Search Console: impresii, clickuri și pagini.
- Documentează schimbarea și data, astfel încât istoricul să poată fi reinterpretat.
- Nu modifica site-ul clientului pentru o problemă aflată în colector.
Întrebări care apar deja
Google a confirmat redirectul /goto?
Da. Un purtător de cuvânt a confirmat rollout-ul și a invocat măsuri tehnice împotriva formelor de abuz. Google nu a publicat însă o specificație tehnică completă.
Este făcut special pentru a bloca rank trackerele?
Nu putem formula atât de precis. Furnizorii îl interpretează ca măsură anti-bot și anti-scraping, dar declarația Google vorbește mai larg despre abuz și protejarea serviciilor.
Îmi scade poziția dacă rezultatul trece prin /goto?
Nu există dovezi că hopul de click modifică rankingul. El poate modifica felul în care un instrument extrage destinația.
Trebuie să schimb canonicalul?
Nu. Canonicalul aparține paginii tale și nu trebuie modificat pentru un redirect folosit în interfața Google.
Search Console va raporta google.com?
Documentația rapoartelor atribuie datele paginii finale și canonicalului. Verifică proprietatea ta, dar nu există motiv să tratăm intermediarul drept landing page indexat.
Cum îmi dau seama că raportul are o problemă?
Caută schimbări simultane pe multe domenii, apariția google.com ca rezultat, creșterea stărilor „missing” și diferențe față de verificarea vizuală sau Search Console.
Pot rezolva automat toate redirecturile?
Tehnic, anumite redirecturi pot fi urmate, dar colectarea trebuie să respecte limitele și măsurile Google. Sistemul trebuie să accepte și starea „necunoscut”, fără să inventeze o pierdere de ranking.
Înainte să repari SEO, verifică instrumentul care ți-a spus că este stricat
google.com/goto este un exemplu bun de risc invizibil. Site-ul poate fi indexat, rezultatul poate fi prezent și utilizatorul poate ajunge corect la destinație, în timp ce dashboardul raportează dispariții.
În astfel de momente, disciplina valorează mai mult decât viteza. Separăm schimbarea de interfață de schimbarea de ranking, păstrăm dovada brută și nu cerem echipei să rescrie pagini fiindcă un parser nu mai recunoaște legătura.
Dacă vrei să verificăm împreună monitorizarea SEO, trackingul și interpretarea alertelor, vezi serviciile SEO AYSA sau trimite-mi configurația pe care vrei să o audităm.