Un créateur de sites en marque blanche est-il bon pour le SEO de vos clients ? Le test en 12 points à faire avant de vous engager
Qu'un créateur en marque blanche soit bon pour le SEO dépend de ce qu'il publie, pas de ce que dit sa page de fonctionnalités. Voici un test en 12 points que les agences peuvent mener sur un site d'essai en un après-midi : HTML explorable, titres, sitemaps, redirections, vitesse, données structurées et plus encore.
Un créateur en marque blanche peut tout à fait convenir au SEO de vos clients, mais testez-le plutôt que de vous fier à la liste des fonctionnalités. Ce qui compte, c'est ce que la plateforme sert réellement à un moteur de recherche : du vrai HTML contenant le contenu, un titre et une description uniques par page, un sitemap, des redirections permanentes que vous maîtrisez, des pages rapides sur téléphone et des URL propres sur le domaine du client. Vous pouvez tout vérifier sur un site d'essai en un après-midi avec des outils gratuits. Si une plateforme échoue aux trois premiers tests ci-dessous, aucun effort SEO de votre équipe ne compensera pleinement.
Pourquoi « dispose d'outils SEO » n'est pas une réponse
Presque tous les créateurs annoncent des « outils SEO » sur leur page de tarifs. Cela désigne généralement un formulaire pour les titres et descriptions de page. Utile, mais c'est la partie facile. Ce qui détermine si le site d'un client peut se positionner est structurel, et ne se voit qu'en examinant ce que publie la plateforme. Créez un site d'essai réaliste (accueil, trois pages de services, une page de contact, un article de blog) sur son propre domaine de test, publiez-le et faites les tests ci-dessous.
Le test en 12 points
| # | Test | Comment vérifier | Réussite |
|---|---|---|---|
| 1 | Le contenu est dans le HTML | Ouvrez « afficher le code source » (pas l'inspecteur) sur une page de service et cherchez une phrase de la page | La phrase figure dans le HTML brut |
| 2 | Titre et description uniques par page | Affichez le code source de trois pages ; comparez les balises title et meta description | Chaque page a les siens, modifiables page par page |
| 3 | Sitemap et fichier robots | Ouvrez /sitemap.xml et /robots.txt sur le domaine publié | Les deux existent, le sitemap liste chaque page sur le vrai domaine, robots.txt ne bloque pas le site |
| 4 | De vrais liens entre les pages | Dans le code source, vérifiez que la navigation utilise des liens d'ancrage classiques avec des adresses href | Les liens sont des balises d'ancrage explorables, pas des gestionnaires de clic |
| 5 | Des URL propres et modifiables | Regardez l'adresse de chaque page | Des chemins lisibles que vous pouvez définir, comme /services/roof-repair |
| 6 | Redirections permanentes | Créez une redirection depuis un ancien chemin ; vérifiez-la avec un outil de contrôle des en-têtes | Renvoie 301 ou 308, et non une page qui vous déplace par script |
| 7 | Les pages manquantes renvoient 404 | Visitez un chemin inventé | Un statut 404, pas la page d'accueil avec un statut 200 |
| 8 | Domaine personnalisé en HTTPS | Connectez un domaine de test | Le site est servi sur le domaine avec un certificat valide ; les autres adresses y redirigent |
| 9 | Titres et texte alternatif des images | Vérifiez la structure des titres d'une page et les attributs alt des images | Un seul titre principal ; les images ont un texte alternatif modifiable |
| 10 | Données structurées | Lancez le test des résultats enrichis de Google sur la page d'accueil | Des données valides d'organisation ou d'entreprise locale, ou un moyen de les ajouter |
| 11 | Vitesse sur téléphone | Lancez PageSpeed Insights en mode mobile | De bons scores en laboratoire ; une fois le site fréquenté, des données terrain dans les seuils de Google |
| 12 | Aucune fuite de la plateforme | Cherchez le nom du fournisseur dans le code source et vérifiez les balises canonical | La balise canonical pointe vers le domaine du client ; aucun lien du fournisseur injecté |
Les tests les plus importants, expliqués
1. Le contenu est-il dans le HTML ?
Beaucoup de créateurs modernes produisent des applications JavaScript. Google sait exécuter le JavaScript, mais sa propre documentation indique que les pages attendent dans une file de rendu qui peut prendre plus de quelques secondes, et elle qualifie toujours le rendu côté serveur ou le prérendu de « très bonne idée », car il rend les sites plus rapides pour les utilisateurs comme pour les robots, et parce que tous les robots ne savent pas exécuter le JavaScript. Ce dernier point compte davantage chaque année : de nombreux robots de recherche IA et de réseaux sociaux ne lisent que le HTML brut. Si le code source affiche un conteneur vide et une balise script, la plateforme compte sur chaque robot pour exécuter son code.
3. Un sitemap sur le vrai domaine
Les plateformes en marque blanche servent souvent chaque site sur plusieurs adresses : un sous-domaine de la plateforme, un lien d'aperçu et le domaine du client. Le sitemap doit lister le domaine du client, et les autres adresses ne doivent pas lui faire concurrence. Vérifiez aussi la balise canonical de chaque page (test 12).
6. Des redirections que vous maîtrisez
Les agences refondent et déplacent des sites. Pour un changement d'adresse, Google recommande des redirections permanentes côté serveur, 301 ou 308, à conserver au moins un an. Une plateforme sans vraies redirections fait de chaque refonte un risque SEO. Consultez notre plan de migration pour voir la place des redirections dans un déménagement de site.
7. De vraies 404
Une plateforme qui répond à toute adresse inconnue par la page d'accueil et un statut 200 crée des « soft 404 » que Search Console signalera, et vous cache les liens cassés.
11. Seuils de vitesse
Les Core Web Vitals de Google, tels que décrits sur web.dev, fixent le niveau « bon » à un Largest Contentful Paint de 2.5 secondes ou moins, un Interaction to Next Paint de 200 millisecondes ou moins et un Cumulative Layout Shift de 0.1 ou moins, mesurés au 75th percentile des chargements de page. Un site d'essai n'aura pas encore de données terrain : utilisez donc les tests en laboratoire pour comparer les plateformes, puis surveillez les données terrain une fois les vrais clients en ligne.
Ce que la plateforme ne peut pas faire pour vous
Soyez juste envers la plateforme aussi. Même un créateur parfait ne fait pas ce qui suit, et c'est ce qui décide l'essentiel du classement des entreprises locales :
- Un contenu utile et original pour chaque service et chaque zone proposés par le client.
- Une fiche Google Business Profile complète et exacte.
- Des avis et de vrais liens locaux.
- Un maillage interne cohérent entre pages liées.
Nos guides sur le SEO des petites entreprises et la conception de sites optimisés pour le SEO couvrent cet aspect.
Une grille de notation pour comparer les plateformes
| Test | Pondération | Plateforme A | Plateforme B |
|---|---|---|---|
| 1. Contenu dans le HTML | 3 | ||
| 2. Titres et descriptions | 2 | ||
| 3. Sitemap et robots | 2 | ||
| 4. Liens explorables | 2 | ||
| 5. URL propres | 1 | ||
| 6. Redirections permanentes | 2 | ||
| 7. Vraies 404 | 1 | ||
| 8. Domaine et HTTPS | 2 | ||
| 9. Titres et texte alternatif | 1 | ||
| 10. Données structurées | 1 | ||
| 11. Vitesse mobile | 2 | ||
| 12. Aucune fuite | 1 |
Notez chaque test 0 (échec), 1 (partiel) ou 2 (réussi) et multipliez par la pondération. Une plateforme qui obtient 0 au test 1 devrait avoir une très bonne raison de figurer dans votre sélection.
Comment We.Inc s'en charge
Nous préférons que vous nous testiez plutôt que de nous croire sur parole ; voici donc ce qu'il faut regarder. Lorsqu'un site We.Inc est publié, ses pages sont prérendues : le contenu se trouve dans le HTML que reçoit un robot. La publication enregistre aussi la liste des pages, de sorte que le sitemap.xml et le robots.txt du site sont générés sur l'adresse depuis laquelle il est servi, y compris le domaine du client. Les redirections enregistrées sont publiées avec le site.
Dans l'éditeur, les réglages SEO ont leur propre panneau, à côté des autres outils du site.
Les agences choisissent client par client si celui-ci peut modifier les réglages SEO, pour qu'un client ne puisse pas réécrire par mégarde les titres que vous avez optimisés.
Et le site de chaque client fonctionne sur son propre domaine.
Les résultats dépendent toujours du contenu et du marché du client, et nous ne promettons aucun classement. Pour mener le test en 12 points sur un vrai site We.Inc, réservez une démo.
Sources
Dernière vérification le 2026-10-25.
- Google Search Central, Comprendre les principes de base du SEO JavaScript (file de rendu ; le prérendu reste une bonne idée).
- web.dev, Web Vitals (seuils LCP, INP et CLS au 75th percentile).
- Google Search Central, Déplacer un site avec changement d'URL (redirections 301/308, à conserver au moins un an).
Questions fréquentes
Un créateur de sites en marque blanche est-il mauvais pour le SEO ?
Pas en soi. Tout dépend de ce que publie la plateforme : contenu dans le HTML, titres modifiables, sitemap sur le domaine du client, vraies redirections et vraies 404, et pages mobiles rapides. Testez un site d'essai avant de vous engager.
Comment vérifier que les pages d'un créateur sont explorables ?
Affichez le code source d'une page publiée (pas l'inspecteur du navigateur) et cherchez-y une phrase de la page. Si elle figure dans le HTML brut, les robots peuvent la lire sans exécuter de scripts.
Quels scores Core Web Vitals un site client doit-il atteindre ?
Un Largest Contentful Paint de 2.5 secondes ou moins, un Interaction to Next Paint de 200 millisecondes ou moins et un Cumulative Layout Shift de 0.1 ou moins, au 75th percentile des chargements de page.
We.Inc prérend-il les pages publiées ?
Oui. Les pages publiées sont prérendues, et le sitemap ainsi que le fichier robots sont générés pour l'adresse depuis laquelle le site est servi. Nous ne promettons aucun classement.
Commencer gratuitement · Sans carte bancaire
Voir aussi: Guides
- Exemples de pages de remerciement
- TOML vs YAML
- Trop de redirections
- Classes TypeScript
- Types de données TypeScript
- Les enums TypeScript et leurs alternatives
- Interfaces TypeScript
- Les boucles en TypeScript et les types qu'elles donnent
Produit
Pour qui
- Pour les agences
- Pour les indépendants
- Pour les hébergeurs
- Pour les plateformes SaaS
- Pour les startups
- Services financiers
- Solutions pour la santé
Fonctionnalités
- Éditeur visuel
- SEO et analyses
- Image de marque personnalisée
- Tableau de bord client
- Facturation revendeur
Ressources
- Blog
- Centre d'aide
- Outils gratuits pour les entreprises
- Free UI Components
- Modèles
- Collections de modèles
- Exemples de sites
- Guides
- Comparatifs
- Alternatives
- Les meilleurs
- Avis
- Guides des tarifs
- Cas d'usage
- Glossaire et guides
- Intégrations
- Développeurs
- Benchmark
- Windows App