SEO para webs estáticas: 8 problemas a tener en cuenta

Pero que sea más fácil de construir no significa necesariamente que sea más fácil de optimizar.

WordPress y otros CMS gestionan discretamente muchos aspectos básicos del SEO a través de plugins y funcionalidades integradas: desde etiquetas canonical y sitemaps hasta redirecciones, metadatos, schema y la gestión de errores 404.

Con un sitio web estático, gran parte de ese trabajo pasa a ser tu responsabilidad.

Para entender dónde suelen fallar las cosas en la práctica, los expertos del sector Suganthan Mohanadasan, Pedro Dias y Ryan Law han compartido sus experiencias creando y trabajando con sitios web estáticos.

Como dice Suganthan:

Eso no hace que los sitios estáticos sean malos para el SEO. Simplemente significa que necesitas saber qué solía hacer tu CMS por ti, y qué necesitas ahora construir, configurar y monitorizar por tu cuenta.

Los sitios web estáticos pueden ser rápidos y limpios a nivel técnico, pero también dejan más margen para que se pasen por alto pequeños errores de SEO, ya que no hay un CMS ni un plugin que gestione las cosas en segundo plano.

Esto se vuelve aún más importante con las webs creadas con vibe coding. La IA puede construir la página, pero no sabrá necesariamente qué convenciones de SEO quieres que siga en todo el sitio web.

Aquí tienes algunos de los problemas más comunes a los que debes prestar atención:

Una auditoría del sitio web es una de las maneras más fáciles de detectar estos problemas.

La herramienta Site Audit de Ahrefs rastrea tu sitio web y saca a la luz más de 170 problemas de SEO técnico que, de otro modo, podrían pasar desapercibidos. Esto es especialmente útil cuando no hay un CMS ni un plugin de SEO revisándolos por ti.

Los sitios estáticos pueden hacer accidentalmente que la misma página esté accesible desde dos URLs distintas, como /pagina y /pagina/.

Esto suele ocurrir porque tu framework estático y tu plataforma de alojamiento tienen diferentes valores predeterminados para las barras diagonales finales (trailing slashes).

Tu framework podría generar una versión mientras que tu servidor de alojamiento muestra o redirige a otra.

El problema es que tus etiquetas canonical, tus enlaces internos y tus redirecciones pueden entonces entrar en conflicto sobre cuál de las dos URLs es la versión preferida. En el mejor de los casos, esto crea redirecciones innecesarias. En el peor, los motores de búsqueda pueden ver URLs duplicadas y las señales de posicionamiento pueden dividirse entre ellas.

Elige un formato de URL, con o sin barra diagonal al final, y úsalo de forma consistente en todo tu sitio web.

Configura tanto tu framework como tu entorno de alojamiento para que sigan la misma convención, y luego comprueba que tus etiquetas canonical y enlaces internos apuntan a la versión que realmente resuelve correctamente.

También puedes rastrear el sitio con Site Audit de Ahrefs para encontrar conflictos canonical, cadenas de redirección y enlaces internos que apunten a URLs no canónicas.

En un sitio estático, tu sitemap XML suele generarse mediante código. El problema es que el generador de sitemaps puede no saber qué páginas has marcado como noindex.

Esto significa que URLs como borradores, páginas de agradecimiento, páginas de confirmación u otras páginas que no quieres que aparezcan en los resultados de búsqueda, pueden terminar incluidas en el sitemap.

Esto ocurre porque no hay ningún plugin de CMS manteniendo todo sincronizado por ti. Una página podría estar excluida de tu navegación principal o marcada como noindex, pero seguir apareciendo en el sitemap o en el feed RSS a menos que hayas construido explícitamente una lógica para excluirla.

La configuración también puede volverse frágil a medida que el sitio crece. Un sitemap plano básico es bastante fácil de gestionar, pero las cosas se complican una vez que necesitas dividir los sitemaps por tipo de página, excluir ciertas secciones o aplicar reglas diferentes a plantillas distintas.

Los sitios web estáticos pueden tener un problema similar con el archivo robots.txt.

Dependiendo de tu framework y la configuración de despliegue, es posible que no se cree uno de forma automática, por lo que merece la pena comprobar que el archivo existe y contiene las reglas de rastreo que realmente deseas aplicar. Solo recuerda que el archivo robots.txt controla el rastreo, no la indexación, por lo que no debe utilizarse como sustituto de la etiqueta noindex.

Crea una regla para las páginas que quieres mantener fuera de las búsquedas. Por ejemplo, márcalas como noindex: true, y luego indícale a tu sitemap y a tu feed RSS que ignoren cualquier página con esa etiqueta. Comprueba también que tu archivo robots.txt existe, que dirige a los motores de búsqueda al sitemap correcto y que no bloquea accidentalmente secciones que sí quieres que sean rastreadas.

Vuelve a revisar la lógica siempre que añadas un nuevo tipo de página o cambies la forma en que se generan las páginas.

También puedes usar Site Audit de Ahrefs para comparar las URLs de tu sitemap con las señales de indexabilidad y atrapar páginas que no deberían estar ahí.

Por ejemplo, este informe puede ayudarte a rastrear páginas indexables que no están en tu sitemap (y deberían estarlo) y páginas noindex que no deberían estar en el sitemap pero lo están.

Algunos frameworks de sitios estáticos incluyen herramientas para redimensionar, comprimir y servir imágenes de manera más eficiente. Pero esto no es universal. Por ejemplo, Jekyll copia los archivos de imagen tal cual por defecto, sin redimensionarlos, comprimirlos ni convertirlos automáticamente. Para obtener esas optimizaciones de imágenes con Jekyll, necesitarás un plugin, una CDN de imágenes o un paso adicional de procesamiento de imágenes antes de publicar.

Incluso cuando un framework cuenta con herramientas de imagen integradas, generalmente solo funcionan cuando añades las imágenes a través del flujo de procesamiento de imágenes del propio framework.

Por ejemplo, Next.js proporciona un componente <Image> a través de next/image que gestiona automáticamente aspectos como el tamaño adaptable (responsive), la optimización, la carga diferida (lazy loading) y la entrega en formatos de imagen modernos. Si usas una etiqueta HTML estándar <img> en su lugar, tienes que encargarte de esas optimizaciones tú mismo.

Si sueltas un archivo de imagen en bruto directamente en el sitio, puede saltarse ese proceso por completo.

Puedes terminar publicando un archivo de imagen que es mucho más grande de lo que necesita ser, lo que puede ralentizar las cargas de página (especialmente en dispositivos móviles). O podrías publicar una imagen sin texto alternativo (alt text), haciéndola menos accesible para personas que usan lectores de pantalla y dando menos contexto a los motores de búsqueda sobre lo que muestra la imagen. Debido a que el sitio aún puede compilarse con éxito, no hay garantía de que ninguno de los dos problemas se detecte antes de publicar.

Eso es lo que hace que esto sea fácil de pasar por alto, especialmente en sitios creados con vibe coding. La página puede verse completamente bien en una vista previa mientras sigue cargando imágenes innecesariamente pesadas o un marcado de imagen incompleto.

Usa el componente de imagen de tu framework o el flujo de optimización de manera consistente en lugar de introducir archivos en bruto directamente en las páginas. Antes de publicar, busca imágenes de tamaño excesivo y texto alternativo faltante o en blanco.

También puedes rastrear el sitio con Site Audit de Ahrefs y comprobar problemas como archivos de imagen pesados, textos alternativos faltantes y otros problemas de SEO relacionados con imágenes.

También hay un informe dedicado a Imágenes que puedes utilizar para profundizar en problemas de imágenes específicos:

En los sitios web estáticos, los títulos, las meta descripciones, las etiquetas canonical y el marcado schema se generan a menudo a partir de plantillas compartidas. Eso hace que sean eficientes de gestionar, pero también significa que un mal ajuste predeterminado puede afectar a cientos de páginas a la vez.

Por ejemplo, añadir automáticamente el nombre de tu marca a cada título podría empujar a todo un conjunto de títulos de página más allá de la longitud que tenías prevista.

Lo mismo se aplica a schema. Si la plantilla utiliza el tipo incorrecto, omite propiedades obligatorias o estructura las relaciones de forma incorrecta, ese error se reproduce en todas partes donde se utilice la plantilla.

Si has usado Yoast en WordPress, la idea es similar a sus plantillas de títulos SEO y meta descripciones.

Puedes definir un patrón una sola vez, como añadir el nombre del sitio web a cada título de página, y aplicarlo en todo un tipo de contenido completo. La diferencia es que Yoast te ofrece una interfaz específica orientada al SEO para gestionar esas reglas.

En un sitio estático, es posible que estés construyendo la misma lógica directamente dentro de tus plantillas.

Por ejemplo, Next.js te permite definir una plantilla de título una vez en un diseño compartido y aplicarla en múltiples páginas. Eso es conveniente, pero también significa que un valor predeterminado erróneo puede propagarse con la misma rapidez.

El vibe coding puede hacer que esto sea más difícil de detectar. Una plantilla generada por IA puede producir metadatos o un schema básico que parezca razonable sin coincidir necesariamente con el tipo de página o la estructura que realmente necesitas.

Define los requisitos de metadatos y schema para cada tipo de página antes de construir la plantilla. Luego prueba múltiples páginas que la utilicen, no solo un ejemplo, cada vez que hagas un cambio.

Para schema específicamente, pasa el código de marcado generado a través de la prueba de resultados enriquecidos de Google:

O prueba el validador de Schema.org.

Site Audit de Ahrefs también puede ayudar a sacar a la luz problemas con títulos, meta descripciones, etiquetas canonical y datos estructurados en todo el sitio web.

Una página puede parecer un error 404 para el usuario mientras que, en realidad, devuelve un código de estado "200 OK" a los motores de búsqueda.

Por ejemplo, el desarrollador Josh Deltener documentó cómo ocurría esto en un sitio estático hecho con Nuxt y desplegado en Vercel.

La página mostraba visiblemente un mensaje de "404 — Página no encontrada", pero Chrome DevTools indicaba que la petición devolvía un estado 200. Google trataría esto como un error soft 404 porque la página dice que no existe, mientras que el servidor informa de una respuesta exitosa.

Esto puede suceder cuando la gestión de errores 404 no se ha configurado correctamente a nivel de framework o alojamiento. En la configuración de Nuxt de Deltener, el problema provenía de un archivo fallback 200.html de tipo SPA que se estaba sirviendo para rutas desconocidas.

Lo más complicado es que no detectarás necesariamente el mismo problema en tu sitio web con solo mirar tus páginas. Busca aquellos casos en los que el diseño visual indique "Página no encontrada" mientras la respuesta HTTP subyacente afirme que todo está bien.

Crea una página 404 adecuada, luego prueba un par de URLs que sepas que no existen y comprueba el código de respuesta HTTP real. Deberían devolver un 404, no limitarse a mostrar una página que parece un 404.

La herramienta Site Audit de Ahrefs también puede sacar a la superficie las URLs que devuelven códigos de estado inesperados, incluyendo los soft 404 y los enlaces internos rotos, para que puedas detectar casos que no son evidentes al navegar por el sitio de forma manual.

Los sitios estáticos pueden acabar teniendo enlaces internos inconsistentes, especialmente cuando diferentes plantillas o componentes generados por IA construyen las URLs de formas ligeramente distintas.

Por ejemplo, algunos enlaces pueden apuntar a /nosotros, mientras que otros apuntan a /nosotros/. También puedes terminar mezclando URLs relativas como ../nosotros/ con URLs absolutas como https://ejemplo.com/nosotros/.

Ninguno de estos formatos es inherentemente incorrecto, pero los problemas surgen cuando no coinciden con la convención de URLs que has elegido para el sitio.

Estos problemas pueden ocurrirle incluso a los equipos con más experiencia. Cuando migramos nuestro blog a un nuevo framework de sitio web, una regla de enlazado interno mal configurada hizo que estuviéramos aplicando un nofollow a todos nuestros enlaces internos —básicamente diciéndole a Google que los ignorase—. No es lo ideal:

Estos problemas pueden crear redirecciones innecesarias, enviar a los rastreadores a través de múltiples versiones de URL, y hacer que sea más difícil mantener enfocadas las señales de enlazado interno en la versión canónica de cada página. Esto es particularmente fácil de introducir en sitios hechos con vibe coding, donde los componentes generados por IA pueden usar diferentes formatos de URL a menos que le indiques explícitamente al sistema qué convención debe seguir.

Elige un formato de URL y utilízalo de forma consistente a través de plantillas, navegación, migas de pan (breadcrumbs) y en los enlaces dentro del contenido.

Siempre que sea posible, define ese formato una sola vez en un componente de enlace compartido o un archivo auxiliar (helper) en lugar de escribir manualmente las URLs por todo el sitio.

Luego rastrea el sitio para comprobar si hay enlaces internos que apunten a redirecciones o a versiones de URL no canónicas. La herramienta Site Audit de Ahrefs puede marcar las páginas que enlazan a redirecciones:

Mientras que el informe Estructura del Sitio Site Structure puede ayudarte a inspeccionar cómo se organizan las URLs por carpetas y profundidad de los enlaces.

Los sitios estáticos tienen reputación de ser rápidos, pero la generación estática por sí sola no garantiza un buen rendimiento.

Un sitio todavía puede:

Estos problemas pueden ralentizar el renderizado y la interactividad, incluso cuando el propio HTML se genera con antelación.

Vale la pena comprobar especialmente los sitios creados mediante vibe coding.

La IA puede seguir añadiendo scripts, librerías, animaciones y componentes sin considerar necesariamente su coste de rendimiento acumulativo. Una página puede verse pulida en su versión de vista previa mientras se vuelve más pesada con cada iteración.

Comprueba las decisiones técnicas detrás de la construcción del sitio, incluyendo:

Luego prueba el sitio ya terminado en lugar de asumir que una construcción estática va a ser rápida por defecto. Utiliza PageSpeed Insights para comprobar las Core Web Vitals, como el LCP, el INP y el CLS, y rastrea el sitio para encontrar problemas de rendimiento en múltiples páginas.

También puedes consultar en Site Audit de Ahrefs los informes específicos sobre errores de JavaScript y CSS:

Pasar de un CMS a un sitio web estático puede introducir problemas de SEO, incluso cuando las páginas nuevas se ven idénticas.

Esto se debe a que una migración de sitio web a menudo elimina mucho más que solo la interfaz del CMS. También puedes perder redirecciones, reglas de sitemap, la lógica de los metadatos, schema, el comportamiento del enlazado interno y otras configuraciones SEO que anteriormente se gestionaban en un segundo plano.

Uno de los mayores riesgos son los cambios de URL.

Si una antigua URL desaparece sin una redirección 301 adecuada a su reemplazo, cualquier enlace y señal de posicionamiento que apunte a esa página podría perderse.

Puedes comprobar esto fácilmente con la barra de herramientas SEO de Ahrefs. Aquí tienes un ejemplo de nuestra reciente migración del blog internacional, al pasar de una estructura de subcarpetas a otra distinta:

También es muy fácil pasar por alto detalles como las etiquetas canonical heredadas, entradas de sitemap desactualizadas o activos obsoletos que se están sirviendo desde un build o la caché.

Trata el traslado como una migración SEO completa, no solo como un rediseño. Antes del lanzamiento:

Una migración estática puede funcionar perfectamente, pero no asumas que el nuevo framework recreará de la nada todo aquello que tu antiguo CMS estaba haciendo discretamente por ti.

No hay un solo framework estático que sea inherentemente "el mejor para el SEO".

Astro, Next.js, Gatsby, Hugo, Jekyll y frameworks similares pueden ser compatibles con un SEO sólido, pero la cantidad de trabajo requerida varía dependiendo de lo que necesites construir. Cuestiones como las etiquetas canonical, las etiquetas de Open Graph, schema, las reglas del sitemap y la gestión de la etiqueta noindex aún deben configurarse en lugar de simplemente darse por supuestas.

La gestión de las imágenes es una de las áreas donde los frameworks difieren de forma más notable.

Algunos, como Astro, cuentan con herramientas de imagen integradas más potentes, mientras que otros te dejan a ti gran parte del trabajo de optimización. Pero en lo que respecta a metadatos, schema, canonicals y lógica del sitemap, la mayor diferencia suele reducirse a lo bien que configures el framework y no tanto a cuál decidas elegir.

Así que en lugar de preguntar "¿Qué framework es el mejor para el SEO?", pregúntate:

La decisión correcta depende del sitio que estés construyendo y de cuánto control técnico necesites en realidad.

Como dice Pedro:

Ese es, probablemente, el enfoque más útil a la hora de tomar una decisión. Un sitio web pequeño con un puñado de páginas y actualizaciones poco frecuentes puede encajar perfectamente con una configuración estática. Sin embargo, una operación de publicación de contenidos a gran escala con flujos de trabajo complejos, tal vez no lo sea.

Los sitios web estáticos pueden ofrecerte un mayor control, menos dependencias y una menor necesidad de utilizar plugins. Pero todo ese control conlleva una mayor responsabilidad.

Un CMS tradicional oculta gran parte de las tuberías del SEO detrás de sus plugins y de su configuración predeterminada. Con un sitio web estático o generado mediante vibe coding, es más probable que tú mismo tengas que encargarte de toda esa instalación: desde las etiquetas canonical y los sitemaps hasta las redirecciones, schema, el rendimiento y los códigos de estado HTTP.

El vibe coding hace que el proceso de creación de una página sea más rápido, pero no elimina la necesidad de entender cómo debe ser un buen SEO técnico en la práctica.

¿Tienes preguntas? Estamos en LinkedIn y en X.