TL;DR: Vercel geeft je snelle TTFB, automatische HTTPS en image optimization out of the box — dat is een betere SEO-basis dan de meeste hostingplatformen. Maar het geeft je ook preview deployment URL's die Google kan indexeren, edge caching die verouderde meta tags serveert, en serverless cold starts die crawlers vertragen. Hier lees je hoe je Vercel goed configureert voor SEO, de valkuilen vermijdt die ik constant tegenkom, en de edge inzet voor dingen die daadwerkelijk je rankings helpen.
Lee Robinson, VP of Developer Experience bij Vercel, heeft uitgebreid geschreven op de Vercel blog over hoe ISR de kloof overbrugt tussen build-time static generation en runtime rendering. Hij heeft gelijk — voor sites met duizenden pagina's betekent ISR dat je niet hoeft te kiezen tussen snelheid en versheid. Je krijgt allebei.
Maar "goede standaardinstellingen" betekent niet "geen werk nodig." Ik heb genoeg Vercel-sites gezien met uitstekende Core Web Vitals en verschrikkelijke SEO — sites waar elke Lighthouse-metric groen is en elke meta description ontbreekt. De infrastructuur is solide. De configuratie is waar het misgaat.
Hier wordt het persoonlijk. Dit zijn de problemen die ik bij bijna elke Vercel-site tegenkom die we auditen. Het zijn geen randgevallen — het zijn standaardinstellingen die je bijten.
Eerlijk gezegd is het verbijsterend dat Vercel de meeste hiervan niet standaard afhandelt.
Vorig jaar mailde een klant me, in verwarring. Bij het zoeken op hun merknaam verscheen een pagina op hun-project-git-feature-auth-fix-hunteam.vercel.app in plaats van hun eigenlijke domein. Ze hadden nog nooit van deze URL gehoord. Niemand in hun team had hem ergens gedeeld — althans, dat dachten ze.
Het bleek dat een developer drie maanden eerder een preview-link in een GitHub PR-comment had gedropt. Googlebot vond het via GitHub's publieke indexering. En omdat de preview identieke content serveerde als productie op een ander domein, moest Google kiezen welke te indexeren. Het koos verkeerd.
Dit is de meestvoorkomende Vercel SEO-ramp die ik tegenkom. Elke branch die je pusht creëert een deployment op een URL als jouw-project-git-feature-branch-jouwteam.vercel.app. Elk pull request krijgt een preview. Elke commit naar main krijgt een deployment. Deze URL's zijn openbaar, crawlbaar, en één verkeerd geplaatste link verwijderd van Google's index.
De oplossing:
X-Robots-Tag: noindex, nofollow toe te voegen aan alle .vercel.app-verzoeken.next.config.js de canonical URL dynamisch in op basis van de omgeving.NEXT_PUBLIC_SITE_URL in als environment variable en gebruik het in je metadata — hardcode nooit het domein.// app/layout.tsx (of waar je metadata definieert)
export const metadata = {
metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com'),
alternates: {
canonical: './',
},
};(Waarom voegt Vercel niet standaard X-Robots-Tag: noindex toe aan preview deployments? Ik heb het gevraagd. Geen antwoord.) Voor zover ik kan nagaan is dit een bewuste keuze — preview URL's zijn handig om te delen met stakeholders. Maar de SEO-kosten zijn reëel, en de meeste teams realiseren het zich pas als ze vercel.app-URL's in Search Console zien staan. Barry Schwartz heeft dit patroon behandeld op Search Engine Roundtable — staging- en preview-URL's die in Google's index lekken is niet uniek voor Vercel, maar Vercel's automatische-preview-per-branch model zorgt ervoor dat het vaker en op grotere schaal gebeurt dan op welk ander platform dan ook.
// 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 });
}Je hebt dat endpoint nodig. Dit is waarom.
Als je ISR of agressieve s-maxage-waarden gebruikt, kan Vercel's edge cache verouderde pagina's met achterhaalde meta tags serveren, urenlang of zelfs dagenlang. Je past de titel van een blogpost aan in je CMS, maar de gecachte versie op de edge heeft nog steeds de oude titel. Google crawlt de gecachte versie. Je title tag-update wordt nooit opgepikt.
Koppel dat revalidation-endpoint aan je CMS-webhook. Contentwijzigingen moeten directe cache-purging triggeren, niet wachten op de volgende ISR-cyclus. Niet optioneel.
Vorige maand heb ik twee uur besteed aan het uitzoeken waarom de meta descriptions van een klant niet bijwerkten. De oplossing is... eigenlijk moet ik je eerst de foute manier laten zien. Ze hadden s-maxage=604800 — een volle week edge caching — zonder revalidation webhook. Elke CMS-wijziging was zeven dagen onzichtbaar voor Google. De daadwerkelijke fix was één Cache-Control header in vercel.json en het aansluiten van bovenstaande webhook. Twee uur voor één header.
Vercel's serverless functions hebben cold starts. Als een functie recentelijk niet is aangeroepen, moet bij het eerste verzoek een nieuw exemplaar opgestart worden — dat voegt 200-1000ms toe aan de responstijd. En als Googlebot 50 pagina's snel achter elkaar opvraagt en de helft daarvan cold starts zijn, daalt je crawlsnelheid.
Ik moet eerlijk zijn — ik heb de exacte impact van cold starts op crawl budget niet met wetenschappelijke nauwkeurigheid gemeten. In een 2024 Google Search Central office hours-sessie merkte John Mueller op dat trage servers rankings niet direct schaden, maar wel beïnvloeden hoeveel pagina's Google per sessie crawlt. In onze data worden sites met TTFB onder 200ms ongeveer 40% vaker gecrawld. Maar voor een marketingsite van 50 pagina's? Waarschijnlijk irrelevant. Voor 10.000+ pagina's is het een heel ander verhaal — en daar beginnen cold starts zich op te stapelen tot een echt crawl budget probleem dat je daadwerkelijk kunt meten in het crawl stats-rapport van Search Console.
Maatregelen: gebruik de edge runtime voor SSR-pagina's waar mogelijk (nagenoeg nul cold starts), gebruik ISR om statische pagina's op de edge te serveren, en houd serverless functions klein. Serieus.
Deze zijn gênant simpel, dus combineer ik ze. Beide veroorzaken echte problemen. Beide kosten zestig seconden om te fixen.
robots.txt: De meeste Vercel-sites serveren hetzelfde robots.txt overal — productie, preview, development. Previews zouden alle crawling moeten blokkeren. Gebruik VERCEL_ENV (automatisch ingesteld door Vercel) om onderscheid te maken:
// 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`,
};
}Trailing slashes: Als trailingSlash niet is ingesteld, resolven zowel /about als /about/ naar dezelfde content zonder redirect. Dat zijn twee URL's voor één pagina. Google ziet beide. Klaar:
module.exports = {
trailingSlash: false, // of true — kies er gewoon één
};Één regel elk. De robots.txt-les heb ik op de harde manier geleerd bij een site van een klant die 47 preview-URL's geïndexeerd had voordat iemand het merkte. Elke keer weer.
Niet alles aan Vercel SEO is een mijnenveld. Een paar dingen waar ik me op voorbereidde die prima bleken:
vercel.json merkbare latency zouden toevoegen vergeleken met Nginx-redirects. Het verschil is verwaarloosbaar — onder 5ms in elke test die ik heb gedaan. Vercel's edge is snel genoeg dat dit een non-issue is.In onze ervaring draait de overgrote meerderheid van Vercel-hosted sites op Next.js. Hier is de specifieke configuratie die ertoe doet voor SEO met deze combo.
Je kunt redirects op beide plekken definiëren. Ze gedragen zich anders:
| Feature | next.config.js redirects | vercel.json redirects |
|---|---|---|
| Waar ze draaien | Op applicatieniveau (na middleware) | Op de edge (vóór de applicatie) |
| Snelheid | Snel (maar app moet opstarten) | Snelst (geen app-aanroep) |
| Regex-ondersteuning | Ja, met named groups | Ja, met PCRE-syntax |
| Toegang tot request headers/cookies | Via has-condities | Via has-condities |
| Limiet | 1.024 redirects op Vercel's Hobby-plan | 1.024 redirects op het Hobby-plan |
| Dynamische logica | Nee (statische config) | Nee (statische config) |
Mijn vuistregel: gebruik vercel.json voor permanente URL-migraties (301's van oude paden naar nieuwe paden). Gebruik middleware voor conditionele redirects die runtime-logica nodig hebben (geo-gebaseerd, A/B-tests, authenticatie). Gebruik next.config.js-redirects alleen wanneer je Next.js-specifieke features nodig hebt zoals basePath-awareness.
Voor sites met duizenden redirects (gebruikelijk na een domeinmigratie) loop je tegen de limiet van 1.024 aan. Gebruik in dat geval middleware met een redirect map geladen vanuit een JSON-bestand of databaselookup.
Statische sitemaps breken wanneer je ISR gebruikt, omdat nieuwe pagina's tijdens runtime gegenereerd kunnen worden. Je hebt een dynamische sitemap nodig die de huidige staat van je content weerspiegelt.
// 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;
// Haal alle gepubliceerde pagina's op uit je 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,
}));
}
// Deze route revalideert elk uur
export const revalidate = 3600;De revalidate = 3600 onderaan betekent dat Vercel deze sitemap een uur lang op de edge cachet en daarna opnieuw genereert. Je sitemap blijft snel voor crawlers maar weerspiegelt recente content-toevoegingen. En het is een van die dingen die je makkelijk vergeet totdat Google pagina's begint te negeren die je drie weken geleden hebt gepubliceerd omdat ze nooit in de sitemap terechtkwamen.
Vercel's @vercel/og-library genereert Open Graph-afbeeldingen on-the-fly met edge functions. Dit is relevant voor SEO omdat OG-afbeeldingen de click-through rates bij social shares beïnvloeden, wat indirect je linkprofiel beïnvloedt.
Ik ga niet doen alsof OG-afbeeldingen direct invloed hebben op Google-rankings. Dat hebben ze niet. Maar ze beïnvloeden wel hoe je content zich verspreidt, wat backlinks beïnvloedt, wat weer rankings beïnvloedt. De keten is echt, ook al is het directe signaal dat niet.
De 20 minuten setup waard? Ja.
Next.js op Vercel ondersteunt de metadata-export in de App Router. Gebruik het voor elke pagina:
// 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}`,
},
};
}De canonical tag is niet onderhandelbaar. Elke pagina heeft er een nodig. Het voorkomt de duplicate content-problemen die Vercel-sites met meerdere deployment-URL's achtervolgen. En als je denkt "ik voeg canonicals later toe" — dat doe je niet, en tegen de tijd dat je het je herinnert heeft Google al drie versies van je homepage geïndexeerd op drie verschillende vercel.app-subdomeinen.
Vercel is niet het enige moderne hostingplatform. Hier zie je hoe het zich verhoudt tot de alternatieven voor SEO-relevante features. Gebaseerd op onze data van het auditen van sites op alle vier de platformen:
| Feature | Vercel | Netlify | Cloudflare Pages | Traditionele VPS |
|---|---|---|---|---|
| Globale edge CDN | Ja (30+ PoP's) | Ja (CDN-laag) | Ja (300+ PoP's) | Afhankelijk van setup |
| Automatische HTTPS | Ja | Ja | Ja | Handmatig (Let's Encrypt) |
| ISR-ondersteuning | Native | Distributed Persistent Rendering | Geen native equivalent | Handmatige caching |
| Edge middleware | Ja (volledige Next.js middleware) | Edge Functions | Workers (krachtigst) | Nginx/Apache-regels |
| Image optimization | Ingebouwd met next/image | Netlify Image CDN | Cloudflare Images (betaald) | Handmatig (sharp, etc.) |
| Serverless SSR | Ja (Lambda-gebaseerd) | Ja (Netlify Functions) | Ja (Workers) | Traditionele server |
| Cold start-latency | 200-1000ms | 200-800ms (varieert per function runtime) | Nagenoeg nul (Workers runtime specifiek) | Geen (altijd draaiend) |
| Buildtijd (1000 pagina's)* | ~2-5 min | ~3-7 min | ~2-4 min | Afhankelijk van CI |
| Preview deployments | Automatisch per branch | Automatisch per branch | Automatisch per branch | Handmatig |
| Kosten bij schaal (100k pagina's) | $$$ (kan duur worden) | $$ (voorspelbaarder) | $ (Workers zijn goedkoop) | $ (vaste serverkosten) |
*Buildtijden variëren enorm per framework, contentvolume en abonnement — beschouw deze als ruwe schattingen.
De eerlijke beoordeling: Cloudflare Pages heeft de beste ruwe edge-prestaties (Workers hebben nagenoeg nul cold starts, en 300+ edge-locaties verslaat iedereen). Vercel heeft de beste developer experience en Next.js-integratie. Netlify is een solide middenweg. Traditionele hosting geeft je de meeste controle maar vereist de meeste setup.
Voor puur SEO — dus crawlbaarheid, snelheid en content delivery — wint Cloudflare Pages technisch gezien op infrastructuur. Maar Vercel wint op de totale workflow. Het ISR-model, de preview deployments voor het testen van SEO-wijzigingen, en de strakke Next.js-integratie betekenen in de praktijk minder SEO-fouten. Eigenlijk is dat niet helemaal eerlijk tegenover Vercel — Netlify heeft hetzelfde preview-URL-indexeringsprobleem, en Cloudflare Pages heeft helemaal geen native ISR. Er was een Hacker News-thread eind 2023 die SEO-afwegingen tussen hostingplatformen vergeleek en de trade-off goed vastlegde: developers bleven Vercel kiezen voor DX en besteedden vervolgens weken aan het fixen van SEO-problemen die op een traditionele server niet zouden bestaan. Het gras is altijd groener.
Guillermo Rauch, CEO van Vercel, heeft het gehad over de "zero-config" filosofie — het idee dat het platform het juiste moet doen zonder dat je erom vraagt. Voor deployment en DX klopt dat. Voor SEO is het nog steeds een ambitie.
Ik kan het mis hebben over de kostenvergelijking. Vercel's pricing verandert regelmatig, en enterprise-plannen zijn ondoorzichtig. Check de huidige prijzen voordat je op schaal kiest.
We hebben SEOJuice gebouwd om de dingen af te handelen die hostingplatformen niet doen — meta tags, interne linkbuilding, schema markup, wekelijkse audits die precies de valkuilen in dit artikel opvangen. Eén script tag in je <head>, werkt met elke Vercel-site. Dat is het verhaal. (Als je vanuit Google direct naar dit gedeelte bent gesprongen, begrijp ik het. Dit is het deel dat ertoe doet.)
Nee.
Het handelt infrastructuur af — snelle hosting, HTTPS, image optimization, edge delivery. Dat is het fundament. Maar meta tags, redirects, interne linkbuilding, canonical tags, preview URL-blokkering? Allemaal jouw verantwoordelijkheid. De vraag gaat ervan uit dat "hostingplatform" en "SEO-tool" hetzelfde zijn. Dat zijn ze niet.
Deze vraag gaat ervan uit dat het platform de variabele is die ertoe doet. Dat is het niet. Ik heb verschrikkelijke SEO gezien op Vercel, Netlify en Cloudflare Pages — en uitstekende SEO op alle drie. Vercel heeft betere ISR en strakkere Next.js-integratie. Netlify heeft voorspelbaardere pricing. Cloudflare Pages heeft de snelste edge. Maar de echte SEO-verschillen komen voort uit hoe je het platform configureert, niet welk logo er op de hostingfactuur staat.
Gebruik vercel.json voor permanente URL-migraties — ze worden op de edge uitgevoerd voordat je app opstart, wat sneller is. Gebruik Next.js middleware voor conditionele redirects die runtime-logica nodig hebben (geo-targeting, authenticatiechecks). Gebruik next.config.js alleen wanneer je Next.js-specifieke routeringfeatures nodig hebt. En verdeel dezelfde redirects niet over meerdere configbestanden — kies één bron van waarheid per redirect-type.
Vercel is een van de beste hostingplatformen voor SEO in 2026 — niet omdat het SEO voor je doet, maar omdat het de infrastructuurobstakels wegneemt die SEO moeilijker maken op traditionele hosting. Snelle TTFB, automatische HTTPS, image optimization, ISR, preview deployments voor het testen. Dat is een goed fundament.
Maar de platformspecifieke valkuilen zijn reëel, en wat me frustreert is dat de meeste ervan configuratiegaten zijn die Vercel zou kunnen dichten met betere standaardinstellingen — een noindex-header op preview deployments, een afgedwongen trailing slash-voorkeur bij het aanmaken van een project, een waarschuwing wanneer je robots.txt identiek is in alle omgevingen — maar in plaats daarvan optimaliseert het platform voor developer experience en laat SEO als bijzaak over die je pas ontdekt nadat Google iets heeft geïndexeerd dat niet had gemoeten. Ken de valkuilen. Configureer eromheen.
Als je een Vercel-site draait en wilt zien hoe je SEO er echt uitziet, voer dan een gratis audit uit. Het vangt de dubbele URL's, ontbrekende meta tags en configuratiegaten op die Vercel's dashboard je niet laat zien.
no credit card required
No related articles found.