SEO Technique pour Sites Industriels : Ce que nous voyons, ce que nous croyons, ce qui fonctionne

Introduction

Chez Portocarrero, nous travaillons principalement avec des sites web industriels B2B. Catalogues techniques, fiches produits avec spécifications, secteurs avec réglementations spécifiques. Et il y a quelque chose que nous voyons encore et encore : le SEO technique est traité comme une checklist de plugins au lieu d'une décision architecturale.

Notre position est claire : sans architecture propre, aucun SEO ne vous sauvera. Vous pouvez installer Yoast, RankMath ou ce que vous voulez. Si votre site fait 45 requêtes SQL par page, si vos URLs sont un chaos de paramètres, si vous n'avez pas de schema.org standard... aucun plugin ne vous sauvera.

Cet article explique ce que nous croyons sur le SEO technique industriel, ce que nous voyons sur les sites que nous analysons, et ce qui fonctionne quand nous l'implémentons. Avec du code PHP réel et des métriques de projets comme ProSilicones64.

Le problème

Quand nous analysons un site web industriel pour la première fois, le schéma se répète. Que ce soit WordPress, PrestaShop ou un vieux développement sur mesure. Les problèmes sont presque toujours les mêmes :

• URLs mélangeant IDs numériques, slugs et paramètres GET sans critère
• Canonicals mal implémentés ou complètement absents
• TTFB au-dessus de 800ms parce que chaque page exécute des dizaines de requêtes
• Zéro schema.org, ou pire : schema.org mal implémenté qui confond Google
• Sitemaps monolithiques avec des milliers d'URLs sans segmentation
• Core Web Vitals dans le rouge parce que personne n'a mesuré avant le lancement

Ce que nous voyons, c'est que ces problèmes ne viennent pas d'un manque de connaissance SEO. Ils viennent d'un manque d'architecture. De sites web qui ont grandi sans plan, ajoutant plugins et correctifs jusqu'à ce que personne ne sache ce qui fait quoi.

Architecture d'URLs : si ce n'est pas prévisible, ça ne scale pas

Nous croyons que la structure d'URLs est la décision SEO la plus importante que vous puissiez prendre. Pas parce que Google le dit (ce qu'il fait), mais parce qu'une URL prévisible signifie que votre système a une logique interne. Et cette logique est ce qui permet de grandir sans chaos.

Ce que nous voyons sur les sites industriels :

/produit.php?id=847&cat=3&lang=fr
/catalog/view/847
/fr/produits/847-profile-silicone
/product-847/

/produits/
/produits/{categorie}/
/produits/{categorie}/{produit}/

# Exemples réels :
/produits/extrusion/
/produits/extrusion/profiles-silicone-ferroviaire/

Quatre URLs pour le même produit. Quatre façons d'atteindre le même contenu. Pour Google, quatre pages différentes en compétition.

Notre position : une structure hiérarchique stricte, sans exceptions.

TTFB et Core Web Vitals : le problème n'est pas le HTML, c'est la base de données

Nous voyons des sites industriels avec un TTFB de 2 secondes. Deux secondes pour que le serveur commence à répondre. Et quand nous analysons pourquoi, ce n'est presque jamais le HTML. C'est la base de données.

Un catalogue industriel typique a des produits liés à des séries, secteurs, certifications, matériaux. Chaque fiche produit peut avoir besoin de données de 5-6 tables. Sans cache, chaque visite déclenche les mêmes requêtes encore et encore.

Notre position : le cache n'est pas de l'optimisation, c'est de l'architecture de base. Si votre système n'a pas de cache dès le premier jour, il est mal conçu.

Schema.org : soit vous le faites bien, soit ne le faites pas

Nous voyons deux extrêmes. Des sites sans aucun schema.org, et des sites avec du schema.org généré par plugins qui inclut des données incorrectes ou incomplètes. Les deux sont mauvais, mais le second est pire parce qu'il confond Google.

Notre position : schema.org doit refléter des données réelles de votre base de données. Pas des templates génériques. Si votre produit a un SKU, une température maximale de fonctionnement et une certification EN 45545-2, ça doit être dans le schema.

Sitemaps : divisez et vous contrôlerez

Nous voyons des sitemaps de 15 000 URLs dans un seul fichier. Sans priorités, sans vraies dates de modification, sans segmentation. Google les traite, oui. Mais vous n'avez aucun contrôle sur ce qui est indexé en premier et ne pouvez pas diagnostiquer les problèmes par type de contenu.

Nous croyons qu'un catalogue industriel a besoin de sitemaps segmentés : produits, secteurs, processus, pages statiques. Chacun avec son propre fichier, sa propre fréquence de mise à jour, son propre suivi dans Search Console.

Hreflang : si vous avez plusieurs langues, faites-le bien ou ne le faites pas

Nous voyons des sites multilingues avec du hreflang implémenté à moitié. Seulement sur certaines pages. Ou avec des codes de langue incorrects. Ou sans x-default. Google ignore le hreflang mal implémenté, donc soit vous le faites complètement, soit vous perdez votre temps.

Notre position : hreflang sur toutes les pages, généré automatiquement depuis le système de routage, avec validation.

Conclusion

Ce que nous croyons chez Portocarrero est simple : le SEO technique n'est pas une couche qu'on ajoute à la fin. C'est une conséquence d'avoir une architecture propre. URLs prévisibles, cache dès le premier jour, schema.org avec des données réelles, sitemaps segmentés, hreflang complet.

Nous voyons des sites industriels dépenser des milliers d'euros en contenu et linkbuilding alors que leur TTFB est à 2 secondes et qu'ils ont 200 doublons dans Search Console. C'est jeter l'argent par les fenêtres.

La bonne nouvelle, c'est que corriger les fondations techniques n'est pas de la magie. C'est du code, c'est de l'architecture, ce sont des décisions correctes. Et une fois que c'est bien, le reste du SEO fonctionne.