Web de baja implicación: generación estática y caché HTML
En el diseño técnico de una web de baja implicación, hay que comprobar tanto el contenido del HTML inicial como la caché HTML de la CDN. Un TTFB de 0.8 segundos es un valor de referencia para mejorar el rendimiento; el alcance de la caché y su actualización tras los cambios también deben formar parte del diseño.
Si el HTML inicial incluye el contenido principal, se puede reducir la dependencia de la ejecución de JavaScript.
Google ejecuta JavaScript, por lo que el uso de React por sí solo no permite concluir que el rastreo haya fallado.
Un TTFB de 0.8 segundos o menos es un valor de referencia para mejorar el rendimiento y no indica el tiempo de carga total de la página.
Cloudflare CDN no almacena HTML en caché por defecto, por lo que hay que revisar las reglas de caché de las páginas públicas.
Para la caché HTML, se necesita excluir las páginas de inicio de sesión y definir una política de actualización tras modificar el contenido.
Para facilitar el rastreo de los sitios web de baja implicación, el HTML inicial debe incluir el contenido principal. La generación estática y la caché de HTML en la CDN son útiles para el contenido público. Sin embargo, alcanzar un TTFB de 0.8 segundos no basta para garantizar la visibilidad en las búsquedas.
La referencia para el valor de TTFB es el documento de web.dev actualizado el 18 de noviembre de 2025.
Condiciones técnicas que conviene revisar primero en los sitios web de baja implicación
En este artículo, los sitios web de baja implicación son aquellos donde se consulta brevemente la información necesaria. El renderizado y la velocidad de transferencia son aspectos que deben revisarse en estos sitios. Sin embargo, estos dos aspectos no explican por sí solos todas las diferencias de visibilidad en las búsquedas.
El rastreo es el proceso por el que un robot obtiene una página. La indexación es el proceso que prepara el contenido obtenido para que pueda aparecer en las búsquedas. Google explica que no todas las páginas rastreadas se incluyen en el índice. Guía de Google sobre el presupuesto de rastreo
Aspecto que revisar | Qué comprobar | Problema que se busca resolver
HTML inicial | Si la respuesta incluye el título y el contenido principal | Dependencia de una ejecución adicional para leer el contenido
Renderizado | Si el contenido aparece correctamente tras ejecutar JavaScript | Omisiones por errores de ejecución o bloqueos
TTFB | Tiempo que tarda en llegar la primera respuesta | Retrasos de conexión y de respuesta del servidor
Caché de HTML | Si la CDN reutiliza los documentos públicos | Coste de enviar solicitudes repetidas al servidor de origen
Estado de indexación | Cómo ha procesado Google esa URL | Confusión entre un rastreo correcto y la inclusión en las búsquedas
Por qué una página de React puede parecer un HTML vacío
El HTML inicial de una página de React depende de cómo esté implementada. El método que genera el contenido en el navegador se llama CSR. Con este método, la primera respuesta puede contener solo código para ejecutar, sin el contenido principal.
Google usa Chromium para ejecutar JavaScript. Después del rastreo, la página puede quedar a la espera del renderizado. Las páginas o los archivos bloqueados pueden quedar excluidos del renderizado. Además, no todos los robots ejecutan JavaScript. Guía básica de Google sobre SEO para JavaScript
Por tanto, no evalúe el estado del rastreo solo porque la página se vea bien. Compruebe primero si la respuesta inicial contiene el contenido principal. Puede consultar el resultado renderizado por Google con la inspección de URLs de Search Console.
Comparación entre generación estática y renderizado en el servidor
Puede elegir el método de generación de HTML según cómo se actualice el contenido público. La generación estática crea el HTML antes de recibir una solicitud. El renderizado en el servidor crea el HTML en el servidor cuando recibe una solicitud. Estos métodos también pueden usarse con React. Guía de web.dev sobre métodos de renderizado
Método | Cuándo se crea el HTML | Situaciones en las que conviene considerarlo | Aspectos operativos que revisar
Renderizado en el cliente CSR | Al ejecutar JavaScript en el navegador | Pantallas con mucha interacción del usuario | Ejecución y solicitudes necesarias hasta mostrar el contenido
Generación estática SSG | Durante la compilación o la creación del contenido | Documentos públicos que muestran el mismo contenido a todos los visitantes | Regeneración y despliegue después de los cambios
Renderizado en el servidor SSR | Al procesar la solicitud de una página | Pantallas que generan contenido actualizado para cada solicitud | Tiempo de consulta de datos y de generación de HTML
Prerenderizado | Al ejecutar la aplicación antes del despliegue para obtener el HTML | Cuando se quiere ofrecer de antemano el contenido inicial de una aplicación existente | JavaScript necesario para las funciones posteriores
La generación estática y la CDN cumplen funciones distintas. La generación estática es una decisión sobre cuándo crear el HTML. La CDN es una infraestructura para entregar y reutilizar contenido. El HTML creado en el servidor también puede almacenarse en la caché de la CDN si cumple las condiciones.
¿Qué significa un TTFB de 0.8 segundos?
TTFB es el tiempo que transcurre desde el inicio de la navegación hasta la llegada del primer byte de respuesta. web.dev propone 0.8 segundos o menos como objetivo orientativo para la mayoría de los sitios. No es lo mismo que el tiempo necesario para mostrar la página completa. TTFB tampoco es una métrica de Core Web Vitals. Explicación de TTFB en web.dev
TTFB incluye retrasos ajenos al procesamiento interno del servidor. La consulta DNS es el proceso que busca la dirección de conexión de un dominio. Las conexiones TCP y TLS también pueden tardar. Las redirecciones que envían a otra dirección también influyen.
· Tiempo de consulta DNS y preparación de la conexión
· Tiempo de viaje de la solicitud y la respuesta por la red
· Tiempo de consulta de datos y generación de HTML en el servidor de origen
· Tiempo de las redirecciones anteriores a la primera respuesta
El hecho de que el servidor esté en Seúl no basta para concluir que el TTFB será de más de 0.8 segundos. El resultado depende de la ubicación desde la que se accede y de si se reutiliza la conexión. Los rastreadores de Google usan principalmente direcciones IP de Estados Unidos. Sin embargo, también pueden acceder desde direcciones IP de otros países. Características técnicas de los rastreadores de Google
Los retrasos persistentes en las respuestas afectan a la capacidad de rastreo de Google. Los errores del servidor también pueden reducir el volumen de rastreo. Eso no significa que exista una regla que detenga el rastreo por superar una vez los 0.8 segundos. La calidad de las páginas y su frecuencia de actualización también influyen en la demanda de rastreo. Guía de Google sobre el presupuesto de rastreo
Por qué debe comprobar la caché de HTML en la CDN
La CDN de Cloudflare no almacena HTML en caché de forma predeterminada. Aunque las imágenes o el CSS estén en caché, debe comprobar por separado el documento que contiene el texto principal. Consulte la documentación de cada servicio para conocer el comportamiento predeterminado de otras CDN.
La CDN de Cloudflare no almacena HTML ni JSON en caché de forma predeterminada. Cloudflare, Comportamiento predeterminado de la caché
Esta frase significa que HTML y JSON no se incluyen de forma predeterminada entre los contenidos que se almacenan en caché. Puede incluir el HTML público mediante Cache Rules. El almacenamiento efectivo también depende de condiciones como las cabeceras de respuesta y las cookies. Comportamiento predeterminado de la caché de Cloudflare
La caché permite reutilizar respuestas almacenadas. Conectar una CDN no replica de inmediato todos los documentos por todo el mundo. Cloudflare almacena el contenido en caché en el centro de datos que atiende la solicitud. Si el contenido solicitado no está en caché, puede ser necesario consultar el servidor de origen. Guía de inicio de la caché de Cloudflare
Al aplicar reglas de caché al HTML público, excluya las páginas personalizadas. Cloudflare advierte de que almacenar HTML dinámico en caché puede hacer que se entregue información de otra persona. No almacene en caché las páginas de inicio de sesión ni de cuenta. Precauciones sobre Cache Everything de Cloudflare
Criterios para aplicar la caché según las condiciones de la página
El punto de partida para definir el alcance de la caché es si todos los visitantes ven el mismo contenido. Los textos explicativos públicos son adecuados para su reutilización compartida. Las respuestas cuyo contenido cambia según el estado de inicio de sesión deben tratarse por separado.
Condición de la página | Configuración que considerar | Aspectos que comprobar también
Ofrece el mismo texto explicativo a todos los visitantes | Generación estática y caché de HTML público | Regeneración y actualización de la caché después de los cambios
El contenido público incluye cifras que cambian con frecuencia | Separar los métodos de actualización del texto y de los datos variables | Momento de referencia de las cifras y qué se muestra si se produce un fallo
Necesita información pública actualizada en el momento de la solicitud | Considerar el renderizado en el servidor y la caché condicional | Retraso aceptable en la información
Pantallas de inicio de sesión, cuenta y pago | Excluirlas de la caché compartida de HTML | Cookies de autenticación y respuestas específicas de cada usuario
Ofrece documentos públicos en varios idiomas | URL por idioma y caché de cada documento | Enlaces entre traducciones y actualización por idioma
Cargar los datos en tiempo real más tarde facilita mantener estático el contenido principal. Sin embargo, no posponga la carga de todo el contenido esencial para las búsquedas. Podría contradecir el propósito de ofrecer HTML inicial.
Errores frecuentes y criterios de comprobación
Es fácil pasar por alto errores si se juzgan los resultados solo por los nombres de las tecnologías o las pantallas de configuración. Compruebe tanto el HTML real como las cabeceras de respuesta. Los siguientes estados deben distinguirse entre sí.
Conclusión frecuente | Criterio que debe comprobarse
Los robots de búsqueda no pueden leer los sitios de React | HTML inicial y resultado del renderizado de Google
Con un TTFB de 0.8 segundos, toda la página ya está visible | Tiempo desde la primera respuesta hasta que se muestra el contenido
Como se ha conectado una CDN, el HTML también está en caché | Estado de caché de la solicitud de HTML
Un archivo estático siempre contiene la información más reciente | Momento de la última generación y contenido desplegado
Si la respuesta es rápida, la inclusión en las búsquedas ya está completa | Estado de indexación en Search Console
Un único acierto de caché permite evaluar la velocidad global | Mediciones según la región de acceso y si hubo un acierto de caché
CF-Cache-Status de Cloudflare es una cabecera que muestra el estado de la caché. HIT significa que la respuesta se encontró en la caché. MISS significa que no estaba en la caché cuando llegó la solicitud y se obtuvo del servidor de origen. DYNAMIC indica que no se trató como contenido que debía almacenarse en caché. Explicación de las respuestas de caché de Cloudflare
Actualización de la caché después de modificar el contenido
Con los archivos estáticos y la caché de la CDN, también debe planificar cómo se reflejarán los cambios. Aunque modifique el contenido de origen, si la caché anterior permanece, se entregará el contenido antiguo. Si publica HTML y JSON juntos, el contenido de ambos formatos también debe coincidir.
Esta es la secuencia de comprobación cuando se mantienen documentos y archivos de datos juntos.
· Confirme los cambios en los datos de origen.
· Vuelva a generar el HTML y los archivos de datos a partir de la misma versión modificada.
· Despliegue los archivos nuevos y después actualice la caché de las URL modificadas.
· Vuelva a solicitar cada URL y compruebe que los cambios coincidan.
Cloudflare recomienda borrar la caché por URL. Borrar la caché elimina las respuestas almacenadas. La regeneración del HTML estático es una tarea aparte. Por tanto, integre la generación de archivos y la actualización de la caché en el mismo proceso de despliegue. Guía de Cloudflare para borrar la caché
Ajuste el intervalo de actualización al retraso de información que permita el contenido. No es necesario aplicar el mismo intervalo a los textos explicativos y a las cifras en tiempo real. Un periodo de validez corto de la caché no basta para resolver todos los problemas de actualización.
Criterios de hreflang para sitios multilingües
hreflang es información que relaciona las direcciones de un mismo contenido para distintos idiomas y regiones. No es una función que genere traducciones. Ayuda a Google a encontrar la versión lingüística adecuada para el visitante.
Ubicación de implementación | Forma de indicarlo | Qué comprobar al elegir
HTML | Incluir enlaces a idiomas alternativos en el head del documento | Si pueden gestionarse en la plantilla de cada página
Cabeceras HTTP | Indicarlo en la cabecera Link de la respuesta | Si las cabeceras pueden gestionarse en el servidor
Mapa del sitio | Indicar en el mapa del sitio la relación entre las URL de cada idioma | Si la lista de documentos puede gestionarse en conjunto
Google trata estos métodos de la misma manera. Por tanto, no es obligatorio incluirlo solo en el HTML. Cada documento debe indicar las versiones en otros idiomas e incluirse a sí mismo. Compruebe también los enlaces entre las páginas correspondientes. Guía de Google sobre páginas multilingües
Orden de comprobación de los resultados del despliegue
Después del despliegue, verifique por separado la entrega del contenido y el funcionamiento de la caché. Registre la región de medición y el estado de la caché junto con los valores de velocidad. Seguir este orden facilita identificar dónde está el problema.
· Revise la respuesta del documento HTML en las herramientas de desarrollo del navegador. Compruebe si incluye el contenido principal.
· Consulte el HTML renderizado en la inspección de URLs de Search Console. Revise también, por separado, el estado real de indexación.
· Compruebe las cabeceras de caché de la respuesta HTML. En Cloudflare, consulte CF-Cache-Status.
· Mida el mismo documento desde las principales regiones de acceso. Distinga entre solicitudes cuyo contenido no está en caché y solicitudes con acierto de caché.
· Modifique el contenido y compruebe el resultado de la actualización. Revise también si las páginas de inicio de sesión están excluidas de la caché.
Cloudflare advierte de que un uso excesivo de la caché de HTML dinámico puede impedir que funcione el inicio de sesión. No almacene en caché los formularios de inicio de sesión ni las páginas autenticadas. Después de los cambios, compruebe también que se conserven las cookies de autenticación. Guía de Cloudflare sobre problemas de inicio de sesión
Requisitos de implementación que debe transmitir a la IA al programar
Pida a la IA resultados verificables junto con los nombres de las tecnologías. Resulta útil especificar el contenido del HTML inicial y qué debe excluirse de la caché. El siguiente texto es un ejemplo de solicitud para crear páginas públicas de conocimiento.
Incluya el contenido principal de las páginas públicas de conocimiento en el HTML inicial.
Para los documentos públicos, considere primero la generación estática.
Explique por separado cómo se actualizarán los datos variables.
Compruebe si la CDN almacena el HTML en caché.
Excluya las páginas de inicio de sesión, cuenta y pago de la caché compartida.
Vincule la regeneración de archivos estáticos con la actualización de la caché cuando cambie el contenido.
Si hay páginas multilingües, configure los enlaces hreflang.
Indique cómo comprobar el HTML inicial, el estado de la caché y si se han reflejado los cambios.
Injoys
