SvelteKit vs Next.js para SEO en 2026: comparación honesta

La pregunta aparece cada vez que arranco un proyecto: ¿SvelteKit o Next.js? En 2026 la respuesta para SEO ya no es "Next.js porque tiene más recursos". SvelteKit maduró, su ecosistema cubre los casos comunes y produce sitios con mejores Core Web Vitals con menos configuración. Pero Next.js no perdió: gana en apps complejas y en equipos React-first. Soy Ignacio y construyo en los dos hace cinco años; esto está basado en proyectos reales, no en benchmarks de marketing.

¿Qué cambió entre 2023 y 2026?

Pasaron tres cosas a nivel estructural:

1. SvelteKit estabilizó. SvelteKit 2 + Svelte 5 con runes (2024-2025) cerró el gap de DX con Next.js. Ya no hay sorpresas por changes breaking entre versiones.
2. Next.js App Router dominó. Server Components, streaming, parallel routes. Más poder, más complejidad. La curva de aprendizaje subió.
3. Core Web Vitals presionó performance. INP reemplazó FID. Los frameworks pesados pagan más caro el JavaScript bloqueante.

El resultado: SvelteKit gana terreno en sitios de contenido. Next.js sigue mandando en apps SaaS complejas.

¿Cómo comparan en métricas concretas?

Dimensión	SvelteKit	Next.js
Bundle size típico (home)	20-50KB JS	80-150KB JS
TTFB SSR en edge	<100ms	<150ms
Core Web Vitals (mobile p75)	Mejor de promedio	Variable
Ecosistema plugins SEO	Bueno	Excelente
Documentación SEO oficial	Mínima	Detallada
Curva de aprendizaje	Media	Alta
ISR / regeneración	Manual	Nativo
Vercel integration	Buena	Excelente
Cloudflare Workers integration	Excelente	Bueno (mejorando)
Comunidad / hire	Mediana	Masiva

Bundle size es el factor más impactante en SEO porque afecta directamente LCP e INP en mobile.

¿Por qué SvelteKit tiene bundles más chicos?

Hay tres razones técnicas:

1. Compilación en vez de runtime. Svelte compila los componentes a código JavaScript directo sin runtime de React. -25KB de base.
2. Sin Virtual DOM. Svelte actualiza el DOM directamente con reactive primitives compilados. -15KB.
3. Hidratación selectiva por default. SvelteKit decide qué necesita hidratación y qué no. Next.js con App Router hace lo mismo con Server Components, pero requiere que el dev sea explícito.

Para sitios de contenido (este blog es ejemplo). Un home con SvelteKit típicamente sirve 25KB de JS. El equivalente Next.js: 100KB+.

¿Cómo se hace SSR en cada uno?

SvelteKit:

<!-- src/routes/articles/[slug]/+page.server.ts -->
import { loadArticle } from '$lib/content/loader';

export async function load({ params }) {
  const article = await loadArticle('es', params.slug);
  if (!article) throw error(404);
  return { article };
}

<!-- src/routes/articles/[slug]/+page.svelte -->
<script>
  let { data } = $props();
</script>

<article>
  <h1>{data.article.title}</h1>
  {@html data.article.html}
</article>

SSR por default. Para SEG, agregás <svelte:head> con title, description y JSON-LD.

Next.js App Router:

// app/articles/[slug]/page.tsx
import { loadArticle } from '@/lib/content';

export default async function ArticlePage({ params }: { params: { slug: string } }) {
  const article = await loadArticle('es', params.slug);
  if (!article) notFound();
  return (
    <article>
      <h1>{article.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: article.html }} />
    </article>
  );
}

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const article = await loadArticle('es', params.slug);
  return {
    title: article?.title,
    description: article?.description,
  };
}

Más boilerplate pero más control fino. generateMetadata es la API SEO recomendada.

¿Cómo se ven los Core Web Vitals reales?

Datos CrUX agregados que mido en proyectos propios (2025-2026):

Sitio de contenido (blog técnico, 100 páginas):

• SvelteKit + Cloudflare Pages: LCP 1.4s mobile, INP 80ms, CLS 0.02 → pasa los tres en p75. Detalle de cómo llegar ahí en Core Web Vitals en Cloudflare Pages.
• Next.js + Vercel: LCP 1.8s mobile, INP 180ms, CLS 0.03 → pasa los tres pero más cerca del límite.

SaaS dashboard (50 rutas, ~10k MAU):

• SvelteKit + Cloudflare Pages: LCP 1.6s, INP 150ms, CLS 0.05.
• Next.js + Vercel (App Router optimizado): LCP 1.7s, INP 140ms, CLS 0.04.

Para apps dashboards. La diferencia se diluye porque la parte interactiva domina. Para contenido estático, SvelteKit gana claramente.

¿Cómo se hace AEO en cada uno?

Ambos sirven HTML SSR que crawlers de IA leen sin ejecutar JavaScript. Las técnicas (Quick Answer, FAQ schema, JSON-LD) se aplican igual. Detalle en qué es AEO.

Diferencia operativa:

• SvelteKit con <svelte:head> inyecta JSON-LD directo en el HTML SSR. Simple.
• Next.js App Router con generateMetadata cubre meta tags pero JSON-LD se inyecta vía <script> en el componente o con la prop script en Metadata API.

Para FAQ schema con 5-6 preguntas reales por página, mi flujo en SvelteKit:

<svelte:head>
  {@html `<script type="application/ld+json">${JSON.stringify({
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": data.article.faqs.map(f => ({
      "@type": "Question",
      "name": f.q,
      "acceptedAnswer": { "@type": "Answer", "text": f.a }
    }))
  })}</script>`}
</svelte:head>

En Next.js App Router, equivalente con <Script> o el approach manual.

¿Cuándo conviene SvelteKit?

• Sitios de contenido: blogs, marketing, portfolio, landings.
• SaaS landing + dashboard pequeño-mediano.
• Multilingüe simple (con Paraglide es trivial: mirá hreflang en SvelteKit + Paraglide).
• Equipos chicos que valoran simplicidad.
• Deploy en Cloudflare Pages (integración óptima).
• Cuando bundle size y Core Web Vitals son no-negociables.

¿Cuándo conviene Next.js?

• Apps con miles de páginas dinámicas con ISR.
• Dashboards complejos con muchos roles y permisos.
• Cuando el equipo ya sabe React y reentrenarlo no se justifica.
• Integración profunda con Vercel (analytics, image optimization, edge functions).
• Ecosistema React específico (charting, mapas, RTE con plugins propietarios).
• Proyectos enterprise donde el peso del ecosistema vale más que el bundle size.

¿Qué pasa con server components vs SvelteKit's load?

Conceptualmente similares: lógica que corre en servidor, sin enviar al cliente. Pero el modelo mental es distinto.

Server Components (Next.js App Router):

• Componentes que se renderizan server-side.
• 'use client' para forzar componente cliente.
• Composición fluida server + client en mismo árbol.

SvelteKit load functions:

• +page.server.ts corre solo en servidor (data fetching).
• +page.svelte corre en ambos (componente).
• Separación más clara entre "datos" y "vista".

Para devs que vienen de React, Server Components se sienten más natural. Para devs que valoran separación explícita, SvelteKit es más limpio.

¿Y Astro?

Astro es la tercera opción que conviene comparar. Mejor que SvelteKit en sitios 100% estáticos (zero JS por default), pero menos potente para apps interactivas. Comparación detallada en Astro vs SvelteKit.

Resumen: Astro para sitios completamente estáticos con interactividad puntual. SvelteKit cuando hay flow dinámico. Next.js cuando hay app SaaS con muchas rutas.

¿Cómo migro de Next.js a SvelteKit (o viceversa)?

Para sitios chicos (<100 páginas) la migración lleva 2 a 4 semanas, en estos pasos:

1. Replicar las rutas en el nuevo framework.
2. Mover el data fetching (load functions ↔ Server Components).
3. Convertir componentes (React → Svelte o viceversa); la mayor parte del trabajo.
4. Re-implementar SEO (meta tags, sitemap, JSON-LD).
5. Configurar redirects 301 si las URLs cambian.

Para apps grandes, la migración rara vez se justifica solo por SEO. Solo si hay otros drivers (DX, costo, equipo).

¿Por dónde empezás?

Si estás arrancando un proyecto nuevo de contenido en 2026: SvelteKit + Cloudflare Pages. Setup en Cloudflare Pages SEO.

Si estás escalando una app SaaS y tu equipo sabe React: Next.js + Vercel o Cloudflare, y el setup SEO + AEO se mantiene parejo en cualquiera de los dos.

Si te interesa una opinión específica para tu caso, escribime a [email protected] con un párrafo describiendo el proyecto. Te paso recomendación en 24 horas, sin compromiso. Referencias oficiales: SvelteKit docs y Next.js docs.