Un sitemap XML bun nu repară o arhitectură slabă, dar scoate la suprafață rapid problemele pe care altfel le vezi abia în raportul de indexare. În audituri găsim des fișiere generate automat care trimit Google către URL-uri cu parametri, variante necanonice, produse indisponibile sau pagini pe care clientul nici nu vrea să le vadă în Search. Fișierul există. Configurația este problema.
Google explică în documentația Search Central despre sitemaps că sitemapul ajută motoarele de căutare să descopere pagini, fișiere video, imagini și relațiile dintre ele, dar nu garantează că toate URL-urile listate vor fi crawl-uite sau indexate. Asta schimbă felul în care trebuie privit fișierul: nu este o comandă pentru Google, ci o listă de recomandări tehnice pe care trebuie să le poți susține cu site-ul real.
Ce pui în sitemap și ce lași afară
Regula practică este simplă: în sitemap intră doar URL-urile pe care le-ai vrea în rezultatele Google și care pot susține acea prezență. Dacă pagina este blocată, duplicată, subțire, necanonică sau temporară, nu are ce căuta acolo.
Aici se rupe multă muncă tehnică. CMS-ul generează automat fișierul, iar echipa îl trimite în Search Console fără să verifice ce conține. Într-un magazin online, asta poate însemna categorii filtrate, URL-uri cu sortare, pagini de tag fără valoare, produse retrase sau variante aproape identice ale aceleiași pagini. Într-un site de servicii, apar uneori pagini vechi de campanie, landing page-uri fără legături interne sau URL-uri rămase după redesign.
Un sitemap XML corect ar trebui să includă:
- pagini canonice, accesibile și indexabile;
- categorii, servicii, articole sau produse care au conținut util;
- URL-uri finale, nu redirecturi;
- pagini care răspund corect pe server;
- versiunea corectă de protocol și host – de exemplu HTTPS și forma aleasă cu sau fără www;
- pagini actualizate semnificativ, marcate corect prin <lastmod>, dacă folosești acest câmp.
Ce nu aș lăsa în sitemap: pagini cu noindex, URL-uri blocate în robots.txt, rezultate interne de căutare, pagini de cont, coș, checkout, filtre fără cerere organică, arhive fără rol editorial și pagini care redirecționează. Google poate descoperi oricum unele dintre ele, dar sitemapul nu trebuie să le legitimeze.
Fișierul trebuie să fie curat înainte să fie trimis
Google Search Central notează în ghidul pentru crearea și trimiterea sitemapurilor că un singur sitemap este limitat la 50 MB necomprimat sau 50.000 de URL-uri. Sursa aceleiași limite este Google Search Central, nu un tool SEO terț. Dacă site-ul depășește limita, fișierul se împarte în mai multe sitemapuri și se poate trimite un sitemap index.
Nu aștepta să ajungi la limita tehnică pentru a separa fișierele. Separarea pe tipuri de conținut ajută la diagnostic. Pentru un e-commerce, are sens să vezi separat produsele, categoriile, articolele de blog și paginile statice. Pentru un publisher, separarea pe articole, autori, categorii sau conținut evergreen poate face raportarea mai clară. Nu pentru că Google are nevoie de o structură frumoasă, ci pentru că tu ai nevoie să vezi unde apar erorile.
În XML, fiecare URL trebuie să fie absolut, nu relativ. Google spune explicit că va încerca să acceseze URL-urile exact cum sunt listate. Asta înseamnă că <loc>/servicii/seo</loc> este o variantă slabă. Corect este URL-ul complet, cu protocol și domeniu.
Câmpul <lastmod> merită folosit doar dacă este corect. Google Search Central spune că Google folosește valoarea <lastmod> dacă este consecventă și verificabilă, iar data ar trebui să reflecte o actualizare semnificativă a paginii, nu o schimbare minoră precum anul din footer. Aici apar multe implementări proaste: sistemul rescrie <lastmod> pentru toate URL-urile la fiecare publicare sau deploy, deși conținutul nu s-a schimbat. Semnalul devine zgomot.
Configurarea corectă în CMS
Dacă folosești WordPress, Shopify, Magento, PrestaShop, un framework custom sau un headless CMS, principiul rămâne același: sitemapul trebuie generat din sursa corectă de adevăr. Nu din toate URL-urile posibile, ci din URL-urile publicabile, canonice și indexabile.
Într-un CMS configurat bine, sitemapul se actualizează când:
- publici o pagină nouă care trebuie indexată;
- modifici semnificativ conținutul unei pagini existente;
- elimini o pagină din indexare;
- schimbi structura URL-urilor;
- muți conținutul prin redirecturi;
- activezi sau dezactivezi tipuri de conținut.
Într-un CMS configurat slab, sitemapul este tratat ca un export static. Se generează o dată, se uită pe server și nimeni nu îl mai compară cu realitatea site-ului. După un redesign, rămân în el URL-uri vechi. După o curățare de conținut, rămân pagini cu noindex. După o migrare la HTTPS, apar amestecate variante HTTP și HTTPS.
O verificare simplă înainte de trimitere: ia câteva URL-uri din fiecare tip de sitemap și verifică dacă pagina se încarcă, dacă este indexabilă, dacă are canonical către ea însăși și dacă este legată intern dintr-o zonă relevantă a site-ului. Dacă pagina există doar în sitemap și nicăieri în navigație sau conținut, nu ai rezolvat problema de crawl. Ai ascuns-o într-un fișier.
Cum trimiți sitemapul în Google Search Console
În raportul Sitemaps din Search Console Help, Google precizează că trimiterea unui sitemap înseamnă să îi spui unde se află fișierul pe site, nu să îl încarci efectiv în Google. Fișierul trebuie să fie public, accesibil pentru Googlebot și neblocat de autentificare.
Procesul este scurt, dar ordinea contează:
- Publici sitemapul pe domeniul corect, ideal la rădăcina site-ului sau într-o locație stabilă.
- Verifici manual că URL-ul sitemapului se deschide în browser.
- Testezi câteva URL-uri listate în fișier, nu doar fișierul în sine.
- Adaugi locația sitemapului în Search Console, în proprietatea corectă.
- Adaugi linia de sitemap în robots.txt, dacă vrei ca fișierul să fie descoperit și pe această cale.
- Revii în raport după procesare și verifici erorile, nu doar statusul general.
Obiecția pe care o auzim des este: „Dacă l-am pus în robots.txt, mai trebuie să îl trimit în Search Console?” Pentru site-uri mici și stabile, Google îl poate descoperi. Dar dacă vrei raportare, erori și istoric în Search Console, trimiterea manuală este mai utilă. robots.txt ajută la descoperire. Search Console ajută la monitorizare.
Unde apar erorile care par misterioase
Când Search Console spune că sitemapul nu poate fi citit, cauza nu este întotdeauna XML-ul. De multe ori, problema stă în server, în redirecturi, în proprietatea greșită din Search Console sau în diferența dintre varianta cu www și cea fără www.
Am văzut sitemapuri care se deschid perfect pentru un utilizator, dar răspund diferit pentru crawler. Am văzut fișiere servite cu redirect în lanț. Am văzut sitemap index trimis pe proprietatea HTTPS fără www, în timp ce URL-urile din fișier erau pe alt host. În raport pare o eroare generică. În spate este o nepotrivire de configurare.
Verificările care scurtează investigația:
- sitemapul răspunde fără autentificare;
- fișierul nu este blocat prin robots.txt;
- nu există redirecturi inutile între URL-ul trimis și fișierul final;
- URL-urile listate folosesc aceeași variantă de domeniu ca proprietatea verificată;
- fișierul este valid XML și are encoding corect;
- nu conține caractere neescapate în URL-uri;
- nu listează URL-uri care întorc erori sau redirecturi.
Nu te opri la mesajul „Success”. Un sitemap procesat cu succes poate conține URL-uri slabe. Statusul îți spune că Google a citit fișierul, nu că strategia de indexare este bună.
Ce faci după trimitere
După ce sitemapul este acceptat, următoarea întrebare nu este „câte URL-uri am trimis?”, ci „ce se întâmplă cu URL-urile trimise?”. Compară sitemapul cu raportul de indexare. Dacă multe pagini din sitemap nu sunt indexate, nu rescrie fișierul la întâmplare. Uită-te la motive.
Unele pagini nu intră în index pentru că sunt duplicate. Altele nu au conținut suficient. Altele sunt descoperite, dar nu primesc semnale interne. Într-un site cu blog, articolele pot fi listate în sitemap, dar fără legături din categorii, pagini de servicii sau articole conexe. Într-un e-commerce, produsele pot fi în fișier, dar categoria care le susține nu are text, filtrele se bat cap în cap, iar canonicalul indică altă variantă.
Asta este diferența dintre un sitemap tehnic corect și o configurație SEO utilă. Primul poate trece validarea. Al doilea ajută crawl-ul să susțină paginile care contează.
Întrebări frecvente
Trebuie să includ toate paginile site-ului în sitemap?
Nu. Include paginile pe care le vrei în rezultatele Google și care sunt canonice, accesibile și indexabile. Pagini de cont, coș, filtre fără valoare organică, rezultate interne de căutare sau URL-uri duplicate ar trebui excluse.
Este o problemă dacă sitemapul nu are <lastmod>?
Nu este automat o problemă. Mai rău este să ai <lastmod> incorect. Dacă CMS-ul poate marca doar actualizări reale de conținut, folosește câmpul. Dacă îl modifică artificial pentru toate paginile, mai bine corectezi implementarea înainte să te bazezi pe el.
Un sitemap XML poate forța indexarea?
Nu. Sitemapul ajută Google să descopere URL-uri și să înțeleagă ce pagini consideri importante, dar indexarea depinde de accesibilitate, calitatea paginii, canonicalizare, conținut, semnale interne și alte criterii de evaluare.
Un sitemap XML bine configurat este o listă scurtă de pagini în care ai încredere, nu un sertar în care pui tot ce a generat CMS-ul. Dacă nu ai curaj să arăți manual fiecare tip de URL din fișier, nu ești gata să îl trimiți către Google.
