Validtor Hartă Site Gratuit

Ce este un sitemap.xml și de ce contează?

Un sitemap este un document XML structurat care listează URL-urile unui site web pe care vrei ca motoarele de căutare să le cunoască. Este servit dintr-o cale stabilă, aproape întotdeauna /sitemap.xml, și urmează Protocolul Sitemap — o specificație mică publicată inițial de Google în 2005 și adoptată ca standard comun de Google, Yahoo și Microsoft un an mai târziu. Formatul este simplu: un element rădăcină <urlset> care conține câte un element <url> per pagină, cu metadate opționale despre când a fost modificat ultima dată fiecare URL, cât de des se schimbă și cum se raportează ca prioritate față de celelalte pagini ale aceluiași site.

Scopul unui sitemap este descoperirea, nu clasarea. Motoarele de căutare crawlează web-ul urmărind link-uri de la o pagină la alta. Pe un site mic cu link-uri interne curate, fiecare pagină este accesibilă de pe pagina de start în câteva click-uri, iar crawlerele găsesc totul fără ajutor. Pe un site mare, pe un site cu paginare adâncă, pe un site cu pagini de destinație izolate spre care nu pointează niciun link intern sau pe un site care tocmai a publicat conținut nou, crawlerele pot lua zile sau săptămâni să descopere URL-uri doar prin link-uri. Sitemap-ul rezolvă asta oferind crawlerului o listă completă de la bun început.

Sitemaps-urile nu garantează indexarea. Google a afirmat explicit acest lucru în documentația sa încă de la lansarea protocolului: un URL din sitemap-ul tău este un semnal că vrei să fie indexat, nu o comandă că va fi. Paginile cu calitate scăzută, conținut duplicat sau informații superficiale vor fi ignorate indiferent de includerea în sitemap. Ceea ce schimbă sitemap-ul este eficiența crawlării. Cu un sitemap, Google poate crawla mai întâi paginile noi și actualizate, le poate prioritiza pe baza câmpului lastmod și poate evita să irosească cereri pe URL-uri vechi sau arhivate.

Sitemaps-urile contează și pentru coada lungă. Un site cu 100.000 de pagini de produse, 5.000 de postări de blog și 200 de pagini de categorii are prea mult pentru ca orice model de link-uri interne să expună fiecare URL în câteva click-uri. Fără un sitemap, site-ul se bazează pe crawlarea exploratorie a Googlebot pentru a găsi URL-urile adânci, ceea ce funcționează, dar este lent. Cu un sitemap, fiecare URL este cunoscut de Google imediat, iar crawler-ul poate cheltui bugetul pe verificări de prospețime și calitatea conținutului, nu pe descoperire. Pentru e-commerce, publicații de știri, piețe online și site-uri cu conținut bogat, sitemap-ul nu este opțional.

Cum se folosește acest verificator

Verificatorul primește un URL de sitemap sau rădăcina unui domeniu și returnează un raport structurat despre validitate, completitudine și accesibilitate.

Pasul 1 — Introdu URL-ul sitemap-ului. Lipește URL-ul complet al sitemap-ului tău sau doar domeniul — verificatorul va face autodiscovery prin robots.txt și va încerca căi comune precum /sitemap.xml, /sitemap_index.xml și /sitemap.xml.gz. Urmărește automat și fișierele sitemap-index și parcurge fiecare sitemap copil din interior.

Pasul 2 — Revizuiește raportul de validitate. Verificatorul validează XML-ul față de schema Protocolului Sitemap, semnalează valorile lastmod malformate, verifică URL-urile care depășesc limita de 2048 de caractere pentru cale și verifică dacă fișierul se încadrează în limitele stricte de 50 MB necomprimat și 50.000 de URL-uri. Fiecare problemă este afișată cu URL-ul exact sau numărul de linie care a declanșat-o.

Pasul 3 — Verifică accesibilitatea. Pentru un eșantion de URL-uri din sitemap, verificatorul efectuează o cerere HEAD și raportează codul de răspuns. URL-urile care returnează 404, 301, 302 sau 5xx în sitemap-ul tău sunt zgomot care irosește bugetul de crawlare; raportul le afișează grupate pentru a putea fi corectate sau eliminate.

Protocolul sitemap în profunzime

Un sitemap valid minimal arată astfel:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Doar <loc> este obligatoriu. Celelalte trei câmpuri opționale sunt <lastmod>, <changefreq> și <priority>, iar buna practică modernă tratează fiecare diferit.

Limite stricte și modelul sitemap-index

Un singur fișier sitemap poate conține cel mult 50.000 de URL-uri și trebuie să fie sub 50 MB necomprimat. Aceste limite există în protocol de la lansare și sunt respectate de fiecare crawler major. Fișierele care depășesc limita nu sunt pur și simplu trunchiate — sunt respinse în totalitate de Googlebot, care raportează ulterior o eroare în Search Console. Pentru un site cu mai multe URL-uri decât încap într-un singur fișier, protocolul definește un format sitemap-index care listează mai multe sitemaps copil:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

Indexul poate lista până la 50.000 de sitemaps copil, fiecare conținând 50.000 de URL-uri, pentru o limită teoretică de 2,5 miliarde de URL-uri pe site. În practică, organizarea pe tipuri de conținut — pagini, produse, postări de blog, etichete, categorii — produce o structură mentenabilă care permite și regenerarea doar a sub-sitemap-ului modificat la fiecare deploy. Convenția este de a numi indexul sitemap.xml sau sitemap_index.xml, iar copiii cu căi descriptive.

Precizia lastmod și când are încredere Google în el

Google a afirmat în mod repetat că folosește lastmod atunci când valoarea este exactă și îl ignoră pentru întregul sitemap când pare nesigur. Un site care raportează mereu data de azi pentru fiecare URL raportează o prospețime care nu există; Google detectează modelul și nu mai ia în considerare câmpul. Același lucru se aplică valorilor lastmod care nu se actualizează niciodată chiar dacă conținutul se schimbă — lipsa semnalului este ea însăși un semnal.

Folosește formatul complet ISO 8601 datetime, inclusiv offset-ul de fus orar: 2026-04-27T12:00:00+00:00. Forma doar cu dată 2026-04-27 este validă și acceptată, dar forma datetime este preferată pentru site-urile cu frecvență ridicată unde ora din zi contează. Setează lastmod la momentul real de modificare al conținutului paginii, nu la momentul deploy-ului aplicației tale. Paginile care nu s-au modificat ar trebui să păstreze valoarea veche de lastmod, chiar și când restul sitemap-ului este regenerat.

changefreq și priority: în mare parte ignorate

Câmpurile <changefreq> și <priority> au fost definite în protocolul original pentru a le oferi proprietarilor de site-uri o modalitate de a exprima cât de des se schimbă o pagină (always, hourly, daily, weekly, monthly, yearly, never) și o prioritate relativă în cadrul site-ului (un număr zecimal între 0.0 și 1.0). Google modern le ignoră pe amândouă. Crawler-ul decide frecvența de crawlare din tiparele de schimbare observate și decide prioritatea pe baza calității conținutului și a valorii link-urilor, nu din declarațiile din sitemap.

Recomandarea practică este să le omiți pe ambele. Fac sitemap-ul mai mare și mai complex fără a schimba comportamentul crawlerului. Documentația Bing sugerează că încă ia în considerare changefreq în mod slab, dar impactul este suficient de mic încât menținerea valorilor exacte rareori merită costul de inginerie. Un sitemap curat cu doar <loc> și <lastmod> este implicit-ul modern.

Autodiscovery prin robots.txt vs trimitere prin Search Console

Două moduri de a-i comunica lui Google despre un sitemap: declară-l în robots.txt sau trimite-l prin Search Console. Ambele funcționează, ambele sunt recomandate, iar ambele împreună reprezintă buna practică modernă.

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Declarația din robots.txt este citită de fiecare crawler bine comportat — Googlebot, Bingbot, DuckDuckBot, Yandex și majoritatea instrumentelor SEO — fără nicio configurare pe platformă. Trimiterea prin Search Console este specifică Google, dar deblochează rapoartele de indexare care arată câte URL-uri din sitemap sunt indexate, câte sunt excluse și de ce. Pentru un site care ia SEO în serios, trimite prin Search Console pentru vizibilitate și declară în robots.txt pentru portabilitate.

Extensii sitemap pentru imagini, video și știri

Protocolul de bază are extensii pentru conținut de tip imagine, video și știri. Extensiile pentru sitemaps de imagini adaugă un element <image:image> care listează imaginile de pe fiecare pagină, ajutând Google să descopere imagini pe paginile redate în JavaScript unde URL-urile imaginilor nu se află în HTML-ul inițial. Sitemaps-urile video adaugă un element <video:video> cu titlu, descriere, miniatură și durată și rămân modalitatea canonică de a expune video-ul către Google Video. Sitemaps-urile pentru știri folosesc un element separat <news:news> cu data publicării și namespace-ul necesar și sunt obligatorii pentru includerea în Google News.

Pentru un site tipic de marketing sau conținut, un sitemap simplu cu URL-uri acoperă complet cazul de utilizare. Extensiile merită complexitatea doar când descoperibilitatea imaginilor, video-ul sau includerea în știri reprezintă o sursă semnificativă de trafic.

Greșeli frecvente care afectează SEO

404-uri și redirecționări în sitemap. Listarea URL-urilor care returnează 404 sau redirecționează către un alt URL poluează sitemap-ul cu zgomot. Google le semnalează în Search Console ca erori de sitemap și poate deprecia restul sitemap-ului. Auditează sitemap-ul la fiecare deploy și elimină URL-urile non-200. Redirecționările ar trebui înlocuite cu URL-ul de destinație.

Includerea URL-urilor non-canonice. Paginile cu rel="canonical" care pointează către un alt URL nu ar trebui să apară în sitemap. Sitemap-ul este o listă de pagini pe care vrei să le indexezi; paginile canonicalizate sunt pagini pe care le-ai spus explicit motoarelor de căutare să le ignore. Includerea lor creează semnale conflictuale.

lastmod mereu curent. Setarea lastmod la data de azi pentru fiecare URL la fiecare regenerare îi spune lui Google că câmpul este nesigur, iar crawler-ul nu îl mai ia în considerare. Setează lastmod din momentul real de modificare al conținutului paginii, nu momentul deploy-ului. Paginile care nu s-au modificat ar trebui să-și păstreze lastmod-ul anterior.

Sitemap blocat de robots.txt. O linie Disallow: /sitemap.xml sau un Disallow: /sitemap mai larg care se potrivește cu fișierul împiedică crawlerele să acceseze sitemap-ul. Testează întotdeauna cu curl sau un verificator de sitemap după modificarea robots.txt pentru a confirma că URL-ul sitemap-ului este accesibil.

Sub-sitemaps dintr-un sitemap-index care returnează 404. Un sitemap-index care listează zece sitemaps copil, dar doar nouă dintre ele se rezolvă, determină marcarea celui lipsă ca eroare. Mai rău, dacă modelul de cale se schimbă între deploy-uri, fiecare URL vechi de sub-sitemap devine un 404 până când indexul este regenerat. Generează indexul din aceeași sursă de adevăr ca și copiii pentru a le menține sincronizate.

Amestecarea protocoalelor în cadrul unui sitemap. Un sitemap servit la https://example.com/sitemap.xml ar trebui să conțină doar URL-uri https://. URL-urile http:// mixte sunt tratate ca un host diferit și ignorate de procesorul de sitemap al host-ului canonic. Același lucru se aplică inconsistenței www vs non-www: alege una și folosește-o în tot sitemap-ul.

Uitarea escapării caracterelor speciale din URL-uri. XML necesită escaparea &, <, >, " și ' în valorile atributelor și elementelor. URL-urile cu ampersand-uri brute strică parserul XML, iar întregul sitemap eșuează validarea. Generează URL-uri printr-o bibliotecă care gestionează escaparea în loc să concatenezi șiruri manual.

Cazuri marginale pe care nimeni nu le menționează

Un sitemap.xml servit cu tipul de conținut greșit strică unele crawlere. Tipul de conținut corect este application/xml sau text/xml. Unele servere returnează text/plain sau text/html pentru fișierele .xml când tipul MIME nu este configurat, iar Bingbot în special este cunoscut că refuză astfel de răspunsuri. Verificatorul testează tipul de conținut și îl semnalează ca avertisment când nu se potrivește.

Sitemaps-urile comprimate servite ca .xml.gz economisesc considerabil banda — sitemaps-urile se comprimă la 5-10% din dimensiunea lor originală datorită repetiției masive a prefixelor URL. Atât Google, cât și Bing acceptă sitemaps-uri comprimate cu gzip fără nicio configurare suplimentară, iar limita de dimensiune a fișierului se măsoară față de dimensiunea necomprimată. Singura problemă este că unele platforme de hosting servesc fișierele .gz cu codificarea de conținut greșită, determinând crawler-ul să primească bytes bruti gzip care nu pot fi parsați. Testează versiunea comprimată în browser; dacă vezi caractere binare în loc de XML, răspunsul nu are header-ul Content-Encoding: gzip.