Idiomas

SEO para Svelte

Svelte se renderiza en el cliente; SvelteKit corrige esa limitación con SSR predeterminado. Guía sobre modos de renderizado, svelte:head, funciones load, adaptadores y sitemaps.

Publicado por primera vez: 26 jun 2026 · Última actualización: 14 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

El SEO para Svelte depende de una distinción: Svelte por sí solo entrega una estructura HTML vacía, mientras que SvelteKit renderiza en servidor de forma predeterminada. Para contenido indexable deben usarse SvelteKit, svelte:head, funciones load en +page.server.js y un adaptador apropiado. El modo SPA con ssr: false debe evitarse en páginas que necesitan visibilidad orgánica.

TL;DR — El SEO de Svelte es, en realidad, una cuestión de SvelteKit. Svelte básico usa solo CSR y no coloca el contenido en el HTML inicial. SvelteKit usa SSR de forma predeterminada, permite prerenderizado (SSG) por ruta y combina modos. Los metadatos se gestionan con <svelte:head> y funciones load de +page.server.js. La trampa principal es adapter-static con ssr: false: no prerenderiza, sino que produce estructuras vacías. La documentación advierte que el modo SPA tiene “large negative performance and SEO impacts” (traducción) «un gran impacto negativo en rendimiento y SEO». Deben configurarse History API, trailingSlash y un adaptador adecuado.

Evidence for this claim The article's described svelte-seo capabilities must be evaluated against the platform's current documentation rather than assumed to be search-engine behavior. Scope: Platform-specific capability documentation. Confidence: high · Verified: SvelteKit page options Evidence for this claim Regardless of platform, Google needs crawlable URLs, accessible rendered content, descriptive metadata, and valid search directives. Scope: Google requirements independent of platform. Confidence: high · Verified: Google Search Central: SEO Starter Guide

Svelte no es SvelteKit, una diferencia decisiva para SEO

Svelte es un compilador que transforma componentes .svelte en JavaScript ligero, sin DOM virtual ni biblioteca de ejecución. Esto reduce el paquete, pero no cambia el renderizado. Una aplicación Svelte básica sigue siendo una SPA renderizada en el cliente: el servidor devuelve una estructura HTML vacía y el navegador construye la página. El contenido no aparece al ver la fuente.

Esta es la principal confusión al buscar «SEO para Svelte». La compilación no añade contenido al HTML; SvelteKit sí. Es el metaframework oficial, equivalente a Next.js para React o Nuxt para Vue, y renderiza en el servidor de forma predeterminada. Añade SSR, prerenderizado, rutas por archivos, funciones load y adaptadores. En resumen: Svelte básico = solo CSR; SvelteKit = SSR primero.

Las opciones (ssr, csr, prerender, trailingSlash) se definen por ruta y se heredan: +layout.js o +layout.server.js establece valores para sus rutas hijas, que pueden sobrescribirlos. Por eso debe revisarse cada ruta. La documentación vincula la salida vacía específicamente a ssr: false: “If you set ssr to false, it renders an empty ‘shell’ page instead.” (traducción) «Si se define ssr como false, se renderiza una página de estructura vacía». La guía corresponde a Svelte 5.x y SvelteKit 2.x; las runes afectan a la autoría de componentes, no al modo de renderizado.

El modo importa por el funcionamiento de los buscadores. Google procesa JavaScript mediante rastreo, renderizado e indexación: “all pages with a 200 HTTP status code are sent to the rendering queue” (traducción) «todas las páginas con estado 200 se envían a la cola de renderizado». La cola añade demora. Google recomienda SSR o prerenderizado porque acelera la página y no todos los bots ejecutan JavaScript.

Los cuatro modos de renderizado de SvelteKit

SvelteKit decide el renderizado por ruta. Las opciones son jerárquicas: un valor en +layout.js o +layout.server.js se hereda, salvo que la ruta hija lo sobrescriba. Debe comprobarse la opción efectiva de cada ruta, no solo la raíz del proyecto.

  • SSR (predeterminado). La respuesta inicial contiene HTML completo; conviene para contenido dinámico, personalizado o cambiante.
  • Prerender (export const prerender = true). Genera HTML estático al compilar, ideal para blogs, documentación y marketing. Es SSR durante la compilación, por lo que SSR debe permanecer activo.
  • SPA (ssr: false). Devuelve una estructura sin renderizado de servidor. La documentación advierte de consecuencias negativas para rendimiento y SEO; no es apropiado para contenido indexable.
  • Híbrido. Combina modos por ruta: marketing prerenderizado, productos con SSR y administración tipo SPA tras inicio de sesión.

La trampa de ssr: false

Es el error más costoso: usar adapter-static y definir ssr: false pensando que se obtendrá HTML prerenderizado. No ocurre así.

El prerenderizado es SSR durante la compilación. Si se desactiva, no hay nada que renderizar y adapter-static publica la estructura vacía descrita por la documentación. El contenido aparece solo al ejecutar JavaScript. Con adapter-static, debe mantenerse ssr activo para producir HTML real. ssr: false se reserva para una SPA que acepte el coste de SEO.

Gestión de metadatos con <svelte:head>

El elemento <svelte:head> inserta contenido en <head> sin bibliotecas externas. Cada página debe tener <title> y <meta name="description"> únicos, además de URL preferida, Open Graph, Twitter Card, hreflang, directivas robots y JSON-LD según corresponda.

Patrón recomendado para metadatos dinámicos:

  1. Devolver metadatos desde load() en +page.server.js.
  2. Acceder mediante page.data en el layout.
  3. Renderizar en <svelte:head> dentro de +layout.svelte.
<!-- +layout.svelte -->
<script>
  import { page } from '$app/state';
</script>

<svelte:head>
  <title>{page.data.title}</title>
  <meta name="description" content={page.data.description} />
  <link rel="canonical" href={page.data.canonical} />
</svelte:head>

Como alternativa, el paquete externo svelte-seo envuelve <svelte:head> con propiedades para etiquetas comunes; es una comodidad, no un requisito.

<svelte:head> inserta las etiquetas, pero no valida su exactitud. Cada ruta debe renderizar título y descripción únicos, la URL preferida debe coincidir entre una solicitud directa y la navegación cliente, y robots y JSON-LD deben aparecer en la respuesta sin procesar, no solo tras la hidratación.

Funciones load: importa dónde se obtienen los datos

load() en +page.server.js se ejecuta en el servidor, de modo que sus datos aparecen en el HTML inicial. load() en +page.js se ejecuta en el servidor al primer renderizado y en el cliente durante la navegación. Obtener título, descripción o URL preferida en un bloque <script> mediante onMount es un error: solo se ejecuta en el cliente. Los datos críticos deben obtenerse en una función load de servidor.

El nombre del archivo no prueba por sí solo el límite: load() de +page.js también se ejecuta en el servidor en la primera solicitud y luego en el cliente. Su retorno debe poder serializarse. Conviene verificar tanto el HTML de solicitud directa como la vista tras navegación cliente.

Enrutamiento y estructura de URL

  • Rutas por archivos con [param] producen URL limpias y previsibles.
  • History API es el valor predeterminado. Evita rutas hash como #/page, que Google no resuelve de forma fiable.
  • trailingSlash en svelte.config.js acepta 'always', 'never' o 'ignore'. Una configuración incoherente puede crear duplicados; debe elegirse una opción estable.
  • Las rutas dinámicas prerenderizadas necesitan una función entries que enumere las rutas durante la compilación.

Elección del adaptador para SEO

El adaptador decide cómo y dónde se despliega SvelteKit y afecta sobre todo a TTFB, que influye en LCP:

AdaptadorRenderizadoImplicación para SEO
adapter-staticSSG completoHTML estático; ideal para contenido, con ssr activo
adapter-nodeSSR en NodeSSR dinámico y flexible; requiere servidor
adapter-vercelSSR + edgeSSR con funciones edge opcionales
adapter-cloudflareSSR en WorkersSSR edge global
adapter-netlifySSR + CDNPerfil similar a Vercel

Para blogs o documentación, adapter-static con prerenderizado ofrece velocidad y rastreabilidad. En sitios dinámicos, adapter-cloudflare o adapter-vercel acercan SSR al perímetro de la red. El TTFB real depende de datos, caché y arranque en frío; debe medirse la página desplegada en vez de atribuir el resultado al adaptador.

Un adaptador también delimita streaming, sistema de archivos, caché, API, redirecciones y errores. Una ruta correcta en desarrollo o con adapter-node puede comportarse de otro modo en Cloudflare o Vercel. Debe probarse la compilación en el destino real, no solo con npm run preview.

Sitemaps y robots.txt

SvelteKit no incluye sitemap ni robots.txt; deben crearse explícitamente.

  • Sitemap manual: src/routes/sitemap.xml/+server.js devuelve XML; con adapter-static se añade export const prerender = true.
  • Sitemap dinámico: un endpoint consulta CMS o base de datos en cada solicitud, útil para sitios grandes o cambiantes.
  • Paquetes: svelte-sitemap y sveltekit-static-sitemap generan sitemaps de rutas estáticas.
  • robots.txt: puede guardarse en static/ (y servirse en /robots.txt) o generarse desde src/routes/robots.txt/+server.js. No deben bloquearse .js ni .css, pues Google necesita esos archivos para renderizar.

Rendimiento y Core Web Vitals

El compilador ofrece una ventaja estructural, pero no garantiza Core Web Vitals. SvelteKit suele enviar menos JavaScript que una aplicación React equivalente y ofrece división de código, precarga, caché y despliegue edge. El peso, las imágenes, scripts externos, hidratación y destino determinan las métricas reales. La documentación recomienda: “Google’s PageSpeed Insights and WebPageTest are excellent ways to understand the performance characteristics of a site.” (traducción) «PageSpeed Insights y WebPageTest ayudan a comprender el rendimiento». La optimización de imágenes está disponible mediante @sveltejs/enhanced-img.

Rastreadores de IA y necesidad de SSR

En 2026, el comportamiento de GPTBot, ClaudeBot, PerplexityBot y Bingbot depende del proveedor y la versión; la documentación no establece un renderizado común. Conviene planificar suponiendo que se obtiene HTML estático sin ejecutar JavaScript, no tratarlo como garantía universal. Una ruta CSR entrega una estructura vacía, mientras SSR de SvelteKit coloca el contenido en el HTML inicial. SSR mejora la accesibilidad, pero no garantiza aparecer en respuestas de IA.

Errores frecuentes de SEO en SvelteKit

  • Obtener datos en onMount() en vez de una función load de servidor.
  • Publicar modo SPA (ssr: false) para contenido indexable.
  • Combinar adapter-static con ssr: false: produce estructuras vacías.
  • Bloquear JS o CSS en robots.txt: rompe el renderizado.
  • Omitir trailingSlash: puede crear variantes duplicadas.
  • Usar rutas hash: Googlebot no resuelve esas URL de forma fiable.

Svelte o SvelteKit puede funcionar como frontend desacoplado de un CMS headless. La lógica de modos de renderizado es la misma que rige el SEO para JavaScript en general.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.