SEO pour les sites Vercel : configuration, pièges et bonnes pratiques

En résumé : Vercel vous offre un TTFB rapide, le HTTPS automatique et l’optimisation d’images dès le départ — c’est une meilleure base SEO que la plupart des hébergeurs. Mais la plateforme vous donne aussi des URL de déploiement en preview que Google peut indexer, un cache en edge qui sert des balises meta obsolètes et des cold starts de fonctions serverless qui ralentissent les robots d’exploration. Voici comment configurer Vercel correctement pour le SEO, éviter les pièges que je vois en permanence et exploiter l’edge pour ce qui aide réellement votre positionnement.

Vercel fait déjà plus pour votre SEO que vous ne le pensez

Lee Robinson, VP Developer Experience chez Vercel, a longuement écrit sur le blog de Vercel sur la façon dont l’ISR comble l’écart entre la génération statique au build et le rendu à l’exécution. Il a raison — pour les sites de plusieurs milliers de pages, l’ISR signifie que vous n’avez pas à choisir entre vitesse et fraîcheur. Vous obtenez les deux.

Cela dit, « bons paramètres par défaut » ne signifie pas « aucun travail requis ». J’ai vu de nombreux sites Vercel avec d’excellents Core Web Vitals et un SEO déplorable — des sites où chaque métrique Lighthouse est au vert et où chaque meta description est absente. L’infrastructure est solide. C’est la configuration qui pose problème.

Configuration SEO spécifique à Vercel

Les pièges SEO de Vercel dont personne ne vous prévient

C’est ici que je donne mon avis tranché. Ce sont les problèmes que je constate sur quasiment tous les sites Vercel que nous auditons. Ce ne sont pas des cas limites — ce sont des paramètres par défaut qui finissent par vous mordre.

Honnêtement, le fait que Vercel ne gère pas la plupart de ces points par défaut me dépasse.

Les URL de déploiement en preview indexées par Google

L’année dernière, un client m’a écrit, perplexe. Sa recherche de marque renvoyait une page sur son-projet-git-feature-auth-fix-sonequipe.vercel.app au lieu de son vrai domaine. Il n’avait jamais entendu parler de cette URL. Personne dans son équipe ne l’avait partagée — du moins c’est ce qu’ils croyaient.

Il s’est avéré qu’un développeur avait collé un lien de preview dans un commentaire de PR GitHub trois mois plus tôt. Googlebot l’avait trouvé via l’indexation publique de GitHub. Et comme la preview servait un contenu identique à la production sur un domaine différent, Google avait dû choisir lequel indexer. Il a choisi le mauvais.

C’est le désastre SEO le plus courant que je constate sur Vercel. Chaque branche que vous poussez crée un déploiement avec une URL du type votre-projet-git-feature-branch-votreequipe.vercel.app. Chaque pull request obtient une preview. Chaque commit sur main génère un déploiement. Ces URL sont publiques, explorables par les robots et à un lien mal placé de l’index de Google.

La solution :

1. Utilisez un middleware edge (montré ci-dessus) pour ajouter X-Robots-Tag: noindex, nofollow à toutes les requêtes .vercel.app.
2. Dans votre next.config.js, définissez l’URL canonique de manière dynamique en fonction de l’environnement.
3. Configurez NEXT_PUBLIC_SITE_URL comme variable d’environnement et utilisez-la dans vos métadonnées — ne codez jamais le domaine en dur.

// app/layout.tsx (ou là où vous définissez vos métadonnées)
export const metadata = {
  metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com'),
  alternates: {
    canonical: './',
  },
};

(Pourquoi Vercel n’ajoute-t-il pas simplement un X-Robots-Tag: noindex aux déploiements en preview par défaut ? J’ai posé la question. Pas de réponse.) À ma connaissance, c’est un choix délibéré — les URL de preview sont utiles pour partager avec les parties prenantes. Mais le coût SEO est réel, et la plupart des équipes ne s’en rendent compte que lorsqu’elles voient des URL vercel.app dans la Search Console. Barry Schwartz a couvert ce phénomène sur Search Engine Roundtable — les URL de staging et de preview qui se retrouvent dans l’index de Google ne sont pas propres à Vercel, mais le modèle de preview automatique par branche de Vercel provoque ce problème plus souvent et à plus grande échelle que n’importe quelle autre plateforme.

Le cache edge qui sert des balises meta obsolètes

// pages/api/revalidate.ts
export default async function handler(req, res) {
  const { path, secret } = req.query;
  if (secret !== process.env.REVALIDATION_SECRET) {
    return res.status(401).json({ message: 'Invalid secret' });
  }
  await res.revalidate(path);
  return res.json({ revalidated: true });
}

Vous avez besoin de ce endpoint. Voici pourquoi.

Si vous utilisez l’ISR ou des valeurs s-maxage agressives, le cache edge de Vercel peut servir des pages obsolètes avec des balises meta périmées pendant des heures, voire des jours. Vous mettez à jour le titre d’un article de blog dans votre CMS, mais la version en cache sur l’edge conserve l’ancien titre. Google explore la version en cache. Votre mise à jour de balise titre n’est jamais prise en compte.

Connectez ce endpoint de revalidation au webhook de votre CMS. Les modifications de contenu doivent déclencher une purge immédiate du cache, sans attendre le prochain cycle ISR. Ce n’est pas optionnel.

Le mois dernier, j’ai passé deux heures à comprendre pourquoi les meta descriptions d’un client ne se mettaient pas à jour. La correction est… en fait, je devrais d’abord vous montrer la mauvaise approche. Le client avait s-maxage=604800 — une semaine complète de cache edge — sans webhook de revalidation. Chaque modification dans le CMS restait invisible pour Google pendant sept jours. La vraie solution était un seul en-tête Cache-Control dans vercel.json et la mise en place du webhook ci-dessus. Deux heures pour un en-tête.

Les cold starts des fonctions serverless

Les fonctions serverless de Vercel subissent des cold starts. Si une fonction n’a pas été invoquée récemment, la première requête démarre une nouvelle instance — ajoutant 200 à 1 000 ms au temps de réponse. Et si Googlebot visite 50 pages en succession rapide et que la moitié provoque des cold starts, votre taux d’exploration chute.

Je dois être honnête — je n’ai pas mesuré l’impact exact des cold starts sur le crawl budget avec une rigueur scientifique. Lors d’une session Google Search Central office hours en 2024, John Mueller a noté que les serveurs lents ne nuisent pas directement au positionnement, mais qu’ils affectent le nombre de pages que Google explore par session. D’après nos données, les sites avec un TTFB inférieur à 200 ms sont explorés environ 40 % plus fréquemment. Mais pour un site marketing de 50 pages ? Probablement négligeable. Pour plus de 10 000 pages, c’est une tout autre histoire — et c’est là que les cold starts s’accumulent en un vrai problème de crawl budget mesurable dans le rapport de statistiques d’exploration de la Search Console.

Solutions : utilisez le runtime edge pour les pages SSR quand c’est possible (cold starts quasi nuls), utilisez l’ISR pour servir des pages statiques depuis l’edge et gardez vos fonctions serverless légères. Sérieusement.

robots.txt et slashs de fin : deux corrections en une ligne

Ces deux points sont d’une simplicité embarrassante, alors je les regroupe. Les deux causent de vrais problèmes. Les deux se corrigent en soixante secondes.

robots.txt : La plupart des sites Vercel servent le même robots.txt partout — production, preview, développement. Les previews devraient bloquer toute exploration. Utilisez VERCEL_ENV (défini automatiquement par Vercel) pour différencier :

// app/robots.ts (Next.js App Router)
import { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  const isProduction = process.env.VERCEL_ENV === 'production';

  if (!isProduction) {
    return {
      rules: { userAgent: '*', disallow: '/' },
    };
  }

  return {
    rules: { userAgent: '*', allow: '/' },
    sitemap: `${process.env.NEXT_PUBLIC_SITE_URL}/sitemap.xml`,
  };
}

Slashs de fin : Si trailingSlash n’est pas défini, /about et /about/ renvoient tous deux le même contenu sans redirection. Cela signifie deux URL pour une seule page. Google voit les deux. Corrigé :

module.exports = {
  trailingSlash: false, // ou true — choisissez, c’est tout
};

Une ligne chacun. J’ai appris la leçon du robots.txt à mes dépens sur le site d’un client qui avait 47 URL de preview indexées avant que quiconque ne s’en rende compte. À chaque fois.

Ce que je pensais problématique mais qui ne l’était pas

Tout n’est pas un champ de mines dans le SEO Vercel. Quelques éléments auxquels je m’étais préparé et qui se sont avérés sans danger :

• L’hydratation côté client et l’indexation. Je supposais que les erreurs d’hydratation de Next.js perturberaient Googlebot. Ce n’est pas le cas. Le moteur de rendu de Google gère désormais l’hydratation React sans problème — le contenu est présent dans la réponse HTML initiale, et c’est ce qui est indexé. Les erreurs d’hydratation sont un problème d’expérience utilisateur, pas de SEO.
• La latence des fonctions edge pour les redirections. Je m’attendais à ce que les redirections au niveau edge dans vercel.json ajoutent une latence notable par rapport aux redirections Nginx. La différence est négligeable — moins de 5 ms dans tous les tests que j’ai effectués. L’edge de Vercel est suffisamment rapide pour que ce ne soit pas un sujet.
• Le contenu obsolète de l’ISR pendant la régénération. Quand l’ISR sert une page périmée pendant qu’elle se régénère en arrière-plan, je craignais que Google indexe la version obsolète au mauvais moment. En pratique, la fenêtre stale-while-revalidate est suffisamment courte pour que cela n’ait pas d’importance. Google explore assez peu souvent pour qu’il faille un timing cosmiquement malchanceux pour que cela pose problème.
• La compression automatique de Vercel. J’ai testé si la compression Brotli/gzip de Vercel affectait la façon dont Google analyse le HTML. Ce n’est pas le cas. Googlebot gère parfaitement les réponses compressées. C’était un après-midi de perdu.

Configuration SEO Next.js + Vercel (la combinaison la plus courante)

D’après notre expérience, la grande majorité des sites hébergés sur Vercel tournent sous Next.js. Voici la configuration spécifique qui compte pour le SEO avec cette combinaison.

Redirections : next.config.js vs vercel.json

Vous pouvez définir des redirections aux deux endroits. Elles se comportent différemment :

Ma règle générale : utilisez vercel.json pour les migrations d’URL permanentes (301 depuis les anciens chemins vers les nouveaux). Utilisez le middleware pour les redirections conditionnelles nécessitant une logique à l’exécution (géolocalisation, tests A/B, authentification). N’utilisez les redirections next.config.js que lorsque vous avez besoin de fonctionnalités spécifiques à Next.js comme la prise en compte du basePath.

Pour les sites avec des milliers de redirections (courant après une migration de domaine), vous atteindrez la limite de 1 024. Dans ce cas, utilisez le middleware avec une table de redirections chargée depuis un fichier JSON ou une base de données.

Génération du sitemap avec l’ISR

Les sitemaps statiques ne fonctionnent plus avec l’ISR, car de nouvelles pages peuvent être générées à l’exécution. Vous avez besoin d’un sitemap dynamique qui reflète l’état actuel de votre contenu.

// app/sitemap.ts (Next.js App Router)
import { MetadataRoute } from 'next';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = process.env.NEXT_PUBLIC_SITE_URL;

  // Récupérer toutes les pages publiées depuis votre CMS
  const pages = await getAllPublishedPages();

  return pages.map((page) => ({
    url: `${baseUrl}${page.slug}`,
    lastModified: page.updatedAt,
    changeFrequency: page.type === 'blog' ? 'weekly' : 'monthly',
    priority: page.slug === '/' ? 1.0 : 0.8,
  }));
}

// Cette route se revalide toutes les heures
export const revalidate = 3600;

Le revalidate = 3600 en bas signifie que Vercel met ce sitemap en cache sur l’edge pendant une heure, puis le régénère. Votre sitemap reste rapide pour les robots d’exploration tout en reflétant les ajouts de contenu récents. Et c’est un de ces détails faciles à oublier jusqu’à ce que Google commence à ignorer des pages publiées trois semaines plus tôt parce qu’elles n’ont jamais été ajoutées au sitemap.

Génération d’images OG sur l’edge

La bibliothèque @vercel/og de Vercel génère des images Open Graph à la volée grâce aux fonctions edge. C’est pertinent pour le SEO car les images OG influencent le taux de clics sur les partages sociaux, ce qui affecte indirectement votre profil de backlinks.

Je ne vais pas prétendre que les images OG impactent directement le positionnement Google. Ce n’est pas le cas. Mais elles influencent la diffusion de votre contenu, ce qui influence les backlinks, ce qui influence le positionnement. La chaîne est réelle, même si le signal direct ne l’est pas.

Est-ce que ça vaut les 20 minutes d’installation ? Oui.

Configuration des métadonnées

Next.js sur Vercel prend en charge l’export metadata dans l’App Router. Utilisez-le pour chaque page :

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [`/api/og?title=${encodeURIComponent(post.title)}`],
    },
    alternates: {
      canonical: `/blog/${params.slug}`,
    },
  };
}

La balise canonique n’est pas négociable. Chaque page en a besoin. Elle empêche les problèmes de contenu dupliqué qui hantent les sites Vercel avec de multiples URL de déploiement. Et si vous pensez « j’ajouterai les canoniques plus tard » — vous ne le ferez pas, et le temps de vous en souvenir, Google aura déjà indexé trois versions de votre page d’accueil sur trois sous-domaines vercel.app différents.

Vercel face à la concurrence pour le SEO

Vercel n’est pas la seule plateforme d’hébergement moderne. Voici comment elle se positionne face aux alternatives sur les fonctionnalités pertinentes pour le SEO. Basé sur nos données issues de l’audit de sites sur les quatre plateformes :

*Les temps de build varient considérablement selon le framework, le volume de contenu et le niveau d’abonnement — considérez ces chiffres comme des ordres de grandeur.

Mon avis honnête : Cloudflare Pages offre les meilleures performances edge brutes (les Workers ont des cold starts quasi nuls, et 300+ points de présence surpassent tout le monde). Vercel offre la meilleure expérience développeur et l’intégration Next.js la plus aboutie. Netlify est un bon compromis. L’hébergement traditionnel vous donne le plus de contrôle mais demande le plus de configuration.

Pour le SEO pur — c’est-à-dire l’explorabilité, la vitesse et la diffusion du contenu — Cloudflare Pages l’emporte techniquement sur l’infrastructure. Mais Vercel l’emporte sur le workflow global. Le modèle ISR, les déploiements en preview pour tester les modifications SEO et l’intégration étroite avec Next.js signifient moins d’erreurs SEO en pratique. En fait, ce n’est pas tout à fait juste envers Vercel — Netlify a le même problème d’indexation des URL de preview, et Cloudflare Pages ne propose pas d’ISR natif du tout. Il y avait un fil Hacker News fin 2023 comparant les compromis SEO des plateformes d’hébergement qui résumait bien le dilemme : les développeurs choisissaient Vercel pour la DX puis passaient des semaines à corriger des problèmes SEO qui n’existeraient pas sur un serveur traditionnel. L’herbe est toujours plus verte ailleurs.

Guillermo Rauch, le CEO de Vercel, a évoqué la philosophie du « zero-config » — l’idée que la plateforme devrait faire ce qu’il faut sans qu’on le lui demande. Pour le déploiement et la DX, c’est vrai. Pour le SEO, ça reste un objectif.

Je pourrais me tromper sur la comparaison des coûts. La tarification de Vercel change fréquemment, et les offres entreprise sont opaques. Vérifiez les tarifs en vigueur avant de vous engager à grande échelle.

Comment SEOJuice fonctionne avec les sites Vercel

Nous avons créé SEOJuice pour gérer ce que les plateformes d’hébergement ne font pas — les balises meta, le maillage interne, le balisage schema, les audits hebdomadaires qui détectent exactement les pièges décrits dans cet article. Une seule balise script dans votre <head>, compatible avec n’importe quel site Vercel. Voilà l’argumentaire. (Si vous avez sauté directement à cette section depuis Google, je comprends. C’est la partie qui compte.)

FAQ

Vercel gère-t-il automatiquement le SEO ?

Non.

La plateforme gère l’infrastructure — hébergement rapide, HTTPS, optimisation d’images, diffusion via l’edge. C’est la fondation. Mais les balises meta, les redirections, le maillage interne, les balises canoniques, le blocage des URL de preview ? Tout est à votre charge. La question suppose que « plateforme d’hébergement » et « outil SEO » sont la même chose. Ce n’est pas le cas.

Vercel est-il meilleur que Netlify pour le SEO ?

Cette question suppose que la plateforme est la variable qui compte. Ce n’est pas le cas. J’ai vu du SEO désastreux sur Vercel, Netlify et Cloudflare Pages — et d’excellent SEO sur les trois. Vercel a un meilleur ISR et une intégration Next.js plus étroite. Netlify a une tarification plus prévisible. Cloudflare Pages a l’edge le plus rapide. Mais les vraies différences SEO viennent de la façon dont vous configurez la plateforme, pas du logo sur la facture d’hébergement.

Faut-il utiliser vercel.json ou next.config.js pour les redirections ?

Utilisez vercel.json pour les migrations d’URL permanentes — elles s’exécutent sur l’edge avant le démarrage de votre application, ce qui est plus rapide. Utilisez le middleware Next.js pour les redirections conditionnelles nécessitant une logique à l’exécution (géolocalisation, vérification d’authentification). N’utilisez next.config.js que lorsque vous avez besoin de fonctionnalités de routage spécifiques à Next.js. Et ne répartissez pas les mêmes redirections entre plusieurs fichiers de configuration — choisissez une source unique de vérité par type de redirection.

En conclusion

Vercel est l’une des meilleures plateformes d’hébergement pour le SEO en 2026 — non pas parce qu’elle fait le SEO à votre place, mais parce qu’elle supprime les obstacles d’infrastructure qui rendent le SEO plus difficile sur un hébergement traditionnel. TTFB rapide, HTTPS automatique, optimisation d’images, ISR, déploiements en preview pour les tests. C’est une bonne fondation.

Mais les pièges spécifiques à la plateforme sont réels, et ce qui me frustre, c’est que la plupart d’entre eux sont des lacunes de configuration que Vercel pourrait combler avec de meilleurs paramètres par défaut — un en-tête noindex sur les déploiements en preview, un slash de fin imposé lors de la création du projet, un avertissement quand votre robots.txt est identique entre les environnements — mais au lieu de cela, la plateforme optimise l’expérience développeur et laisse le SEO comme un détail auquel on ne pense qu’après que Google a indexé quelque chose qu’il n’aurait pas dû. Connaissez les pièges. Configurez en conséquence.

Si vous gérez un site Vercel et que vous voulez voir à quoi ressemble réellement votre SEO, lancez un audit gratuit. Il détectera les URL dupliquées, les balises meta manquantes et les lacunes de configuration que le tableau de bord Vercel ne vous montre pas.