Errores soft 404: qué son, cómo detectarlos y cómo corregirlos
Respuesta corta: Un soft 404 es una página que le dice al visitante «no encontrada» (o que casi no muestra nada) pero responde con el estado de éxito 200 en lugar de 404. Google lo trata como un error: cuando una respuesta 2xx tiene un contenido que apunta a un fallo, Search Console informa de un soft 404. La solución es que el servidor envíe el estado que corresponde a la realidad: 404 o 410 para las páginas que ya no existen, un 301 a una página equivalente para las que se han movido y contenido real para las que deben existir.
¿Qué es un soft 404?
Imagina una tienda con el cartel «Abierto» en la puerta y las estanterías vacías por dentro. Así se comporta un soft 404. Toda respuesta de un servidor web empieza con un código de estado, que llega antes que cualquier contenido: 200 significa «correcto, aquí tienes la página» y 404 significa «aquí no hay nada». En un soft 404 los dos no coinciden: la página que se ve en pantalla dice «no encontrada», «0 resultados» o no muestra nada que merezca leerse, pero el estado es 200.
Google describe este caso en su documentación sobre códigos de estado HTTP y errores de red. Ante una respuesta 2xx, Google tiene en cuenta el contenido. Si ese contenido apunta a un error, por ejemplo una página vacía o un mensaje de error, Search Console muestra un error soft 404. Con un estado 4xx auténtico, Google no usa el contenido de la URL en absoluto.
La diferencia se ve en una terminal. Así se comportan un servidor con este problema y uno correcto cuando se pide una dirección que no existe (las direcciones son marcadores de posición):
# Servidor A: muestra «no encontrada» pero envía 200 (un soft 404)
$ curl -s -o /dev/null -w "%{http_code}\n" https://a.ejemplo.example/pagina-que-no-existe
200
# Servidor B: muestra «no encontrada» y envía 404 (correcto)
$ curl -s -o /dev/null -w "%{http_code}\n" https://b.ejemplo.example/pagina-que-no-existe
404
La respuesta correcta es 404. El visitante ve el mismo texto amable de «Página no encontrada» en los dos casos. Solo cambia el estado, y el estado es lo primero que lee un rastreador.
La palabra «soft» (blando) no significa «leve». Significa que el servidor dice que no hay ningún problema mientras la página dice lo contrario.
¿Por qué importa un soft 404?
Esto es lo que está documentado y lo que no.
Documentado:
- Search Console enumera la URL como un error soft 404, así que el propio Google lo considera un problema.
- Con un 404 o un 410 de verdad, Google no usa el contenido de la URL. Con un 200, le dejas a Google la tarea de adivinar por el contenido si la página es un error.
No documentado: un efecto directo en el posicionamiento. Google nombra el error en su informe. No dice que un soft 404 hunda otras páginas de tu sitio, y no hemos encontrado ninguna fuente que lo demuestre. Desconfía de afirmaciones como «los soft 404 destruyen tu SEO».
Nuestra opinión, y nada más que eso: una página sin valor no debería ofrecerse como resultado, y corregirlo cuesta poco. Hay además un motivo práctico que nada tiene que ver con Google: los verificadores de enlaces y los monitores de disponibilidad leen los códigos de estado. Si todas las direcciones responden 200, no pueden avisarte de que un enlace está roto, y quien sigue un enlace antiguo nunca se entera de que la página ya no existe.
¿Qué causa un soft 404?
Los soft 404 suelen venir de patrones como estos:
- Una página de error bonita con estado 200. Un CMS, un framework o una regla de un proxy muestra una plantilla diseñada de «página no encontrada», pero nadie ha puesto el estado en 404. Es el caso más sencillo.
- Una aplicación de una sola página (SPA) que responde a cualquier ruta con el mismo cascarón. El servidor envía la aplicación, con estado 200, para cualquier dirección. Solo cuando se ha ejecutado el JavaScript la pantalla dice «no encontrada». El estado se decidió antes, y es 200. Google procesa estas páginas por fases (rastreo, renderizado, indexación), y una página con estado 200 entra en la cola de renderizado. Las nociones básicas de JavaScript de Google explican el modelo. Los rastreadores que quizá no ejecuten scripts en absoluto, como muchos de IA, ven aún menos.
- Mandar a la página de inicio cualquier dirección que falte. Si mandas las páginas eliminadas en bloque a la página de inicio, acabas en un 200 con contenido que nada tiene que ver. La página de inicio rara vez equivale a la página que falta.
- Listas vacías. Una página de categoría, de etiqueta o de búsqueda interna sin resultados sigue respondiendo 200 y muestra «0 resultados» o un marco vacío.
- Productos agotados o descatalogados. La página sigue en pie con poco más que un «no disponible». Una página que aún tiene una descripción real y una nota sobre la disponibilidad es un caso distinto de un aviso desnudo.
- Páginas con muy poco contenido. Plantillas casi sin texto, como un marcador de posición o una sección a medio hacer. Un contenido que parece un mensaje de error o una página vacía puede quedar marcado aunque nadie quisiera que fuera una página de error.
¿Cómo encontrar errores soft 404?
Tienes tres vías y se complementan.
- Search Console. Abre el informe de indexación de páginas (en inglés, «Page indexing») y busca el motivo «Soft 404». Enumera las URL que Google mismo ha metido en esa categoría. La herramienta de inspección de URLs (en inglés, «URL Inspection») muestra lo que recibe Google de una dirección concreta.
- Una terminal. Pide una dirección que no pueda existir y lee el estado (comando más abajo).
- El navegador. Abre las herramientas para desarrolladores, ve a la pestaña «Red» (Network), carga una dirección inventada y mira el estado de la primera petición. La página en sí no te dice nada, porque se ve igual con cualquier estado.
Para la comprobación en terminal, la opción -L sigue las redirecciones, de modo que también ves dónde termina la dirección:
curl -s -L -o /dev/null -w "%{http_code} %{url_effective}\n" https://tu-sitio.example/pagina-que-no-existe
Lo que quieres ver es 404. Si obtienes 200 https://example.com/, el servidor redirige las direcciones desconocidas a la página de inicio. Usa GET como aquí y no curl -I, porque algunos servidores responden de otra forma a una petición HEAD.
Prueba desde fuera: pide la dirección pública, no la aplicación directamente. Una CDN, una caché o un firewall delante de la aplicación pueden cambiar la respuesta.
Cómo comprueba SEOgrinder un soft 404
El análisis gratuito de SEOgrinder pide a tu sitio una dirección que se inventa, con un nombre aleatorio que no puede existir. Si la respuesta es 200, informa de un hallazgo. Una redirección de esa dirección a tu página de inicio cuenta como el mismo hallazgo, porque también acaba en 200. El resultado aparece en la pestaña «Página en Google», en la tarjeta «Indexación», como una línea: «Las direcciones desconocidas devuelven 404 correctamente» o «Las direcciones desconocidas devuelven 200 en lugar de 404». El hallazgo pasa a la lista de tareas con el consejo de devolver un 404 o un 410 auténtico.
Dos límites, dichos con franqueza. Primero, esta prueba comprueba cómo trata tu servidor las direcciones que no existen. No te dice cuáles de tus URL reales ha archivado Google como soft 404. Para URL concretas, el veredicto está en Search Console. En una instalación local conectada a Search Console, SEOgrinder lee además el estado de indexación guardado de la página analizada y lo indica cuando Google la registra como soft 404. Segundo, la prueba no puede decirte si una página tuya con poco contenido le parece vacía a Google. El recorrido del sitio sí señala páginas con poco contenido y enlaces internos rotos, que son los lugares donde el problema suele empezar.
¿Qué código de estado es el correcto? Una tabla de decisión
La respuesta correcta depende de lo que sea verdad sobre la página. Cambia el estado para que coincida con la realidad, no al revés.
| Situación | Respuesta correcta | Nota |
|---|---|---|
| La página ha desaparecido para siempre y no hay equivalente | 404 o 410 | Una página de error con diseño está bien, pero debe enviar el estado de error |
| La página se ha movido a otra dirección | 301 (o 308) a la nueva página equivalente | Una señal fuerte de que Google debe procesar el destino |
| El cambio es de verdad temporal | 302 (o 307) | Una señal débil, así que no sirve para movimientos permanentes |
| La página existe pero tiene poco contenido o está casi vacía | Añadir contenido real | O eliminarla, si no tiene ninguna función |
| Una página de lista o de búsqueda que está vacía para siempre | 404 | No la ofrezcas en enlaces ni en el sitemap |
| Una página de lista que está vacía por ahora | Mostrar algo útil | Por ejemplo, elementos relacionados y una nota, con estado 200 |
| Un producto que ya no existe | 404 o 410, o un 301 a su sucesor directo | No a la página de inicio |
| Un producto agotado durante un tiempo | Mantener la página con su contenido real | Aquí el estado 200 es correcto |
Google trata 301 y 308 como una señal fuerte de que el destino de la redirección debe procesarse, y 302 y 307 como una señal débil. Sigue hasta diez pasos de redirección por defecto e ignora el contenido de la URL que redirige. Por eso conviene redirigir una sola vez, directamente a la dirección final.
Cómo corregir un soft 404 en nginx, Node y aplicaciones de una sola página
nginx
Esta configuración muestra una página de error con diseño y conserva el estado 404. La línea error_page 404 /404.html; mantiene el estado original salvo que añadas =200, así que no lo añadas.
server {
root /var/www/example;
error_page 404 /404.html;
location / {
try_files $uri $uri/ =404;
}
location = /404.html {
internal;
}
# eliminada a propósito
location /campana-antigua/ {
return 410;
}
# movida
location = /pagina-antigua {
return 301 https://example.com/pagina-nueva;
}
}
Node
En las rutas con datos, el código tiene que buscar primero el registro y decidir el estado después. Este ejemplo usa solo módulos propios de Node:
import http from 'node:http';
const productos = new Map([['taza-azul', 'Taza azul']]); // sustituto de tu base de datos
http.createServer((req, res) => {
const { pathname } = new URL(req.url, 'http://localhost');
const coincidencia = /^\/productos\/([a-z0-9-]+)$/.exec(pathname);
const nombre = coincidencia && productos.get(coincidencia[1]);
res.writeHead(nombre ? 200 : 404, { 'content-type': 'text/html; charset=utf-8' });
res.end(nombre ? `<h1>${nombre}</h1>` : '<h1>Página no encontrada</h1>');
}).listen(3000);
La página de error puede ser amable y tener diseño, y el estado sigue siendo 404. La mayoría de los frameworks tienen una función o un gancho de «no encontrado» para esto. Busca el que fija el estado y no se limita a mostrar una plantilla.
Aplicaciones de una sola página (SPA)
El servidor debe saber qué rutas son reales. El atajo habitual, «enviar index.html para cualquier ruta», es justo lo que crea el problema. En nginx puedes enumerar las rutas reales y responder 404 al resto:
location = / {
try_files /index.html =404;
}
location ~ ^/(nosotros|contacto|docs)/?$ {
try_files /index.html =404;
}
location / {
try_files $uri =404;
}
El último bloque encuentra los recursos, como scripts e imágenes, y cualquier otra ruta recibe un 404. Si la lista de rutas es larga o cambia a menudo, genérala a partir de tu enrutador en el momento de la compilación. La alternativa es renderizar páginas reales en el servidor o por adelantado, de modo que cada dirección tenga su propio archivo HTML y el servidor pueda responder por ella. Google mismo considera una buena idea el renderizado en el servidor o el prerenderizado, porque hace la página más rápida para usuarios y rastreadores y porque no todos los bots ejecutan JavaScript. Para las aplicaciones donde fijar un código de estado es imposible o poco práctico, las nociones básicas de JavaScript de Google mencionan dos vías más: redirigir con JavaScript a una dirección que responda 404 (por ejemplo /no-encontrada) o añadir con JavaScript <meta name="robots" content="noindex"> en las páginas de error.
Después de cada cambio, repite la comprobación con curl y prueba una página real, una página movida y una dirección que no pueda existir.
Errores frecuentes
- Arreglar el diseño y no el estado. Una página preciosa de «no encontrada» que envía 200 sigue siendo un soft 404.
- Redirigir todas las páginas que faltan a la página de inicio. Oculta el problema a tus propias herramientas y da a los visitantes algo distinto de lo que pidieron. Redirige a una página equivalente o responde 404.
error_page 404 =200 /index.html;y atajos parecidos. Cambian el estado a 200 para cualquier dirección desconocida.- Probar solo en el navegador. El navegador se ve igual con cualquier estado. Lee el estado.
- Probar una sola dirección. Comprueba una página real, una movida y una inventada, a ser posible en distintas zonas del sitio.
- Bloquear las direcciones en el robots.txt en lugar de corregir el estado. Un rastreador que no puede pedir una página nunca ve su código de estado.
- Dejar direcciones muertas en el sitemap. Un sitemap debe enumerar solo páginas que existen y responden 200.
- Esperar que el informe se limpie al instante. La entrada de Search Console cambia cuando Google vuelve a pedir la URL. Nadie puede prometer cuándo ocurrirá.
Preguntas frecuentes
¿Perjudica un soft 404 a mi posicionamiento?
No está demostrado. Lo documentado es que Google lo señala como error en Search Console. Una penalización directa para el resto de tu sitio no figura en ninguna fuente de las que hemos usado. La lectura sensata es esta: corrígelo porque es una respuesta incorrecta, no por una ganancia prometida.
¿Es lo mismo un soft 404 que un 404?
No. Un 404 es una respuesta honesta: el estado dice que la página no existe. Un soft 404 dice 200 mientras el contenido dice lo contrario.
¿Debo enviar 404 o 410?
Los dos son estados de error 4xx, y con ninguno de ellos usa Google el contenido de la URL. 404 es la respuesta habitual para «no encontrada». 410 significa «eliminada definitivamente», así que encaja con páginas que has retirado a propósito.
¿Puedo tener una página 404 personalizada?
Sí, y deberías. Diséñala como quieras, añade un enlace a la página de inicio o un buscador, pero asegúrate de que el estado sea 404.
¿Cuánto tarda en desaparecer el aviso de Search Console?
Nadie puede asegurarlo. La entrada cambia cuando Google vuelve a pedir la dirección, y cuándo lo hace lo decide Google.
Mi SPA está en un hosting donde no puedo configurar el servidor. ¿Qué hago?
Entonces el estado lo decide el proveedor. Mira en su documentación si las rutas desconocidas pueden devolver un 404, o pregunta a su soporte. Si no sirve, Google menciona dos vías cuando en una aplicación de una sola página no se puede fijar un código de estado: redirigir con JavaScript a una dirección que responda 404 (por ejemplo /no-encontrada) o añadir con JavaScript <meta name="robots" content="noindex"> en las páginas de error. También puedes generar las páginas por adelantado, de modo que cada dirección real tenga su propio archivo. Para cualquier otra dirección no habrá archivo y el hosting puede responder con su propio 404, siempre que no tenga activa una regla que envíe index.html para cualquier ruta. Compruébalo con curl antes de fiarte.
Tu siguiente paso
Ejecuta curl contra una dirección que no pueda existir en tu propio sitio. Si no obtienes un 404, corrige eso primero. Después haz el análisis gratuito con SEOgrinder, busca la línea del soft 404 en la tarjeta «Indexación» de la pestaña «Página en Google» y pulsa «Comprobar de nuevo» tras tu cambio para ver el resultado nuevo.