Création de site SEO-ready — WordPress, Webflow, Next.js
Soixante pour cent des refontes que j’accompagne auraient pu être évitées. Pas entièrement — un site a une durée de vie — mais la plupart étaient rendues nécessaires par des choix initiaux que personne n’avait anticipés : une architecture d’URL impossible à faire évoluer, des thèmes qui accumulent la dette technique, des métadonnées jamais configurées, une structure de contenu qui oblige Google à deviner ce que le site propose. Quand on construit un site correctement dès le départ, ces problèmes n’existent pas.
Ce que j’appelle un site « SEO-ready », ce n’est pas un site avec un plugin SEO installé. C’est un site dont l’architecture, la performance et les signaux techniques ont été pensés avant même d’écrire la première ligne de contenu. Le référencement n’est pas une couche ajoutée après coup — c’est une contrainte de conception, au même titre que l’accessibilité ou la vitesse.
Cette page décrit comment je travaille sur ce type de mission au Maroc : quelles technologies je recommande, ce que « SEO baked in » veut dire concrètement, ce que je ne fais pas, et à quoi ressemble mon process étape par étape.
Trois stacks que je recommande selon le besoin
Il n’existe pas de stack universelle. Le bon choix dépend du profil de l’équipe qui va maintenir le site, du volume de contenu prévu, et du niveau de performance attendu. Voici les trois options que je propose selon les cas.
WordPress
WordPress reste la solution la plus polyvalente pour les équipes sans profil technique. Un éditeur marketing peut gérer le contenu sans intervention d’un développeur, la documentation est abondante, et l’écosystème de plugins couvre la plupart des besoins courants. Je l’utilise pour les sites institutionnels, les agences, les cabinets professionnels, et les projets dont le volume de contenu va croître sur le temps sans que l’équipe technique suive forcément ce rythme.
Ma configuration WordPress standard exclut les constructeurs de pages visuels lourds — Elementor ou Divi — qui alourdissent le DOM et nuisent aux Core Web Vitals. Je travaille avec le FSE (Full Site Editing) de WordPress ou des thèmes légers sur mesure, selon le budget.
Webflow
Webflow est taillé pour les sites vitrines premium où le design compte autant que le référencement. Un designer peut y travailler directement sans coder, le rendu est propre, et les performances sont généralement bonnes par défaut. Je le recommande pour les portefeuilles, les sites d’architectes ou de studios créatifs, et les landing pages à forte intention commerciale où la présentation visuelle influence directement la conversion.
Ses limites sont réelles : le CMS Webflow est moins flexible que WordPress sur des structures de contenu complexes, et l’exportabilité du code est contraignante. C’est un choix assumé pour un périmètre défini.
Next.js + headless
Pour les projets à forte exigence de performance — plateformes e-commerce, SaaS, applications éditoriales à grand volume — Next.js avec un CMS headless (Contentful, Sanity, ou WordPress en mode API) offre les meilleures garanties techniques. Le rendu hybride (SSG + ISR) permet d’atteindre des scores Lighthouse proches de 100 sur les pages statiques, ce qu’un WordPress standard ne peut pas égaler.
Ce choix suppose une équipe technique capable de maintenir l’infrastructure. Si ce n’est pas le cas, je déconseille cette stack : la complexité opérationnelle l’emporte sur le gain de performance.
Le SEO baked in — qu’est-ce que ça veut dire concrètement
« SEO intégré » est une formule que tout le monde utilise. Voici ce qu’elle recouvre dans ma façon de travailler.
Architecture URL pensée d’avance
La structure d’URL d’un site est l’un des rares éléments qu’on ne peut pas changer sans conséquences après coup. Si vous décidez dans deux ans que votre blog doit passer de /blog/article-titre/ à /ressources/article-titre/, vous gérez des centaines de redirections, des pertes de liens entrants, et des délais d’indexation. Si cette décision est prise avant le build, elle coûte zéro.
Je conçois l’arborescence d’URL en parallèle du wireframe, pas après. Chaque section est associée à une intention de recherche et à un niveau de maillage interne avant que le développement commence.
Performance Core Web Vitals dès le build
LCP, INP, CLS — ces trois métriques influencent directement le positionnement depuis 2021 pour les deux premières, et depuis 2024 pour INP. Les corriger sur un site existant coûte souvent plus cher que de les avoir intégrées dès le build : il faut défaire des choix d’implémentation que le site a accumulés.
Mon processus inclut systématiquement : optimisation des images (formats WebP/AVIF, lazy loading natif, dimensions explicites), chargement différé des scripts tiers, configuration du cache HTTP, et suppression des ressources bloquantes au rendu. Ces points sont vérifiés via PageSpeed Insights et le rapport CrUX avant le lancement.
Schema.org natif sur tous les types de pages
Les données structurées ne servent pas uniquement à activer les rich snippets dans Google. Elles alimentent aussi les réponses des moteurs IA — ChatGPT, Perplexity, Gemini — qui lisent le JSON-LD pour qualifier l’entité derrière le site. Un schéma Organization bien renseigné avec sameAs pointant vers les profils vérifiés, un schéma LocalBusiness avec les horaires et l’adresse, des schémas Article ou Product sur les pages concernées : tout cela est configuré et testé avant le lancement.
Préparation GEO — llms.txt et structured data IA
Les moteurs de recherche génératifs explorent les sites différemment des crawlers traditionnels. Un fichier llms.txt bien structuré — analogue au robots.txt mais conçu pour les LLM — indique quelles pages sont prioritaires pour la compréhension de l’entité. Je configure également les balises og: et les métadonnées qui alimentent les aperçus dans les réponses IA, pour que le site soit correctement représenté dans ces environnements dès le premier jour.
Sitemap, robots.txt, IndexNow configurés
Ce sont des fondations que l’on oublie souvent, jusqu’au moment où Google indexe les mauvaises pages ou ignore celles qui importent. Le sitemap XML liste uniquement les pages indexables — pas les pages de remerciement, les archives de tags vides, ou les variantes de paramètres. Le robots.txt bloque ce qui ne doit pas être crawlé sans bloquer ce qui doit l’être. IndexNow est configuré pour notifier Bing et les moteurs compatibles à chaque publication, sans délai d’attente passif.
Ce que je ne fais pas
Je préfère être clair sur ce point plutôt que de laisser des ambiguïtés créer des attentes non satisfaites.
Je ne fais pas de design from scratch. Je suis consultant SEO et architecte technique — pas designer graphique. Sur les projets qui nécessitent une identité visuelle élaborée, je collabore avec un designer partenaire de confiance. Le brief design inclut mes contraintes techniques et SEO, ce qui évite les frictions habituelles entre les deux disciplines. Si vous avez déjà un designer, je travaille directement avec lui.
Je ne fais pas de développement custom complexe. Des fonctionnalités spécifiques — configurateur de produit, API tierce complexe, moteur de recherche interne avancé — nécessitent un développeur dédié. Je peux cadrer la partie fonctionnelle et assurer la liaison entre le développeur et les exigences SEO, mais je ne code pas ces blocs moi-même. Ce périmètre est discuté et acté avant le début de la mission, pour éviter les surprises de budget.
Mon process — 6 phases
Voici comment se déroule une mission de création de site SEO-ready, de la première réunion au suivi post-lancement.
Phase 1 — Brief et wireframe SEO-first (1 semaine)
La première semaine est entièrement consacrée à la compréhension du besoin et à la traduction en architecture. Je recueille le brief métier, j’analyse la concurrence organique sur les requêtes cibles, et je construis le wireframe SEO-first : une maquette fonctionnelle basse fidélité qui décrit l’arborescence, les niveaux de pages, les modules de contenu par gabarit, et les zones de maillage interne. Ce livrable est discuté et validé avant de passer à la phase design.
Phase 2 — Design (avec partenaire, 2 à 3 semaines)
Le designer travaille sur la base du wireframe validé. Je reste disponible pour répondre aux questions techniques — « cette animation CSS va générer du CLS ? », « peut-on charger cette police en variable font ? » — et je valide les maquettes finales avant le passage en développement. Cette validation porte sur la compatibilité avec les contraintes de performance et d’accessibilité, pas sur les choix esthétiques.
Phase 3 — Build technique SEO-ready (2 à 4 semaines)
Le développement suit les spécifications issues des phases 1 et 2. Je configure l’environnement technique : hébergement, CDN, configuration SSL, cache, balises meta par gabarit de page, données structurées, sitemap dynamique, robots.txt, IndexNow, redirections héritées si le site remplace un site existant. Chaque gabarit de page est testé sur PageSpeed avant d’être considéré comme terminé.
Phase 4 — Contenu (parallèle, 2 à 4 semaines)
La production de contenu peut démarrer en parallèle du build dès que les gabarits de page sont stabilisés. Je rédige ou supervise le contenu des pages prioritaires — services, pages d’atterrissage, page d’accueil — en suivant la stratégie de mots-clés définie en phase 1. Si vous disposez d’une équipe de rédaction interne, je fournis les briefs de contenu avec les requêtes cibles, la structure attendue et le nombre de mots.
Phase 5 — Recette et audit pré-lancement (1 semaine)
Avant de pointer le nom de domaine vers le nouveau site, je réalise un audit complet du site en préproduction : vérification de toutes les balises meta, test de chargement sur mobile et desktop, validation du sitemap et des données structurées via les outils Google, contrôle des redirections si migration, et test de toutes les interactions critiques. Le site ne lance pas si un point bloquant reste ouvert.
Phase 6 — Lancement et monitoring 90 jours
Le jour du lancement est planifié en début de semaine pour disposer de trois jours ouvrables consécutifs de surveillance. Je monitore Google Search Console pour les premières erreurs d’indexation, je vérifie que les pages prioritaires sont crawlées dans les 48 heures, et je surveille les Core Web Vitals terrain via le rapport CrUX. Pendant les 90 jours qui suivent, je reste disponible pour corriger les ajustements post-lancement et accompagner les premières publications de contenu.
Tarification — fourchettes
Je publie des fourchettes plutôt que de renvoyer systématiquement vers un formulaire de devis. Le prix final dépend du volume de pages, de la stack choisie, et du niveau de collaboration avec un designer ou un développeur externe.
- Site vitrine (5 à 15 pages, WordPress ou Webflow) — entre 12 000 et 25 000 MAD selon le volume de contenu et la complexité du design
- Site e-commerce (WooCommerce ou Shopify headless) — entre 25 000 et 55 000 MAD selon le catalogue, les flux et les intégrations tierces
- Plateforme ou SaaS (Next.js headless) — à partir de 50 000 MAD, devis sur mesure après cadrage technique
Ces fourchettes incluent mon travail d’architecture SEO, de configuration technique et de supervision du build. Le design et le développement frontend sont facturés séparément par les partenaires concernés, ou intégrés si vous disposez déjà de ces ressources en interne.
Si le projet est commandé dans le cadre d’un accompagnement SEO mensuel, la phase d’audit pré-lancement est incluse sans supplément.
Quand préférer une refonte plutôt qu’un site neuf
Un site neuf n’est pas toujours la bonne réponse. Si votre site existant a accumulé du capital SEO — backlinks, ancienneté du domaine, pages déjà bien positionnées — le reconstruire de zéro signifie repartir de cette base, ce qui a un coût en temps et en positionnement.
Je recommande une création plutôt qu’une refonte dans trois cas : le domaine est nouveau, le site existant est techniquement irréparable (dette technique trop profonde pour une rénovation), ou l’architecture actuelle est si mal conçue qu’une restructuration partielle ne suffirait pas. Dans tous les autres cas, une refonte SEO pilotée est souvent plus efficiente — elle préserve l’acquis tout en corrigeant les problèmes structurels.
Si vous hésitez entre les deux options, la réponse commence par un audit technique du site existant. L’audit révèle si la base est récupérable ou si reconstruire est la décision rationnelle. Si votre projet implique de déplacer un site d’une plateforme à une autre, consultez également ma page sur la migration SEO — le process diffère sensiblement d’une création pure.
Votre projet vous semble correspondre à ce cadre ? Décrivez-moi la situation sur WhatsApp — je réponds aux messages sérieux sous 24 heures et je peux faire un premier retour sur la faisabilité avant toute démarche commerciale.