NgSysV.SEO (optimisation des moteurs de recherche)

Cette série d'articles est indexée sur NgateSystems.com. Vous y trouverez également une fonction de recherche par mot-clé très utile.

Dernière révision : 24 novembre

1. Introduction

Une fois que vous avez déployé votre application dans Google Cloud, elle devient une cible pour les « araignées du Web » qui patrouillent sur le Web à la recherche de contenu à ajouter à leurs « index » de mots clés. Une fois votre site indexé, les internautes peuvent le voir dans les résultats des moteurs de recherche.

C'est génial si tout fonctionne. Le moteur de recherche dirigera les affaires dans votre direction et ne vous facturera pas un centime. Mais en pratique, il faut encourager les robots à indexer votre site de manière bien visible. C'est ce qu'est « l'optimisation des moteurs de recherche » (SEO, en abrégé) - .

Obtenir un bon référencement pour votre site implique :

• Fournir un plan du site pour aider les robots à naviguer sur votre site
• Utiliser le SSR (Server-side-rendering) et le pré-rendu pour aller plus loin dans votre "budget d'exploration"
• Aider les robots à localiser du contenu utile « digne d'être indexé » dans vos pages

2. Fournir des fichiers de plan de site et de robots pour guider les araignées Web

Votre site doit fournir un fichier plan du site qui répertorie tous les itinéraires que vous souhaitez que Google (et d'autres moteurs de recherche) indexent. Les robots d'indexation les découvriront généralement de toute façon, à condition que les pages de la hiérarchie « arborescente » de votre site soient correctement liées via liens d’ancrage. Mais, des problèmes peuvent survenir si votre site est volumineux ou nouveau et encore mal référencé par d'autres sites.

Ces problèmes sont résolus en créant un fichier "plan du site". Les plans de site peuvent être formatés de plusieurs manières, mais dans sa forme la plus simple, le moteur d'indexation se contentera d'un simple fichier texte qui répertorie vos pages comme suit :

// /static/sitemap.txt    - Don't copy this line
https://myProjectURL/inventory-display
https://myProjectURL/inventory-maintenance
etc

Notez ce qui suit :

• Les pages déployées sur le moteur d'application Google sont automatiquement dotées d'une URL https (chiffrée)
• "myProjectURL" sera très probablement une URL "personnalisée" que vous avez explicitement liée à votre URL de déploiement.
• Vous devez uniquement ajouter des extensions aux URL « propres » indiquées ci-dessus s'il s'agit de fichiers statiques « .pdf » ou similaires.
• Un plan de site texte peut être appelé comme vous le souhaitez, mais il est d'usage de l'appeler "sitemap.txt". Dans une application Web Svelte, cependant, vous devez le stocker dans le dossier statique de votre projet afin qu'il soit intégré à votre fichier yaml et déployé à la racine de votre application Web.

Le fichier robots fournit un "partenaire" au fichier de plan du site qui :

• Bloque certains robots d'exploration : vous pouvez empêcher certains robots d'exploration d'accéder à certaines parties de votre site.
• Bloque des répertoires spécifiques : par exemple, vous pouvez bloquer /admin/ ou /private/ pour garder ces pages hors des index des moteurs de recherche.
• Spécifie l'emplacement du plan du site.

Voici un exemple

// /static/sitemap.txt    - Don't copy this line
https://myProjectURL/inventory-display
https://myProjectURL/inventory-maintenance
etc

Dans un projet Svelte, le fichier robots.txt (nom de fichier obligatoire) doit être stocké dans un fichier /static/robots.txt.

Vous pouvez vérifier que vos fichiers robots.txt et sitemap.txt sont correctement déployés à la racine de l'URL de votre projet en essayant de les visualiser à l'aide de votre navigateur :

Chacune des URL suivantes saisies dans le champ « Recherche » du navigateur doit répondre en affichant le contenu du fichier.

// /static/robots.txt     - Don't copy this line
User-agent: *
Disallow: https://myProjectURL/inventory-maintenance
Sitemap: https://myProjectURL/sitemap.txt

De plus amples informations sur toutes ces questions sont disponibles sur En savoir plus sur les plans de site

Une fois que vous avez déployé avec succès votre plan de site, vous trouverez peut-être utile d'avertir Google en soumettant le plan de site à la console de recherche de Google.

Vous commencez ici par enregistrer un "principal" - c'est-à-dire l'URL de votre site. Il s'agit de lancer une procédure qui permet d'assurer à Google que vous êtes propriétaire du site. La procédure commence par le téléchargement par la console d'un fichier « vérification du site » dans votre dossier « téléchargements ». Vous devez copier ceci dans votre dossier statique Svelte et reconstruire/redéployer votre application Web pour télécharger le fichier sur votre site distant. Si Google parvient à trouver le fichier avec le contenu qu'il attend lorsque vous cliquez sur le bouton « Vérifier » sur l'écran d'authentification, il sera convaincu que vous en êtes véritablement le propriétaire.

Cliquer sur l'outil "Plans de site" dans le menu à gauche de l'écran vous permettra désormais de saisir l'URL de votre plan de site (sitemap.txt) et d'obtenir un statut "Succès" dans la fenêtre Plans de site soumis

La Search Console est un outil sophistiqué permettant de suivre la progression de l'indexation de votre site et de résoudre les problèmes qui auraient pu être signalés. Consultez l'article Premiers pas avec la Search Console pour plus de détails

3. Utiliser le "rendu côté serveur" et le "pré-rendu" pour aller plus loin dans votre "budget d'exploration"

Bien que ces dernières années, les moteurs de recherche se soient améliorés dans l'indexation du contenu rendu avec du JavaScript côté client, ils sont plus satisfaits des pages qui contiennent uniquement du HTML. Le contenu rendu côté serveur (SSR) (c'est-à-dire les pages dont le HTML a déjà été généré en exécutant du javascript d'accès à la base de données sur le serveur) est indexé plus fréquemment et de manière plus fiable. Personne d'autre que Google ne sait comment fonctionnent leurs moteurs d'indexation, mais une estimation raisonnable ressemble à ceci.

Tout d'abord, votre webapp se voit attribuer un « classement des sites » (déterminé de manière obscure, mais probablement influencé par le nombre de « backlinks » sur les sites qui référencent votre URL). Cela vous accorde à son tour un certain « budget d'exploration » - le temps que le moteur d'indexation est prêt à consacrer à l'indexation de vos pages. Vous voudrez dépenser cela judicieusement. Le rendu côté serveur allège la charge de travail du bot et optimise votre budget. Donc, si vous voulez un bon référencement, vous devriez utiliser SSR !

L'expression ultime du rendu côté service est qu'une page "statique" - celle qui affiche des données qui ne changent jamais ou qui ne changent que rarement - est rendue au moment de la construction en présence de l'instruction suivante pour son fichier page.js ou page.server.js :

// /static/sitemap.txt    - Don't copy this line
https://myProjectURL/inventory-display
https://myProjectURL/inventory-maintenance
etc

Comme le serveur n'a plus qu'à télécharger du HTML pur, votre budget d'exploration va encore plus loin et vos utilisateurs reçoivent une réponse ultra-rapide ! Voir l'article 4.3 pour plus de détails sur un arrangement permettant d'automatiser les builds de pré-rendu à l'aide d'un planificateur.

4. Aider les robots à localiser du contenu utile « digne d'être indexé » dans vos pages

Les documents Google sur Présentation des sujets d'exploration et d'indexation contiennent tout ce que vous savez. Voici un résumé :

Tout d'abord, vous devez comprendre la politique « Mobile first » de Google. Le robot Google analysera votre site tel qu'il serait vu par un navigateur fonctionnant sur un téléphone mobile. Cela signifie qu'il dégradera la « réputation » de votre site (et son budget de crawl) s'il considère, par exemple, que la taille de votre police est trop petite.

Si votre application Web a été conçue pour les utilisateurs de bureau, cela sera un coup dur pour vous. Essayez votre site sur votre téléphone et vous conclurez probablement qu'il est complètement inutile.

La solution est d'utiliser un "style réactif" (voir l'article 4.4 afin que l'application Web détecte la largeur de la page de l'appareil sur lequel elle s'exécute et ajuste les choses en conséquence.

Il se peut que certaines parties de votre application Web ne soient pas appropriées au fonctionnement du site Web. Vous pouvez chercher à les supprimer, mais Google vous rappelle que l’essentiel de son indexation provient de pages mobiles. Ils vous recommandent de dissimuler délicatement ce contenu derrière des onglets ou des « accordéons ».

Ce que recherchent principalement les robots Web, c'est le contenu : des informations que les clients des moteurs de recherche trouveront utiles. Mais ils ont besoin de votre aide pour localiser et interpréter cela. Voici quelques conseils sur la façon dont vous pourriez procéder @

• Donnez à chaque page un bien écrit et unique, et éléments à l'intérieur d'un bloc de code. Voici un exemple :

// /static/robots.txt     - Don't copy this line
User-agent: *
Disallow: https://myProjectURL/inventory-maintenance
Sitemap: https://myProjectURL/sitemap.txt

Cet arrangement délègue à Svelte la tâche délicate d'insérer les champs