---\ntitle: Contenido legible sin JavaScript\ntype: technique\nnavHidden: true\nendorsement: recomendado\ndisciplines: aeo, seo\nscope: sitio\neffort: medio\nimpact: alto\ncreated: 2026-07-21T05:00:00Z\nupdated: 2026-08-23T19:10:16Z\nsummary: Entrega el texto de tu página en el HTML que envía el servidor, para que los rastreadores de IA que nunca ejecutan JavaScript puedan leerlo y citarlo.\n---\n\n# Contenido legible sin JavaScript\n\nEl contenido principal de tu página —los párrafos, encabezados, tablas y precios por los que vino el visitante— debe estar presente en el HTML que tu servidor devuelve en la primera solicitud. La mejora mediante JavaScript está bien. El contenido que solo aparece después de ejecutar JavaScript es invisible para la mayoría de los rastreadores de IA y, por tanto, para los asistentes que citan de ellos.\n\nA lo largo de esta página, supongamos que Fernwood reconstruyó su sitio de marketing como una aplicación de una sola página. En un navegador parece completo. Ver el código fuente muestra un <div id=\"root\"></div> casi vacío. Ese contenedor vacío es lo que reciben GPTBot, ClaudeBot, PerplexityBot y rastreadores similares.\n\n## Por qué funciona\n\nLos buscadores tradicionales resolvieron en gran medida esto: Google renderiza JavaScript antes de indexar. Los motores de respuestas no. Los rastreadores que alimentan ChatGPT, Claude, Perplexity y sistemas similares suelen obtener la respuesta HTML en bruto y se detienen: no esperan a que tu framework hidrate, no ejecutan tu bundle y no siguen rutas del lado del cliente. La propia comparación de rastreo de Silktide (página renderizada frente a HTML en bruto) se basa exactamente en ese comportamiento; consulta Contenido sin JavaScript.\n\nEl modo de fallo es silencioso y total:\n\n- Una página que posiciona bien en Google puede estar completamente ausente de las respuestas de IA, porque los asistentes nunca recibieron el texto.\n- Cualquier otra inversión en AEO de esa página —datos estructurados, fechas legibles por máquina, redacción con la respuesta primero— no vale nada si el rastreador nunca ve el contenido al que aluden esas señales.\n- Los visitantes, cuando los scripts fallan o están bloqueados, ven el mismo contenedor vacío, y el First Contentful Paint (FCP) empeora incluso cuando los scripts acaban funcionando.\n\nEs un problema de arquitectura del sitio, no de edición de páginas. Arreglar a mano una URL no corrige la plantilla que genera las siguientes cien.\n\n## Cómo comprobar qué ve un rastreador\n\nAntes de cambiar nada, confirma el problema. Tres formas, de más sólida a menos:\n\n1. La comprobación de Silktide. Contenido sin JavaScript compara el texto significativo del cuerpo de la página renderizada con el HTML en bruto capturado en el momento del rastreo. Señala páginas donde el texto en bruto es a la vez inferior a ~10% del texto renderizado y diminuto en términos absolutos: un contenedor realmente vacío, no una página que simplemente se mejora a sí misma.\n2. Ver código fuente, no los Elementos de DevTools. En el navegador, "Ver código fuente de la página" muestra lo que envió el servidor. El panel Elementos muestra el DOM después de que se ejecutó JavaScript. Si el texto de tu artículo está en Elementos pero ausente en Ver código fuente, los rastreadores que omiten JS no lo verán.\n3. Obtener la página sin navegador. Desde una terminal: curl -sL https:\/\/fernwood.example\/pricing | head. O usa un navegador de solo texto. Si la tabla de precios no aparece en esa salida, tampoco aparecerá para el rastreador.\n\nComprueba también que el rastreador tenga permitido el acceso en absoluto: una respuesta HTML perfecta es inútil si robots.txt bloquea al rastreador de IA o si un cortafuegos lo bloquea en la práctica (Rastreadores de IA bloqueados en la práctica).\n\n## Cómo solucionarlo\n\nElige el enfoque que se adapte a tu stack. Los tres producen el mismo resultado: la primera respuesta HTML contiene el contenido.\n\n### 1. Renderizado del lado del servidor (SSR)\n\nEl servidor renderiza cada página a HTML bajo demanda; después JavaScript hidrata para la interactividad. Es el camino por defecto en los frameworks que ya lo soportan:\n\n- Next.js: usa el App Router con Server Components, o getServerSideProps / getStaticProps en el Pages Router. No publiques una raíz solo de cliente que obtenga el contenido tras el montaje.\n- Nuxt: modo universal / SSR (el predeterminado), no ssr: false.\n- Remix, SvelteKit, Astro (modo SSR) y equivalentes: misma idea; la respuesta del documento incluye el texto del cuerpo.\n\nRegla general: si una obtención de datos en useEffect / onMounted es lo que pone el artículo en la página, mueve esa obtención de datos al servidor.\n\n### 2. Generación de sitio estático (SSG)\n\nPrecompila las páginas como HTML simple en el momento de la publicación. Ideal para contenido que no cambia por visitante: entradas de blog, documentación, páginas de marketing, precios. Astro, Eleventy, Hugo, Next.js output: 'export' y Nuxt generate producen archivos que un rastreador puede leer sin ningún JavaScript.\n\nSSG suele ser la victoria más barata para sitios de marketing y contenidos: sin coste de renderizado por solicitud, y el HTML en disco es exactamente lo que recibe el rastreador.\n\n### 3. Pre-renderizado como puente\n\nSi todavía no puedes cambiar de framework, un servicio de pre-renderizado o un paso en la build puede servir una instantánea HTML renderizada a los rastreadores (y a menudo a las visitas por primera vez) mientras la SPA sigue funcionando para las sesiones interactivas. Trátalo como un puente, no como destino: la actualidad de las instantáneas, la invalidación de caché y las rutas autenticadas se convierten en cargas de mantenimiento. Prefiere arreglar el modo de renderizado cuando puedas.\n\nLa propia guía de Google sobre SEO para JavaScript y Renderizado en la Web de web.dev cubren el mismo espectro —SSR, SSG y mejora progresiva— desde el lado de los motores de búsqueda.\n\n## Qué debe estar en el primer HTML\n\nNo cada píxel. El contenido que una cita reproduciría:\n\n- El cuerpo del artículo o de la página: encabezados, párrafos, listas, tablas.\n- Precios, límites y otros datos que quieras que los asistentes repitan.\n- Datos estructurados en un bloque <script type=\"application\/ld+json\"> en el HTML inicial: el JSON-LD inyectado solo tras la hidratación es tan invisible como la prosa.\n- URL canónica, título y meta descripción en <head>.\n\nJavaScript puede seguir controlando menús, personalización, gráficos que mejoran una tabla ya presente y funciones progresivas. La comprobación de Silktide es deliberadamente indulgente con la mejora: aprueban las páginas que sirven su contenido principal como HTML y superponen el comportamiento encima.\n\n## Patrones de fallo comunes\n\n- SPA solo de cliente: Create React App, SPA con Vite y configuraciones similares que entregan un contenedor vacío y obtienen rutas en el navegador. La solución es SSR/SSG, no más código del lado del cliente.\n- Contenido detrás de "Cargar más" o pestañas que nunca aparecen en el HTML. Si la única forma de llegar a la sección tres es un clic que la obtiene, los rastreadores nunca llegarán a la sección tres. Prefiere URL reales o incluye el contenido en la respuesta inicial.\n- "Funciona en Google, así que estamos bien." El renderizado de Googlebot no sustituye a la legibilidad para rastreadores de IA. Aprobar Google y fallar con GPTBot es una división común e invisible.\n- Bloquear al rastreador y culpar a JavaScript. Revisa siempre el acceso del rastreador de IA y la alcanzabilidad efectiva junto con esta técnica.\n\n## Cómo ayuda Silktide\n\n- Contenido sin JavaScript señala páginas indexables cuyo HTML en bruto es un contenedor vacío en comparación con la página renderizada.\n- Acceso del rastreador de IA y Rastreadores de IA bloqueados en la práctica cubren el fallo relacionado: el rastreador no recibe el HTML en absoluto.\n\nSi Silktide no puede leer tu contenido sin JavaScript, tampoco podrán los asistentes de los que quieres que te citen.\n\n## Relacionados\n\n- Contenido sin JavaScript: la comprobación de Silktide\n- Política de acceso del rastreador de IA: permite la entrada del rastreador antes de preocuparte por qué HTML recibe\n- Acceso del rastreador de IA\n- Velocidad de página y Core Web Vitals: el renderizado solo del lado del cliente suele perjudicar tanto la legibilidad para el rastreador como el LCP\n- llms.txt: índice comisariado opcional (inútil si las páginas enlazadas son contenedores vacíos)\n- Marcado de datos estructurados: también no sirve de nada si solo aparece tras la hidratación\n- Estructura de página con la respuesta primero: una vez que el rastreador puede ver la página, así es cómo escribirla\n- AEO\n- Conceptos básicos de SEO para JavaScript (Google Search Central)\n- Renderizado en la Web (web.dev)\n