TL;DR: Vercel te da un TTFB rápido, HTTPS automático y optimización de imágenes de serie — eso ya es una base SEO mejor que la mayoría de plataformas de hosting. Pero también te da URLs de despliegues de preview que Google puede indexar, caché en el edge que sirve meta tags obsoletas, y cold starts de funciones serverless que ralentizan los rastreadores. Aquí te explico cómo configurar Vercel correctamente para SEO, cómo evitar los errores que veo constantemente, y cómo usar el edge para cosas que realmente ayudan al posicionamiento.
Lee Robinson, VP de Developer Experience en Vercel, ha escrito extensamente en el blog de Vercel sobre cómo ISR cierra la brecha entre la generación estática en tiempo de build y el renderizado en tiempo de ejecución. Tiene razón — para sitios con miles de páginas, ISR significa que no tienes que elegir entre velocidad y frescura. Consigues ambas.
Dicho esto, "buenos valores por defecto" no significa "no hay trabajo que hacer." He visto montones de sitios en Vercel con Core Web Vitals excelentes y un SEO desastroso — sitios donde cada métrica de Lighthouse está en verde y cada meta description brilla por su ausencia. La infraestructura es sólida. La configuración es donde la gente la pifia.
Aquí es donde me pongo dogmático. Estos son los problemas que veo en prácticamente todos los sitios de Vercel que auditamos. No son casos extremos — son comportamientos por defecto que te muerden.
Sinceramente, el hecho de que Vercel no gestione la mayoría de esto por defecto me resulta incomprensible.
El año pasado un cliente me escribió confundido. La búsqueda de su marca estaba devolviendo una página en their-project-git-feature-auth-fix-theirteam.vercel.app en vez de su dominio real. Nunca habían oído hablar de esa URL. Nadie de su equipo la había compartido en ninguna parte — o eso creían.
Resulta que un desarrollador había pegado un enlace de preview en un comentario de un PR en GitHub tres meses antes. Googlebot lo encontró a través de la indexación pública de GitHub. Y como el preview servía contenido idéntico al de producción en un dominio diferente, Google tuvo que elegir cuál indexar. Eligió mal.
Este es el desastre SEO más común que veo en Vercel. Cada rama que subes crea un despliegue en una URL como your-project-git-feature-branch-yourteam.vercel.app. Cada pull request recibe un preview. Cada commit a main recibe un despliegue. Estas URLs son públicas, rastreables, y están a un enlace mal colocado de terminar en el índice de Google.
La solución:
X-Robots-Tag: noindex, nofollow a todas las peticiones en .vercel.app.next.config.js, configura la URL canónica de forma dinámica según el entorno.NEXT_PUBLIC_SITE_URL como variable de entorno y úsala en tus metadatos — nunca escribas el dominio directamente en el código.// app/layout.tsx (o donde definas los metadatos)
export const metadata = {
metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com'),
alternates: {
canonical: './',
},
};(¿Por qué Vercel no añade simplemente X-Robots-Tag: noindex a los despliegues de preview por defecto? He preguntado. Sin respuesta.) Por lo que puedo deducir, es una decisión deliberada — las URLs de preview son útiles para compartir con stakeholders. Pero el coste SEO es real, y la mayoría de equipos no se dan cuenta hasta que ven URLs de vercel.app en Search Console. Barry Schwartz ha cubierto este patrón en Search Engine Roundtable — que las URLs de staging y preview se cuelen en el índice de Google no es algo exclusivo de Vercel, pero el modelo de preview automático por rama de Vercel hace que ocurra con más frecuencia y a mayor escala que en cualquier otra plataforma.
// 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 });
}Necesitas ese endpoint. Te explico por qué.
Si usas ISR o valores agresivos de s-maxage, la caché del edge de Vercel puede servir páginas obsoletas con meta tags desactualizadas durante horas o incluso días. Actualizas el título de un post en tu CMS, pero la versión cacheada en el edge sigue teniendo el título viejo. Google rastrea la versión cacheada. Tu cambio de title tag nunca se registra.
Conecta ese endpoint de revalidación al webhook de tu CMS. Los cambios de contenido deberían disparar una purga de caché inmediata, no esperar al siguiente ciclo de ISR. No es opcional.
El mes pasado me pasé dos horas averiguando por qué las meta descriptions de un cliente no se actualizaban. La solución... en realidad, debería enseñarte primero cómo NO hacerlo. Tenían s-maxage=604800 — una semana entera de caché en el edge — sin ningún webhook de revalidación. Cada edición en el CMS era invisible para Google durante siete días. La solución real fue un único header Cache-Control en el vercel.json y conectar el webhook de arriba. Dos horas por un header.
Las funciones serverless de Vercel tienen cold starts. Si una función no ha sido invocada recientemente, la primera petición arranca una nueva instancia — añadiendo entre 200 y 1.000ms al tiempo de respuesta. Y si Googlebot accede a 50 páginas en rápida sucesión y la mitad son cold starts, tu tasa de rastreo se desploma.
Tengo que ser honesto aquí — no he medido el impacto exacto de los cold starts en el crawl budget con rigor científico. En una sesión de Google Search Central office hours de 2024, John Mueller señaló que los servidores lentos no perjudican directamente los rankings, pero sí afectan a cuántas páginas rastrea Google por sesión. En nuestros datos, los sitios con TTFB inferior a 200ms se rastrean aproximadamente un 40% más frecuentemente. Pero para un sitio de marketing de 50 páginas, eso es probablemente irrelevante. Para más de 10.000 páginas, la historia cambia por completo — y ahí es donde los cold starts empiezan a acumularse hasta convertirse en un problema real de crawl budget que puedes medir directamente en el informe de estadísticas de rastreo de Search Console.
Mitigaciones: usa el runtime edge para páginas SSR cuando sea posible (cold starts prácticamente nulos), usa ISR para servir páginas estáticas desde el edge, y mantén las funciones serverless pequeñas. En serio.
Esto es vergonzosamente sencillo, así que lo combino. Ambos causan problemas reales. Ambos se arreglan en sesenta segundos.
robots.txt: La mayoría de sitios en Vercel sirven el mismo robots.txt en todas partes — producción, preview, desarrollo. Los previews deberían bloquear todo el rastreo. Usa VERCEL_ENV (que Vercel establece automáticamente) para diferenciar:
// 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: Si trailingSlash no está configurado, tanto /about como /about/ resuelven al mismo contenido sin redirección. Eso son dos URLs para una sola página. Google ve ambas. Solución:
module.exports = {
trailingSlash: false, // o true — simplemente elige una opcion
};Una línea cada uno. Lo del robots.txt lo aprendí por las malas en el sitio de un cliente que tenía 47 URLs de preview indexadas antes de que nadie se diera cuenta. Siempre pasa.
No todo en el SEO de Vercel es un campo de minas. Algunas cosas para las que me preparé y que resultaron no ser un problema:
vercel.json añadieran una latencia significativa frente a redirecciones en Nginx. La diferencia es despreciable — menos de 5ms en todos los tests que he ejecutado. El edge de Vercel es lo suficientemente rápido como para que esto no sea un problema.Según nuestra experiencia, la gran mayoría de sitios alojados en Vercel usan Next.js. Aquí tienes la configuración específica que importa para el SEO con esta combinación.
Puedes definir redirecciones en ambos sitios. Se comportan de forma diferente:
| Característica | Redirecciones en next.config.js | Redirecciones en vercel.json |
|---|---|---|
| Donde se ejecutan | A nivel de aplicación (después del middleware) | En el edge (antes de la aplicación) |
| Velocidad | Rápida (pero la app debe arrancar) | La más rápida (sin invocación de la app) |
| Soporte de regex | Sí, con grupos con nombre | Sí, con sintaxis PCRE |
| Acceso a headers/cookies de la petición | Vía condiciones has | Vía condiciones has |
| Límite | 1.024 redirecciones en el plan Hobby de Vercel | 1.024 redirecciones en el plan Hobby |
| Lógica dinámica | No (configuración estática) | No (configuración estática) |
Mi regla general: usa vercel.json para migraciones permanentes de URL (301 de rutas antiguas a rutas nuevas). Usa middleware para redirecciones condicionales que necesiten lógica en tiempo de ejecución (basadas en geolocalización, tests A/B, autenticación). Usa las redirecciones de next.config.js solo cuando necesites funcionalidades específicas de Next.js como la gestión de basePath.
Para sitios con miles de redirecciones (algo habitual después de una migración de dominio), vas a chocar con el límite de 1.024. En ese caso, usa middleware con un mapa de redirecciones cargado desde un archivo JSON o una consulta a base de datos.
Los sitemaps estáticos se rompen cuando usas ISR porque se pueden generar nuevas páginas en tiempo de ejecución. Necesitas un sitemap dinámico que refleje el estado actual de tu contenido.
// 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;
// Obtener todas las páginas publicadas del 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,
}));
}
// Esta ruta se revalida cada hora
export const revalidate = 3600;El revalidate = 3600 del final significa que Vercel cachea este sitemap en el edge durante una hora y luego lo regenera. Tu sitemap se mantiene rápido para los rastreadores pero refleja las adiciones de contenido recientes. Y es una de esas cosas fáciles de olvidar hasta que Google empieza a ignorar páginas que publicaste hace tres semanas porque nunca llegaron al sitemap.
La biblioteca @vercel/og de Vercel genera imágenes Open Graph al vuelo usando edge functions. Esto es relevante para el SEO porque las imágenes OG afectan a las tasas de clics en las comparticiones sociales, lo que indirectamente influye en tu perfil de backlinks.
No voy a pretender que las imágenes OG impactan directamente en los rankings de Google. No lo hacen. Pero sí impactan en cómo se difunde tu contenido, lo que impacta en los backlinks, lo que impacta en los rankings. La cadena es real aunque la señal directa no lo sea.
¿Merece la pena dedicarle 20 minutos a configurarlo? Sí.
Next.js en Vercel soporta el export metadata en el App Router. Úsalo en cada página:
// 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 etiqueta canonical es innegociable. Cada página necesita una. Previene los problemas de contenido duplicado que persiguen a los sitios de Vercel con múltiples URLs de despliegue. Y si piensas "ya añadiré las canonicals después" — no lo harás, y para cuando te acuerdes, Google ya habrá indexado tres versiones de tu homepage en tres subdominios diferentes de vercel.app.
Vercel no es la única plataforma de hosting moderna. Así se compara con las alternativas en funcionalidades relevantes para SEO. Basado en nuestros datos de auditorías en sitios en las cuatro plataformas:
| Característica | Vercel | Netlify | Cloudflare Pages | VPS tradicional |
|---|---|---|---|---|
| CDN global en el edge | Sí (30+ PoPs) | Sí (capa CDN) | Sí (300+ PoPs) | Depende de la configuración |
| HTTPS automático | Sí | Sí | Sí | Manual (Let's Encrypt) |
| Soporte ISR | Nativo | Distributed Persistent Rendering | Sin equivalente nativo | Caché manual |
| Edge middleware | Sí (middleware completo de Next.js) | Edge Functions | Workers (el más potente) | Reglas de Nginx/Apache |
| Optimización de imágenes | Integrada con next/image | Netlify Image CDN | Cloudflare Images (de pago) | Manual (sharp, etc.) |
| SSR serverless | Sí (basado en Lambda) | Sí (Netlify Functions) | Sí (Workers) | Servidor tradicional |
| Latencia de cold start | 200-1.000ms | 200-800ms (varía según el runtime) | Prácticamente nula (runtime de Workers) | Ninguna (siempre activo) |
| Tiempo de build (1.000 páginas)* | ~2-5 min | ~3-7 min | ~2-4 min | Depende del CI |
| Despliegues de preview | Automático por rama | Automático por rama | Automático por rama | Manual |
| Coste a escala (100.000 páginas) | $$$ (puede salir caro) | $$ (más predecible) | $ (Workers son baratos) | $ (coste fijo del servidor) |
*Los tiempos de build varían enormemente según el framework, el volumen de contenido y el nivel del plan — toma estas cifras como orientativas.
Mi opinión sincera: Cloudflare Pages tiene el mejor rendimiento bruto en el edge (Workers tienen cold starts prácticamente nulos, y 300+ ubicaciones en el edge le gana a todos). Vercel tiene la mejor experiencia de desarrollador y la integración más estrecha con Next.js. Netlify es un punto intermedio sólido. El hosting tradicional te da el máximo control pero requiere la mayor cantidad de configuración.
Para SEO puro — es decir, rastreabilidad, velocidad y distribución de contenido — Cloudflare Pages gana técnicamente en infraestructura. Pero Vercel gana en el flujo de trabajo global. El modelo ISR, los despliegues de preview para probar cambios SEO, y la integración ajustada con Next.js significan menos errores SEO en la práctica. Bueno, siendo justos con Vercel — Netlify tiene exactamente el mismo problema de indexación de URLs de preview, y Cloudflare Pages directamente no tiene ISR nativo. Hubo un hilo en Hacker News a finales de 2023 comparando las ventajas y desventajas SEO de las plataformas de hosting que capturó bien esta tensión: los desarrolladores seguían eligiendo Vercel por la DX y luego pasaban semanas arreglando problemas de SEO que no existirían en un servidor tradicional. La hierba siempre parece más verde al otro lado.
Guillermo Rauch, CEO de Vercel, ha hablado sobre la filosofía de "zero-config" — la idea de que la plataforma debería hacer lo correcto sin que se lo pidas. Para el despliegue y la DX, es cierto. Para el SEO, sigue siendo aspiracional.
Podría estar equivocado respecto a la comparación de costes. Los precios de Vercel cambian con frecuencia, y los planes enterprise son opacos. Comprueba los precios actuales antes de comprometerte a escala.
Construimos SEOJuice para encargarse de lo que las plataformas de hosting no cubren — meta tags, enlaces internos, schema markup, auditorías semanales que detectan exactamente los problemas que aparecen en este artículo. Una etiqueta script en tu <head>, funciona con cualquier sitio de Vercel. Ese es el pitch. (Si saltaste directamente a esta sección desde Google, lo entiendo. Esta es la parte que importa.)
No.
Gestiona la infraestructura — hosting rápido, HTTPS, optimización de imágenes, distribución en el edge. Esa es la base. Pero las meta tags, las redirecciones, los enlaces internos, las etiquetas canonical, el bloqueo de URLs de preview... todo eso depende de ti. La pregunta asume que "plataforma de hosting" y "herramienta SEO" son lo mismo. No lo son.
Esta pregunta asume que la plataforma es la variable que importa. No lo es. He visto un SEO desastroso en Vercel, Netlify y Cloudflare Pages — y un SEO excelente en las tres. Vercel tiene mejor ISR y una integración más estrecha con Next.js. Netlify tiene precios más predecibles. Cloudflare Pages tiene el edge más rápido. Pero las diferencias reales en SEO vienen de cómo configuras la plataforma, no de qué logotipo aparece en la factura de hosting.
Usa vercel.json para migraciones permanentes de URL — se ejecutan en el edge antes de que tu app arranque, lo que es más rápido. Usa middleware de Next.js para redirecciones condicionales que necesiten lógica en tiempo de ejecución (segmentación geográfica, comprobaciones de autenticación). Usa next.config.js solo cuando necesites funcionalidades específicas de enrutamiento de Next.js. Y no dividas las mismas redirecciones entre múltiples archivos de configuración — elige una única fuente de verdad por tipo de redirección.
Vercel es una de las mejores plataformas de hosting para SEO en 2026 — no porque haga el SEO por ti, sino porque elimina los obstáculos de infraestructura que dificultan el SEO en el hosting tradicional. TTFB rápido, HTTPS automático, optimización de imágenes, ISR, despliegues de preview para probar cambios. Esa es una buena base.
Pero los problemas específicos de la plataforma son reales, y lo que me frustra es que la mayoría son lagunas de configuración que Vercel podría cerrar con mejores valores por defecto — un header noindex en los despliegues de preview, una preferencia de trailing slash obligatoria durante la configuración del proyecto, un aviso cuando tu robots.txt es idéntico en todos los entornos — pero en su lugar la plataforma optimiza para la experiencia del desarrollador y deja el SEO como algo secundario que descubres solo después de que Google haya indexado algo que no debería. Conoce los problemas. Configura en torno a ellos.
Si tienes un sitio en Vercel y quieres ver cómo está realmente tu SEO, ejecuta una auditoría gratuita. Detectará las URLs duplicadas, las meta tags faltantes y las lagunas de configuración que el panel de Vercel no te muestra.
no credit card required
No related articles found.