Comment résoudre les problèmes techniques SEO sur les applications de réaction côté client

Les robots Web de Google ont parcouru un long chemin ces dernières années dans leur capacité à récupérer et à exécuter JavaScript.

Cependant, l’intégration JavaScript reste difficile lors de la configuration de l’extrémité avant d’une application Web.

Il nécessite des appels réseau supplémentaires et du temps de traitement pour charger du contenu, ce qui augmente l’utilisation du processeur du navigateur et les temps de chargement de page.

Une application Web qui repose entièrement sur JavaScript côté client peut toujours dépasser la capacité du service de rendu Web de Google (WRS), ce qui rend difficile pour Googlebot de ramper et d’indexer le contenu.

JavaScript est toujours l’épine dorsale du Web – la seule langue qui peut fonctionner nativement dans le navigateur.

Dans le même temps, la montée des modèles de grands langues (LLMS) a déclenché une vague de robots Web à la recherche de contenu de qualité pour former leurs ensembles de données.

Cependant, des études récentes montrent que beaucoup de ces robots ne peuvent pas exécuter JavaScript – ils ne peuvent que le récupérer.

C’est pourquoi il est crucial de savoir comment diagnostiquer les problèmes communs liés à JavaScript et résoudre les retards potentiels de rampage ou d’indexation avant qu’ils affectent votre référencement technique.

Le rôle des bibliothèques JavaScript dans le flux d’indexation

Les sites Web dépendent fortement de JavaScript depuis un certain temps.

Avec la montée en puissance de grands modèles de langue, plus est en cours de construction et plus rapidement.

Mais la vitesse peut brouiller les détails, il est donc important de rester vigilant sur l’impact de JavaScript sur la framer et l’indexation de votre site.

Les bibliothèques JavaScript sont des collections de code pré-écrit que les développeurs peuvent brancher leurs projets pour gérer des tâches spécifiques, comme:

• Manipulation Dom.
• Demandes HTTP.
• Injection de métadonnées (ce dernier étant un drapeau rouge potentiel SEO).

Surtout, ces bibliothèques opèrent sous le contrôle du développeur.

Prenez React, par exemple, une bibliothèque JavaScript populaire qui permet aux développeurs de créer des composants réutilisables en JavaScript et de les assembler sur une page.

Cependant, parce que ce nouveau contenu n’existe pas dans le HTML d’origine, il est généralement découvert lors de ce que l’on appelle le sECOND WAVE D’INDEXING, lorsque les moteurs de recherche revisitent la page pour rendre et traiter le contenu JavaScript.

Notez que JavaScript est à forte intensité de ressources (Googlebot rampe plus de 130 billions de pages).

Il peut manger dans votre budget d’exploration, en particulier pour les grands sites de commerce électronique avec de nombreuses pages à propulsion JavaScript.

Cela peut inévitablement dissuader vos allocations budgétaires de rampe et empêcher le rendu correct.

Vous plus profondément: SEO pour JavaScript réactif en utilisant React ou Vue avec Nodejs et autres piles backend 

Rendu react: côté client vs côté serveur

Une application React peut être rendue sur le serveur ou dans le navigateur (côté client).

Les applications Web routées côté serveur rendent JavaScript sur le serveur pour chaque demande, forçant un rechargement de page complet chaque fois qu’une charge de page est soumise.

En dépit de l’exécution des ressources et légèrement inférieure à un point de vue UX, il renforce la cohérence entre la vue renvoyée par Googlebot et celle de l’utilisateur moyen à l’avant.

L’approche la plus courante et la plus par défaut pour les applications Web modernes est le rendu côté client.

Dans cette configuration, le serveur offre une page vide qui sera remplie dès que le navigateur termine le téléchargement, l’analyse et l’exécution du javascript.

Bien qu’ils ne soient pas aussi courants dans le commerce électronique, certaines plateformes, telles qu’Adobe PWA Studio, sont toujours entièrement rendues par le client.

Cette configuration peut être problématique pour le référencement, et elle est intrinsèquement liée à la configuration du soi-disant routeur React, une solution populaire pour gérer les itinéraires dans des applications à une page (SPAS).

Pour les personnes ayant des connaissances techniques limitées, le «routage» dans les applications Web permet des transitions en douceur entre les pages sans avoir besoin d’un rechargement de la page complète du serveur.

Il en résulte des performances plus rapides et une charge de bande passante du serveur réduit lors de la navigation entre les pages.

Considérez le routeur dans une application React comme contrôleur de trafic tout en haut de votre hiérarchie de composants. Il enveloppe l’ensemble de votre application et regarde la barre d’adresse du navigateur.

Dès que l’URL change, le routeur décide quelle «salle» (composant) afficher, sans jamais recharger la page, contrairement à un site Web traditionnel, qui demande une page du serveur à chaque navigation.

Dans les applications React, les routeurs utilisent des chemins dynamiques, comme /product/:idpour charger des modèles de page sans rafraîchissement complet.

Le : signifie la valeur change basée sur le produit ou le contenu indiqué.

<Routes>
<Route path="/" element={<Home />} /> 
<Route path="/note/:noteId" element={<NoteDetailPage />} /> 
</Routes>

Bien que cela soit idéal pour l’expérience utilisateur, une mauvaise configuration peut se retourner sur SEO, surtout si cela est effectué côté client.

Par exemple, si le routeur génère des variations sans fin d’URL (comme /filter/:color) Sans renvoyer une réponse complète du serveur, les moteurs de recherche peuvent avoir du mal à les rendre et à les indexer.

Comment un routeur défectueux peut nuire à l’indexation

Lors d’un récent audit de référencement pour un constructeur automobile notoire, nous avons découvert un problème de routage qui a eu un impact sur l’indexation.

Un filtre dynamique sur une page d’inscription de catégorie a utilisé un segment d’itinéraire d’espace réservé (par exemple, /:/). Cela a entraîné des URL comme /page-category/:/ Être accessible aux moteurs de recherche.

Ceci est généralement sur le routeur et comment il est configuré.

Du point de vue du référencement, l’effet secondaire principal était la génération automatique de pages autonomes non valides, largement interprétées comme des doublons par Googlebot.

Découvert, actuellement non indexé

Précisément, les URL non valides ont été classées comme «découvertes, actuellement non indexées» ou «URL est inconnue de Google» dans le rapport d’indexation de la console de recherche de Google, bien qu’il soit soumis au site de site XML.

Cela indique que Google ne les a jamais indexés ou prioritaires en raison d’une faible valeur.

Vous plus profondément: Comprendre et résoudre «découvert – actuellement non indexé‘

Plusieurs URL avec des goûts /page-category/:/product-xyz Offert peu ou pas de contenu unique et ne se démarque que pour un nombre variable de marques de filtre côté client hydraté par le routeur React.

Après une plongée profonde, nous étions très convaincus que le problème concernait le routage côté client de l’application Web à l’aide d’un espace réservé (/:/) Pour générer des pages de vue filtrées sans envoyer de demandes au serveur.

Cette approche était nuisible pour le référencement parce que:

• Les moteurs de recherche ont eu du mal à rendre les vues filtrées.
• Les moteurs de recherche ont manqué les demandes de serveur pour de nouvelles pages.

Les moteurs de recherche ont eu du mal à rendre les vues filtrées

Un routage côté client agressif a fait que la réponse HTML initiale n’a pas le contenu nécessaire pour les moteurs de recherche lors de la première onde d’indexation (avant l’exécution de JavaScript).

Cela pourrait avoir découragé Googlebot de traiter ces URL comme valides pour l’indexation.

Sans charger des filtres ou des listes de produits, les pages peuvent être apparues en double aux moteurs de recherche.

Rechercher les demandes de serveur manquées pour de nouvelles pages

Parce que l’application n’a pas pu résoudre les vues filtrées (par exemple, /:/) Au niveau du serveur, les pages générées dynamiquement peuvent avoir été traitées comme des doublons de leurs pages parents.

En conséquence, Googlebot peut avoir rapidement supprimé la fréquence de chagrin de ces pages.

Meilleures pratiques de référence pour réagir le routage côté client

La construction d’une application React Performant et de recherche sur le moteur de recherche nécessite quelques considérations générales pour sauvegarder la rampe et l’indexation.

Organisez votre application avec une structure de dossiers propre

Cela comprend le regroupement des fichiers d’itinéraire connexes dans un dossier et la rupture des itinéraires en petits composants réutilisables pour une maintenance et un débogage plus faciles.

Configurer un système robuste d’erreur

Les erreurs de routage conduisant à des pages inexistantes peuvent nuire au référencement et à la confiance des utilisateurs. Envisagez de mettre en œuvre:

• Un itinéraire à tout transporter pour les chemins non définis en utilisant:
  • path="*": <Route path="*" element={<NotFound />} />
• Une page 404 personnalisée pour guider les utilisateurs vers votre page d’accueil ou votre contenu pertinent.
• Utiliser ErrorBoundary Pour attraper les erreurs dans l’application et afficher l’interface utilisateur de secours sans écraser l’application.

Migrer vers Next.js

Bien que React offre de nombreux avantages, il est important de se rappeler qu’il s’agit fondamentalement d’une bibliothèque, pas d’un cadre complet.

Cela signifie que les développeurs doivent souvent intégrer plusieurs outils tiers pour gérer les tâches telles que:

• Routage.
• Données récupérant.
• Optimisation des performances.

Next.js, en revanche, fournit une solution plus complète hors de la boîte. Ses plus grands avantages comprennent:

• Rendu côté serveur Comme une option par défaut pour des pages plus rapides et conviviales.
• Clissage automatique du codedonc seul le JavaScript et les CS nécessaires sont chargés par page.

Cela réduit les charges JavaScript lourdes sur le thread principal du navigateur, ce qui entraîne des charges de page plus rapides, des expériences utilisateur plus lisses et un meilleur référencement.

En ce qui concerne les éléments d’action SEO, l’étude de cas a suggéré un certain nombre de meilleures pratiques, que nous avons réellement remises aux développeurs Web pour agir.

Valider et optimiser les routes dynamiques

• Construisez des URL propres et conviviales:
  • /category/filter-1/filter-2
  • /category/:/
• Assurer des segments dynamiques (par exemple, /category/:filter) Ne conduisez pas à des vues brisées ou vides.

Utilisez des redirectes pour gérer les canoniques et éviter les doublons

• Ajoutez des replies ou des redirects pour les filtres vides pour empêcher Google d’indexer du duplicata ou des URL dénué de sens.
• Implémentez 301 Redirection des URL canoniques générées par l’utilisateur vers la version canonique correcte sélectionnée par Google.
  • Par exemple, définissez la redirection HTTP 301:
    • /parent-category/:/ → /parent-category/

Tirez parti des ressources préalables aux ressources statiques ou du rendu côté serveur

Le pré-rendu est généralement l’option la plus abordable, et c’est probablement celle que votre équipe informatique ou de développement choisira pour votre application Web.

Avec cette méthode, une version HTML statique de votre page est générée spécifiquement pour les robots de recherche de moteurs.

Cette version peut ensuite être mise en cache sur un CDN, ce qui lui permet de charger beaucoup plus rapidement pour les utilisateurs.

Cette approche est bénéfique car elle maintient une expérience dynamique et interactive pour les utilisateurs tout en évitant le coût et la complexité du rendu complet du côté serveur.

Conseil bonus: La mise en cache de ce HTML pré-rendu sur un CDN aide votre site à charger encore plus rapidement lorsque les utilisateurs visitent.