Structurer des données JSON-LD pour le SEO technique B2B

Le JSON-LD n'est pas une case à cocher pour rassurer un audit SEO. C'est une couche de données structurées que Google, Bing et les moteurs de génération de réponses (SGE, Copilot) utilisent pour comprendre l'entité derrière votre domaine, vos produits et votre organisation. Pour une infrastructure B2B sur Next.js/Vercel, l'enjeu est double : exposer des données exactes sans dupliquer la logique métier, et le faire sans dégrader les performances de rendu.

Pourquoi JSON-LD plutôt que Microdata ou RDFa

JSON-LD s'injecte dans un bloc <script type="application/ld+json">, indépendant du DOM visible. Concrètement, ça signifie :

• Aucune pollution du HTML sémantique existant.
• Possibilité de générer le payload côté serveur à partir des mêmes données que celles qui alimentent vos composants React, sans transformation supplémentaire.
• Facilité de test unitaire : le JSON est sérialisable, comparable, versionnable en snapshot.

Microdata et RDFa imposent d'attacher les attributs directement aux balises HTML, ce qui couple la sémantique SEO à la structure visuelle. Sur un design system B2B qui évolue vite, ce couplage devient une dette technique rapidement.

Les schémas prioritaires pour un site B2B

Tous les types Schema.org n'ont pas le même retour sur investissement. Pour Securium Labs ou un éditeur B2B équivalent, l'ordre de priorité est le suivant :

1. Organization — un seul bloc, injecté globalement dans le layout racine, avec sameAs pointant vers LinkedIn, GitHub, et le registre légal si pertinent (SIREN via identifier).
2. SoftwareApplication ou Product — pour chaque page produit/offre, avec offers, aggregateRating seulement si les données sont réelles (pas de rating fictif, Google pénalise le spam de review).
3. FAQPage — uniquement si le contenu FAQ est visible sur la page rendue, pas injecté artificiellement pour gagner du rich snippet.
4. BreadcrumbList — généré automatiquement à partir du routing Next.js, jamais saisi à la main.
5. Article ou TechArticle — pour le contenu de blog technique, avec author typé comme Organization ou Person selon le cas.

Évitez LocalBusiness si vous n'avez pas de point de vente physique pertinent pour l'utilisateur — c'est un anti-pattern fréquent en B2B SaaS.

Implémentation dans Next.js App Router

Le plus fiable est de centraliser la génération du JSON-LD dans une fonction pure, testable, séparée du composant de rendu. Exemple pour une page produit :

// lib/structured-data.ts
export function buildProductSchema(product: Product) {
  return {
    '@context': 'https://schema.org',
    '@type': 'SoftwareApplication',
    name: product.name,
    applicationCategory: 'SecurityApplication',
    operatingSystem: 'Web',
    offers: {
      '@type': 'Offer',
      price: product.price,
      priceCurrency: 'EUR',
    },
  };
}

Puis injection dans le composant serveur :

export default async function ProductPage({ params }: Props) {
  const product = await getProduct(params.slug);
  const schema = buildProductSchema(product);

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
      />
      <ProductView product={product} />
    </>
  );
}

Ne générez jamais ce bloc côté client via useEffect : les moteurs qui ne rendent pas le JS différé (certains crawlers B2B, outils d'agrégation) manqueront la donnée. Sur Vercel, le