À qui s’adresse ce guide
Ce n’est pas un tutoriel. Il s’adresse à la personne qui valide le site web : quelles décisions prendre, sur quoi insister et quelles idées reçues ignorer.
Choisir une plateforme
La plupart des débats sur les plateformes relèvent du tribalisme. En réalité, la décision est assez mécanique et repose sur une seule question : à quelle fréquence des personnes non techniques doivent-elles modifier des éléments ?
WordPress
Reste la réponse pragmatique pour une grande partie des entreprises britanniques. Votre responsable marketing peut ajouter une page de service, publier une étude de cas ou changer un titre sans créer un ticket. Sur douze mois, cette autonomie compte souvent plus que tout avantage technique, car la fréquence de publication est le levier de contenu le plus puissant pour la plupart des entreprises.
Sa faiblesse ne réside pas dans WordPress lui-même, mais dans ce qui s’accumule par-dessus. Un constructeur de pages empilé sur un thème avec son propre constructeur, plus vingt extensions, génère des temps de chargement de quatre secondes et une base de code que personne ne veut toucher. Si vous utilisez WordPress, faites-le de manière délibérée : un seul constructeur, peu d’extensions et une vraie discipline de mise à jour.
Une solution sur mesure (Next.js ou similaire)
Justement lorsque vous avez besoin de logique applicative, d’une vitesse réelle ou d’un contrôle précis sur le référencement technique. Vous obtenez du HTML rendu côté serveur, un plafond de performance bien supérieur à une pile d’extensions, et une surface d’attaque réduite.
Le coût ? Une flexibilité éditoriale moindre. À moins de construire également un modèle de contenu et une interface d’administration adaptés — ce qui représente un vrai travail — chaque nouvelle page de destination devient une tâche pour les développeurs. Prévoyez ce budget, sinon vous vous retrouverez avec un site rapide que personne ne peut mettre à jour.
Le test honnête
Si votre réponse à la question « qui ajoute une nouvelle page ? » est « notre responsable marketing, chaque semaine », optez pour WordPress. Si c’est « nous ajoutons des pages deux fois par an et avons besoin d’un site rapide qui fait des choses », optez pour une solution sur mesure.
Ce qui influence réellement le classement
Mis à part la qualité du contenu, qui est primordial, les fondamentaux techniques sont peu glamour et souvent totalement absents :
- Un titre unique et une méta-description par page, dans les limites d’environ 60 et 160 caractères, rédigés pour la requête plutôt qu’en commençant par le nom de l’entreprise
- Un seul H1 par page qui décrit le contenu de la page — un nombre surprenant de sites n’en ont même pas
- Des URL canoniques, afin que le même contenu à plusieurs adresses ne se concurrence pas lui-même
- Des données structurées sous forme de graphe interconnecté : Organisation, SiteWeb, Service, FAQ, Article, Fil d’Ariane
- Des balises Open Graph et Twitter Card, sinon chaque partage sur WhatsApp ou LinkedIn s’affiche en blanc
- Un plan de site propre qui exclut les archives d’auteurs et les pages sans valeur pour le référencement
- Des liens internes suivis, organisés en grappes thématiques
Ce dernier point mérite d’être souligné, car l’avis inverse circule largement. Ne marquez pas vos liens internes comme nofollow. Le PageRank est réparti entre les liens d’une page, et la part attribuée à un lien marqué nofollow est perdue au lieu d’être redistribuée. Marquer vos propres liens comme nofollow ne préserve pas l’autorité ; il la détruit. Vous pouvez marquer comme nofollow les liens externes si vous le souhaitez — les liens internes doivent toujours être suivis.
Performance, en termes concrets
Les Core Web Vitals sont la mesure de l’expérience selon Google, mais la raison commerciale est plus simple : les sites lents perdent des demandes de contact.
Trois chiffres à imposer à votre développeur :
- Plus grand affichage de contenu sous 2,5 secondes sur un téléphone milieu de gamme en 4G — pas sur votre ordinateur de bureau
- Interaction jusqu’au prochain affichage sous 200 millisecondes
- Décalage cumulé de la mise en page sous 0,1 — rien ne doit sauter pendant le chargement de la page
La plupart des échecs proviennent de quatre causes : des images non optimisées, des polices qui bloquent le rendu, des scripts tiers (widgets de chat, gestionnaires de balises, traceurs) et du JavaScript embarqué pour des fonctionnalités que la page n’utilise pas.
Convenez d’un budget performance avant de commencer la conception. Adapter un design qui suppose quatre vidéos d’accroche pour y ajouter de la vitesse coûte bien plus cher que de concevoir dans le respect d’un budget dès le départ.
Le changement lié à l’ère de l’IA à comprendre
Quelque chose a vraiment changé, et cela impacte une décision architecturale.
Les robots d’IA — GPTBot, ClaudeBot, PerplexityBot, CCBot — récupèrent principalement du HTML brut et n’exécutent pas JavaScript. Google peut rendre JavaScript, mais le fait plus lentement et moins fiablement que le simple envoi de HTML brut.
La conséquence : une application monopage rendue côté client est presque invisible pour les systèmes qui répondent désormais aux questions de vos clients. Si vous tenez à ce que vos contenus soient cités par les assistants IA, ils doivent figurer dans la réponse HTML initiale — ce qui implique un rendu côté serveur ou une génération statique, et non une application React qui charge tout après l’affichage.
La bonne nouvelle ? Cela ne nécessite aucune nouvelle discipline. Un HTML sémantique rendu côté serveur, des données structurées précises et des informations commerciales cohérentes sont les mêmes exigences que le bon référencement a toujours recherchées.
Reconstruire ou réparer ?
Reconstruire est souvent une mauvaise réponse, et les agences ont un intérêt évident à ne pas le dire.
Réparer lorsque le contenu et la structure sont globalement corrects et que les problèmes sont techniques — temps de chargement lent, métadonnées manquantes, absence de schéma, surcharge d’extensions. Ces problèmes se corrigent à une fraction du coût d’une reconstruction, généralement en quelques semaines, sans aucun risque de migration.
Reconstruire lorsque l’architecture de l’information est vraiment erronée, que la plateforme bloque ce dont vous avez besoin, ou que la base de code est ingérable. Même dans ce cas, préservez autant d’URL indexées que possible.
Demandez à toute agence qui recommande une reconstruction quel serait le coût pour réparer le site actuel à la place. La réponse, et la facilité avec laquelle elle est donnée, en disent long.
Migration sans perdre de positions
Si vous reconstruisez, la migration est l’étape où les sites sont pénalisés. Les essentiels :
- Inventorier chaque URL indexée via Search Console et votre plan de site, avant toute chose.
- Préserver plutôt que rediriger chaque fois que possible. Conserver une URL exactement telle quelle — y compris son slash final — ne présente aucun risque. Une redirection 301 transmet la plupart des signaux, mais la plupart n’est pas tout.
- Lorsqu’une redirection est inévitable, la rendre directe. Les chaînes de redirections diluent et gaspillent le budget de crawl.
- Transférer les titres, descriptions et données structurées. Les améliorer est acceptable ; les perdre ne l’est pas.
- Ne pas lancer un site plus lent que l’ancien. Benchmarker avant et après.
- Surveiller Search Console quotidiennement pendant le premier mois, afin que les erreurs de couverture soient détectées en jours, et non en trimestres.
Prévoyez une à deux semaines de fluctuations mineures. Une migration bien exécutée ne produit pas de chute brutale.
Ce qu’il faut exiger
- Prix fixe pour un périmètre écrit
- Propriété intégrale du code, incluant le dépôt
- Un budget performance convenu avant la conception
- Chaque URL indexée comptabilisée par écrit
- Données structurées sur chaque modèle de page
- Formation pour que votre équipe puisse publier sans vous
Prochaines étapes
Si vous hésitez entre corriger ce que vous avez et repartir de zéro, cela mérite un échange plutôt qu’un devis. Nous sommes prêts à vous dire que l’option la moins chère est la bonne, et nous le faisons souvent.
Questions fréquentes
WordPress est généralement adapté lorsque votre équipe publie fréquemment et a besoin d'un contrôle éditorial complet sans intervention d'un développeur. Un développement sur mesure en Next.js est préférable si vous avez besoin de vitesse, de logique applicative ou d'un contrôle strict du SEO technique. La question décisive est la fréquence à laquelle des non-techniciens doivent modifier des éléments.
Uniquement si la migration est mal gérée. Le référencement est perdu lorsque les URL changent sans redirections, que les métadonnées ne sont pas conservées ou que le nouveau site est plus lent. La méthode la plus sûre consiste à préserver chaque URL déjà indexée à l'identique — même chemin, réponse 200, sans redirection — car une URL déjà bien classée n'a rien à gagner à être déplacée.
Un site marketing ciblé avec quelques modèles commence à partir de £4,500. Un site plus important avec un modèle de contenu personnalisé et des dizaines de pages se situe généralement entre £9,000 et £25,000. Les applications web avec comptes et intégrations font l'objet d'un devis après une phase payante de découverte.
Parce que les robots d'IA comme GPTBot, ClaudeBot et PerplexityBot récupèrent le HTML brut et n'exécutent généralement pas JavaScript. Une application monopage rendue côté client est presque invisible pour eux. Si vous souhaitez être cité par les assistants IA ainsi que bien classé par Google, votre contenu doit figurer dans la réponse HTML initiale.
- développement web
- WordPress
- Next.js
- SEO
- performance