{"version":"1.1","schema_version":"1.1.0","plugin_version":"1.1.2","url":"https://peakace.fr/blog/seo/full-client-side-rendering-comment-gerer-ses-canonical/","llm_html_url":"https://peakace.fr/blog/seo/full-client-side-rendering-comment-gerer-ses-canonical/llm","llm_json_url":"https://peakace.fr/blog/seo/full-client-side-rendering-comment-gerer-ses-canonical/llm.json","manifest_url":"https://peakace.fr/llm-endpoints-manifest.json","language":"fr-FR","locale":"fr_FR","title":"Full client side rendering: Comment gérer ses canonical ?","site":{"name":"Peak Ace","url":"https://peakace.fr/"},"author":{"id":17,"name":"Mathieu CHAPON","url":"https://peakace.fr/blog/author/searchforesight/"},"published_at":"2018-05-30T14:16:27+00:00","modified_at":"2025-12-09T10:34:28+00:00","word_count":616,"reading_time_seconds":185,"summary":"Envie de gagner du temps ? Faites résumer cet article par l’IA en quelques secondes. Résumer avec l’IA Une conférence [&hellip;]","summary_points":["Envie de gagner du temps ?","Faites résumer cet article par l’IA en quelques secondes.","Résumer avec l’IA\n          \n        \n      \n    Une conférence au Google I/O présentée par Tom Greenaway &amp; Jhon Mueller nous en apprend un peu plus sur les bonnes pratiques à avoir pour le développement d’un site full client side rendering , et s&rsquo;assurer de la bonne indexabilitée de nos pages.","Avant d’aller plus loin, nous rappelons qu’il est de bonne pratique que d’avoir en server side rendering , tout les éléments importants de nos pages (Hreflang, canonical, index tags…)."],"topics":["SEO","SEO Technique"],"entities":[],"entities_metadata":[{"id":5,"name":"SEO","slug":"seo","taxonomy":"category","count":274,"url":"https://peakace.fr/categories/seo/"},{"id":15,"name":"SEO Technique","slug":"seo-technique","taxonomy":"category","count":31,"url":"https://peakace.fr/categories/seo/seo-technique/"}],"tags":["SEO","SEO Technique"],"content_hash":"9bbd7a6aefc56e3a0958498575281c5c","plain_text":"Envie de gagner du temps ?\n\t\t  \n          Faites résumer cet article par l’IA en quelques secondes.\n        \n        \n          \n            Résumer avec l’IA\n          \n        \n      \n    Une conférence au Google I/O présentée par Tom Greenaway &amp; Jhon Mueller nous en apprend un peu plus sur les bonnes pratiques à avoir pour le développement d’un site full client side rendering , et s&rsquo;assurer de la bonne indexabilitée de nos pages.\nAvant d’aller plus loin, nous rappelons qu’il est de bonne pratique que d’avoir en server side rendering , tout les éléments importants de nos pages (Hreflang, canonical, index tags…). Donc si votre site est en JS, privilégier le rendering « server side », ou encore l’utilisation dudynamic rendering, aujourd’hui facilement accessible grâce à des technologies comme puppeteer ou Rendertron (lien github)\nSi nous avons aujourd&rsquo;hui la certitude que le code HTML est correctement pris en compte par les moteurs de recherche, qu&rsquo;en est-il des sites générés en JS ? Comment Google réagit au JS (sans rendering côté serveur) ?\nCe qu’il faut retenir \nRendering côté client :\nPour Google (et pour les visiteurs aussi), générer des pages en JS demande beaucoup de ressource et d’énergie. C’est pourquoi l’indexation de ces pages se fait en deux temps :\n\nGooglebot passe donc une première fois voir nos pages dans l’état (sans rendering) et indexe ce qu’il peut trouver dans le code. Si une partie du code est généré côté serveur, ce contenu sera directement et correctement assimilé.\nSeulement après cela et lorsque Google pourra allouer les ressources nécessaires (potentiellement quelques jours après le premier crawl, eh oui …) , il enclenchera le rendering avant de recrawler la page et de la mettre à jour dans l’index.\n\nIl est vrai que le rendering côté client permet d’économiser les ressources de nos serveurs, mais cette solution nous confronte à 2 problèmes évidents :\n\nL’assimilation du contenu de la part de Google peut être longue.\nLe contenu généré côté client ne se verra pas attribuer la même valeur que s’il avait été généré directement en HTML\n\nIl est donc important, pour la bonne prise en compte de votre contenu et de vos performances, de réfléchir à la meilleure solution pour votre site. Et il n’y à pas de cas générique, toutes les solutions peuvent être correctes en fonction de vos besoins..\nGestion des canonical : \nPour rester dans le sujet du rendering côté client, une deuxième information importante a été dévoilé par Tom G.\nLes balises canonical DOIVENT IMPÉRATIVEMENT être générées SERVER SIDE pour être lues et interprétées correctement.\nEn vue de cette nouvelle information, nous vous rappelons les bonnes pratiques sur les balises canoniques :\n\nElles doivent se trouver dans le Header (avant les scripts)\nSi site en JS : Générer la balise serveurs side\nUtiliser le balisage décrit dans la documentation de Google\nRenseigner une URL en absolut et non pas relative\n\nAstuce \n-&gt; Sur votre navigateur, utiliser les combinaisons « Ctrl+U » pour voir le code source de la page, et donc vérifier si vos balises/contenus sont bien en place. Sinon, vous reste toujours la possibilité « d’explorer » la page comme le ferait Google à travers la Search-Console.\nATTENTION : Lorsque nous faisons clic droit &gt; inspecter, nous avons le rendu après rendering. Un résultat donc biaisé sur ce que Google verra vraiment.\nPour revoir cette partie de la conférence, présenté par Tom Greenaway &amp; Jhon Mueller :\n\n\nChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)","paragraphs":["Envie de gagner du temps ?\n\t\t  \n          Faites résumer cet article par l’IA en quelques secondes.\n        \n        \n          \n            Résumer avec l’IA\n          \n        \n      \n    Une conférence au Google I/O présentée par Tom Greenaway &amp; Jhon Mueller nous en apprend un peu plus sur les bonnes pratiques à avoir pour le développement d’un site full client side rendering , et s&rsquo;assurer de la bonne indexabilitée de nos pages.\nAvant d’aller plus loin, nous rappelons qu’il est de bonne pratique que d’avoir en server side rendering , tout les éléments importants de nos pages (Hreflang, canonical, index tags…). Donc si votre site est en JS, privilégier le rendering « server side », ou encore l’utilisation dudynamic rendering, aujourd’hui facilement accessible grâce à des technologies comme puppeteer ou Rendertron (lien github)\nSi nous avons aujourd&rsquo;hui la certitude que le code HTML est correctement pris en compte par les moteurs de recherche, qu&rsquo;en est-il des sites générés en JS ? Comment Google réagit au JS (sans rendering côté serveur) ?\nCe qu’il faut retenir \nRendering côté client :\nPour Google (et pour les visiteurs aussi), générer des pages en JS demande beaucoup de ressource et d’énergie. C’est pourquoi l’indexation de ces pages se fait en deux temps :","Googlebot passe donc une première fois voir nos pages dans l’état (sans rendering) et indexe ce qu’il peut trouver dans le code. Si une partie du code est généré côté serveur, ce contenu sera directement et correctement assimilé.\nSeulement après cela et lorsque Google pourra allouer les ressources nécessaires (potentiellement quelques jours après le premier crawl, eh oui …) , il enclenchera le rendering avant de recrawler la page et de la mettre à jour dans l’index.","Il est vrai que le rendering côté client permet d’économiser les ressources de nos serveurs, mais cette solution nous confronte à 2 problèmes évidents :","L’assimilation du contenu de la part de Google peut être longue.\nLe contenu généré côté client ne se verra pas attribuer la même valeur que s’il avait été généré directement en HTML","Il est donc important, pour la bonne prise en compte de votre contenu et de vos performances, de réfléchir à la meilleure solution pour votre site. Et il n’y à pas de cas générique, toutes les solutions peuvent être correctes en fonction de vos besoins..\nGestion des canonical : \nPour rester dans le sujet du rendering côté client, une deuxième information importante a été dévoilé par Tom G.\nLes balises canonical DOIVENT IMPÉRATIVEMENT être générées SERVER SIDE pour être lues et interprétées correctement.\nEn vue de cette nouvelle information, nous vous rappelons les bonnes pratiques sur les balises canoniques :","Elles doivent se trouver dans le Header (avant les scripts)\nSi site en JS : Générer la balise serveurs side\nUtiliser le balisage décrit dans la documentation de Google\nRenseigner une URL en absolut et non pas relative","Astuce \n-&gt; Sur votre navigateur, utiliser les combinaisons « Ctrl+U » pour voir le code source de la page, et donc vérifier si vos balises/contenus sont bien en place. Sinon, vous reste toujours la possibilité « d’explorer » la page comme le ferait Google à travers la Search-Console.\nATTENTION : Lorsque nous faisons clic droit &gt; inspecter, nous avons le rendu après rendering. Un résultat donc biaisé sur ce que Google verra vraiment.\nPour revoir cette partie de la conférence, présenté par Tom Greenaway &amp; Jhon Mueller :","ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)"],"content_blocks":[{"id":"text-1","type":"text","heading":"","plain_text":"Envie de gagner du temps ?\n\t\t  \n          Faites résumer cet article par l’IA en quelques secondes.\n        \n        \n          \n            Résumer avec l’IA\n          \n        \n      \n    Une conférence au Google I/O présentée par Tom Greenaway &amp; Jhon Mueller nous en apprend un peu plus sur les bonnes pratiques à avoir pour le développement d’un site full client side rendering , et s&rsquo;assurer de la bonne indexabilitée de nos pages.\nAvant d’aller plus loin, nous rappelons qu’il est de bonne pratique que d’avoir en server side rendering , tout les éléments importants de nos pages (Hreflang, canonical, index tags…). Donc si votre site est en JS, privilégier le rendering « server side », ou encore l’utilisation dudynamic rendering, aujourd’hui facilement accessible grâce à des technologies comme puppeteer ou Rendertron (lien github)\nSi nous avons aujourd&rsquo;hui la certitude que le code HTML est correctement pris en compte par les moteurs de recherche, qu&rsquo;en est-il des sites générés en JS ? Comment Google réagit au JS (sans rendering côté serveur) ?\nCe qu’il faut retenir \nRendering côté client :\nPour Google (et pour les visiteurs aussi), générer des pages en JS demande beaucoup de ressource et d’énergie. C’est pourquoi l’indexation de ces pages se fait en deux temps :","html":"<p>Envie de gagner du temps ?\n\t\t  \n          Faites résumer cet article par l’IA en quelques secondes.\n        \n        \n          \n            Résumer avec l’IA\n          \n        \n      \n    Une conférence au Google I/O présentée par Tom Greenaway &amp; Jhon Mueller nous en apprend un peu plus sur les bonnes pratiques à avoir pour le développement d’un site full client side rendering , et s&rsquo;assurer de la bonne indexabilitée de nos pages.\nAvant d’aller plus loin, nous rappelons qu’il est de bonne pratique que d’avoir en server side rendering , tout les éléments importants de nos pages (Hreflang, canonical, index tags…). Donc si votre site est en JS, privilégier le rendering « server side », ou encore l’utilisation dudynamic rendering, aujourd’hui facilement accessible grâce à des technologies comme puppeteer ou Rendertron (lien github)\nSi nous avons aujourd&rsquo;hui la certitude que le code HTML est correctement pris en compte par les moteurs de recherche, qu&rsquo;en est-il des sites générés en JS ? Comment Google réagit au JS (sans rendering côté serveur) ?\nCe qu’il faut retenir \nRendering côté client :\nPour Google (et pour les visiteurs aussi), générer des pages en JS demande beaucoup de ressource et d’énergie. C’est pourquoi l’indexation de ces pages se fait en deux temps :</p>"},{"id":"text-2","type":"text","heading":"","plain_text":"Googlebot passe donc une première fois voir nos pages dans l’état (sans rendering) et indexe ce qu’il peut trouver dans le code. Si une partie du code est généré côté serveur, ce contenu sera directement et correctement assimilé.\nSeulement après cela et lorsque Google pourra allouer les ressources nécessaires (potentiellement quelques jours après le premier crawl, eh oui …) , il enclenchera le rendering avant de recrawler la page et de la mettre à jour dans l’index.","html":"<p>Googlebot passe donc une première fois voir nos pages dans l’état (sans rendering) et indexe ce qu’il peut trouver dans le code. Si une partie du code est généré côté serveur, ce contenu sera directement et correctement assimilé.\nSeulement après cela et lorsque Google pourra allouer les ressources nécessaires (potentiellement quelques jours après le premier crawl, eh oui …) , il enclenchera le rendering avant de recrawler la page et de la mettre à jour dans l’index.</p>"},{"id":"text-3","type":"text","heading":"","plain_text":"Il est vrai que le rendering côté client permet d’économiser les ressources de nos serveurs, mais cette solution nous confronte à 2 problèmes évidents :","html":"<p>Il est vrai que le rendering côté client permet d’économiser les ressources de nos serveurs, mais cette solution nous confronte à 2 problèmes évidents :</p>"},{"id":"text-4","type":"text","heading":"","plain_text":"L’assimilation du contenu de la part de Google peut être longue.\nLe contenu généré côté client ne se verra pas attribuer la même valeur que s’il avait été généré directement en HTML","html":"<p>L’assimilation du contenu de la part de Google peut être longue.\nLe contenu généré côté client ne se verra pas attribuer la même valeur que s’il avait été généré directement en HTML</p>"},{"id":"text-5","type":"text","heading":"","plain_text":"Il est donc important, pour la bonne prise en compte de votre contenu et de vos performances, de réfléchir à la meilleure solution pour votre site. Et il n’y à pas de cas générique, toutes les solutions peuvent être correctes en fonction de vos besoins..\nGestion des canonical : \nPour rester dans le sujet du rendering côté client, une deuxième information importante a été dévoilé par Tom G.\nLes balises canonical DOIVENT IMPÉRATIVEMENT être générées SERVER SIDE pour être lues et interprétées correctement.\nEn vue de cette nouvelle information, nous vous rappelons les bonnes pratiques sur les balises canoniques :","html":"<p>Il est donc important, pour la bonne prise en compte de votre contenu et de vos performances, de réfléchir à la meilleure solution pour votre site. Et il n’y à pas de cas générique, toutes les solutions peuvent être correctes en fonction de vos besoins..\nGestion des canonical : \nPour rester dans le sujet du rendering côté client, une deuxième information importante a été dévoilé par Tom G.\nLes balises canonical DOIVENT IMPÉRATIVEMENT être générées SERVER SIDE pour être lues et interprétées correctement.\nEn vue de cette nouvelle information, nous vous rappelons les bonnes pratiques sur les balises canoniques :</p>"},{"id":"text-6","type":"text","heading":"","plain_text":"Elles doivent se trouver dans le Header (avant les scripts)\nSi site en JS : Générer la balise serveurs side\nUtiliser le balisage décrit dans la documentation de Google\nRenseigner une URL en absolut et non pas relative","html":"<p>Elles doivent se trouver dans le Header (avant les scripts)\nSi site en JS : Générer la balise serveurs side\nUtiliser le balisage décrit dans la documentation de Google\nRenseigner une URL en absolut et non pas relative</p>"},{"id":"text-7","type":"text","heading":"","plain_text":"Astuce \n-&gt; Sur votre navigateur, utiliser les combinaisons « Ctrl+U » pour voir le code source de la page, et donc vérifier si vos balises/contenus sont bien en place. Sinon, vous reste toujours la possibilité « d’explorer » la page comme le ferait Google à travers la Search-Console.\nATTENTION : Lorsque nous faisons clic droit &gt; inspecter, nous avons le rendu après rendering. Un résultat donc biaisé sur ce que Google verra vraiment.\nPour revoir cette partie de la conférence, présenté par Tom Greenaway &amp; Jhon Mueller :","html":"<p>Astuce \n-&gt; Sur votre navigateur, utiliser les combinaisons « Ctrl+U » pour voir le code source de la page, et donc vérifier si vos balises/contenus sont bien en place. Sinon, vous reste toujours la possibilité « d’explorer » la page comme le ferait Google à travers la Search-Console.\nATTENTION : Lorsque nous faisons clic droit &gt; inspecter, nous avons le rendu après rendering. Un résultat donc biaisé sur ce que Google verra vraiment.\nPour revoir cette partie de la conférence, présenté par Tom Greenaway &amp; Jhon Mueller :</p>"},{"id":"text-8","type":"text","heading":"","plain_text":"ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)","html":"<p>ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)</p>"}],"sections":[{"id":"text-1","heading":"Text","content":"Envie de gagner du temps ?\n\t\t  \n          Faites résumer cet article par l’IA en quelques secondes.\n        \n        \n          \n            Résumer avec l’IA\n          \n        \n      \n    Une conférence au Google I/O présentée par Tom Greenaway &amp; Jhon Mueller nous en apprend un peu plus sur les bonnes pratiques à avoir pour le développement d’un site full client side rendering , et s&rsquo;assurer de la bonne indexabilitée de nos pages.\nAvant d’aller plus loin, nous rappelons qu’il est de bonne pratique que d’avoir en server side rendering , tout les éléments importants de nos pages (Hreflang, canonical, index tags…). Donc si votre site est en JS, privilégier le rendering « server side », ou encore l’utilisation dudynamic rendering, aujourd’hui facilement accessible grâce à des technologies comme puppeteer ou Rendertron (lien github)\nSi nous avons aujourd&rsquo;hui la certitude que le code HTML est correctement pris en compte par les moteurs de recherche, qu&rsquo;en est-il des sites générés en JS ? Comment Google réagit au JS (sans rendering côté serveur) ?\nCe qu’il faut retenir \nRendering côté client :\nPour Google (et pour les visiteurs aussi), générer des pages en JS demande beaucoup de ressource et d’énergie. C’est pourquoi l’indexation de ces pages se fait en deux temps :"},{"id":"text-2","heading":"Text","content":"Googlebot passe donc une première fois voir nos pages dans l’état (sans rendering) et indexe ce qu’il peut trouver dans le code. Si une partie du code est généré côté serveur, ce contenu sera directement et correctement assimilé.\nSeulement après cela et lorsque Google pourra allouer les ressources nécessaires (potentiellement quelques jours après le premier crawl, eh oui …) , il enclenchera le rendering avant de recrawler la page et de la mettre à jour dans l’index."},{"id":"text-3","heading":"Text","content":"Il est vrai que le rendering côté client permet d’économiser les ressources de nos serveurs, mais cette solution nous confronte à 2 problèmes évidents :"},{"id":"text-4","heading":"Text","content":"L’assimilation du contenu de la part de Google peut être longue.\nLe contenu généré côté client ne se verra pas attribuer la même valeur que s’il avait été généré directement en HTML"},{"id":"text-5","heading":"Text","content":"Il est donc important, pour la bonne prise en compte de votre contenu et de vos performances, de réfléchir à la meilleure solution pour votre site. Et il n’y à pas de cas générique, toutes les solutions peuvent être correctes en fonction de vos besoins..\nGestion des canonical : \nPour rester dans le sujet du rendering côté client, une deuxième information importante a été dévoilé par Tom G.\nLes balises canonical DOIVENT IMPÉRATIVEMENT être générées SERVER SIDE pour être lues et interprétées correctement.\nEn vue de cette nouvelle information, nous vous rappelons les bonnes pratiques sur les balises canoniques :"},{"id":"text-6","heading":"Text","content":"Elles doivent se trouver dans le Header (avant les scripts)\nSi site en JS : Générer la balise serveurs side\nUtiliser le balisage décrit dans la documentation de Google\nRenseigner une URL en absolut et non pas relative"},{"id":"text-7","heading":"Text","content":"Astuce \n-&gt; Sur votre navigateur, utiliser les combinaisons « Ctrl+U » pour voir le code source de la page, et donc vérifier si vos balises/contenus sont bien en place. Sinon, vous reste toujours la possibilité « d’explorer » la page comme le ferait Google à travers la Search-Console.\nATTENTION : Lorsque nous faisons clic droit &gt; inspecter, nous avons le rendu après rendering. Un résultat donc biaisé sur ce que Google verra vraiment.\nPour revoir cette partie de la conférence, présenté par Tom Greenaway &amp; Jhon Mueller :"},{"id":"text-8","heading":"Text","content":"ChatGPTPerplexityGoogle AIWhatsAppLinkedInX (Twitter)"}],"media":{"primary_image":"https://peakace.fr/wp-content/uploads/2025/06/peak-ace-logos-patchwork.jpg"},"relations":[{"rel":"canonical","href":"https://peakace.fr/blog/seo/full-client-side-rendering-comment-gerer-ses-canonical/"},{"rel":"alternate","href":"https://peakace.fr/blog/seo/full-client-side-rendering-comment-gerer-ses-canonical/llm","type":"text/html"},{"rel":"alternate","href":"https://peakace.fr/blog/seo/full-client-side-rendering-comment-gerer-ses-canonical/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://peakace.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}