Google a lansat pe 14 octombrie 2026 prima ediție din „The Non-Canonical Cabinet”, o serie video găzduită de Gary Illyes și Cherry Prommawin pe canalul Search Central. Subiectul primei ediții: ce poate și ce nu poate sta într-un nume de domeniu sau într-un path de URL, inclusiv emoji, plus dacă cuvintele-cheie din URL influențează clasarea. Seria e anunțată de un teaser din 6 octombrie și e descrisă ca un format de sitcom despre întrebări care nu au loc într-un FAQ standard, dar rămân utile pentru Search și funcțiile generative de AI. Următorul episod tratează robots.txt, fără un calendar de lansare anunțat public.

Ce a lansat Google de fapt

Nu e o schimbare de algoritm, nu e o funcție nouă în Search Console, nu e un update de documentație. E un canal de comunicare. Diferența e importantă, pentru că în piață orice anunț Google tinde să fie citit ca semnal de ranking. Aici nu e cazul.

The Non-Canonical Cabinet pornește de la întrebări venite din partea proprietarilor de site-uri și a industriei SEO, nu de la un curriculum. Primul episod documentează poziția oficială a Google pe trei zone care apar constant în audituri: caractere speciale în domeniu, caractere non-ASCII în path și separatori de cuvinte în URL. Google cere explicit ca întrebările de caz limită să fie trimise în comentariile videoclipurilor, ceea ce transformă seria într-un canal semi-oficial de clarificare. Pentru echipele care lucrează cu clienți, asta contează: ai unde să îndrepți o întrebare care nu intră în documentația standard.

Un detaliu de context, util dacă te raportezi la istoricul Search Central: Illyes a găzduit în 2024 seria „How Search Works”, în cinci părți, care explica crawl, indexare și servire. The Non-Canonical Cabinet inversează ordinea: nu pornește de la bază, ci de la întrebări punctuale venite din piață.

Domenii vs. path-uri: două seturi de reguli

Aici e miezul tehnic al episodului și, probabil, motivul pentru care multe echipe au nevoie de clarificare. Domeniul și path-ul nu respectă aceleași reguli.

Pentru domenii, standardele sunt stabilite de ICANN și de IETF. Conform liniilor directoare IETF (RFC 1035, RFC 1123), numele de domeniu acceptă litere, cifre și cratime, iar Google aplică aceleași standarde. Domeniile internaționalizate (IDN) permit scripturi native pentru limbi non-latine, de exemplu chineză sau arabă, dar acestea sunt traduse în Punycode, un șir care începe cu „xn--”. Browserele afișează de regulă IDN-ul în scriptul original, ceea ce poate crea confuzie, pentru că anumite caractere din scripturi diferite arată aproape identic. Un exemplu dat în episod: o literă chirilică foarte apropiată vizual de „p” latin.

Emoji în domeniu: nu. Standardele tehnice actuale pentru IDN nu le permit, iar o rezoluție a Consiliului ICANN din 2017 menționează explicit această interdicție. Există o nuanță: rezoluția notează că, deși standardele actuale le blochează, emoji pot fi totuși înregistrate la nivelul doi în anumite ccTLD-uri.

Path-ul e mult mai permisiv. Googlebot crawl-ează un path care conține emoji, iar sistemul îl procesează. Browserele codifică procentual caracterele, deci emoji-ul cu pui devine %F0%9F%90%94 în path. Problema nu e la Google, e la afișare: nu toate browserele și aplicațiile de social media redau emoji-ul corect, unele afișând un șir de caractere ilizibile. Documentația Google privind structura URL-urilor acoperă deja partea de path, recomandă codificarea procentuală pentru caracterele non-ASCII și folosește emoji într-un exemplu.

Concluzia operațională: dacă site-ul tău respectă deja documentația de structură URL, nu ai nimic de modificat. Episodul confirmă public o practică pe care documentația o spunea deja.

Cuvintele-cheie din URL: un semnal minuscul

Illyes a numit cuvintele-cheie din URL „un semnal incredibil de mic”, relevant „doar când nu avem absolut nimic altceva pe care să ne bazăm”. Exemplul dat: un site vechi de câteva secunde, fără conținut. În momentul în care Google vede conținut, cuvintele-cheie din domeniu și din URL „devin practic irelevante”.

Nu e o poziție nouă. John Mueller a descris factorul ca „foarte mic” în 2016 și „foarte, foarte ușor” în 2021. Ce aduce nou episodul e contextul: o declarație pe înregistrare, utilă atunci când un client cere URL-uri cu densitate mare de cuvinte-cheie. Răspunsul nu mai e o opinie de agentie, e o poziție publică Google.

Pe separatori, poziția e la fel de clară. Cuvintele legate prin underscore într-un path sunt tratate de Google ca un singur cuvânt lung. Uneori e acceptabil, pentru că sistemul poate folosi totuși termenii, dar recomandarea Google e cratima ca separator standard pe web. Documentația invocă motive istorice, underscore-ul marchează frecvent concepte care trebuie ținute împreună, cum ar fi numele de funcții în programare.

Recapitularea finală a episodului transmite un mesaj direct: nu mai încercați să forțați rezultatele din Search umplând URL-urile cu cuvinte-cheie.

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

Dacă ai un magazin online pe un domeniu .ro sau .com, cu structură de URL setată acum doi-trei ani, probabil nu ai nimic de schimbat. Episodul confirmă practici deja documentate, iar echipele care au urmat ghidul Google privind structura URL-urilor nu sunt afectate. Tradu pe asta în decizii concrete:

Nu prioritiza migrarea URL-urilor pentru separatori. Dacă ai un catalog mare cu slug-uri construite pe underscore, rescrierea tuturor linkurilor produce cost de implementare, redirectări, risc de erori, iar câștigul estimat din acest semnal e aproape zero. Prioritatea reală e conținutul, structura internă de linkuri, viteza și datele structurate.

Folosește episodul ca argument, nu ca proiect. Când un client insistă pe URL-uri încărcate cu cuvinte-cheie, ai acum o poziție publică Google pe care o poți cita. Discuția se mută de la „agentia zice” la „Google a declarat”.

Verifică problema emoji-urilor înainte să le folosești în campaign-uri. Dacă ai URL-uri cu emoji, promovate prin reclame, email sau social media, testul relevant nu e în Google, ci în afișare. Deschide linkul în trei-patru browsere diferite și în aplicațiile de social media pe care le folosești. Dacă ceva se sparge vizual, ai un cost de experiență pentru utilizator, nu o problemă de indexare. Asta e o recomandare de verificare, nu o constatare din episod.

Nu extrapola la IDN. Dacă ai un domeniu cu caractere naționale, episodul explică mecanismul Punycode și riscul de confuzie vizuală între scripturi. Nu e o problemă de ranking, e o problemă de brand și de phishing. Dacă lucrezi cu un client care are sau vrea un astfel de domeniu, testează cum se afișează în contexte reale înainte de a promite ceva.

Fii atent la diferența dintre hreflang și caractere. Multe echipe amestecă discuția despre caracterele non-latine cu implementarea hreflang pentru piețele regionale. Sunt lucruri separate. Un audit corect tratează structura URL, migrarea și hreflang ca proiecte distincte, cu propriile riscuri.

Pe partea de măsurare, niciunul dintre semnalele discutate aici nu se vede curat în dashboard. Dacă vrei să urmărești impactul unei decizii de structură URL, ai nevoie de segmente de trafic și de perioade de comparație curate, nu de rapoarte agregate. Merită citit și materialul nostru despre de ce dashboardul de TikTok ratează majoritatea cumpărărilor, pentru că aceeași logică se aplică și în Search: ce vezi în interfață și ce se întâmplă în realitate nu sunt identice.

Ce urmează și ce rămâne de verificat

Următorul episod tratează robots.txt. Nici descrierea videoclipurilor, nici teaser-ul nu includ un calendar de lansare, iar primele două materiale au apărut la opt zile distanță. Nu există confirmare publică pentru o periodicitate fixă, deci orice plan editorial bazat pe „un episod pe săptămână” e o presupunere, nu un fapt.

Ce merită urmărit, în ordinea relevanței operaționale:

Ce rămâne necunoscut: nu există informații publice despre cât de departe merge seria, câte episoade sunt planificate sau dacă va acoperi subiecte unde Google nu are încă o poziție publicată. Nu presupune că un subiect din roadmap-ul tău intern va fi acoperit.

FAQ

Emoji în URL afectează indexarea? Conform episodului, Googlebot crawl-ează și procesează path-uri cu emoji, iar browserele le codifică procentual. Riscul nu e în indexare, ci în afișarea inconsistentă între browsere și aplicații de social media. Verifică comportamentul în contexte reale înainte de a construi campanii pe astfel de linkuri.

Mai contează cuvintele-cheie din URL pentru ranking? Google le descrie ca semnal extrem de mic, relevant doar când nu există altceva pe care să se bazeze sistemul. Odată ce există conținut, efectul devine practic irelevant. Nu justifică rescrierea unui catalog de URL-uri existent.

Pot folosi emoji în numele de domeniu? Standardele tehnice actuale pentru IDN nu le permit, iar o rezoluție ICANN din 2017 menționează explicit interdicția. Există o excepție documentată la nivelul doi în anumite ccTLD-uri, dar nu e o practică pe care să construiești o strategie de brand.

Concluzia ALLSoft Agency

AI-ul e util aici pentru un lucru concret: să adune rapid pozițiile publice Google, să le compare cu documentația existentă și să marcheze unde un audit intern are nevoie de verificare. Poate tria sute de pagini de documentație și poate genera un checklist de întrebări relevante pentru contul tău. Ce nu poate face: să decidă dacă merită să rescrii URL-urile unui catalog de 40.000 de produse, să estimeze impactul real în contul tău sau să își asume riscul de implementare.

Decizia și execuția rămân umane. Un media buyer sau un SEO senior citește contextul de business, verifică probele, separă constatarea măsurată de ipoteză și decide ce intră în sprint. Iar pasul concret îl face ALLSoft Agency, acolo unde analiza devine implementare măsurată, nu slide-uri. Dacă vrei să traduci semnale ca acesta în decizii pentru contul tău, începe cu o verificare reală a structurii URL-urilor și a impactului în trafic, nu cu o rescriere în bloc.