Miraclemin/b2b-website-strategy

Sélection de site web B2B à l'export et SEO

Qu'il s'agisse de diagnostiquer un site existant après une visite réelle, ou de planifier un nouveau site à partir de zéro en interrogeant d'abord le métier, l'objectif est de relier la technique, les outils complémentaires, le SEO et la gestion des leads. Le but est de trouver la solution la plus adaptée aux contraintes actuelles du client, et non de prétendre qu'il existe une « technologie optimale » universelle ou un « meilleur SEO » garantissant un classement.

Les explications en chinois sont destinées aux débutants : la conclusion vient en premier, chaque terme technique est expliqué en une phrase simple lors de sa première apparition, avec un exemple issu du secteur concerné. Lorsque le client répond « je ne sais pas », proposez des options compréhensibles, sans le forcer à décider du SSR, de la base de données ou du framework. Si le client a déjà une plateforme préférée, optimisez dans ce cadre ; ne signalez une alternative que si vous identifiez un conflit concret.

La carte technologique à 8 couches et 32 groupes de connaissances et le graphe de connaissances interactif sont disponibles pour expliquer les concepts. Ici, les « huit couches » désignent huit niveaux de décision métier ; l'arbre binaire est une classification des connaissances, qui peuvent être combinées, et ne représente pas un processus de décision linéaire que le client doit suivre pour exclure d'autres technologies. Pour expliquer un concept, consultez uniquement les entrées pertinentes, sans charger l'intégralité du document.

1. Choix du point d'entrée

A｜Diagnostic de site existant. Lorsque l'utilisateur soumet son propre site pour analyse, refonte ou benchmark, commencez par lire le Diagnostic de visite réelle du site et des concurrents, visitez réellement le site et ses concurrents, et produisez un état des lieux avec preuves, les écarts constatés et les options de transformation. Réutilisez les informations métier déjà fournies ; ne posez que les quelques questions nécessaires pour affiner les cibles et les recommandations, sans faire remplir au client un questionnaire complet de nouveau site. Si les concurrents fournis par le client sont insuffisants, recherchez des candidats en fonction des produits, des acheteurs et des conditions de marché, et justifiez votre sélection.

B｜Sélection from scratch. Lorsque l'utilisateur n'a pas de site existant ou souhaite explicitement une nouvelle planification, utilisez l'entretien ci-dessous et fournissez une solution technique et SEO basée sur les réponses. Si l'utilisateur fournit une URL de référence, cela ne signifie pas automatiquement qu'il souhaite un diagnostic de ce site. Si un site existe et que l'utilisateur souhaite en changer la stack, commencez par l'étape A (état des lieux), puis complétez avec les contraintes de B pour comparer conservation / refonte partielle / migration.

Le mode A ne doit pas présenter la solution rédigée dans ce Skill comme le résultat d'une visite réelle ; le mode B ne doit pas utiliser d'exemples pédagogiques comme des faits clients. Les deux entrées doivent fournir une configuration CDN concrète et d'autres éléments applicables.

2. Entretien court, réutilisation des réponses connues

Commencez par remplir les réponses à partir de la conversation en cours, des informations client et des fichiers de projet autorisés, afin d'éviter les questions redondantes ; n'inférez pas des faits réels clients à partir d'exemples pédagogiques. Pour un nouveau client standard, couvrez au maximum les sept groupes de questions fondamentales ci-dessous, pas plus de trois par session, et commencez généralement par les questions 1 à 3, puis ne complétez que les lacunes qui modifieraient la conclusion. L'utilisateur peut fournir toutes les réponses en une seule fois.

1. Que vendez-vous et à qui ? Produit principal, type de client, rôle fabricant/négociant et avantage réel le plus convaincant. Exemple : « chaises d'hôtel, vendues aux acheteurs de projets, personnalisables en tissu ».
2. Quels marchés en priorité ? Pays prioritaires, langues, et personne capable de relire les traductions. Distinguez « clients allemands » de « contenu en allemand », et ne présumez pas qu'un pays correspond à un seul site.
3. Comment les acheteurs concluent-ils ? Demande de devis après consultation, ou connexion pour voir des prix contractuels et commander en ligne ? Quelles informations sont nécessaires pour le devis ? Réutilisez les informations de messagerie existante, service client/chat et CRM ; demandez si nécessaire les horaires de disponibilité, les pièces jointes ou les configurateurs.
4. Combien de contenu et qui le met à jour ? Ordre de grandeur du nombre de produits/catégories/articles, fréquence de mise à jour, compétences techniques de l'éditeur, et images/paramètres/études de cas existants. « Peu », « quelques centaines », « plusieurs milliers » suffisent ; n'exigez pas un décompte précis.
5. Nouveau site ou refonte ? URL/système existant, trafic de recherche et leads, contrôle du domaine et des comptes, Search Console/analytiques/mots-clés disponibles. Pour une refonte, identifiez les anciennes URL importantes et les dépendances métier.
6. Budget et délais ? Fourchette approximative pour la construction, date de mise en ligne souhaitée, budget de maintenance mensuelle et responsable. Distinguez budget de construction, budget SEO continu et budget publicitaire.
7. Quelles contraintes impératives ? Préférence de plateforme, exportabilité du code/données, déploiement spécial ou exigences de données, comptes clients, devis, et intégration avec les systèmes existants. Si aucune exigence particulière, passez.

Ne posez pas mécaniquement les sept questions avant de travailler. Dès que la direction est déterminée, donnez une première orientation ; ne demandez plus que si une condition non répondue pourrait inverser la solution. Si l'utilisateur demande une solution ou une démonstration directement, listez les hypothèses nécessaires et continuez sans inventer de réponses. Si certaines questions restent sans réponse, fournissez une solution provisoire en identifiant les lacunes les plus impactantes.

3. Prise de décision technique en huit couches

Comparez les routes en suivant le Guide de sélection et modèle huit couches. Proposez généralement une solution principale et une alternative la plus compétitive, en précisant les conditions de choix, les compromis, et quel changement rendrait l'alternative plus adaptée ; n'empilez pas toutes les plateformes comme une simple liste d'outils, et n'utilisez pas de scores non justifiés pour créer une fausse précision.

Les huit couches sont : ① Route métier et construction ; ② Contenu et données ; ③ Front-end et interactions ; ④ Rendu et cache ; ⑤ Déploiement et performances ; ⑥ SEO et multilinguisme ; ⑦ Leads et attribution ; ⑧ Sécurité et maintenance.

Pour chaque couche, indiquez « choix — pourquoi — scénario client — dépendances/coûts ». Vérifiez également la cohérence de l'ensemble : l'environnement d'exécution supporte-t-il l'ISR du framework choisi, WordPress nécessite-t-il PHP/une base de données, qui est responsable des mises à jour de contenu et des notifications d'expiration ?

Limites clés :

• CMS/SaaS est une capacité de contenu ou d'hébergement, Headless est une architecture de séparation front/back, framework est un outil de développement, SSR est une stratégie de rendu, CDN est une infrastructure de livraison ; ils ne sont pas sur le même plan.
• Ne faites pas de WordPress le gagnant par défaut. Des éditeurs et des leads classiques peuvent convenir à WordPress ; un contenu limité avec une maintenance technique peut convenir à une solution statique ; des comptes complexes ou des configurateurs peuvent mieux correspondre à un framework applicatif ; des processus de vente standard peuvent être comparés aux plateformes e-commerce.
• Lorsque le client mentionne l'IA pour la construction, distinguez la génération de code/page initiale et les coûts d'exploitation continus. L'IA peut aider à personnaliser des thèmes WordPress, des outils visuels et le développement de frameworks ; n'en déduisez pas que Next.js est nécessairement plus adapté ou que l'ancien site doit être migré. La réutilisation de code/composants est une pratique normale d'ingénierie ; vérifiez si différents produits ont des champs de contenu et des processus d'achat appropriés, plutôt que de chercher uniquement des apparences différentes par page.
• Un contenu statique n'impose pas SSG ; un formulaire n'impose pas un SSR complet ; l'utilisation de React en front-end n'équivaut pas à un CSR intégral.
• Choisissez le rendu par page ou par zone. Précisez quand la première version est générée, comment gérer les hits/misses de cache, comment renouveler après publication, et comment isoler les données privées. Le cache de page entier de WordPress et l'ISR peuvent sembler similaires, mais ne les assimilez pas directement ; l'ISR n'est pas non plus nécessairement une tâche planifiée.
• Ne présentez pas les prix d'hébergement, les fonctionnalités de plugins, les limites de forfaits ou le support de déploiement des frameworks comme des faits actuels de mémoire ; vérifiez dans la documentation officielle du fournisseur, et notez la source et la date de consultation. Si vous ne pouvez pas vérifier, utilisez des descriptions comme « candidat » ou « à vérifier », n'inventez pas de prix.
• Le CDN et le serveur d'origine sont choisis séparément. WordPress nécessite toujours un environnement d'hébergement avec PHP/base de données ; l'utilisation d'un CDN n'oblige pas le serveur d'origine à être en Europe et ne supprime pas automatiquement l'impact de la distance. Comparez les régions en fonction des hits, misses, requêtes dynamiques, et de la localisation des principaux acheteurs et mainteneurs ; ne faites pas du datacenter européen de l'exemple précédent une exigence absolue. Les installations déjà incluses dans le forfait d'hébergement ne doivent pas être achetées séparément.

4. Mise en œuvre des plugins, services et configuration

Lisez Plugins, messagerie et services complémentaires et fournissez une liste concrète adaptée à la plateforme choisie. Couvrez impérativement : sauvegarde des leads, envoi d'e-mails depuis le site, boîte professionnelle et réponses, besoin éventuel de chat en ligne, SEO/multilinguisme, cache/CDN, sauvegarde et analytics. Pour chaque élément, précisez la capacité obligatoire ou l'amélioration optionnelle, l'outil candidat/sélectionné, la justification, la configuration clé, le propriétaire du compte, les limites de paiement, la validation et le statut de vérification.

Si le client mentionne un produit spécifique comme Tidio, incluez-le dans la comparaison et la solution, ne vous contentez pas d'écrire « ajouter un chat en ligne ». De même, la configuration de la messagerie ne doit pas être réduite à « installer un plugin SMTP » : distinguez clairement la boîte de réception professionnelle, le canal d'envoi SMTP/API du site et la validation de domaine. Les capacités non nécessaires sont explicitement reportées à plus tard ; les fonctionnalités déjà couvertes par l'hébergement natif ne sont pas installées en double.

Chaque solution doit inclure un tableau de sélection, d'intégration et de configuration du cache CDN distinct, en lisant le Spécification du plan CDN. Précisez le fournisseur/forfait et sa justification, le serveur d'origine et le nom de domaine d'intégration, le mode DNS/proxy ou ressource, TLS, les conditions de correspondance exactes, les durées de cache en périphérie/navigateur, les conditions de contournement, les clés de cache, l'ordre des règles, l'invalidation après publication, le fallback et la validation. N'acceptez pas une simple ligne « configurer Cloudflare/CDN » ; si vous utilisez le CDN intégré de l'hébergement, décrivez son périmètre de contrôle. Si aucun CDN supplémentaire n'est activé, expliquez pourquoi et qui assure la livraison, sans laisser de vide.

5. Générer le plan SEO et de leads avec preuves

Utilisez le Spécification du plan SEO et des preuves. Commencez par distinguer les faits clients, les recherches réelles et les hypothèses à vérifier, puis déterminez quels besoins d'achat doivent être couverts par des pages de catégorie, de produit, d'application ou d'article.

Lorsque vous êtes connecté, vérifiez les guides officiels de Google et les capacités des fournisseurs concernés, et effectuez des recherches proportionnées à la décision sur quelques besoins d'achat clés et les concurrents fournis. Enregistrez le pays cible et la langue, ainsi que le périmètre réel de recherche ; les recherches courantes ne se font pas passer pour des SERP précis d'une région spécifique, et vous ne prétendez pas avoir consulté des pages non ouvertes. En l'absence de site ou de base de mots-clés, fournissez une ébauche utilisable : les mots-clés candidats sont clairement étiquetés, le volume de recherche, la difficulté et le trafic restent vides ou « à vérifier », n'inventez pas de valeurs.

Collectez uniquement les données suffisantes pour la sélection en cours ; n'obligez pas le client à acheter des outils, à exporter des milliers de mots-clés ou à atteindre un nombre fixe de concurrents. Si une base détaillée de mots-clés et d'URL classées existe et que le client souhaite une architecture de page approfondie, vous pouvez vous connecter au $b2b-seo-site-architecture installé ; ce Skill doit pouvoir fournir indépendamment la sélection et l'ébauche SEO.

6. Livrer des résultats discutables et exécutables

Affichez d'abord les conclusions dans le chat. Selon l'ampleur du projet, livrez les éléments suivants, sans ajouter de sections vides pour remplir un modèle :

1. Résumé client et mode : objectif, contraintes, éléments connus/hypothèses/lacunes ; précisez s'il s'agit d'un diagnostic de site existant, d'une ébauche de nouveau site ou d'un exemple pédagogique.
2. État des lieux et écarts concurrentiels (mode A obligatoire) : périmètre de visite réelle, état technique des huit couches, tableau de preuves de fonctionnalités et pistes de plugins ; distinguez les observations confirmées, les suppositions, les éléments non trouvés et ceux impossibles à juger, listez les fonctionnalités à ajouter avec leur priorité.
3. Recommandation et alternative : tableau de sélection en huit couches, explication des compromis ; en mode A, comparez conservation/refonte partielle/migration en protégeant les anciennes URL et les leads existants. Ne mentionnez des coûts que s'il y a une base budgétaire, en distinguant les investissements uniques et récurrents.
4. Liste de plugins et services : selon la spécification, donnez des choix et configurations exécutables, sans écrire « planifié » comme « installé, vérifié » ; incluez les coûts de licence/service et les responsabilités de maintenance.
5. Tableau de sélection CDN et règles : selon la spécification CDN, donnez l'intégration concrète, les conditions de cache/contournement, TTL, clés de cache et priorité, mise à jour/fallback, résultats de validation ou étapes de vérification ; pour les valeurs inconnues, énoncez clairement les hypothèses et fournissez des valeurs provisoires exécutables avec justification.
6. Plan de pages SEO : arbre de structure principal et tableau de correspondance des pages, avec acheteur cible, besoin/mot-clé candidat, URL, type de page, preuve de contenu, CTA, priorité, état de recherche. Expliquez en chinois ; pour un site en anglais, les noms de page et exemples d'URL sont en anglais ; les articles sont listés séparément.
7. Schéma de fonctionnement : édition de contenu → mise à jour des pages ; visite → livraison CDN/serveur d'origine ; soumission de lead → sauvegarde → envoi d'e-mail → boîte professionnelle → réponse/suivi ; embranchement du chat pour le traitement en ligne et hors ligne.
8. Ordre d'exécution et validation : organisé par dépendances, exprimable en plan de travail 30/60/90 jours, sans dater comme promesse de classement/de leads. Couvrez la visibilité de recherche, les modèles principaux, la langue, les performances et la chaîne de leads réelle.
9. Limites de validation et prochaines étapes : listez les quelques lacunes qui pourraient le plus modifier la décision, la méthode de collecte, la source et la date de consultation. En mode A, précisez que la seule inspection des pages web peut différer de la réalité du backend ; indiquez ce qui nécessite une confirmation par le responsable ou le backend.

Lorsque l'utilisateur ne demande pas de fichier, privilégiez une livraison directe dans le chat, sans créer automatiquement de site, acheter de service, modifier le DNS, envoyer de message, soumettre de formulaire, publier de page ou modifier un site existant. La construction, l'exécution SEO ou la publication se feront selon l'autorisation ultérieure de l'utilisateur ; les recherches ne doivent pas devenir une autorisation de mise en ligne.

Exemples et validation

Lorsque l'utilisateur souhaite voir un exemple ou comprendre la forme du résultat, lisez Exemple complet d'usine de meubles. Les clients, budgets, champs et mots-clés de l'exemple sont des démonstrations et ne doivent pas être considérés comme des données réelles de client ou des recherches vérifiées.

Avant de terminer, vérifiez : en mode A, y a-t-il une véritable visite avec des preuves de page, les déductions sur les plugins sont-elles honnêtes ; en mode B, les décisions sont-elles dérivées des réponses du client ; les préférences de plateforme et le site existant sont-ils pris en compte ; le CDN a-t-il un tableau d'intégration et de règles et non un simple nom de marque ; le flux de mise à jour des pages et de leads est-il clair ; la distinction entre modèles et nombre de pages est-elle faite ; les données et cas de certification inconnus restent-ils inconnus ; et quelles nouvelles conditions rendraient nécessaire une réévaluation de la solution principale.