Structure d'URL Google Aidez Doc à jour

Google a mis à jour la documentation des meilleures pratiques de structure URL – c'était à peu près une réécriture, mais les conseils globaux ne sont pas nouveaux. Google a déclaré avoir ajouté « un flux plus clair et est plus facile à naviguer, avec des exemples supplémentaires basés sur les URL du monde réel que nous avons rencontrés ».

Google a montré clairement que ces modifications de document ne signifient pas que Google a apporté des modifications à la recherche Google et comment les processus de recherche URL. « Il s'agit d'un changement uniquement des documents, pas de changement de comportement, a ajouté Google.

L'ancien document a été divisé en deux sections:

Introduction

Problèmes communs liés aux URL

Résoudre les problèmes liés aux URL

Le nouveau document est divisé en plusieurs sections:

Exigences pour une structure URL de randable

Suivez IETF STD 66

N'utilisez pas les fragments d'URL pour modifier le contenu

Utilisez un codage commun pour les paramètres URL

Faciliter la compréhension de votre structure URL

Utiliser des URL descriptives

Utilisez la langue de votre public

Utilisez le codage UTF-8 si nécessaire

Utilisez des traits d'accès pour séparer les mots

Utilisez aussi peu de paramètres que vous pouvez savoir que les URL sont sensibles à la casse

Pour les sites multirégionaux

Évitez les problèmes communs liés aux URL

Filtrage additif d'un ensemble d'éléments

Paramètres non pertinents

Problèmes de calendrier

Liens relatifs cassés

Fixation des problèmes de structure d'URL liés à la rampe

Vous pouvez voir un vérificateur de document Diff pour ces changements ici et parce que c'est beaucoup, j'ai demandé à Gemini de résumer ces changements pour moi. Gemini a écrit:

Ton et focus globaux:

Original: plus largement éducatif et consultatif («meilleures pratiques»). Cela explique pourquoi certaines pratiques sont bonnes ou mauvaises.

Révisé: plus normatif et met l'accent sur les exigences d'une rampe efficace par la «recherche Google». Il indique explicitement les conséquences de ne pas répondre à ces exigences (« ramper probablement de manière inefficace votre site – y compris, mais sans s'y limiter, des taux d'exploration extrêmement élevés, ou pas du tout »). La langue est généralement plus directe et axée sur l'action.

Changements et titres structurels:

Original: utilise des paragraphes plus descriptifs et des sous-titres « recommandés » / « non recommandés » dans les sections. Les «problèmes communs liés aux URL» et «résoudre les problèmes liés aux URL» sont des sections distinctes.

Révisé: introduit des sections et des sous-sections plus explicites avec des titres clairs comme « les exigences pour une structure d'URL d'exploration », « facilite la compréhension de votre structure URL », « meilleures pratiques » et « éviter les problèmes courants liés aux URL ». Il introduit également «recommandé» et «non recommandé» dans un format tabulaire pour une meilleure lisibilité avec des exemples spécifiques.

Différences clés de contenu et ajouts / suppressions:

(1) Introduction / portée:

Original: « Google prend en charge les URL telles que définies par RFC 3986 ».

Révisé: « Pour vous assurer que Google Search peut ramper efficacement votre site, utilisez une structure d'URL de crawlable qui répond aux exigences suivantes. Si vos URL ne répondent pas aux critères suivants, la recherche Google explorera probablement de manière inefficace votre site – y compris mais sans s'y limiter à des taux d'exploration extrêmement élevés, ou pas du tout. » Cela ajoute un fort avertissement quant à l'importance de la conformité.

(2) IETF STD 66 (anciennement RFC 3986):

Original: fait référence à « RFC 3986 ».

Révisé: mentionne explicitement « IETF STD 66 » et précise que « Google Search prend en charge les URL telles que définies par l'IETF STD 66 ». Il s'agit d'une référence plus à jour et spécifique pour les normes URL.

(3) Encodage UTF-8:

Original: Mentionne les caractères non ASCII doit être encodé UTF-8 et montre des exemples de caractères non-ASCII recommandés (codés) et non recommandés (non codés).

Révisé: consolide la discussion de codage UTF-8 sous « Utiliser le codage UTF-8 si nécessaire » et contraste directement « recommandé (codage UTF-8) » avec « non recommandé (caractères non ASCII) » dans un format à deux colonnes, ce qui rend la distinction plus claire. Il ajoute également un exemple japonais.

(4) Numéros d'identification longs:

Original: « Recommandé: des mots descriptifs simples dans l'URL. » « Non recommandé: illisible les numéros d'identification illisible dans l'URL. » L'exemple du cas recommandé est générique (https://en.wikipedia.org/wiki/aviation).

Révisé: les consolide dans une section « Utiliser des URL descriptives » et présente les exemples « recommandés » et « non recommandés » côte à côte, ce qui rend la comparaison immédiate. L'exemple « recommandé » est désormais un exemple générique.com.

(5) Typhes vs soulignements:

Original: recommande les traits de traits et indique explicitement « Nous vous recommandons d'utiliser des traits de traits (-) au lieu de souligner (_) dans vos URL. »

Révisé: ajoute une explication plus détaillée pour expliquer pourquoi les soulignements ne sont pas recommandés: « Pour des raisons historiques, nous ne recommandons pas d'utiliser des soulignements, car ce style est déjà couramment utilisé pour indiquer les concepts qui doivent être conservés ensemble, par exemple, par divers langages de programmation pour nommer des fonctions (comme Format_Date). » Cela fournit un contexte précieux.

(6) Paramètres URL:

Original: « Lors de la spécification des paramètres d'URL, utilisez le codage commun suivant: un signe égal (=) pour séparer les paires de valeurs de clé et ajouter des paramètres supplémentaires avec un ampère et). Pour répertorier plusieurs valeurs pour la même clé dans une paire de valeurs clés, vous pouvez utiliser n'importe quel caractère qui n'intervient pas avec IETF STD 66, comme une limite (,). »

Révisé: Le langage pour l'encodage des paramètres est principalement le même, mais les exemples « recommandés » et « non recommandés » sont présentés dans une table à deux colonnes, qui est plus visuellement organisée.

(7) « Problèmes communs liés aux URL »:

Original: répertorie les problèmes comme «filtrage additif», «génération dynamique de documents», «paramètres problématiques», «paramètres de tri», «paramètres non pertinents» et «problèmes de calendrier» et «liens relatifs rompus». Chacun a sa propre description de paragraphe.

Révisé: les réorganise et les reformulent. La «génération dynamique de documents» est supprimée en tant que point séparé, peut-être implicitement couvert par d'autres catégories. «Paramètres problématiques», «paramètres de tri» et «paramètres non pertinents» sont largement combinés sous des «paramètres non pertinents» avec des exemples spécifiques pour les «paramètres de référence», «paramètres de tri de shopping» et «ID de session». Il ajoute un nouvel avertissement sur les ID de session ici: « Dans la mesure du possible, évitez l'utilisation d'ID de session dans les URL et envisagez d'utiliser des cookies à la place. »

(8) « Résoudre les problèmes liés aux URL » (original) vs « Fixation des problèmes de structure URL liés à la rampe » (révisé):

Original: fournit des solutions telles que «Créer une structure URL simple», «Envisagez d'utiliser un fichier robots.txt pour bloquer», «Évitez l'utilisation des identifiants de session», «Convertissez tout le texte en même cas», «Raccourcir les URL» et «vérifiez votre site pour les liens brisés».

Révisé: Cette section est considérablement rationalisée et se concentre davantage sur les actions à prendre lorsque des problèmes sont remarqués.

Il consolide les conseils pour les robots.txt Blocking pour inclure «les fonctions de commande et de filtrage».

Il ajoute spécifiquement un nouveau point: « Si votre site a une navigation à facettes, apprenez à gérer la rampe de ces URL de navigation à facettes. » Ceci est un nouveau conseil pratique.

Les conseils sur le « calendrier infini » sont déplacés dans la section « Calendar Issues » ci-dessus.

Les conseils sur la « conversion du texte en même cas » sont désormais une section distincte « sachez que les URL sont sensibles à la caisse », avec une explication plus formelle de la sensibilité des cas de Google.

Les conseils sur le raccourcissement des URL sont désormais « Utiliser le moins de paramètres que possible. »

L'explication des « liens relatives brisés » est élargie, clarifie la question des « liens relatives parentales » et recommande explicitement « URL relatives racinaires ».

(9) Nouvelles sections / concepts dans le texte révisé:

« Sachez que les URL sont sensibles à la casse »: il s'agit d'une section dédiée avec une explication claire de la sensibilité aux cas de Google et une recommandation de cohérence.

Intégration avec SEO Starter Guide: « Pour plus d'informations sur la structuration de votre site dans son ensemble, consultez cette section du guide de démarrage du référencement. » Cela se lie à d'autres ressources Google.

Navigation à facettes: un nouveau point important dans la section « Problèmes de structure URL liés à la fixation ».

Formatage et présentation:

Original: utilise des puces plus simples et en gras.

Révisé: utilise largement les tables pour des exemples «recommandés» contre «non recommandés», améliorant la lisibilité et les comparaisons immédiates. Il utilise également le formatage de code pour les URL et les paramètres de manière plus cohérente.

En résumé, le texte révisé est plus structuré, normatif et moderne. Il fournit des conseils plus clairs avec une meilleure mise en forme et des exemples plus spécifiques, indiquant explicitement l'importance de suivre les recommandations d'un rampage efficace par Google Search. Il intègre également une terminologie mise à jour et des liens vers d'autres ressources pertinentes.

Discussion du forum à X.