SEO für Vercel-Websites

TL;DR: Vercel liefert dir schnellen TTFB, automatisches HTTPS und Bildoptimierung out of the box – das ist als SEO-Basis besser als bei den meisten Hosting-Plattformen. Aber es erzeugt auch Preview-Deployment-URLs, die Google indexieren kann, Edge-Caching, das veraltete Meta-Tags ausliefert, und Serverless-Cold-Starts, die Crawler ausbremsen. So konfigurierst du Vercel richtig für SEO, vermeidest typische Fallstricke, die ich ständig sehe, und nutzt das Edge-Setup für Dinge, die tatsächlich beim Ranking helfen.

Vercel leistet für SEO bereits mehr, als du denkst

Lee Robinson, VP of Developer Experience bei Vercel, hat ausführlich im Vercel-Blog beschrieben, wie ISR die Lücke zwischen statischer Generierung zur Build-Zeit und dem Rendering zur Laufzeit schließt. Er hat recht – für Websites mit tausenden Seiten bedeutet ISR, dass du dich nicht zwischen Geschwindigkeit und Aktualität entscheiden musst. Du bekommst beides.

Allerdings heißt „gute Voreinstellungen“ nicht „es ist kein Aufwand nötig“. Ich habe jede Menge Vercel-Projekte gesehen, die hervorragende Core Web Vitals haben, aber katastrophales SEO – Websites, bei denen jede Lighthouse-Kennzahl grün ist und trotzdem jede Meta Description fehlt. Die Infrastruktur ist solide. Die Konfiguration ist das, wo die Leute regelmäßig stolpern.

Spezifische SEO-Konfiguration für Vercel

Die Vercel-SEO-Fallstricke, vor denen niemand warnt

Hier werde ich etwas meinungsstark. Das sind die Probleme, die ich bei nahezu jeder Vercel-Website sehe, die wir auditieren. Keine Ausnahmen – es sind Defaults, die dich später beißen.

Ehrlich gesagt ist es verwunderlich, dass Vercel die meisten davon nicht standardmäßig abfängt.

Preview-Deployment-URLs, die indexiert werden

Letztes Jahr schrieb mir ein Kunde verwirrt. Bei ihrer Suche nach dem Markennamen wurde eine Seite unter ihre-projekt-git-feature-auth-fix-ihreteamposition.vercel.app angezeigt – statt unter ihrer echten Domain. Die URL kannten sie nicht. Niemand im Team hatte sie irgendwo geteilt – zumindest dachten sie das.

Es stellte sich heraus: Ein Entwickler hatte vor drei Monaten in einem GitHub-PR-Kommentar einen Preview-Link hinterlegt. Googlebot fand ihn über die öffentliche Indizierung von GitHub. Und weil die Preview auf einer anderen Domain identische Inhalte wie die Produktion ausliefert, musste Google entscheiden, welche Version es indexiert. Es hat falsch entschieden.

Das ist das häufigste SEO-Desaster, das ich bei Vercel sehe. Jeder Branch, den du pusht, erzeugt ein Deployment unter einer URL wie dein-projekt-git-feature-branch-deinteam.vercel.app. Jede Pull Request bekommt eine Preview. Jeder Commit auf main erzeugt ein Deployment. Diese URLs sind öffentlich, crawlbar und nur einen falsch platzierten Link davon entfernt, in Googles Index zu landen.

Die Lösung:

1. Nutze Edge Middleware (wie oben gezeigt), um X-Robots-Tag: noindex, nofollow für alle .vercel.app-Requests zu setzen.
2. Setze in deinem next.config.js die Canonical-URL dynamisch anhand der Umgebung.
3. Setze NEXT_PUBLIC_SITE_URL als Environment Variable und verwende sie in deinen Metadaten – die Domain nie hart codieren.

// app/layout.tsx (oder wo auch immer du Metadaten definierst)
export const metadata = {
  metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com'),
  alternates: {
    canonical: './',
  },
};

(Warum fügt Vercel nicht einfach standardmäßig X-Robots-Tag: noindex zu Preview-Deployments hinzu? Ich habe gefragt. Keine Antwort.) Soweit ich das beurteilen kann, ist das eine bewusste Entscheidung – Preview-URLs sind praktisch, um Stakeholdern etwas zu zeigen. Aber der SEO-Aufwand ist real, und die meisten Teams merken es erst, wenn sie in der Search Console vercel.app-URLs sehen. Barry Schwartz hat dieses Muster im Search Engine Roundtable aufgegriffen – dass Staging- und Preview-URLs in Googles Index „durchsickern“, ist nicht nur Vercel-spezifisch. Aber Vercels automatisches Modell „Preview pro Branch“ macht es häufiger und skaliert es stärker als jede andere Plattform.

Edge Caching liefert veraltete Meta-Tags

// 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 });
}

Du brauchst diesen Endpoint. Hier ist der Grund.

Wenn du ISR oder aggressive s-maxage-Werte nutzt, kann der Edge Cache von Vercel stunden- oder sogar tagelang veraltete Seiten mit alten Meta-Tags ausliefern. Du aktualisierst im CMS den Titel eines Blogposts, aber die gecachte Version am Edge hat weiterhin den alten Titel. Google crawlt diese gecachte Version. Die Aktualisierung deines Title-Tags wird nie registriert.

Verdrahte diesen Revalidierungs-Endpoint mit deinem CMS-Webhook. Content-Änderungen sollten sofort das Cache-Purging auslösen – nicht warten, bis der nächste ISR-Zyklus durchläuft. Nicht optional.

Letzten Monat habe ich zwei Stunden herausgefunden, warum die Meta Descriptions eines Kunden nicht aktualisiert wurden. Die Lösung ist … eigentlich sollte ich dir erst den falschen Weg zeigen. Sie hatten s-maxage=604800 gesetzt – volle eine Woche Edge-Caching – ohne Revalidierungs-Webhook. Jede CMS-Änderung war für Google sieben Tage unsichtbar. Die echte Lösung war dann genau ein einziger Cache-Control-Header in vercel.json plus das Verdrahten des Webhooks oben. Zwei Stunden für genau einen Header.

Serverless Function Cold Starts

Serverless Functions von Vercel haben Cold Starts. Wenn eine Function längere Zeit nicht aufgerufen wurde, startet die erste Anfrage eine neue Instanz – das kostet 200–1000 ms zusätzliche Reaktionszeit. Und wenn Googlebot in kurzer Folge 50 Seiten anfragt und die Hälfte davon Cold Starts sind, sinkt deine Crawl-Rate.

Ich sollte hier ehrlich sein – ich habe den exakten Einfluss von Cold Starts auf das Crawl-Budget nicht mit wissenschaftlicher Strenge gemessen. In einer Google-Search-Central-Office-Hours-Session 2024 merkte John Mueller an, dass langsame Server Rankings nicht direkt verschlechtern, aber beeinflussen, wie viele Seiten Google pro Sitzung crawlt. In unseren Daten werden Seiten mit einem sub-200-ms TTFB ungefähr 40 % häufiger gecrawlt. Aber bei einer Marketing-Website mit 50 Seiten? Wahrscheinlich egal. Bei 10.000+ Seiten sieht die Sache komplett anders aus – dort addieren sich Cold Starts zu einem echten Crawl-Budget-Problem, das du in den Crawl-Statistiken in Search Console tatsächlich messen kannst.

Gegenmaßnahmen: Nutze für SSR-Seiten, wenn möglich, den edge-Runtime (nahezu keine Cold Starts), verwende ISR, um statische Seiten am Edge auszuliefern, und halte serverless Functions klein. Wirklich.

robots.txt und abschließende Slashes: zwei Fixes in einer Zeile

Beides ist peinlich einfach – deshalb fasse ich es zusammen. Beides verursacht echte Probleme. Beides dauert 60 Sekunden zur Korrektur.

robots.txt: Die meisten Vercel-Seiten liefern das gleiche robots.txt überall aus – Produktion, Preview, Entwicklung. Previews sollten sämtliches Crawling blockieren. Nutze VERCEL_ENV (von Vercel automatisch gesetzt), um zu unterscheiden:

// 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`,
  };
}

Abschließende Slashes: Wenn trailingSlash nicht gesetzt ist, lösen sowohl /about als auch /about/ dieselben Inhalte auf, ohne Redirect. Das sind zwei URLs für eine Seite. Google sieht beide. Fertig:

module.exports = {
  trailingSlash: false, // oder true — einfach eins wählen
};

Jeweils eine Zeile. Den robots.txt-Fix habe ich mir auf die harte Tour bei einer Seite eines Kunden geholt, die schon 47 Preview-URLs im Index hatte, bevor irgendjemand es bemerkt hat. Jedes Mal.

Dinge, die ich erwartet habe, dass sie Probleme werden – aber nicht

Nicht alles an Vercel-SEO ist eine Minenfelder. Ein paar Dinge, bei denen ich skeptisch war, die aber gut ausgingen:

• Client-seitiges Hydration und Indexierung. Ich dachte, Hydration-Mismatches bei Next.js würden Googlebot verwirren. Tun sie nicht. Der Google-Renderer geht inzwischen sauber mit React-Hydration um – der Content ist bereits in der initialen HTML-Response vorhanden, und genau das wird indexiert. Hydration-Fehler sind ein UX-Problem, kein SEO-Problem.
• Edge-Function-Latenz für Redirects. Ich erwartete, dass Edge-Redirects in vercel.json im Vergleich zu Nginx-Redirects relevante Latenz hinzufügen. Der Unterschied ist vernachlässigbar – unter 5 ms in jedem Test, den ich gemacht habe. Vercels Edge ist schnell genug, dass das kein Thema ist.
• ISR veralteter Content während der Regeneration. Wenn ISR beim Regenerieren im Hintergrund eine veraltete Seite ausliefert, sorgte ich mich, dass Google die veraltete Version in genau dem Moment indexiert, in dem es ungünstig ist. In der Praxis ist das „stale-while-revalidate“-Fenster kurz genug, dass es nicht ins Gewicht fällt. Google crawlt ohnehin selten genug, dass du dafür kosmisch schlechtes Timing bräuchtest.
• Vercels automatische Komprimierung. Ich habe getestet, ob die Brotli/gzip-Komprimierung von Vercel beeinflusst, wie Google HTML auswertet. Tut sie nicht. Googlebot kommt mit komprimierten Responses klar. Das war ein Nachmittag, der sich nicht wirklich gelohnt hat.

Next.js + Vercel SEO Setup (die häufigste Kombi)

Nach unserer Erfahrung laufen die allermeisten Vercel-Setups mit Next.js. Das ist die konkrete Konfiguration, die für SEO in dieser Kombi wirklich zählt.

Redirects: next.config.js vs vercel.json

Redirects kannst du an beiden Stellen definieren. Sie verhalten sich unterschiedlich:

Meine Faustregel: Nutze vercel.json für permanente URL-Migrationen (301s von alten Pfaden zu neuen Pfaden). Middleware nutzt du für bedingte Redirects, die Laufzeitlogik brauchen (geo-basiert, A/B-Tests, Authentifizierung). Redirects in next.config.js nutzt du nur, wenn du Next.js-spezifische Features wie basePath-Bewusstsein benötigst.

Wenn du tausende Redirects hast (häufig nach einer Domain-Migration), erreichst du das Limit von 1.024. In dem Fall verwende Middleware mit Redirect-Map, die du aus einer JSON-Datei lädst oder per Database-Lookup ermittelst.

Sitemap-Generierung mit ISR

Statische Sitemaps funktionieren nicht mehr sauber, wenn du ISR verwendest, weil neue Seiten zur Laufzeit generiert werden können. Du brauchst eine dynamische Sitemap, die den aktuellen Stand deines Contents abbildet.

// 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;

  // Alle veröffentlichten Seiten aus deinem CMS holen
  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,
  }));
}

// Diese Route revalidiert jede Stunde
export const revalidate = 3600;

Das revalidate = 3600 am Ende bedeutet: Vercel cached diese Sitemap am Edge für eine Stunde und regeneriert sie dann. Für Crawler bleibt deine Sitemap schnell, aber sie spiegelt neue Content-Additionen wider. Und es ist so ein Punkt, den man leicht vergisst, bis Google anfängt, Seiten zu ignorieren, die man vor drei Wochen veröffentlicht hat, weil sie nie in die Sitemap gelangt sind.

OG-Image-Generierung am Edge

Die @vercel/og-Bibliothek von Vercel generiert Open-Graph-Images on-the-fly über Edge Functions. Das ist relevant für SEO, weil OG-Images die Klickrate bei Social Shares beeinflussen – und diese indirekt wiederum dein Linkprofil.

Ich werde nicht so tun, als hätten OG-Images direkt Einfluss auf Google-Rankings. Haben sie nicht. Aber sie beeinflussen, wie sich dein Content verbreitet – und das wirkt sich auf Backlinks aus – und Backlinks wirken auf Rankings. Die Kette ist real, auch wenn das direkte Signal fehlt.

Die 20 Minuten Setup sind es wert? Ja.

Metadata-Konfiguration

Next.js auf Vercel unterstützt den metadata-Export im App Router. Nutze ihn für jede Seite:

// 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}`,
    },
  };
}

Das Canonical-Tag ist nicht verhandelbar. Jede Seite braucht eines. Es verhindert die Duplicate-Content-Probleme, die Vercel-Seiten mit mehreren Deployment-URLs heimsuchen. Und wenn du denkst „Ich ergänze die Canonicals später“ – dann wirst du es nicht. Und bis du dich erinnerst, hat Google bereits drei Versionen deiner Startseite in drei verschiedenen vercel.app-Subdomains indexiert.

Vercel vs. der Wettbewerb für SEO

Vercel ist nicht die einzige moderne Hosting-Plattform. So schneidet sie bei SEO-relevanten Features im Vergleich zu den Alternativen ab. Basierend auf unseren Daten aus Audits von Websites über alle vier Plattformen hinweg:

*Build-Zeiten variieren stark je nach Framework, Content-Volumen und Planstufe – sieh das als grobe Richtwerte.

Ungeschönt: Cloudflare Pages hat die beste reine Edge-Performance (Workers haben nahezu keine Cold Starts, und 300+ Edge-Standorte schlagen alle). Vercel hat die beste Developer Experience und Next.js-Integration. Netlify ist ein solides Mittelfeld. Traditionelles Hosting gibt dir die meiste Kontrolle, erfordert aber das umfangreichste Setup.

Für reines SEO – also Crawlability, Geschwindigkeit und Auslieferung von Content – gewinnt technisch Cloudflare Pages durch die Infrastruktur. Aber Vercel gewinnt beim Gesamt-Workflow. Das ISR-Modell, die Preview-Deployments zum Testen von SEO-Änderungen und die enge Next.js-Integration bedeuten in der Praxis weniger SEO-Fehler. Und mal ehrlich: Das ist nicht ganz fair gegenüber Vercel – Netlify hat das gleiche Problem mit der Indexierung von Preview-URLs, und Cloudflare Pages hat überhaupt kein natives ISR. Es gab Anfang/Ende 2023 einen Hacker-News-Thread zu SEO-Tradeoffs verschiedener Hosting-Plattformen, der die Abwägung gut getroffen hat: Entwickler entschieden sich weiter für Vercel wegen DX und verbrachten dann Wochen damit, SEO-Probleme zu beheben, die auf einem traditionellen Server gar nicht erst auftreten würden. Das Gras ist eben immer auf der anderen Seite grüner.

Guillermo Rauch, CEO von Vercel, spricht über die „zero-config“-Philosophie – die Idee, dass die Plattform ohne dein Nachfragen das Richtige tun soll. Für Deployment und DX stimmt das. Für SEO bleibt es eher ein Wunschbild.

Beim Kostenvergleich könnte ich mich irren. Vercels Pricing ändert sich häufig, und Enterprise-Pläne sind intransparent. Prüfe die aktuellen Preise, bevor du im großen Stil darauf setzt.

So arbeitet SEOJuice mit Vercel-Seiten

Wir haben SEOJuice gebaut, um genau die Dinge abzudecken, die Hosting-Plattformen nicht automatisch leisten – Meta-Tags, interne Links, Schema-Markup sowie wöchentliche Audits, die die exakten Fallstricke aus diesem Artikel aufdecken. Ein einziges Script-Tag in deinem <head> funktioniert mit jeder Vercel-Seite. So lautet das Versprechen. (Wenn du direkt von Google zu diesem Abschnitt gesprungen bist, verstehe ich das. Das ist der Teil, der zählt.)

FAQ

Behandelt Vercel SEO automatisch?

Nein.

Vercel kümmert sich um Infrastruktur – schnelles Hosting, HTTPS, Bildoptimierung, Edge-Auslieferung. Das ist die Basis. Aber Meta-Tags, Redirects, interne Links, Canonical-Tags, das Blockieren von Preview-URLs? Das liegt bei dir. Die Frage setzt voraus, dass „Hosting-Plattform“ und „SEO-Tool“ dasselbe sind. Sind sie nicht.

Ist Vercel für SEO besser als Netlify?

Diese Frage geht davon aus, dass die Plattform die variable Größe ist, die zählt. Das ist nicht so. Ich habe katastrophales SEO auf Vercel, Netlify und Cloudflare Pages gesehen – und hervorragendes SEO auf allen drei. Vercel hat besseres ISR und eine engere Next.js-Integration. Netlify hat planbarere Preise. Cloudflare Pages hat die schnellste Edge-Auslieferung. Aber die echten SEO-Unterschiede entstehen daraus, wie du die Plattform konfigurierst – nicht davon, welches Badge in der Hosting-Rechnung steht.

Sollte ich für Redirects vercel.json oder next.config.js verwenden?

Nutze vercel.json für permanente URL-Migrationen – sie laufen am Edge aus, bevor deine App überhaupt startet, was schneller ist. Nutze Next.js Middleware für bedingte Redirects, die Laufzeitlogik benötigen (Geo-Targeting, Authentifizierungschecks). Nutze next.config.js nur dann, wenn du Next.js-spezifische Routing-Features brauchst. Und teile nicht dieselben Redirects über mehrere Konfigurationsdateien auf – wähle pro Redirect-Typ eine einzige Source of Truth.

Fazit

Vercel ist 2026 eine der besten Hosting-Plattformen für SEO – nicht, weil sie dir SEO abnimmt, sondern weil sie die Infrastruktur-Hürden entfernt, die SEO auf traditionellem Hosting deutlich schwerer machen. Schnelles TTFB, automatisches HTTPS, Bildoptimierung, ISR, Preview-Deployments zum Testen. Das ist eine gute Grundlage.

Die plattform-spezifischen Fallstricke sind aber real. Und was mich frustriert: Die meisten davon sind Konfigurationslücken, die Vercel mit besseren Defaults schließen könnte – ein noindex-Header für Preview-Deployments, eine erzwungene Präferenz für abschließende Slashes beim Projekt-Setup, eine Warnung, wenn deine robots.txt in allen Umgebungen identisch ist – stattdessen optimiert die Plattform vor allem für Developer Experience und lässt SEO als Nachgedanken zurück, den man erst bemerkt, nachdem Google etwas indexiert hat, was nicht indexiert werden dürfte. Kenne die Fallstricke. Konfiguriere darum herum.

Wenn du einen Vercel-Stand betreibst und sehen willst, wie dein SEO tatsächlich aussieht, führe ein kostenloses Audit durch. Es erkennt doppelte URLs, fehlende Meta-Tags und Konfigurationslücken, die dir das Dashboard von Vercel nicht zeigt.