Indexarea mobile-first: Ce înseamnă pentru un website

Indexarea mobile-first: Ce înseamnă pentru un website, în forma finală pe care Google a anunțat-o în 2023: toate site-urile sunt accesate, indexate și clasate pe baza versiunii pentru telefon, cu Googlebot Smartphone, iar versiunea desktop este folosită doar în cazuri rare. Consecința: ce nu există pe versiunea mobilă nu există pentru Google; un site cu meniul, textul sau legăturile ascunse pe telefon este indexat fără ele.

Ghidul explică istoricul pe scurt, ce evaluează Google pe versiunea mobilă, ce trebuie să fie la fel pe mobil și desktop, cum verificați în Search Console, diferența între responsive, dinamic și m-dot, greșelile pe care le găsim la audituri și lista de verificare.

Indexarea mobile-first: Ce înseamnă pentru un website

Istoricul, pe scurt

2016: anunțul experimentului. 2018: trecerea primelor site-uri. 2020-2021: trecerea aproape a tuturor site-urilor, cu notificări în Search Console. Octombrie 2023: Google declară trecerea completă și încheie raportarea separată; din 2024, accesarea cu Googlebot Desktop este redusă la câteva site-uri care nu funcționează deloc pe mobil. În 2026, întrebarea „sunt pe indexarea mobile-first?” are un singur răspuns: da, ca toată lumea.

Ce evaluează Google pe versiunea mobilă

• Conținutul: textul, titlurile, imaginile, clipurile așa cum apar în HTML-ul servit telefonului (inclusiv cel randat din JavaScript).
• Meta-datele: titlul, descrierea, robots, canonical, hreflang, datele structurate.
• Legăturile interne: meniul și legăturile din conținut de pe mobil sunt cele urmărite.
• Experiența paginii: Core Web Vitals măsurate pe mobil, compatibilitatea cu telefonul, ferestrele intruzive; detaliile sunt în articolul despre semnalele de experiență a paginii.
• Resursele: CSS, JavaScript și imaginile trebuie să fie accesibile lui Googlebot Smartphone, altfel pagina este randată greșit.

Paritatea: ce trebuie să fie identic

1. Același conținut principal: textul complet, nu o versiune scurtată; conținutul din taburi și din secțiuni pliate este indexat, dar trebuie să existe în HTML, nu să se încarce la clic.
2. Aceleași titluri și descrieri, aceleași etichete robots și canonical.
3. Aceleași date structurate, cu aceleași valori.
4. Aceleași imagini, cu aceleași adrese și texte alternative; imaginile încărcate la nevoie trebuie să fie în HTML (srcset sau data-src recunoscut la randare).
5. Aceleași legături interne: meniul de pe mobil, chiar pliat, conține toate secțiunile; paginile legate doar din subsolul de desktop devin greu de găsit.
6. Același răspuns pentru roboți și pentru vizitatori: fără versiuni „ușoare” servite doar user agent-urilor de robot.

Site-urile responsive (același HTML, aspect adaptat prin CSS) au paritatea implicit; problemele apar la site-urile cu versiune mobilă separată sau cu conținut ascuns prin CSS pe ecrane mici, fără să fie eliminat din HTML (acest caz este în regulă pentru indexare) sau eliminat cu totul (nu este în regulă).

Cum verificați ce vede Google

• URL Inspection din Search Console: robotul folosit (Googlebot smartphone), HTML-ul randat, captura de ecran a paginii pe mobil, resursele blocate. Comparați HTML-ul randat cu ce vedeți dumneavoastră pe telefon.
• Raportul de statistici de accesare: proporția Smartphone față de Desktop la tipul de robot; Smartphone trebuie să domine.
• Raportul Core Web Vitals, fila Mobile: adresele slabe pe telefon.
• Lighthouse din Chrome, în modul mobil, pentru diagnostic de laborator; testul Mobile-Friendly a fost retras în 2023.
• Un crawler configurat cu user agent Googlebot Smartphone, pentru site întreg: titluri, descrieri, legături și conținut comparate cu varianta desktop.

Responsive, dinamic sau m-dot

Configurație	Cum funcționează	Recomandare
Responsive	același HTML și aceeași adresă, aspect prin CSS	recomandată de Google; fără riscuri de paritate
Servire dinamică	aceeași adresă, HTML diferit după user agent	acceptată; cere antetul Vary: User-Agent și paritate strictă
Adrese separate (m.exemplu.ro)	site mobil separat, cu rel=alternate și canonical între versiuni	de evitat; Google a anunțat că nu mai suportă bine această configurație și recomandă migrarea la responsive

Site-urile m-dot rămase în 2026 au de obicei probleme de indexare și trebuie migrate la responsive, cu redirecționări de la adresele m. spre cele principale, după regulile din ghidul despre migrarea unui website.

Greșelile pe care le găsim la audituri

• Text principal eliminat pe mobil „ca să fie mai curat”: paginile pierd pozițiile pe expresiile din textul lipsă.
• Meniul de pe mobil cu doar trei intrări, restul paginilor legate nicăieri de pe telefon.
• Imagini de fundal prin CSS în locul elementelor img: nu sunt indexate.
• Tabele care ies din ecran, butoane lipite, text de 12 pixeli: semnale de experiență slabe.
• Ferestre peste conținut la sosire, pe telefon: penalizate ca intruzive.
• Resurse blocate în robots.txt (dosare de teme, scripturi), din vremea când „Google nu are nevoie de CSS”.
• Versiune mobilă mai lentă din cauza scripturilor și a imaginilor la dimensiune de desktop; LCP peste 4 secunde.
• Date structurate doar pe desktop, adăugate de un modul care nu rulează pe șablonul mobil.

Lista de verificare

1. Site responsive, cu același HTML pentru toate ecranele.
2. Conținut, titluri, meta, canonical, hreflang, date structurate identice.
3. Meniu complet pe mobil, legături interne prezente în HTML.
4. Imagini în elemente img, cu srcset, alt și dimensiuni.
5. Resurse accesibile lui Googlebot; robots.txt fără blocări pe CSS și JavaScript.
6. Core Web Vitals pe mobil în zona bună; verificarea și remedierea sunt în articolul despre optimizarea Core Web Vitals.
7. Fără ferestre intruzive; fereastra de cookie mică, cu refuz egal.
8. Test lunar cu URL Inspection pe cinci pagini importante, comparând HTML-ul randat cu ce vede utilizatorul.

Conținutul pliat, taburile și derularea

Google a confirmat că, pe mobil, conținutul ascuns implicit (taburi, acordeoane, secțiuni „citiți mai mult”) este indexat cu greutate normală, fiindcă pe ecranele mici plierea este o practică de aspect, nu de ascundere. Condiția este ca textul să existe în HTML la încărcare; conținutul adus prin cerere suplimentară la clic nu este văzut. Derularea infinită (produse sau articole încărcate pe măsură ce derulați) cere paginare accesibilă și pentru roboți, cu adrese pentru fiecare pagină, altfel Google vede doar primul ecran. Verificarea: HTML-ul randat din URL Inspection conține tot textul? Dacă nu, problema e reală.

Viteza pe mobil, partea care se vede

Googlebot Smartphone măsoară cu bugetul unui telefon mediu; un site care „merge bine pe laptop” poate avea LCP de 5 secunde pe un telefon Android de 200 de euro pe 4G. Cauzele obișnuite: imagini la dimensiune de desktop servite telefonului (lipsa srcset), scripturi ale terților (chat, hărți, reclame) încărcate înainte de conținut, fonturi mari, cache lipsă. Datele reale din raportul Core Web Vitals, fila Mobile, sunt cele care contează, iar remediile, în ordinea efectului, sunt în articolul despre îmbunătățirea scorului PageSpeed Insights.

Întrebări frecvente

1. Pot avea conținut suplimentar pe desktop? Da, dar nu conta pe el pentru clasare; Google îl vede rar.
2. Am nevoie de AMP? Nu; Google a retras avantajele AMP în 2021, iar o pagină responsive rapidă face același lucru.
3. Site-ul meu nu are versiune mobilă deloc; este indexat? Da, cu Googlebot Smartphone, care vede pagina de desktop micșorată; este clasat cu semnale slabe de experiență și pierde față de concurenții responsive.
4. Cum știu dacă Google folosește versiunea mobilă pentru site-ul meu? Din 2023, o folosește pentru toate; raportul de statistici de accesare confirmă prin proporția Smartphone.

Un caz din practică

Un magazin cu temă „optimizată pentru mobil” de un furnizor extern: pe telefon, descrierile produselor erau eliminate din HTML (nu ascunse), iar filtrele și legăturile spre categoriile înrudite dispăreau. Search Console arăta scăderea afișărilor pe expresiile lungi din descrieri, exact după lansarea temei. Remediere: descrierile readuse în HTML, pliate implicit pe mobil (permis), meniul complet, legăturile spre categorii mutate într-un bloc vizibil. Afișările au revenit în șase săptămâni. Lecția: „optimizat pentru mobil” înseamnă adaptat, nu amputat.

Ce înseamnă pentru redactori și designeri

Cine scrie conținut verifică articolul pe telefon înainte de publicare: subtitlurile la distanță de derulare rezonabilă, listele scurte, tabelele care încap sau derulează în propriul container, imaginile cu legendă, primul paragraf cu răspunsul înainte de orice imagine mare. Cine proiectează tema începe de la ecranul mic (mobile-first în design, nu doar în indexare): meniul complet, butoanele de cel puțin 48 de pixeli, textul de minimum 16 pixeli, fără elemente care depind de trecerea cursorului. Un articol excelent într-o temă care îl taie pe mobil este, pentru Google, un articol tăiat.

Legătura cu restul

Indexarea mobile-first nu este un factor de clasare separat, ci regula jocului: tot ce faceți în SEO (conținut, structură, viteză, date structurate) este evaluat pe versiunea de telefon. De aceea auditul tehnic începe pe mobil, iar pașii generali sunt în ghidul despre optimizarea unui site pas cu pas; pentru WordPress, particularitățile temelor și ale modulelor sunt în ghidul despre SEO tehnic pentru WordPress. Erorile de indexare care apar din diferențele mobil-desktop sunt tratate în articolul despre erorile de indexare frecvente.

Surse

• Google Search Central, indexarea mobile-first: bunele practici, paritatea conținutului și configurațiile acceptate.
• Google Search Central, experiența paginii în rezultatele Google: semnalele evaluate pe mobil.