SEO para SolidJS

TL;DR — SolidJS es una biblioteca rápida parecida a React, pero por sí sola construye la página en el navegador, por lo que los buscadores reciben primero un contenedor vacío. La solución es SolidStart, su herramienta integral oficial, que entrega HTML terminado. El modo de renderizado se define por ruta: conviene usar SSR o SSG en las rutas que deben posicionarse, establecer títulos y metadatos con @solidjs/meta y comprobar el HTML real de cada ruta.

Qué es SolidJS

SolidJS es una biblioteca de JavaScript para crear interfaces. Usa JSX y un estilo de componentes similar a React, pero no tiene DOM virtual: actualiza únicamente las partes de la página que cambian, lo que reduce el trabajo de ejecución.

El problema para el SEO es que SolidJS usa renderizado del lado del cliente (CSR) de forma predeterminada. El servidor envía un HTML casi vacío y el navegador descarga JavaScript para construir la página. Por ello, un buscador puede recibir inicialmente una versión sin texto, título ni descripción.

Por qué el CSR plantea un problema de SEO

Google puede volver después, ejecutar JavaScript y leer el contenido, pero esa segunda fase puede demorarse. Bing y los rastreadores sociales a menudo no ejecutan JavaScript, por lo que quizá nunca vean el contenido ni las vistas previas para compartir.

Es el mismo problema de React, Vue y Angular sin un framework de servidor: una propiedad del CSR, no de SolidJS en particular. El artículo sobre SEO para JavaScript ofrece el contexto completo.

La solución: SolidStart

SolidStart es el metaframework oficial de SolidJS, comparable con Next.js para React o Nuxt para Vue. Permite que el servidor entregue HTML terminado en la primera solicitud. Sus dos modos principales son:

• SSR (renderizado del lado del servidor): la página se construye en el servidor para cada solicitud; resulta adecuado para contenido que cambia con frecuencia.
• SSG (generación de sitios estáticos): las páginas se construyen durante el despliegue y se sirven como archivos; suele ser la opción más rápida para blogs, documentación y páginas de marketing.

Configuración del título y los metadatos

El paquete @solidjs/meta permite controlar <title>, la descripción y las etiquetas sociales mediante <Title>, <Meta> y <Link>. Con SSR de SolidStart, esas etiquetas aparecen en el HTML que leen los rastreadores.

Una distinción importante

SolidJS no es reanudable como Qwik. La reanudación es una arquitectura de Qwik; SolidJS usa hidratación ordinaria, aunque con menos trabajo que React. Para la indexación, ambos pueden incluir contenido en el HTML, pero los mecanismos no son equivalentes.

La pestaña Advanced explica SSR, SSG, streaming, la API de @solidjs/meta, los estados de error reales, la carga de datos en servidor y Core Web Vitals.

TL;DR — SolidJS ofrece reactividad granular mediante señales y no usa DOM virtual, pero de forma predeterminada funciona como una biblioteca CSR: entrega un contenedor vacío y plantea el mismo problema de indexación en la primera oleada que React sin framework de servidor. SolidStart lo resuelve: SSR, SSG mediante prerenderizado por ruta y SSR por streaming incluyen contenido y metadatos en la primera respuesta. Las etiquetas de cabecera se administran con @solidjs/meta (<Title>, <Meta> y <Link> dentro de <MetaProvider>), los estados HTTP reales se devuelven con <HttpStatusCode> y los datos se cargan en el servidor con createAsync para incorporarlos al HTML SSR. La precisión esencial es esta: SolidJS hidrata; NO es reanudable. La reanudación corresponde a Qwik. La reactividad granular optimiza las actualizaciones del cliente, no el arranque entre servidor y cliente; su posible ventaja SEO se concentra en Core Web Vitals —como INP y TBT— sobre un SSR convencional.

Arquitectura de SolidJS: diferencias reales

SolidJS usa un JSX que se parece al de React y primitivas similares a hooks (createSignal, createEffect, createMemo), pero su modelo de ejecución es fundamentalmente distinto:

• React vuelve a ejecutar toda la función del componente cuando cambia el estado y compara un DOM virtual para decidir qué debe actualizar.
• SolidJS compila JSX como operaciones del DOM real durante la construcción. Los componentes se ejecutan una sola vez; las señales reactivas conectan cada valor directamente con los nodos específicos del DOM que dependen de él. Cuando cambia una señal, Solid actualiza solo ese nodo, sin reconciliación ni costo de un DOM virtual.

Por ello, SolidJS suele aparecer cerca de los primeros puestos de js-framework-benchmark y su entorno de ejecución es mucho más ligero que el modelo de rerenderizado de React. La biblioteca ocupa aproximadamente 7 KB comprimida con gzip. Un entorno pequeño y actualizaciones selectivas explican su rendimiento, pero no modifican el modo de renderizado, que es el factor decisivo para el SEO.

CSR predeterminado: el problema de SEO

Si se construye solo con SolidJS, sin SolidStart, se obtiene una aplicación renderizada del lado del cliente:

1. El servidor envía index.html con un cuerpo casi vacío, normalmente un <div id="root"></div> y una etiqueta de script.
2. El navegador descarga el paquete de JS, ejecuta el código reactivo de Solid y completa el DOM.
3. La primera oleada de Googlebot encuentra el contenedor vacío, sin contenido ni metadatos.
4. La segunda oleada de Googlebot, es decir, la cola de renderizado, termina por ejecutar el JS y ver el contenido; el plazo es impredecible y puede ir de horas a semanas.
5. Bing, los rastreadores sociales y los bots sin JS quizá nunca vean el contenido.

Este es el proceso de renderizado en dos oleadas y afecta a cualquier SPA con CSR. Sus consecuencias prácticas son una indexación inicial lenta del contenido nuevo, títulos y descripciones ausentes del HTML sin procesar —con fragmentos erróneos o vacíos en las SERP— y errores blandos de página no encontrada, porque una aplicación CSR no puede devolver un HTTP 404 real: el servidor siempre responde 200 con el contenedor de la aplicación.

SolidStart: la solución

SolidStart (1,0, estable) es el metaframework oficial de SolidJS, construido sobre Vinxi (Vite + Nitro). Ofrece:

• Enrutamiento isomórfico basado en archivos: los archivos de src/routes/ se asignan a URL (src/routes/blog/[slug].tsx → /blog/:slug). Debe precisarse una corrección: SolidStart no incluye de forma integrada un router ni una biblioteca de metadatos. Su documentación dice: “SolidStart itself does not ship with a Router or Metadata library. Rather, it leaves that open for you to use any library you want.” (traducción) «SolidStart no incluye un router ni una biblioteca de metadatos; deja abierta la posibilidad de usar la biblioteca que se prefiera». El enrutamiento y el comportamiento de @solidjs/meta descritos aquí proceden de añadir explícitamente @solidjs/router y @solidjs/meta. Las plantillas oficiales incorporan ambos paquetes, por lo que puede parecer automático; conviene revisar package.json en vez de suponer que forman parte del framework.
• Varios modos de renderizado elegidos por ruta: CSR, SSR —sincrónico, asincrónico o por streaming— y SSG o prerenderizado de rutas. Un proyecto de SolidStart no es «SSR» o «CSR» en su conjunto: cada ruta selecciona su modo. Deben comprobarse la configuración y el HTML resultante de la ruta específica, sin presuponer que todo el sitio heredó la misma opción.
• Funciones de servidor: la directiva "use server" permite código de servidor con un patrón similar a RPC, como acceso a datos y bases de datos.
• Adaptadores para Cloudflare y Vercel; también para Netlify, Deno, Node y alojamiento estático.

Nota de versión: esta explicación refleja la documentación vigente de SolidStart 1,0, que se presenta como beta y se actualizó por última vez el 28/4/2026. Antes de considerar permanente cualquier API, deben confirmarse los detalles en la documentación correspondiente a la versión utilizada.

SSR, SSG y streaming desde la perspectiva del SEO

• SSR —sincrónico, asincrónico o por streaming, que SolidStart identifica como submodos distintos— entrega todo el contenido en la primera solicitud y permite indexarlo en la primera oleada. Resulta adecuado para páginas que cambian con frecuencia.
• SSG (prerenderizado de rutas) construye el HTML durante el despliegue. Ofrece TTFB y LCP bajos, admite caché en CDN y evita trabajo del servidor en cada solicitud. Es apropiado para blogs, documentación y páginas de marketing. Las rutas prerenderizadas se configuran en app.config.ts:

// app.config.ts
import { defineConfig } from "@solidjs/start/config";

export default defineConfig({
  server: {
    prerender: {
      routes: ["/", "/about", "/blog"],
    },
  },
});

• SSR por streaming envía el HTML de forma progresiva para mejorar el TTFB en páginas con muchos datos; Google renderiza toda la salida transmitida.
• CSR es adecuado para paneles autenticados y herramientas que no necesitan posicionarse, pero no para contenido público.

Gestión de etiquetas de cabecera con @solidjs/meta

El paquete @solidjs/meta equivale en SolidJS a React Helmet o al <Head> de Next.js. Admite SSR y funcionamiento asincrónico. La aplicación debe envolverse con <MetaProvider> para recopilar las etiquetas durante el SSR; después se definen las etiquetas de cada página dentro de los componentes de ruta:

// src/routes/about.tsx
import { Title, Meta, Link } from "@solidjs/meta";

export default function AboutPage() {
  return (
    <>
      <Title>About Us — My Site</Title>
      <Meta name="description" content="Learn more about us." />
      <Link rel="canonical" href="https://example.com/about" />
      <Meta property="og:title" content="About Us" />
      <Meta property="og:description" content="Learn more about us." />
      <Meta property="og:image" content="https://example.com/og-about.jpg" />
      <main>...</main>
    </>
  );
}

Los componentes disponibles son <Title>, <Meta>, <Link>, <Style>, <Base> y el contenedor <MetaProvider>. La deduplicación está integrada: las etiquetas <Meta> con el mismo atributo name sustituyen las definiciones superiores. Gana la más profunda y específica, también durante el SSR. Por tanto, un título predeterminado en la raíz y las sustituciones de cada página funcionan de la manera prevista.

La documentación incluye una advertencia directa: no deben añadirse etiquetas <title> sin procesar a los archivos del servidor, porque sustituyen la función de @solidjs/meta. Debe usarse siempre el componente <Title>, no un título HTML escrito a mano en la plantilla del servidor.

Datos estructurados (JSON-LD)

Google admite JSON-LD tanto en el HTML sin procesar como cuando JavaScript lo inyecta, pero el JSON-LD generado mediante SSR es la opción más confiable. En SolidStart se renderiza en el componente de ruta:

export default function ArticlePage() {
  const schema = {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "My Article",
    "author": { "@type": "Person", "name": "Author Name" },
  };

  return (
    <>
      <script
        type="application/ld+json"
        innerHTML={JSON.stringify(schema)}
      />
      <article>...</article>
    </>
  );
}

Con SSR habilitado, el JSON-LD aparece en el HTML renderizado por el servidor, el enfoque preferible para que funcione de manera confiable con todos los rastreadores. Debe validarse con la Prueba de resultados enriquecidos o la herramienta de inspección de URL.

Hidratación, no reanudación

La hidratación es el proceso por el cual, después de que el SSR entrega el HTML renderizado, el framework se conecta al DOM existente para volverlo interactivo: descarga el paquete de JS, ejecuta el código, concilia el estado con los nodos existentes y añade detectores de eventos. SolidJS usa hidratación, el mismo mecanismo fundamental que hydrate de React, createSSRApp de Vue o el SSR de Angular.

La reanudación, arquitectura de Qwik, es distinta: el servidor serializa el estado de ejecución del framework dentro del HTML y el cliente continúa desde ese punto sin volver a ejecutar los componentes; la página es interactiva antes de que se ejecute cualquier JS.

Debe descartarse un mito: a veces se confunde la reactividad granular de SolidJS con la reanudación porque ambas evitan «volver a ejecutar» componentes en el sentido tradicional. No son equivalentes. La reactividad granular optimiza las actualizaciones del cliente; la reanudación es un mecanismo de arranque entre servidor y cliente. SolidJS todavía descarga y ejecuta su entorno antes de que la página sea interactiva.

Para el SEO, tanto SSR con hidratación —SolidJS— como la reanudación —Qwik— incluyen HTML renderizado en la respuesta del servidor y favorecen la indexación. La diferencia afecta al tiempo hasta la interactividad y al INP en dispositivos lentos, donde Qwik tiene ventaja por su JS de arranque casi nulo. Para rastrear e indexar, el SSR de SolidStart ya es suficiente.

Core Web Vitals

Las ventajas del entorno de SolidJS pueden mejorar las métricas de Core Web Vitals en rutas con SSR, pero el efecto no es automático ni universal. Ninguna fuente primaria garantiza una hidratación barata ni mejores resultados para todas las rutas de Solid o SolidStart: el tamaño del paquete, la carga de datos, los scripts de terceros, el dispositivo y el modo real de renderizado determinan el costo. Los puntos siguientes describen el mecanismo por el que SolidJS puede ayudar; deben medirse las rutas propias para confirmarlo:

• LCP puede mejorar porque el elemento de contenido más grande está en el HTML renderizado por el servidor y no espera al JS.
• INP puede mejorar porque el entorno granular de Solid gestiona las interacciones con eficiencia, sin comparar un DOM virtual.
• CLS puede disminuir porque el contenido generado con SSR no se desplaza cuando se incorpora el JS tardío.

Conviene mantener una cautela: cifras como «SolidJS es aproximadamente un 70 % más rápido que el DOM virtual de React» proceden de pruebas sintéticas (js-framework-benchmark), no de datos de campo reales. Las CWV dependen mucho más de la calidad de la implementación, la carga de datos y el alojamiento que del framework. Estas cifras solo indican una tendencia; los datos propios deben medirse en CrUX y Search Console.

Enrutamiento, carga de datos y estados de error reales

Enrutamiento. SolidStart usa la History API de forma predeterminada. No debe usarse el enrutamiento con hash (#/page), que impide descubrir URL de manera confiable. El comportamiento de la barra final debe ser coherente y aplicarse con redirecciones del servidor, no solo con etiquetas canónicas.

Carga de datos para SEO. El contenido que debe posicionarse se carga en el servidor para incluirlo en el HTML SSR. Deben usarse createAsync y funciones de servidor, no onMount ni efectos del cliente, que se ejecutan después de enviar el HTML:

// Server-side data fetch — content lands in the initial HTML ✓
import { createAsync } from "@solidjs/router";
import { getPost } from "~/lib/api";

export const route = {
  load: ({ params }) => getPost(params.slug),
};

export default function BlogPost(props) {
  const post = createAsync(() => getPost(props.params.slug));
  return <article>{post()?.content}</article>;
}

Estados de página no encontrada reales. Una ruta comodín junto con <HttpStatusCode> de @solidjs/start establece en el servidor el código real de la respuesta HTTP: un 404 verdadero en lugar de un 404 blando:

// src/routes/[...404].tsx
import { HttpStatusCode } from "@solidjs/start";

export default function NotFound() {
  return (
    <>
      <HttpStatusCode code={404} />
      <h1>Page Not Found</h1>
    </>
  );
}

Sitemaps, robots.txt y SEO internacional

• robots.txt: se añade public/robots.txt en la raíz del proyecto y se incluye la ubicación del sitemap. No deben bloquearse las rutas /api/ utilizadas para cargar datos mediante XHR.
• Sitemap: el complemento externo solid-start-sitemap, de madaxen86, genera sitemap.xml durante la construcción y admite rutas dinámicas mediante asignación de parámetros o una ruta de API en tiempo de ejecución.
• SEO internacional: se emite hreflang con <Link rel="alternate" hreflang="…"> de @solidjs/meta y se prefiere una estructura de subdirectorios (/en/, /fr/) a subdominios o parámetros de consulta.

Errores comunes de SEO en SolidJS

1. Ejecutar CSR de SolidJS sin SSR o SSG de SolidStart.
2. Cargar contenido posicionable en onMount o en efectos del cliente.
3. Omitir el contenedor <MetaProvider>; las etiquetas no se renderizarán con SSR.
4. Añadir etiquetas HTML <title> sin procesar en las plantillas del servidor, lo que sustituye la salida de @solidjs/meta.
5. Usar enrutamiento basado en hash.
6. Servir errores blandos de página no encontrada sin <HttpStatusCode>.
7. Bloquear rutas de API en robots.txt.
8. No asignar huellas a los recursos JS; Google almacena los scripts en caché de forma intensiva.
9. Ocultar contenido tras un clic, acordeón o pestaña que nunca se carga automáticamente en el DOM.
10. Suponer que SSR funciona sin comprobarlo mediante el código fuente o la inspección de URL.
11. Suponer que @solidjs/router y @solidjs/meta vienen integrados con SolidStart. No es así: su documentación indica que “does not ship with a Router or Metadata library” (traducción) «no incluye un router ni una biblioteca de metadatos». Las plantillas oficiales añaden ambos, pero una configuración desde cero o personalizada debe instalarlos explícitamente.
12. Considerar que todo el proyecto es «SSR» o «CSR». SolidStart configura el modo por ruta, por lo que una ruta supuestamente renderizada por el servidor podría no estarlo.

Contexto dentro del SEO técnico

SolidJS pertenece al subgrupo de frameworks de JavaScript junto con Qwik, dentro del grupo más amplio de SEO para JavaScript. El paralelo más cercano es SEO para React: SolidJS comparte con React el uso de JSX y el problema de CSR predeterminado, pero lo corrige con SolidStart en vez de Next.js y funciona sin DOM virtual. Para entender cómo Google ve el contenido generado, pueden consultarse renderizado y rastreo.

Resumen de IA

Síntesis de la perspectiva Advanced:

• SolidJS ofrece reactividad granular y no usa DOM virtual. Los componentes se ejecutan una vez y las señales actualizan solo los nodos exactos que cambian. Su entorno es pequeño —unos 7 KB— y suele ocupar puestos altos en js-framework-benchmark, por delante del modelo de rerenderizado de React.
• SolidJS sin SolidStart usa CSR de forma predeterminada y entrega un contenedor HTML vacío. Presenta el mismo problema de indexación en la primera oleada que React, Vue o Angular sin servidor: Googlebot no ve contenido al principio, el renderizado queda en cola durante horas o semanas, y Bing o los rastreadores sociales quizá nunca lo vean. También existe riesgo de errores 404 blandos porque CSR no puede devolver un 404 real.
• SolidStart resuelve el problema por ruta. El metaframework ofrece CSR, SSR sincrónico, asincrónico o por streaming y SSG por ruta; no convierte todo el proyecto a SSR de manera predeterminada. Las rutas SSR o SSG incluyen contenido y metadatos en la primera respuesta. Debe comprobarse cada ruta en lugar de suponer que la cobertura es general.
• El router y los metadatos no vienen integrados. La documentación de SolidStart indica que no incluye un router ni una biblioteca de metadatos. @solidjs/router y @solidjs/meta son adiciones explícitas que incorporan las plantillas oficiales.
• Etiquetas de cabecera con @solidjs/meta: <Title>, <Meta> y <Link> dentro de <MetaProvider>; la deduplicación funciona con SSR y no deben usarse etiquetas <title> sin procesar en archivos del servidor.
• Estados de error reales con <HttpStatusCode>; datos en el servidor con createAsync, no onMount; enrutamiento con History API, sin rutas hash; y JSON-LD renderizado en el componente de ruta.
• Precisión esencial: SolidJS hidrata; NO es reanudable. La reanudación pertenece a Qwik. La reactividad granular optimiza las actualizaciones del cliente, no el arranque. SSR con hidratación y la reanudación sirven para indexar; Qwik conserva una ventaja en tiempo hasta la interactividad.
• La mejora de CWV es posible, no segura, en rutas con SSR. LCP, INP y CLS pueden mejorar, pero las diferencias de las pruebas son sintéticas y los datos de campo dependen de la implementación, los datos y el alojamiento, no solo del framework.

Documentación oficial

Documentación de fuente primaria de Google y del equipo de SolidJS.

Google — JavaScript SEO

• Understand JavaScript SEO Basics — proceso de rastreo → renderizado → indexación y funcionamiento de las dos oleadas.
• Dynamic Rendering as a Workaround — motivos por los que Google dejó de recomendar el renderizado dinámico frente a SSR, renderizado estático e hidratación.
• SEO Guide for Web Developers — fundamentos dirigidos a quienes desarrollan sitios web.

SolidJS / SolidStart

• SolidJS documentation — página principal de la documentación oficial.
• Fine-Grained Reactivity — modelo de señales y actualización de nodos individuales del DOM.
• SolidStart — metaframework, SSR, streaming, enrutamiento y funciones de servidor.
• SolidStart — Head and Metadata — gestión de etiquetas de título, metadatos y enlaces para SEO.
• SolidStart — Route Pre-rendering — configuración de SSG.

@solidjs/meta

• solid-meta GitHub repository — código fuente y referencia de la API.
• @solidjs/meta on npm — paquete publicado.
• Title component docs y Meta component docs — documentación de ambos componentes.

Citas de la fuente

Declaraciones públicas de Google sobre SEO para JavaScript y explicaciones del equipo de SolidJS.

Google: procesamiento de aplicaciones JavaScript

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traducción) «Google procesa las aplicaciones web JavaScript en tres fases principales: 1. Rastreo, 2. Renderizado, 3. Indexación». — Google Search Central. Understand JavaScript SEO Basics
• “It’s fine to use JavaScript to inject links into the DOM, as long as such links follow the best practices for crawlable links.” (traducción) «Se puede usar JavaScript para insertar enlaces en el DOM, siempre que respeten las prácticas recomendadas para enlaces rastreables». — Google Search Central; debe usarse <a href>, no onclick ni javascript:void(0). Understand JavaScript SEO Basics
• “You shouldn’t use JavaScript to change the canonical URL to something else than the URL you specified as the canonical URL in the original HTML.” (traducción) «No debe usarse JavaScript para cambiar la URL canónica por una distinta de la indicada como canónica en el HTML original». — Google Search Central. Understand JavaScript SEO Basics
• “Use the History API to implement routing between different views of your web app.” (traducción) «Debe usarse la History API para implementar el enrutamiento entre las distintas vistas de una aplicación web». — Google Search Central; es decir, sin enrutamiento mediante fragmentos o hash. Understand JavaScript SEO Basics

Equipo de SolidJS: explicación de la reactividad granular

• La documentación de cabecera y metadatos de SolidStart advierte: “Be sure to avoid adding any normal <title /> tags in any server files, as they would override the functionality of @solidjs/meta.” (traducción) «Debe evitarse añadir etiquetas <title /> normales a archivos del servidor, ya que sustituirían la función de @solidjs/meta». SolidStart — Head and Metadata

Lista de comprobación de SEO para SolidJS

Comprobaciones para confirmar que un sitio de SolidJS es rastreable, indexable y rápido:

• Se usa SolidStart con SSR o SSG, no SolidJS sin framework en modo CSR.
• Ver código fuente muestra contenido real y enlaces <a href> en el HTML sin procesar, no solo <div id="root"></div>.
• La aplicación está dentro de <MetaProvider> para que las etiquetas de cabecera se rendericen durante el SSR.
• <Title> y <Meta name="description"> se definen por ruta mediante @solidjs/meta.
• No hay etiquetas <title> sin procesar en archivos del servidor, porque sustituyen la salida de @solidjs/meta.
• Las etiquetas de Open Graph y Twitter se incluyen mediante <Meta property="og:…"> para generar vistas previas sociales.
• La canónica se establece con <Link rel="canonical"> y no se modifica con JS después de la carga.
• El enrutamiento usa la History API, sin rutas hash (#/page).
• El contenido posicionable se carga con createAsync o funciones de servidor, no con onMount.
• Las páginas inexistentes devuelven un 404 real mediante <HttpStatusCode code={404} />.
• Existe public/robots.txt, apunta al sitemap y no bloquea las rutas de datos /api/.
• Se genera un sitemap XML, por ejemplo con solid-start-sitemap, que usa URL canónicas.
• El JSON-LD se renderiza en el componente de ruta y aparece en el HTML SSR.
• Inspección de URL de Search Console confirma que el HTML generado coincide.
• Las Core Web Vitals de campo se revisan en CrUX o Search Console, no solo en pruebas de laboratorio.

Modelos mentales

1. Biblioteca frente a metaframework. SolidJS, la biblioteca, determina cómo se actualiza la interfaz; SolidStart, el metaframework, determina dónde se renderiza. El segundo gobierna el SEO. SolidJS sin metaframework = CSR = contenedor vacío. SolidStart con SSR o SSG = contenido en el HTML. Debe identificarse cuál se está desplegando realmente.

2. Escala de modos de renderizado. En cada ruta se elige el primer nivel que permita el contenido: SSG —estático, más rápido y apropiado para contenido estable— → SSR —dinámico, por solicitud— → SSR por streaming —para muchos datos— → CSR —solo para vistas autenticadas que no deben posicionarse—. Los primeros niveles suelen favorecer tanto a los rastreadores como a Core Web Vitals.

3. Dos oleadas, un objetivo. Google rastrea el HTML sin procesar en la primera oleada y renderiza en la segunda, que pasa por una cola. El objetivo del SSR de SolidStart es completar el contenido en la primera para no depender de una segunda oleada impredecible.

4. Hidratación ≠ reanudación. SolidJS hidrata —descarga → ejecución → conexión—. Qwik reanuda, sin volver a ejecutar. La reactividad granular acelera las actualizaciones posteriores a la hidratación; no elimina la hidratación. Esta diferencia evita clasificar SolidJS de forma incorrecta.

5. Carga en servidor para todo lo que deba posicionarse. Si el contenido se obtiene en onMount, llega después de enviar el HTML y no es visible en la primera oleada. Debe obtenerse con createAsync o funciones de servidor para incluirlo en la respuesta SSR.

SolidJS SEO: hoja de referencia rápida

SolidJS frente a SolidStart

Componentes de @solidjs/meta

Prácticas recomendadas y errores

• ✅ Usar <Title> de @solidjs/meta. ❌ Insertar <title> sin procesar en archivos del servidor.
• ✅ Enrutar con History API. ❌ Enrutar con hash (#/page).
• ✅ Usar createAsync o funciones de servidor para datos posicionables. ❌ Obtenerlos con onMount.
• ✅ Usar <HttpStatusCode code={404} />. ❌ Servir un 404 blando (200 + contenedor).

Mitos y correcciones

• ❌ «SolidJS es reanudable como Qwik». → Hidrata con poco costo; solo Qwik reanuda.
• ❌ «SolidJS es malo para el SEO». → El problema es CSR sin servidor; SSR o SSG de SolidStart permite indexar.
• ❌ «Google no puede leer SolidJS». → Puede hacerlo con Chromium moderno; el riesgo es la demora de la segunda oleada, que SSR elimina.

Errores de SEO en SolidJS que deben evitarse

Publicar contenido con CSR de SolidJS sin SolidStart

Por qué es incorrecto: la primera respuesta es un contenedor de aplicación, por lo que los rastreadores no reciben de inmediato el contenido ni los metadatos. Alternativa: usar SSR de SolidStart o prerenderizado en cada ruta pública que deba posicionarse.

Obtener datos posicionables en onMount

Por qué es incorrecto: onMount se ejecuta después de la respuesta del servidor y deja el contenido fuera del HTML sin procesar. Alternativa: obtener los datos con createAsync, cargadores de ruta o funciones de servidor para que estén presentes durante el SSR.

Omitir MetaProvider o añadir un título sin procesar

Por qué es incorrecto: sin MetaProvider, @solidjs/meta no puede recopilar etiquetas para SSR; un <title> sin procesar en un archivo del servidor puede sustituir su salida. Alternativa: envolver la aplicación con MetaProvider y usar <Title>, <Meta> y <Link> de forma coherente.

Usar rutas hash o errores blandos de página no encontrada

Por qué es incorrecto: las rutas #/page se descubren con dificultad y una página inexistente que devuelve HTTP 200 parece un 404 blando. Alternativa: usar rutas de History API y establecer el estado real con <HttpStatusCode code={404} />.

Llamar reanudación a la reactividad granular

Por qué es incorrecto: SolidJS hidrata; no reanuda el estado de ejecución del servidor como Qwik. Alternativa: describir su ventaja como actualizaciones eficientes del cliente y comprobar después el renderizado real del servidor y el rendimiento de campo.

Confiar en SSR sin revisar la respuesta

Por qué es incorrecto: una ruta puede usar SolidStart y aun así dejar texto, metadatos o JSON-LD en código exclusivo del cliente. Alternativa: revisar el código fuente y la respuesta inicial de red después de cada cambio de renderizado o carga de datos.

Auditoría de una respuesta de SolidStart desde la línea de comandos

macOS / Linux: inspección del estado, los metadatos y el contenido del cuerpo

URL="https://example.com/blog/example-post"
curl -sSIL "$URL" | sed -n '1,12p'
curl -sSL "$URL" -o /tmp/solidstart-page.html
grep -Ei '<title>|name="description"|rel="canonical"|<h1|application/ld\+json' \
  /tmp/solidstart-page.html

La primera respuesta de una ruta activa debe tener un estado real de éxito. El HTML sin procesar debe contener el título, la descripción, la canónica, el H1 y cualquier JSON-LD de la ruta sin ejecutar JavaScript.

Windows PowerShell: ejecución de la misma comprobación del HTML sin procesar

$url = "https://example.com/blog/example-post"
$response = Invoke-WebRequest -Uri $url
$response.StatusCode
$response.Content | Select-String -Pattern '<title>|name="description"|rel="canonical"|<h1|application/ld\+json'

Comprobación de que una ruta inexistente devuelve un 404 real

curl -sS -o /dev/null -w '%{http_code}\n' \
  'https://example.com/this-route-should-not-exist'
# Expected: 404

Consola de DevTools: listado de señales renderizadas en la cabecera

({
  title: document.title,
  description: document.querySelector('meta[name="description"]')?.content,
  canonical: document.querySelector('link[rel="canonical"]')?.href,
  h1: [...document.querySelectorAll('h1')].map((node) => node.textContent.trim()),
})

El fragmento se ejecuta en la consola del navegador y se compara con el resultado de la línea de comandos. Si una señal existe solo en el DOM renderizado, todavía se añade después de la respuesta HTML inicial.

Medición del rendimiento SEO de SolidStart con datos de campo

Largest Contentful Paint por tipo de ruta

Métrica: LCP de campo para contenido público, marketing y otros grupos de rutas representativos.

Qué indica: si el contenido visible más grande llega con rapidez a usuarios reales. SSR solo ayuda si los datos, las imágenes y el alojamiento completan el proceso de forma eficiente.

Cómo obtenerla: usar CrUX o el informe de Core Web Vitals de Search Console, segmentado por grupos de URL similares cuando sea posible.

Referencia o intervalo realista: usar la clasificación vigente de datos de campo de Google y la línea base del sitio antes de publicar; una prueba sintética del framework no sustituye los datos de usuarios.

Frecuencia: cada mes y después de que un cambio importante de renderizado, alojamiento o entrega de imágenes haya acumulado datos de campo.

Interaction to Next Paint

Métrica: INP de campo en rutas interactivas de SolidJS.

Qué indica: si las actualizaciones granulares producen interacciones reales ágiles, más allá de pruebas favorables de la biblioteca.

Cómo obtenerla: usar CrUX o Search Console y reproducir después los grupos de páginas deficientes con herramientas de rendimiento del navegador para encontrar la interacción prolongada.

Referencia o intervalo realista: comparar con la clasificación vigente de Google y la línea base del grupo de rutas. El framework por sí solo no establece un intervalo garantizado.

Frecuencia: cada mes y después de añadir componentes grandes del cliente o scripts de terceros.

Cumulative Layout Shift

Métrica: CLS de campo en rutas con SSR y streaming.

Qué indica: si la hidratación, los datos transmitidos, las imágenes o componentes tardíos desplazan contenido después de mostrar el HTML inicial.

Cómo obtenerla: usar CrUX o Search Console para el KPI permanente y DevTools para diagnosticar las plantillas afectadas.

Referencia o intervalo realista: usar la clasificación vigente de datos de campo de Google y comparar las nuevas versiones con la línea base establecida de la ruta.

Frecuencia: cada mes y después de cambiar límites de streaming, dimensiones de imágenes o componentes exclusivos del cliente.

Herramientas para el SEO de SolidJS

• Ver código fuente en el navegador: la comprobación más rápida de SSR. Si el contenido está en el HTML sin procesar y no solo en <div id="root"></div>, SSR funciona.
• Google Search Console — Inspección de URL: referencia para saber qué rastreó y renderizó Googlebot; «Ver página probada → HTML» muestra la salida renderizada.
• Prueba de resultados enriquecidos: valida los datos estructurados JSON-LD de una página de SolidStart.
• Bing Webmaster Tools — Inspección de URL: muestra la versión renderizada por Bing, importante porque su tratamiento de JavaScript es más conservador que el de Google.
• Ahrefs Site Audit con renderizado de JS: rastrea un sitio de SolidJS como un rastreador con renderizado y detecta metadatos ausentes o enlaces no rastreables.
• solid-start-sitemap: genera el sitemap XML de SolidStart durante la construcción.
• CrUX o informe de Core Web Vitals de Search Console: confirma que la posible ventaja de INP, LCP y CLS llega a usuarios reales, no solo al laboratorio.
• Pestaña Red de DevTools: permite inspeccionar el cuerpo de la respuesta HTML inicial y distinguir contenido SSR de contenido inyectado después de ejecutar JS.

Evaluación: SEO para SolidJS

Cinco preguntas breves sobre SolidJS, SolidStart y la indexación de un sitio creado con Solid. Se selecciona una respuesta en cada caso y después se comprueba el resultado.

Recursos recomendados

Mis artículos

• JavaScript SEO Issues & Best Practices — guía completa sobre renderizado, paridad del DOM, enlaces rastreables e indexación de contenido creado con JS; es la base para un sitio de SolidJS.
• Core Web Vitals: A Complete Guide — explicación de lo que miden INP, LCP y CLS y de su relación con el SEO, las métricas en las que puede ayudar el entorno de SolidJS.
• The Beginner’s Guide to Technical SEO — lugar que ocupan el renderizado y la elección de framework en el panorama general.

Mis presentaciones

• SMX Advanced 2018: SEO for JavaScript Frameworks (SlideShare) — recorrido por la forma en que los buscadores tratan los frameworks de JS.
• JavaScript SEO — Ungagged 2019 (SlideShare) — modos de renderizado, proceso en dos oleadas y diagnóstico.

Recursos del sector

• SolidStart — Head and Metadata — guía de fuente primaria sobre @solidjs/meta y etiquetas de cabecera con SSR.
• SolidStart — Route Pre-rendering — configuración de SSG en app.config.ts.
• SolidJS — Fine-Grained Reactivity — señales y actualizaciones sin DOM virtual según la documentación.
• Google — Understand JavaScript SEO Basics — reglas de Google sobre enlaces rastreables, canónicas y proceso de renderizado.
• solid-start-sitemap plugin — generación del sitemap XML de SolidStart durante la construcción.
• js-framework-benchmark (current results) — prueba de larga duración en la que SolidJS aparece cerca de los primeros puestos y por delante de React en tareas con muchas actualizaciones.

Registro de cambios