Cabeceras HTTP y SEO: qué son, cuáles importan y cómo revisarlas

Las cabeceras HTTP son los metadatos que el navegador y el servidor se intercambian antes de que llegue una sola línea de HTML: quién pide la página, qué tipo de archivo es, si se puede indexar, cuánto tiempo guardarla en caché o si se puede mostrar dentro de otra web.

Googlebot las lee antes que el contenido, y algunas mandan sobre lo que diga tu HTML. Por eso, cuando una página no se indexa «sin motivo aparente», muchas veces el motivo está en una cabecera que nadie ha mirado.

En esta guía te explico qué son, qué tipos hay, cuáles influyen en el SEO (también las de seguridad, porque una web hackeada pierde posiciones muy rápido), cómo se configuran y cómo revisarlas desde la terminal.

Todas las capturas de consola son de mi propia web, aliciaruiz.es, lanzando curl desde el Símbolo del sistema de Windows, y las de hackeos son casos reales documentados por Google.

Qué es una cabecera HTTP

Cada vez que abres una página hay dos mensajes: la petición que hace tu navegador y la respuesta que devuelve el servidor. Los dos tienen la misma estructura: una primera línea, una lista de cabeceras con el formato Nombre: valor, una línea en blanco y, a veces, un cuerpo (el HTML, la imagen, el PDF…).

Con curl -v puedes ver los dos mensajes a la vez. Las líneas que empiezan por > son lo que envía tu ordenador y las que empiezan por < son lo que contesta el servidor:

Tres detalles que conviene tener claros desde el principio:

• El código de estado no es una cabecera. HTTP/1.1 200 OK es la «línea de estado». Se suele hablar de él junto a las cabeceras porque viaja con ellas, pero técnicamente va aparte.
• Los nombres no distinguen mayúsculas. X-Robots-Tag y x-robots-tag son lo mismo. En HTTP/2 y HTTP/3 viajan siempre en minúscula y comprimidas en binario, pero el significado no cambia.
• Se procesan antes que el contenido. El navegador decide qué hacer con la respuesta (redirigir, guardar en caché, bloquear un iframe) antes de leer el HTML.

Cómo ver las cabeceras de cualquier página

Desde la terminal con curl

curl viene instalado en Windows 10 y 11, en macOS y en casi cualquier Linux. Abre el Símbolo del sistema (tecla Windows, escribe cmd e Intro) y lanza:

curl -I https://aliciaruiz.es/

La opción -I pide solo las cabeceras de la respuesta, sin descargar el HTML:

Los comandos que más uso en auditorías:

Comando	Para qué sirve
curl -I URL	Ver las cabeceras de la respuesta.
curl -sIL URL	Seguir todas las redirecciones y ver cada salto.
curl -sv -o NUL URL	Ver la petición y la respuesta completas (en macOS y Linux, -o /dev/null).
curl -I -A "Googlebot" URL	Pedir la página haciéndote pasar por Googlebot, para detectar respuestas distintas según quién pregunta.
curl -I -H "Cabecera: valor" URL	Enviar una cabecera concreta en la petición, por ejemplo If-Modified-Since.

Cuando quieras quedarte solo con algunas líneas, en Windows añade | findstr /i "texto" al final (en macOS y Linux, | grep -i "texto"). Lo verás en varias capturas de esta guía.

Desde el navegador y desde Screaming Frog

• Chrome DevTools: pulsa F12, ve a la pestaña Red (Network), recarga la página y haz clic en el primer documento. En Encabezados tienes los de la respuesta y los de la petición.
• Screaming Frog: activa Configuración > Spider > Extracción > HTTP Headers y rastrea. Tendrás una pestaña con las cabeceras de todas las URLs, ideal para encontrar un X-Robots-Tag escondido o canonicals que se contradicen.
• Search Console: la inspección de URLs muestra, en Ver página rastreada > Más información, las cabeceras que recibió Googlebot de verdad.

Las cabeceras que influyen en el SEO

El código de estado

Es lo primero que mira Googlebot y decide qué hace con todo lo demás. Según la documentación de Google sobre códigos de estado:

Código	Qué significa	Qué hace Google
200	Todo bien.	Procesa el contenido para indexarlo (un 200 no garantiza la indexación).
301 / 308	Movido de forma permanente.	Señal fuerte: acaba mostrando la URL de destino y le pasa las señales.
302 / 307	Movido de forma temporal.	Señal débil: suele seguir mostrando la URL original.
304	No ha cambiado desde tu última copia.	Reutiliza la versión que ya tenía (lo vemos en el apartado de caché).
404 / 410	No existe / eliminada.	Los trata igual: deja de indexar la URL y la rastrea cada vez menos.
429 / 5xx	Demasiadas peticiones / error del servidor.	Baja la velocidad de rastreo. Si el error dura días, empieza a sacar URLs del índice.

Dos errores típicos que veo en auditorías: el soft 404 (una página que dice «no encontrado» pero responde 200, y que Search Console marca como error) y la página de mantenimiento que responde 200 en lugar de 503, con lo que Google puede acabar indexando el texto «volvemos pronto».

Location: las redirecciones

Un 301 o un 302 no sirven de nada sin la cabecera Location, que dice adónde ir. Con curl -sIL ves la cadena completa de saltos. Este es uno que configuré hace poco, al redirigir la antigua página de categoría del blog:

Aunque Googlebot sigue hasta 10 saltos, cada redirección intermedia añade tiempo de carga y más posibilidades de error. Lo ideal es que cualquier URL antigua llegue a la definitiva en un único 301.

X-Robots-Tag: el meta robots fuera del HTML

X-Robots-Tag admite las mismas directivas que <meta name="robots"> (noindex, nofollow, nosnippet, max-image-preview…), pero va en la cabecera. Eso tiene dos consecuencias:

• Es la única forma de desindexar archivos que no son HTML, como PDFs, imágenes o documentos de Office, porque no tienen un <head> donde poner la meta etiqueta.
• Es la gran olvidada en las auditorías. Si una página no se indexa y en su HTML no hay ningún noindex, revisa la cabecera: a veces la pone un plugin, el CDN o una regla antigua del servidor.

Un ejemplo real y correcto: Rank Math envía X-Robots-Tag: noindex en los sitemaps XML. Así Google los usa para descubrir URLs, pero no los muestra como resultado de búsqueda:

Para poner noindex a todos los PDFs de una web en Apache o LiteSpeed basta con esto en el .htaccess:

<FilesMatch ".pdf$">
Header set X-Robots-Tag "noindex"
</FilesMatch>

Link: canonical y hreflang sin tocar el HTML

La cabecera Link puede llevar las mismas relaciones que las etiquetas <link> del HTML. Google acepta por esta vía la canonical y el hreflang, lo que es muy útil para archivos sin HTML. Por ejemplo, para que un PDF ceda sus señales a la página que lo explica:

Link: <https://ejemplo.com/guia/>; rel="canonical"

Cuidado con una trampa clásica: si la cabecera dice una canonical y el HTML otra distinta, Google recibe señales contradictorias y puede ignorar las dos. En la captura de antes ves que WordPress ya usa esta cabecera para anunciar su API (rel="https://api.w.org/") y el enlace corto (rel=shortlink).

Caché: Cache-Control, ETag, Last-Modified y el 304

Estas cabeceras deciden cuánto tiempo se guarda una copia y cómo se comprueba si ha cambiado:

• Cache-Control: public, max-age=7200: cualquiera puede guardar una copia durante 7.200 segundos (2 horas).
• Last-Modified y ETag: la fecha de la última modificación y una «huella» del archivo.
• If-Modified-Since e If-None-Match: las preguntas que hace el cliente en la siguiente visita («¿ha cambiado desde esta fecha o esta huella?»).

Si el archivo no ha cambiado, el servidor contesta 304 Not Modified sin enviar el contenido. Fíjate en la diferencia entre la primera petición y la segunda:

¿Por qué importa en SEO? Porque Google confirma que sus rastreadores hacen estas peticiones condicionales, tanto con ETag como con Last-Modified, y recomienda especialmente ETag por ser menos propenso a errores. Un 304 le ahorra recursos en las páginas que no cambian y deja más presupuesto de rastreo para las nuevas.

En una web pequeña apenas se nota, pero en un ecommerce con cientos de miles de URLs marca la diferencia. Google contaba en ese mismo artículo que solo un 0,017 % de lo que rastrea se puede reutilizar desde caché, así que hay mucho margen de mejora.

Para los usuarios, max-age decide si al volver a tu web el navegador tiene que descargar otra vez imágenes, CSS y JavaScript. Para archivos estáticos lo habitual es entre un mes y un año; dos horas es poco, y es una de las cosas que tengo pendientes de ajustar en mi propia web.

Content-Type y charset

Content-Type: text/html; charset=UTF-8 le dice a cualquier cliente qué es el archivo y cómo leer sus caracteres. Si el charset no coincide con la codificación real, las tildes salen como é en tu web y en el snippet de Google. Y si un archivo se sirve con el tipo equivocado (un JavaScript como text/plain, por ejemplo), el navegador puede negarse a ejecutarlo.

Vary: cuando una URL tiene varias versiones

Vary avisa a las cachés de que la respuesta cambia según una cabecera de la petición: Vary: Accept-Encoding (comprimida o no), Vary: User-Agent (móvil o escritorio). Si sirves HTML distinto a móvil y escritorio en la misma URL y falta Vary, un CDN puede servir la versión equivocada… también a Googlebot, que rastrea sobre todo como smartphone.

Rendimiento: compresión, HTTP/3 y precarga

• Content-Encoding: br o gzip: el contenido viaja comprimido.
• alt-svc: h3=":443": el servidor anuncia que admite HTTP/3, más rápido en redes móviles inestables (la tienes en mi captura).
• Link: </fuente.woff2>; rel=preload: pide al navegador que descargue un recurso crítico (la fuente o la imagen del LCP) cuanto antes. Combinada con la respuesta 103 Early Hints, el navegador empieza a descargarlo incluso antes de que el HTML esté listo.

Ninguna de estas es un factor de posicionamiento por sí misma, pero todas mejoran la velocidad y, con ella, las Core Web Vitals.

La seguridad también es SEO

Google no puntúa una a una las cabeceras de seguridad, pero una web insegura sí pierde posiciones, y a veces todo su tráfico de golpe. La seguridad influye en el SEO por cuatro vías: los hackeos con spam, el cloaking, los avisos de Safe Browsing y HTTPS.

Hackeos con spam: tu web posicionando lo que no es tuyo

Las políticas de spam de Google definen el contenido hackeado como cualquier contenido colocado en una web sin permiso aprovechando una vulnerabilidad. El objetivo casi nunca es tu web en sí, sino su autoridad: el atacante crea miles de páginas para posicionar sus productos o sus enlaces usando tu dominio.

El caso más conocido es el hackeo de palabras clave japonesas. Aparecen en Google páginas de tu dominio con títulos en japonés que venden productos de marca falsificados:

Otra variante es el hackeo de texto sin sentido (gibberish hack): cientos de URLs con palabras clave dentro de una carpeta con nombre aleatorio, rellenas de texto incoherente que redirige a los visitantes a otras webs.

Las consecuencias para el SEO son serias: Google puede aplicar una acción manual por «sitio hackeado», mostrar el aviso Es posible que este sitio web haya sido pirateado debajo de tus resultados (y el CTR se desploma) o, simplemente, dejar de confiar en tu dominio mientras está lleno de spam.

Cloaking: lo que ve Google no es lo que ves tú

Google define el cloaking como «mostrar contenido distinto a los usuarios y a los buscadores». Los hackers lo usan para que el dueño no se entere: miran la cabecera User-Agent de la petición (o la IP) y, si es Googlebot, sirven el spam; si es una persona, enseñan la web normal o un 404.

Es lo que hace el hackeo de palabras clave y enlaces ocultos: genera páginas con tu plantilla, rellenas de texto y enlaces sin sentido, que solo ve Google. Muchas veces todo empieza con una regla RewriteRule añadida al .htaccess que manda las peticiones a un archivo PHP malicioso con un nombre inocente.

Cómo detectarlo, de más rápido a más fiable:

1. Busca site:tudominio.com en Google y revisa varias páginas de resultados buscando títulos o URLs que no reconozcas.
2. Compara la respuesta como navegador y como Googlebot con curl -I -A "Googlebot" URL frente a curl -I URL. Si una devuelve 200 y la otra 404, o redirige a otro dominio, hay algo raro. No es infalible, porque muchos scripts comprueban la IP y no solo el User-Agent.
3. Usa la inspección de URLs de Search Console y mira la página rastreada: es lo que Google ha visto de verdad, desde sus IPs.
4. Revisa el informe Seguridad y acciones manuales > Problemas de seguridad de Search Console. Google avisa ahí (y por correo) cuando detecta un hackeo.

Safe Browsing: la pantalla roja que vacía tu tráfico

Navegación segura (Safe Browsing) es el sistema de Google que detecta webs con malware, phishing o software no deseado. Cuando marca tu dominio, Chrome, Firefox y Safari muestran una advertencia a pantalla completa antes de dejar entrar a nadie, y Google puede avisar también en los resultados de búsqueda. En la práctica, el tráfico cae casi a cero hasta que limpias la web y pides una revisión.

Puedes consultar el estado de cualquier dominio en el Informe de transparencia de Google. Así se ve un dominio marcado (es la web de pruebas que mantiene el propio Google para comprobar que estos avisos funcionan):

Y así se ve una web limpia:

HTTPS y HSTS

HTTPS es una señal de posicionamiento de Google desde 2014 y forma parte de la experiencia de página. Además, Chrome marca como «No seguro» las páginas sin cifrar, lo que espanta a los usuarios. La cabecera HSTS (Strict-Transport-Security) remata el trabajo: le dice al navegador que, durante el tiempo indicado, vaya siempre directo a HTTPS aunque alguien escriba http://, sin pasar ni una vez por la versión sin cifrar.

Las cabeceras de seguridad, una a una

Estas son las que Screaming Frog marca como ausentes en casi cualquier auditoría, y las que yo tengo activas en mi web:

Cabecera	Qué hace	Contra qué protege
Strict-Transport-Security	Obliga a usar HTTPS durante el tiempo indicado en max-age (en segundos; 31536000 es un año).	Que alguien intercepte la primera visita por HTTP.
X-Content-Type-Options: nosniff	El navegador se fía solo del Content-Type declarado y no «olfatea» el archivo para adivinar qué es.	Que una supuesta imagen subida por un atacante se ejecute como JavaScript.
X-Frame-Options: SAMEORIGIN	Solo tu propio dominio puede mostrar tus páginas dentro de un <iframe>.	Clickjacking: cargar tu web invisible encima de otra para que el usuario haga clic sin saberlo.
Referrer-Policy: strict-origin-when-cross-origin	Dentro de tu web envía la URL completa como referencia; hacia otras webs, solo el dominio; de HTTPS a HTTP, nada.	Filtrar rutas con parámetros, búsquedas internas o datos personales a terceros.
Content-Security-Policy	Lista blanca de los orígenes desde los que la página puede cargar scripts, estilos, imágenes o iframes.	Inyección de scripts (XSS). Su directiva frame-ancestors sustituye a X-Frame-Options.
Permissions-Policy	Desactiva funciones del navegador que no usas: cámara, micrófono, geolocalización…	Que un script de terceros las use sin que lo sepas.

Una advertencia sobre la Content-Security-Policy: es la más potente y la más delicada. Si tu web usa scripts en línea, Google Analytics o widgets de terceros, una CSP mal ajustada los bloquea sin avisar. Empieza siempre con la versión de solo informe (Content-Security-Policy-Report-Only), revisa los errores en la consola y no la pases a modo estricto hasta que esté limpia.

Y una cabecera que conviene quitar: X-Powered-By. En las capturas de este post aparece X-Powered-By con la versión de PHP (la he pixelado a propósito): no aporta nada al visitante y le dice a un atacante exactamente qué versión buscar. Lo mismo pasa con un Server que incluya número de versión.

Otros tipos de cabeceras que conviene conocer

Las que envía el navegador

Cabecera	Para qué sirve	Lo que importa en SEO
Host	Qué dominio pides (un servidor aloja muchas webs).	Es lo que separa www de la versión sin www.
User-Agent	Qué navegador o robot hace la petición.	Así se identifica Googlebot. Se puede falsificar: el Googlebot de verdad se verifica con una búsqueda DNS inversa de su IP.
Accept-Language	En qué idiomas prefiere leer el usuario.	Googlebot rastrea sin esta cabecera, así que si rediriges por idioma solo verá una versión. Para webs multidioma, usa hreflang.
Accept / Accept-Encoding	Qué formatos y compresiones entiende el cliente.	El servidor puede elegir WebP o AVIF y brotli.
Cookie	Los datos que el navegador guardó de tu web.	Googlebot no conserva cookies entre visitas: si un contenido depende de una cookie, Google no lo ve.
Referer	Desde qué página viene el usuario.	Es la «fuente de referencia» que ves en GA4.

Las que gestionan estado, permisos y funciones

• Set-Cookie: crea una cookie. Sus atributos Secure, HttpOnly y SameSite también son seguridad.
• Access-Control-Allow-Origin (CORS): qué otros dominios pueden leer tus recursos con JavaScript. Si falla, una fuente web servida desde otro dominio no carga y la página «salta» (CLS).
• Origin-Trial: activa funciones experimentales de Chrome en tu dominio. La de mi web habilita WebMCP para agentes de IA.
• Cabeceras propias de cada herramienta, como X-LiteSpeed-Cache: hit, que te dice si la página salió de la caché del servidor. Muy útil para depurar.

Cómo se configuran las cabeceras

Una misma respuesta pasa por varias capas antes de llegar al navegador, y cada una puede añadir, cambiar o quitar cabeceras. Por eso a veces aparecen duplicadas o contradictorias: conviene saber dónde se pone cada una.

En el servidor (Apache, LiteSpeed o Nginx)

En Apache y LiteSpeed, en el archivo .htaccess de la raíz. Este es, tal cual, el bloque que uso en mi web:

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

always hace que se envíen también en las respuestas de error y en las redirecciones. En Nginx el equivalente va en el bloque server:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;

Desde el código (PHP y WordPress)

Es como lo hacen los plugins SEO y de caché:

header('X-Robots-Tag: noindex');
header('Location: https://ejemplo.com/nueva-url/', true, 301);

Hay que llamar a header() antes de enviar cualquier byte del HTML. Si no, PHP da el famoso error «headers already sent»: las cabeceras ya se fueron y no se pueden cambiar.

En el CDN o la plataforma de hosting

Cloudflare (con Transform Rules), Netlify (archivo _headers) o Vercel (vercel.json) permiten añadir o reescribir cabeceras en el borde. Como actúan los últimos, lo que pongan ahí gana sobre lo que haga tu servidor. Es el primer sitio que miro cuando una cabecera «aparece de la nada».

Con meta http-equiv (solo para algunas)

Algunas cabeceras tienen un equivalente en el HTML:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
<meta http-equiv="origin-trial" content="TOKEN">

Pero no sirve para todas: X-Frame-Options y Strict-Transport-Security en una meta etiqueta se ignoran. Y X-Robots-Tag tiene su propia versión en HTML, que es el meta robots de toda la vida.

Cómo leen las cabeceras el servidor, el navegador y Googlebot

El servidor, cuando recibe la petición

1. Lee Host para saber a qué web va dirigida (en un hosting compartido hay cientos en la misma máquina).
2. Aplica sus reglas: las redirecciones del .htaccess se resuelven antes de que WordPress llegue a arrancar, por eso son tan rápidas.
3. Busca una copia en caché para esa URL (y esa variante: móvil o escritorio, comprimida o no). Si la tiene, la sirve sin ejecutar PHP.
4. Si la petición trae If-None-Match o If-Modified-Since y nada ha cambiado, contesta 304 sin cuerpo.
5. Si no, genera la página y le añade las cabeceras de todas las capas.

El navegador, cuando recibe la respuesta

1. Mira el código de estado. Si es una redirección, lee Location y se va, sin mirar el cuerpo.
2. Aplica la seguridad: guarda HSTS para las próximas visitas, comprueba si puede mostrar la página dentro de un iframe y prepara la CSP.
3. Lee Content-Type y el charset para saber cómo interpretar el cuerpo.
4. Empieza a descargar en paralelo lo que pida Link: rel=preload.
5. Guarda las cookies de Set-Cookie y decide si guarda la respuesta en caché, según Cache-Control.
6. Solo entonces empieza a construir el DOM con el HTML.

Googlebot

Hace casi lo mismo que un navegador, con diferencias importantes: respeta el código de estado, Location, X-Robots-Tag, la canonical y el hreflang de la cabecera Link, y el Content-Type. Si encuentra un noindex en la cabecera, ni siquiera necesita mirar el HTML. En cambio, ignora las cabeceras de seguridad, no conserva cookies entre visitas, no envía Accept-Language y hace peticiones condicionales para ahorrar rastreo.

Checklist para auditar las cabeceras de una web

1. Las URLs importantes responden 200, y las que no existen, 404 o 410 (nada de soft 404).
2. Las redirecciones son 301 en un solo salto desde http://, www y URLs antiguas.
3. No hay ningún X-Robots-Tag: noindex en páginas que quieres posicionar, y sí en los archivos que no (PDFs internos, sitemaps).
4. La canonical de la cabecera Link, si existe, coincide con la del HTML.
5. El servidor envía ETag o Last-Modified y contesta 304 a las peticiones condicionales.
6. Los archivos estáticos tienen un Cache-Control largo y el HTML va comprimido.
7. Googlebot y un navegador reciben la misma respuesta (compara con curl -A "Googlebot" y con la inspección de URLs).
8. Están activas HSTS, nosniff, X-Frame-Options y Referrer-Policy, y no se anuncian versiones con X-Powered-By.
9. El informe de Problemas de seguridad de Search Console está vacío y el dominio aparece limpio en el Informe de transparencia.

Preguntas frecuentes

¿Las cabeceras de seguridad mejoran el posicionamiento?

No de forma directa: Google no da puntos por tener nosniff o X-Frame-Options. Lo que sí influye es lo que evitan. Una web hackeada, con spam o marcada por Safe Browsing pierde tráfico de forma drástica, y HTTPS sí es una señal de posicionamiento. Las cabeceras de seguridad son una capa más de esa protección.

¿Qué pasa si el meta robots y el X-Robots-Tag se contradicen?

Google aplica la directiva más restrictiva. Si la cabecera dice noindex y el HTML dice index, la página no se indexa.

¿Es mejor un 404 o un 410 para una página eliminada?

Para Google son equivalentes: según su documentación, todos los errores 4xx (salvo el 429) se tratan igual. Usa el que sea semánticamente correcto, pero no esperes diferencias en la velocidad de desindexación.

¿Por qué Screaming Frog marca enlaces externos con error 403 que funcionan?

Porque muchas webs (CodePen, medios de comunicación, cualquiera detrás de Cloudflare) bloquean a los rastreadores que no son navegadores. Ábrelos en el navegador antes de cambiarlos: si cargan, es un falso positivo y no hay nada que corregir.

Conclusión

Las cabeceras HTTP son la parte de tu web que nadie ve y que Google lee primero. Un código de estado incorrecto, un X-Robots-Tag olvidado o una caché mal configurada pueden frenar tu SEO sin que nada cambie a simple vista, y una web insegura puede perderlo todo en un día. Revisarlas cuesta un comando de curl: acostúmbrate a mirarlas en cada auditoría y cada vez que algo no cuadre.

Si quieres que revise las cabeceras, las redirecciones y la seguridad de tu web dentro de una auditoría completa, echa un vistazo a mi servicio de SEO técnico o escríbeme y lo vemos.