Comment valider et diviser un XML Plan du site : Limites et exemples
Vérifier XML syntaxe, URL et dates, comprendre les limites de nombre et d'octets du sitemap, puis télécharger des parties complètes du sitemap et un index.
Commencez par la liste que vous comptez publier
Une carte du site est la plus utile lorsqu'elle reflète un ensemble délibéré de destinations publiques. Commencez avec vos pages actuelles d'outils, d'articles et de catégories, puis vérifiez si chaque URL est la version préférée que vous voulez que les visiteurs trouvent. Recherchez les anciens noms d'hôte, les adresses de mise en scène, les variations de requête et les pages supprimées. Un fichier peut être parfaitement formé XML tout en énumérant les mauvaises destinations. Le validateur Small Hours aide à inspecter la syntaxe du fichier et les règles de protocole sélectionnées. Il ne visite jamais ces URLs, donc vous devez toujours vérifier leurs réponses, le but de la page, les paramètres canoniques et les instructions d'indexation séparément.
Comprendre les deux limites avant le fractionnement
L'orientation de Google limite un sitemap à 50,000 URLs ou 50 MB non comprimé. Le protocole du sitemap exprime le cap octet comme 52,428,800 Des octets. La compression ne rend pas un document non compressé surdimensionné conforme à cette limite. Notre séparateur vérifie à la fois le nombre d'entrées choisi et sérialisé UTF-8 les octets, y compris XML déclaration et emballage racine. Vous pouvez choisir des pièces plus petites pour l'organisation, mais une partie doit toujours correspondre à la limite d'octets. Une entrée contenant des données étendues d'extension peut consommer plus d'espace qu'une simple page URLDonc URL compte seul est insuffisant.
Reproduisez l'exemple de trois URL
Sélectionnez Essayez un exemple dans l'outil plan du site. Le fixture contient https://example.com/, https://example.com/tools/ et https://example.com/blog/?page=1&sort=new, avec l'ampersand échappé comme & dans sa source XML. Il utilise l'espace de nom standard du sitemap, un calendrier lastmod sur la première entrée et un horodatage avec fuseau horaire sur la seconde. L'action est Valider et fractionner, avec un maximum de deux entrées par partie et https://example.com/ comme répertoire de sortie publique. L'installation existante contrôlée par le navigateur produit deux fichiers de parties de plan du site et sitemap-index.xml. Il s'agit d'une petite démonstration de fractionnement, pas d'un fichier assez grand pour l'exiger.
| Produit | Sommaire | Objet |
|---|---|---|
| Première partie | 2 entrées d'URL | Première tranche de la liste originale |
| Deuxième partie | 1 entrée URL | URL restante |
| Plan du site index | 2 emplacements partiels | Points des deux parties publiées |
La limite à deux entrées est à titre d'illustration. Le fractionnement de la production respecte également la limite d'octets non comprimée.
Utilisez cet exemple Ouvre Plan du site validator avec ces entrées.
Corriger les erreurs avant de traiter les avertissements comme acceptables
Lisez chaque découverte à côté de son numéro d'entrée. Un document XML mal formé ne peut pas être analysé. Un emplacement relatif, une date de calendrier invalide ou un champ de base inattendu doit être corrigé avant que ce séparateur ne crée des parties. Les URLs dupliquées sont des avertissements et restent en sortie; l'outil ne dédouble pas silencieusement la source. Les origines multiples sont en dehors de sa portée de fractionnement supportée et signalées comme des erreurs, même si les documents de Google ont vérifié séparément les accords de soumission intersite. La distinction est importante : un workflow supporté par un outil peut être plus étroit que chaque déploiement de protocole. Ne pas décrire un arrangement non appuyé comme universellement invalide.
Maintenir lastmod lié à un réel changement de contenu
Une chaîne de date valide n'établit que sa syntaxe. Elle n'établit pas qu'une page a changé à cette date. Google dit que lastmod devrait refléter une mise à jour significative et être toujours précis. Gardez cette valeur connectée à vos enregistrements de publication plutôt que de réinitialiser chaque page chaque fois que le plan du site est régénéré. Le validateur accepte les dates de calendrier complètes et les chronomètres avec fuseau horaire; il n'accepte pas tous les formulaires de date de précision réduite. Google ignore les valeurs de priorité et de changementfreq, de sorte que le polissage de ces champs ne devrait pas déplacer la correction des pages manquantes, des destinations cassées ou des informations de modification inexactes dans le flux de travail de publication sous-jacent.
Télécharger toutes les pièces et utiliser l'emplacement réel de sortie
Le répertoire de sortie publique doit correspondre à l'endroit où vous allez télécharger les fichiers générés et se terminer dans une barre oblique. Pour le répertoire exemple, l'index indique https://example.com/sitemap-1.xml et https://example.com/sitemap-2.xml. Le téléchargement de l'index ne laisse pas ses fichiers référencés. Utilisez votre racine de site lorsque les pages listées couvrent différentes familles de chemins; le séparateur vérifie que les URL correspondent au répertoire choisi. Téléchargez chaque fichier généré, vérifiez son nom et enregistrez la source originale à côté. La génération se produit dans le navigateur. Aucun fichier n'a été téléchargé ou soumis à un moteur de recherche par cet outil.
Reconnaître ce que la validation locale laisse sans réponse
Cet outil accepte les entrées XML UTF-8 non compressées jusqu'à 64 MiB et 100,000. Les entrées plus importantes ont besoin d'un flux de travail en streaming. Il ne décompresse pas gzip, ne récupère pas les fichiers enfants à partir d'un index sitemap, n'effectue pas les destinations ou n'effectue la validation complète de XSD et d'extension-schéma. L'extension XML est conservée lors du fractionnement, mais la préservation ne certifie pas son sens. Pour les images, les vidéos ou les annotations en langues alternées, vérifiez les exigences pertinentes dans leur documentation principale. Si vous validez un index existant, consultez séparément les cartes du site de l'enfant qu'il énumère. Un index propre ne peut à lui seul établir que ces documents distants sont accessibles ou correctement formés.
Vérifier la découverte après publication plutôt que l'indexation prometteuse
Une fois les fichiers en direct, confirmez leurs réponses et les emplacements référencés, puis soumettez le plan du site ou l'index via Search Console ou référez-le dans robots.txt. Google traite la soumission comme un indice, sans garantir le téléchargement, le rampage ou l'indexation. Utilisez les règles des robots tester pour vérifier si vos règles de rampage collé permettent des chemins importants listés, et vérifier le comportement déployé séparément. Gardez également des liens de navigation normaux vers des pages utiles. Lorsqu'une page est absente des résultats, étudier l'accès, la canonicalisation, le contenu et les preuves de Search Console plutôt que de soumettre à plusieurs reprises une carte du site inchangée. Le fichier est une partie d'un chemin de découverte de travail.