TL;DR: Vercel ti dà TTFB veloce, HTTPS automatico e ottimizzazione delle immagini “out of the box” — una base SEO migliore rispetto alla maggior parte delle piattaforme di hosting. Ma ti fornisce anche URL di anteprima delle distribuzioni che Google può indicizzare, una cache edge che può servire tag meta non aggiornati e serverless cold start che rallentano i crawler. Ecco come configurare Vercel in modo corretto per la SEO, evitare le trappole che vedo continuamente e usare l’edge per tutto ciò che davvero aiuta il posizionamento.
Lee Robinson, VP of Developer Experience di Vercel, ha scritto a lungo sul blog di Vercel su come l’ISR colmi il divario tra generazione statica in fase di build e rendering a runtime. Ha ragione: per siti con migliaia di pagine, l’ISR significa che non devi scegliere tra velocità e freschezza. Hai entrambe.
Detto questo, “buone impostazioni predefinite” non significa “nessun lavoro richiesto”. Ho visto tanti siti Vercel con Core Web Vitals eccellenti e SEO pessima — siti in cui ogni metrica Lighthouse è verde e ogni meta description manca. L’infrastruttura è solida. È la configurazione dove le persone sbagliano.
Qui divento un po’ “di parte”. Sono problemi che vedo su praticamente ogni sito Vercel che analizziamo. Non sono casi limite: sono impostazioni di default che ti si ritorcono contro.
Onestamente, il fatto che Vercel non gestisca la maggior parte di queste cose automaticamente è sconcertante.
L’anno scorso un cliente mi ha scritto, confuso. La ricerca per il nome del brand restituiva una pagina su their-project-git-feature-auth-fix-theirteam.vercel.app invece del loro dominio reale. Non avevano mai sentito nominare quel URL. Nessuno del team l’aveva condiviso da qualche parte — o almeno così pensavano.
In realtà, tre mesi prima un developer aveva inserito un link di preview in un commento a una PR su GitHub. Googlebot l’ha trovato tramite l’indicizzazione pubblica di GitHub. E siccome la preview serviva contenuti identici a quelli di produzione su un dominio diverso, Google doveva scegliere quale versione indicizzare. Ha scelto male.
Questo è il disastro SEO più comune di Vercel che vedo. Ogni branch che pushi crea un deployment con un URL tipo your-project-git-feature-branch-yourteam.vercel.app. Ogni pull request ha una preview. Ogni commit su main genera un deployment. Questi URL sono pubblici, indicizzabili e basta un link messo male per farli finire nell’indice di Google.
La soluzione:
X-Robots-Tag: noindex, nofollow.vercel.app.next.config.js, imposta in modo dinamico l’URL canonico in base all’ambiente.NEXT_PUBLIC_SITE_URL come variabile d’ambiente e usala nei metadata — mai codificare “a mano” il dominio.// app/layout.tsx (oppure dove definisci i metadata)
export const metadata = {
metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com'),
alternates: {
canonical: './',
},
};(Perché Vercel non aggiunge semplicemente X-Robots-Tag: noindex alle preview deployment di default? Ho chiesto. Nessuna risposta.) Per come la vedo io, è una scelta deliberata: gli URL di anteprima sono utili per condividerli con gli stakeholder. Ma il costo SEO è reale, e molti team se ne accorgono solo quando vedono URL con vercel.app in Search Console. Barry Schwartz ha già coperto questo schema su Search Engine Roundtable — la fuga di staging e preview URLs nell’indice di Google non è esclusiva di Vercel, ma il modello automatico “preview per branch” di Vercel lo rende più frequente e su scala maggiore rispetto a qualunque altra piattaforma.
// 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 });
}Ti serve quell’endpoint. Ecco perché.
Se usi ISR o valori aggressivi di s-maxage, la cache edge di Vercel può servire pagine “stale” con meta tag vecchi per ore o anche giorni. Aggiorni il titolo di un articolo nel tuo CMS, ma la versione cachegata sull’edge conserva ancora il titolo precedente. Google indicizza quella versione cache. Il tuo aggiornamento del title tag non viene mai recepito.
Collega quell’endpoint di revalidation al webhook del CMS. Le modifiche ai contenuti dovrebbero innescare una pulizia immediata della cache, non aspettare il prossimo ciclo ISR. Non è opzionale.
Lo scorso mese ho passato due ore a capire perché le meta description di un cliente non si aggiornassero. La soluzione è… in realtà, prima ti mostro il modo sbagliato. Avevano s-maxage=604800 — un’intera settimana di caching edge — senza webhook di revalidation. Ogni modifica nel CMS era invisibile a Google per sette giorni. La soluzione vera era un singolo header Cache-Control in vercel.json, più il wiring del webhook di cui sopra. Due ore per un header.
Le funzioni serverless di Vercel hanno cold start. Se una funzione non viene chiamata da poco, la prima richiesta avvia una nuova istanza — aggiungendo 200-1000ms al tempo di risposta. E se Googlebot colpisce 50 pagine in rapida successione e metà sono cold start, il tuo crawl rate scende.
Dovrei essere onesto qui: non ho misurato l’impatto esatto dei cold start sul crawl budget con rigore scientifico. In una sessione delle Google Search Central office hours del 2024, John Mueller ha osservato che server lenti non danneggiano direttamente i ranking, ma influenzano quante pagine Google riesce a crawlarle per sessione. Nei nostri dati, i siti con TTFB sotto i 200ms vengono crawled circa il 40% più spesso. Ma per un sito marketing da 50 pagine? Probabilmente irrilevante. Per 10.000+ pagine cambia tutto: a quel punto i cold start iniziano ad accumularsi in un vero problema di crawl budget, misurabile davvero nella reportistica di Search Console (crawl stats).
Mitigazioni: usa edge runtime per le pagine SSR quando possibile (cold start quasi azzerati), usa ISR per servire pagine statiche dall’edge e mantieni le serverless function piccole. Sul serio.
Sono cose imbarazzantemente semplici, quindi le unisco. Entrambe causano problemi reali. Entrambe richiedono sessanta secondi per essere sistemate.
robots.txt: La maggior parte dei siti Vercel serve lo stesso robots.txt ovunque — produzione, preview, sviluppo. Le preview dovrebbero bloccare tutto il crawling. Usa VERCEL_ENV (impostato automaticamente da Vercel) per distinguerle:
// 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`,
};
}Slash finali: Se trailingSlash non è impostato, sia /about sia /about/ risolvono lo stesso contenuto senza redirect. Sono due URL per la stessa pagina. Google li vede entrambi. Fatto:
module.exports = {
trailingSlash: false, // oppure true — basta sceglierne uno
};Una riga ciascuno. Ho imparato il fix di robots.txt “a modo mio” in un sito di un cliente che aveva 47 URL di preview indicizzati prima che qualcuno se ne accorgesse. Ogni volta.
Non tutto sulla SEO su Vercel è una mina. Alcune cose per cui mi aspettavo problemi si sono risolte bene:
vercel.json aggiungessero una latenza significativa rispetto ai redirect di Nginx. La differenza è trascurabile — sotto i 5ms in ogni test che ho eseguito. L’edge di Vercel è abbastanza veloce da rendere il tema irrilevante.Per come la vediamo noi, la stragrande maggioranza dei siti hostati su Vercel usa Next.js. Ecco la configurazione specifica che conta per la SEO con questa combinazione.
Puoi definire i redirect in entrambi i posti. Si comportano in modo diverso:
| Funzionalità | next.config.js redirects | vercel.json redirects |
|---|---|---|
| Dove vengono eseguiti | A livello applicazione (dopo middleware) | All’edge (prima dell’app) |
| Velocità | Veloci (ma l’app deve partire) | Le più rapide (nessuna invocazione dell’app) |
| Supporto regex | Sì, con gruppi nominati | Sì, con sintassi PCRE |
| Accesso a header/cookie della richiesta | Tramite condizioni has | Tramite condizioni has |
| Limite | 1.024 redirect nel piano Hobby di Vercel | 1.024 redirect nel piano Hobby |
| Logica dinamica | No (config statica) | No (config statica) |
La mia regola pratica: usa vercel.json per migrazioni permanenti di URL (301 dai vecchi path ai nuovi). Usa il middleware per redirect condizionali che richiedono logica a runtime (geo-based, test A/B, autenticazione). Usa next.config.js per i redirect solo quando ti servono funzionalità specifiche di Next.js come la consapevolezza di basePath.
Per siti con migliaia di redirect (comune dopo una migrazione di dominio) andrai a sbattere contro il limite di 1.024. In quel caso, usa middleware con una redirect map caricata da un file JSON o con una query su database.
Le sitemap statiche si rompono quando usi ISR, perché nuove pagine possono essere generate a runtime. Ti serve una sitemap dinamica che rispecchi lo stato attuale dei tuoi contenuti.
// 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;
// Recupera tutte le pagine pubblicate dal tuo 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,
}));
}
// Questa route esegue la revalidation ogni ora
export const revalidate = 3600;Il revalidate = 3600 in fondo significa che Vercel mette in cache questa sitemap sull’edge per un’ora, poi la rigenera. La tua sitemap resta veloce per i crawler ma riflette le aggiunte recenti. Ed è una di quelle cose che si dimentica facilmente finché Google non inizia a ignorare pagine pubblicate tre settimane fa perché non ci sono mai finite nella sitemap.
La libreria @vercel/og di Vercel genera al volo immagini Open Graph usando edge functions. È rilevante per la SEO perché le immagini OG influenzano i tassi di click-through nelle condivisioni social, che a loro volta impattano indirettamente il tuo profilo link.
Non voglio fingere che le immagini OG impattino direttamente i ranking su Google. Non lo fanno. Però impattano la diffusione dei contenuti: e quella impatta i backlink, che impattano i ranking. La catena è reale, anche se il segnale diretto non c’è.
Vale i 20 minuti di setup? Sì.
Next.js su Vercel supporta l’export metadata nell’App Router. Usalo su ogni 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}`,
},
};
}Il tag canonico è non negoziabile. Ogni pagina ne deve avere uno. Evita i problemi di contenuti duplicati che perseguitano i siti Vercel con più URL di deployment. E se pensi “lo aggiungo dopo”— no, non lo farai, e quando te ne ricorderai Google avrà già indicizzato tre versioni della tua homepage su tre sottodomini diversi di vercel.app.
Vercel non è l’unica piattaforma di hosting moderna. Ecco come si posiziona rispetto alle alternative per funzionalità rilevanti per la SEO. Basato sui nostri dati da audit svolti su siti su tutte e quattro le piattaforme:
| Funzionalità | Vercel | Netlify | Cloudflare Pages | VPS tradizionale |
|---|---|---|---|---|
| Edge CDN globale | Sì (30+ PoP) | Sì (layer CDN) | Sì (300+ PoP) | Dipende dalla configurazione |
| HTTPS automatico | Sì | Sì | Sì | Manuale (Let's Encrypt) |
| Supporto ISR | Nativo | Distributed Persistent Rendering | Nessun equivalente nativo | Cache manuale |
| Edge middleware | Sì (middleware completo di Next.js) | Edge Functions | Workers (il più potente) | Regole Nginx/Apache |
| Ottimizzazione immagini | Integrata con next/image | Netlify Image CDN | Cloudflare Images (a pagamento) | Manuale (sharp, ecc.) |
| Serverless SSR | Sì (basato su Lambda) | Sì (Netlify Functions) | Sì (Workers) | Server tradizionale |
| Latenza cold start | 200-1000ms | 200-800ms (varia in base al runtime della funzione) | Quasi zero (runtime dei Workers in particolare) | Nessuna (sempre in esecuzione) |
| Tempo di build (1000 pagine)* | ~2-5 min | ~3-7 min | ~2-4 min | Dipende dalla CI |
| Deployment di anteprima | Automatico per branch | Automatico per branch | Automatico per branch | Manuale |
| Costo a scala (100k pagine) | $$$ (può diventare costoso) | $$ (più prevedibile) | $ (i Workers sono economici) | $ (costo server fisso) |
*I tempi di build variano drasticamente in base al framework, alla quantità di contenuti e al livello del piano — considerali stime indicative.
La versione sincera: Cloudflare Pages ha la migliore performance edge “raw” (i Workers hanno cold start quasi azzerati, e 300+ location edge battono tutti). Vercel ha la migliore developer experience e l’integrazione più stretta con Next.js. Netlify è un buon compromesso. L’hosting tradizionale ti dà più controllo, ma richiede la maggior parte del lavoro di setup.
Per la SEO “pura” — cioè crawlabilità, velocità e delivery dei contenuti — Cloudflare Pages vince tecnicamente sull’infrastruttura. Però Vercel vince sul workflow complessivo. Il modello ISR, le preview deployment per testare cambiamenti SEO e l’integrazione stretta con Next.js significano meno errori SEO nella pratica. In realtà, non è del tutto equo verso Vercel: Netlify ha lo stesso problema di indicizzazione degli URL di preview, e Cloudflare Pages non ha ISR nativo. A fine 2023 c’è stato un thread su Hacker News che confrontava gli tradeoff SEO delle piattaforme di hosting e lo sintetizzava bene: gli sviluppatori continuavano a scegliere Vercel per la DX, poi passavano settimane a sistemare problemi SEO che non esisterebbero su un server tradizionale. L’erba è sempre più verde.
Guillermo Rauch, CEO di Vercel, ha parlato della filosofia del “zero-config” — l’idea che la piattaforma debba fare la cosa giusta senza che tu debba chiederlo. Per deployment e DX, è vero. Per la SEO, resta ancora un’aspirazione.
Posso anche sbagliarmi sul confronto costi. I prezzi di Vercel cambiano spesso e i piani enterprise sono poco trasparenti. Controlla il pricing attuale prima di impegnarti su larga scala.
Abbiamo costruito SEOJuice per gestire le cose che le piattaforme di hosting non fanno — meta tag, link interni, schema markup, audit settimanali che individuano esattamente le trappole descritte in questo articolo. Un solo tag <script> nella tua <head>, e funziona con qualsiasi sito Vercel. È questo il pitch. (Se sei arrivato qui saltando dal Google, capisco. È la parte che conta.)
No.
Gestisce l’infrastruttura — hosting veloce, HTTPS, ottimizzazione delle immagini, delivery sull’edge. Quella è la base. Ma meta tag, redirect, link interni, tag canonici, blocco degli URL di anteprima? Dipende da te. La domanda assume che “piattaforma di hosting” e “strumento SEO” siano la stessa cosa. Non lo sono.
Questa domanda assume che la piattaforma sia la variabile che conta. Non lo è. Ho visto SEO pessima su Vercel, Netlify e Cloudflare Pages — e SEO eccellente su tutte e tre. Vercel ha ISR migliore e integrazione più stretta con Next.js. Netlify ha prezzi più prevedibili. Cloudflare Pages ha l’edge più veloce. Ma le vere differenze SEO dipendono da come configuri la piattaforma, non da quale badge compare nella fattura dell’hosting.
Usa vercel.json per migrazioni permanenti di URL — vengono eseguiti sull’edge prima che la tua app si avvii, quindi sono più veloci. Usa il middleware di Next.js per redirect condizionali che richiedono logica a runtime (targeting geo, controlli di autenticazione). Usa next.config.js solo quando ti servono funzionalità di routing specifiche di Next.js. E non dividere gli stessi redirect su più file di configurazione: scegli una sola fonte di verità per ciascun tipo di redirect.
Vercel è una delle migliori piattaforme di hosting per la SEO nel 2026 — non perché fa SEO al posto tuo, ma perché rimuove gli ostacoli infrastrutturali che rendono la SEO più difficile su un hosting tradizionale. TTFB veloce, HTTPS automatico, ottimizzazione delle immagini, ISR, preview deployment per testare. È una buona base.
Ma le trappole specifiche della piattaforma sono reali, e quello che mi frustra è che molte di esse sono gap di configurazione che Vercel potrebbe colmare con impostazioni predefinite migliori — un header noindex sulle preview deployment, la preferenza forzata per lo slash finale durante la configurazione del progetto, un avviso quando il tuo robots.txt è identico tra ambienti — invece la piattaforma ottimizza per la developer experience e lascia la SEO come ripensamento: la scopri solo quando Google ha già indicizzato qualcosa che non avrebbe dovuto. Conosci le trappole. Configurati di conseguenza.
Se stai usando un sito su Vercel e vuoi vedere davvero che aspetto ha la tua SEO, esegui una verifica gratuita. Individuerà URL duplicati, meta tag mancanti e gap di configurazione che la dashboard di Vercel non ti mostra.
no credit card required