<meta http-equiv="refresh">redirige o recarga una página desde el navegador, y su equivalente en servidor es la cabeceraRefresh.- Google lo interpreta como redirección: permanente si es instantáneo (0 segundos) y temporal si tiene retardo. Aun así prefiere una redirección de servidor y deja el meta refresh como alternativa.
- Con un retardo o una recarga automática, el W3C lo trata como fallo de accesibilidad (técnica F41 de WCAG).
- De los siete valores de
http-equivque lista MDN, hoy solo tienen sentido prácticocontent-typey, con cuidado,refresh;set-cookieyx-ua-compatiblelos navegadores los ignoran. - Se detecta con
curlygrepsobre el HTML y las cabeceras, y se corrige sustituyéndolo por una 301 en el servidor. - En cristofercruz.net no uso ningún
http-equiv: solo<meta charset>.
El meta refresh aparece casi siempre por un motivo: alguien necesitaba mover una URL y no tenía acceso al servidor. Funciona, Google lo entiende, y por eso sobrevive en gestores de contenido antiguos, constructores de páginas y migraciones a medias. El problema llega cuando se usa con retardo, se encadena o se confunde con una forma de «refrescar» la página para el SEO.
Este artículo cubre qué hace exactamente la etiqueta, qué dice Google y qué dice el W3C, qué pasa con el resto de valores de http-equiv, cómo localizarla en una auditoría y cómo sustituirla por una redirección de servidor. Donde pone «lo probé» es porque monté un servidor local y miré qué hacía un navegador real.
Qué es el meta refresh y cómo funciona
El atributo http-equiv permite que una etiqueta meta haga el papel de una cabecera HTTP. Con el valor refresh, la etiqueta equivale a la cabecera Refresh y tiene dos usos. Según MDN, si content es un entero no negativo, indica los segundos que pasan hasta recargar la página; si ese entero va seguido de ;url= y una URL válida, indica los segundos hasta redirigir a esa dirección.
<!-- Redirección instantánea -->
<meta http-equiv="refresh" content="0; url=https://example.com/nuevo/">
<!-- Redirección tras 5 segundos -->
<meta http-equiv="refresh" content="5; url=https://example.com/nuevo/">
<!-- Recarga de la misma página cada 300 segundos -->
<meta http-equiv="refresh" content="300">MDN precisa un detalle que se pasa por alto: el temporizador arranca cuando la página está completamente cargada, es decir, después de que se hayan disparado los eventos load y pageshow. Con «0», el navegador salta en cuanto termina de cargar la página.
La cabecera HTTP tiene la misma sintaxis. La documentación de MDN admite tres formas (Refresh: 5, Refresh: 5; url=… y Refresh: 5, url=…), y señala que el prefijo url= no distingue mayúsculas y que es opcional.
Cómo lo trata Google
La documentación de Google sobre redirecciones separa dos casos y los trata como señales distintas. Reproduzco la redacción con exactitud porque muchos artículos la simplifican:
- Meta refresh instantáneo: «Triggers as soon as the page is loaded in a browser». Google Search lo interpreta como redirección permanente.
- Meta refresh con retardo: se activa «only after an arbitrary number of seconds set by the site owner». Google Search lo interpreta como redirección temporal.
La distinción importa porque, según la misma página, una redirección permanente hace que se muestre el destino en los resultados y una temporal hace que se siga mostrando la página de origen. Un refresh de 5 segundos que usabas para una URL que se ha movido de forma definitiva le dice a Google justo lo contrario de lo que querías.
Google no lo presenta como primera opción. Pide usar redirecciones de servidor siempre que se pueda y deja el meta refresh para cuando la plataforma no las permita («may be a viable alternative»). Admite la etiqueta en el <head> o la cabecera Refresh enviada con código de servidor, y su ejemplo para esta última es Refresh: 0; url=https://www.example.com/newlocation.
En su lista de metaetiquetas, además, Google incluye refresh como etiqueta soportada y añade que no lo soportan todos los navegadores y que puede confundir al usuario, por lo que recomienda una redirección de servidor, en concreto una 301. Esa lista también soporta Content-Type y charset, y deja fuera meta keywords y los atributos lang, entre otros.
Un caso concreto donde la regla cambia: al pedir el robots.txt, Google no sigue redirecciones lógicas como frames, JavaScript o meta refresh. Ahí solo valen los 3xx de servidor.
Meta refresh frente al resto de redirecciones
Los tipos de redirección se distinguen por dónde se ejecutan y por la señal que mandan. Una redirección de servidor responde con un 3xx y una cabecera Location antes de enviar ningún contenido. El meta refresh responde con un 200 y un documento HTML que luego el navegador interpreta. Esa diferencia es el origen de casi todos sus problemas.
| Método | Respuesta del servidor | Señal para Google | Cuándo tiene sentido |
|---|---|---|---|
| 301 o 308 | 3xx con Location | Permanente | Siempre que puedas tocar el servidor |
| 302 o 307 | 3xx con Location | Temporal | Cambios que van a revertirse |
| Meta refresh 0 s | 200 con HTML | Permanente | Plataformas sin acceso al servidor |
| Meta refresh con retardo | 200 con HTML | Temporal | Casi nunca |
JavaScript location | 200 con HTML y script | Depende de que el renderizado funcione | Solo si no puedes usar ninguna de las dos anteriores |
La documentación de Google sobre JavaScript es explícita: úsalo solo si no puedes hacer redirecciones de servidor ni meta refresh, porque si falla el renderizado «Google might never see it». Si tu redirección depende de scripts, el artículo sobre SEO con JavaScript explica qué se pierde cuando el renderizado falla. El orden de preferencia queda así: servidor, meta refresh, JavaScript.
Lo que probé: cómo se comporta en un navegador real
Para no basarme solo en lo que dicen otros, monté un nginx local con varias páginas de prueba y las abrí con Chromium automatizado, midiendo cuándo cambiaba la URL. Es una prueba de comportamiento del navegador; no dice nada sobre cómo lo procesa Googlebot.
| Caso | Resultado en Chromium |
|---|---|
content="0; url=/nuevo/" | Navega a /nuevo/ a los 0,0 s |
content="5; url=/nuevo/" | Navega a /nuevo/ a los 5,0 s |
Cabecera Refresh: 0; url=/nuevo/ (nginx, sin HTML) | Navega a /nuevo/ a los 0,0 s |
content="0; /nuevo/" (sin url=) | También redirige |
| Dos páginas encadenadas, cada una con su refresh de 0 s | Llega al destino final tras pasar por las dos |
Meta refresh dentro de <noscript>, con JavaScript activo | No redirige |
Dos conclusiones prácticas. La primera: aunque Chromium tolere un content sin url=, no tiene sentido depender de ello; escribe el formato completo que documenta Google. La segunda: la cabecera Refresh funciona sin una sola línea de HTML, lo que significa que una redirección de este tipo puede estar escondida en el servidor y no aparecer al ver el código fuente. Por eso la auditoría tiene que mirar las dos capas.
No probé la recarga automática (content="30") durante un ciclo completo, y tampoco he comprobado cómo se comportan Safari o Firefox.
Accesibilidad: lo que dice el W3C
El criterio de éxito 2.2.1 (Tiempo ajustable) de WCAG exige que, cuando el contenido fija un límite de tiempo, el usuario pueda desactivarlo, ajustarlo o ampliarlo, con algunas excepciones. El meta refresh con retardo cae de lleno en ese terreno, y el W3C lo recoge en varias técnicas de fallo:
- F41: fallo de los criterios 2.2.1, 2.2.4 y 3.2.5 por usar meta refresh para recargar la página. Su procedimiento de prueba marca los valores de segundos menores que 1 o mayores que 72.000, y pregunta si el usuario puede desactivar, ampliar o ajustar el tiempo.
- F40: fallo por redirección meta con límite de tiempo.
- F58: fallo por redirección de servidor con límite de tiempo.
La página de WCAG explica la razón con un ejemplo: si el intervalo es demasiado corto y no hay forma de apagar la recarga, las personas ciegas no tienen tiempo de que su lector de pantalla lea la página. MDN lo resume igual: quien navega con tecnología asistiva puede no llegar a leer el contenido antes de que lo redirijan, y los cambios abruptos pueden desorientar a personas con baja visión.
Hay una matización que casi nadie cuenta. La técnica H76 del W3C describe precisamente el refresh de 0 segundos como redirección en cliente «sin confundir al usuario», aclara que no es obligatoria para cumplir WCAG y añade que las redirecciones se implementan preferiblemente en el servidor. Además, la página de WCAG indica que las redirecciones de servidor sin temporizador (los 3xx) no aplican porque no hay límite de tiempo. Lo que sí es un problema documentado es el retardo y la recarga periódica. El refresh de 0 segundos es tolerado, pero no es lo recomendado.
La recarga automática de página: por qué evitarla
Una etiqueta content="60" sin URL recarga la página cada minuto. Se usó mucho en paneles, marcadores deportivos y portadas de noticias. Hay tres razones para sacarla de una web que vive del SEO:
- Entra de lleno en el fallo F41: recarga sin que el usuario controle el tiempo.
- Pierde la posición de scroll, el foco y lo que el usuario estuviera escribiendo.
- Google no documenta ningún beneficio de que una página se recargue sola; ninguna de las fuentes oficiales que he leído lo sugiere. Una frase como «refrescar la página mejora el posicionamiento» no tiene respaldo en la documentación.
Si el contenido tiene que actualizarse, lo habitual es pedir los datos nuevos con JavaScript (fetch) y actualizar solo la parte que cambia, con un control para pausar si la actualización es visible. Eso es un diseño de aplicación, no una etiqueta meta, y queda fuera de este artículo.
Otros valores de http-equiv: cuáles siguen vivos
MDN lista siete valores de http-equiv. La página no usa las palabras «obsoleto» ni «deprecado», pero sí avisa de varios que los navegadores ya no procesan y de uno que no debes usar como medida de seguridad.
| Valor | Qué dice MDN | Qué dice Google |
|---|---|---|
refresh | Recarga o redirige tras N segundos; riesgos de accesibilidad | Soportado; prefiere una 301 de servidor |
content-type | Valor listado por MDN | Soportado (junto con charset): define tipo de contenido y codificación; recomienda UTF-8 |
content-language | «Use the lang attribute instead» | No aparece como soportado; los atributos lang tampoco se usan, porque detecta el idioma por el texto |
content-security-policy | Advierte de no usar meta para otras cabeceras de seguridad por el falso sentido de seguridad | No aparece en su lista |
set-cookie | Los navegadores lo ignoran ya | No aparece en su lista |
x-ua-compatible | Para versiones antiguas de Internet Explorer; los agentes de usuario lo ignoran | No aparece en su lista |
default-style | Valor listado por MDN; sin relación con SEO | No aparece en su lista |
Dos aclaraciones para no pasarse de frenada. Que un valor no aparezca en la lista de Google no demuestra que Google lo penalice: Google dice que ignora las metaetiquetas que no soporta. Y la regla de MDN sobre la política de seguridad es una advertencia general («Do not set other security headers using <meta http-equiv=»), no un listado de directivas que funcionen o no. Si necesitas CSP, envíala como cabecera HTTP.
En cuanto a content-type, Google recomienda Unicode/UTF-8 donde sea posible. La forma corta, <meta charset="utf-8">, es la que uso yo.
Errores típicos
Cadenas y bucles
Una URL con refresh que apunta a otra con refresh es una cadena. En mi prueba, el navegador resolvió dos saltos de 0 s sin problema, y esa comodidad es la trampa: el usuario no lo nota y se queda sin auditar. Con retardos, cada salto suma segundos de espera. Y si dos páginas se apuntan entre sí, hay un bucle. En un rastreo, una cadena se ve en el informe de redirecciones solo si el rastreador interpreta el meta refresh; compruébalo antes de fiarte.
Refresh en una página que responde 404
Si una URL devuelve un código 404 y además lleva un meta refresh, estás enviando dos señales contradictorias: «no existe» y «se ha movido». Resuélvelo en el servidor con una 301 al destino o con un 404 limpio, según corresponda. Los códigos de respuesta del servidor son la capa que tiene que decir la verdad; el HTML no debería contradecirla.
Refresh que contradice el canonical
Si una página redirige con meta refresh a una URL y su etiqueta canonical señala otra, el rastreador recibe señales cruzadas. Google dice que usa ciertas redirecciones como señal de que el destino debe ser el canónico, así que el destino del refresh y el canonical tienen que coincidir.
Otros fallos
- Dentro de
<noscript>: en mi prueba, con JavaScript activo el navegador no redirigió. Qué hace Googlebot con eso no está documentado y no lo he verificado. - Retardo «para que el usuario lea el aviso»: para Google eso es una redirección temporal. Si el cambio es definitivo, estás mandando la señal contraria.
- URLs relativas con rutas mal escritas: un destino que no existe termina en un 404 tras haber pasado por un 200.
Cómo lo trato en mi web
Busqué http-equiv y refresh en todo el código de cristofercruz.net (plantillas, cabeceras, la página 404, las plantillas legacy y los artículos del blog, salvo este) y esto es lo que hay:
- No uso ninguna etiqueta
<meta http-equiv>. Las plantillasincludes/header.phpyincludes/legacy/header.phpdeclaran la codificación con<meta charset="utf-8">. - No hay cabecera
Refreshen el código PHP ni en el.htaccess. - La única redirección propia del código es la del formulario:
send.phpresponde con unLocationy un código 303 tras enviar. Es una redirección de servidor. - La página 404 (
404.php) fija ella misma el código conhttp_response_code(404)y no redirige a ninguna parte. - La política de seguridad de
send.phpse envía como cabecera HTTPContent-Security-Policy, no como meta.
En mi servidor local de PHP, la respuesta de una página del blog llega con Content-type: text/html; charset=UTF-8 en las cabeceras. No he comprobado aquí la cabecera que envía el servidor de producción, así que no puedo asegurar que sea la misma.
Cómo detectarlo en una auditoría
La revisión necesita dos pasadas, porque el refresh puede estar en el HTML o en las cabeceras. Estos comandos los probé contra mis páginas de prueba.
# 1) Meta refresh en el HTML (sin renderizar)
curl -s https://tu-dominio.com/pagina/ | grep -oiE '<meta[^>]+http-equiv=["'\'']?refresh[^>]*>'
# 2) Cabecera Refresh enviada por el servidor
curl -sI https://tu-dominio.com/pagina/ | grep -i '^refresh'Con mi página de prueba, el primer comando devolvió <meta http-equiv="refresh" content="0; url=/nuevo/"> y el segundo, Refresh: 0; url=/nuevo/. Para un sitio entero no vas a lanzar curl URL a URL; usa la búsqueda personalizada de tu rastreador con http-equiv y vuelca el resultado a una hoja con URL de origen, valor de content y destino.
- Rastrea el sitio y extrae todas las apariciones de
http-equiv="refresh". - Pasa el listado por
curl -sIpara pillar también las cabeceras. - Clasifica cada caso: 0 s o retardo, destino con 200 o con error, cadenas.
- Comprueba si el destino coincide con el canonical y con lo que hay en el sitemap.
- Compara el HTML crudo con el renderizado para ver si hay refresh que solo aparecen tras ejecutar JavaScript.
Cómo migrarlo a una redirección 301
Cada meta refresh que localices puede sustituirse por una regla de servidor que devuelva 301 al mismo destino. Probé estas dos reglas en un Apache y un nginx locales y ambas devolvieron el 301 con Location al destino. Las probé en la configuración del servidor; en un .htaccess la sintaxis de Apache es la misma, pero no la probé ahí.
# Apache (mod_alias)
Redirect 301 /viejo.html /nuevo/
# Apache (mod_rewrite)
RewriteEngine On
RewriteRule ^/viejo\.html$ /nuevo/ [R=301,L]
# nginx
location = /viejo.html { return 301 /nuevo/; }En una regla de RewriteRule dentro de un .htaccess, el patrón se escribe sin la barra inicial, así que no copies tal cual la versión de configuración de servidor. Para más variantes, tienes el artículo sobre redirecciones en .htaccess.
- Crea la regla 301 en el servidor y pruébala con
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n'. - Quita la etiqueta
meta refreshde la página antigua, o elimina la página si ya no hace falta. - Actualiza los enlaces internos y el sitemap para que apunten al destino final, sin pasar por la URL antigua.
- Vuelve a rastrear y confirma que no quedan cadenas.
Si el refresh viene de una migración grande, la lista de URLs, el mapa de redirecciones y la verificación posterior son parte del trabajo de una migración SEO.
Si de verdad no puedes tocar el servidor, usa el meta refresh de 0 segundos con la URL completa (como en el ejemplo de Google), mantén un enlace visible al destino dentro de la página y evita cualquier retardo.
Preguntas frecuentes
¿Google sigue un meta refresh?
Sí. Su documentación de redirecciones lo trata como redirección: permanente si es instantáneo y temporal si tiene retardo. Aun así recomienda las redirecciones de servidor.
¿Pasa un meta refresh la misma señal que una 301?
Google solo dice que interpreta el refresh instantáneo como redirección permanente. No he encontrado una declaración de que sean equivalentes en todos los casos, así que si puedes elegir, elige la 301.
¿Es mejor un refresh de 0 segundos o de 5?
0. Con retardo, Google lo interpreta como temporal y además cae en los fallos de accesibilidad del W3C. Si el cambio es definitivo, no hay motivo para esperar.
¿Sirve content-language para indicar el idioma a Google?
No hay constancia en su documentación. Google dice que detecta el idioma a partir del texto y no usa los atributos lang. Para versiones por idioma está hreflang, que tiene su propio artículo en este blog.
¿Puedo poner Content-Security-Policy con una etiqueta meta?
MDN lo lista como valor de http-equiv, pero avisa de no usar meta para otras cabeceras de seguridad. Si puedes, envíala como cabecera HTTP.
¿Cómo sé si mi web tiene meta refresh?
Busca http-equiv en el código fuente y mira la cabecera Refresh con curl -I. En sitios grandes, usa la búsqueda personalizada de tu rastreador.
¿Un meta refresh dentro de noscript sirve para algo?
En mi prueba con JavaScript activo no redirigió. Qué hace Googlebot con él no está documentado y no lo he verificado.
Referencias y fuentes
Documentación consultada para este artículo.
- Redirects and Google Search Google Search Central
- Metaetiquetas que Google admite Google Search Central
- <meta http-equiv> MDN Web Docs
- Refresh header MDN Web Docs
- Understanding SC 2.2.1: Timing Adjustable W3C WAI
- F41: Failure due to using meta refresh to reload the page W3C WAI
- H76: Using meta refresh to create an instant client-side redirect W3C WAI
- Cómo aplicar la meta http-equiv refresh en el SEO Carlos Sánchez
