Abres Search Console, entras en Páginas > No indexadas y ahí está el estado «Soft 404» junto a URLs que en tu navegador cargan sin problema, con su ficha y su botón de compra. La primera reacción suele ser pensar que Google se ha equivocado, y a veces es así, pero en las auditorías que hago el aviso casi siempre señala algo que merece clasificarse antes de tocar nada.
Por qué Google marca como soft 404 una página que a ti te funciona
Según la documentación de Google sobre errores de rastreo, un soft 404 es una URL que muestra al usuario un mensaje de que la página no existe pero responde con un código de estado 200, es decir, con un «todo correcto» que contradice lo que se ve en pantalla. Google lo deduce por el contenido que encuentra al renderizar la URL, y por eso puede etiquetar como soft 404 una página que tú das por buena.
Entre las causas que cita la propia documentación aparecen un archivo de inclusión del servidor (server-side include) que falta, una conexión rota con la base de datos y una página de resultados de búsqueda interna sin resultados. En todas ellas el servidor sigue contestando 200 mientras el usuario lee un mensaje de error o una plantilla casi vacía.
Si lo que ves en tu informe es otro estado, el de rastreada actualmente sin indexar, la lógica cambia, porque ahí Google llegó a leer una página con contenido y aún no la ha incluido en el índice, y en el soft 404 interpreta que la página dice no existir. Son avisos distintos y se resuelven con decisiones distintas.
Otro detalle de la documentación de Google sobre códigos de estado HTTP que conviene tener presente es que un 2xx no garantiza la indexación, y que las URLs con 4xx no entran en el índice o salen de él si ya estaban. Dicho de otro modo, un 200 con un mensaje de «no encontrado» cae en una zona gris que Google resuelve por su cuenta.
Cómo confirmo en la Inspección de URL si el problema es real
Antes de decidir nada, hago siempre la misma comprobación con la herramienta de Inspección de URL de Search Console, y sigo este orden porque cada paso descarta una familia de causas:
- Pruebo la URL publicada y miro el HTML renderizado y el código HTTP que recibe Google, que a veces difiere de lo que ves tú en el navegador.
- Reviso si hay recursos bloqueados, errores de servidor o una carga tan lenta que la página llega a medias, tres cosas que la documentación de Google menciona para los casos en los que el contenido sí existe.
- Me hago una única pregunta, la que ordena todo lo demás: ¿esta URL debería existir?
Con un sí como respuesta, el fallo es de contenido o de renderizado y cambiar el código de estado no lo arregla. Esa es la parte que las guías genéricas se saltan, porque casi todas arrancan en «devuelve un 404» sin preguntar si la página tenía que seguir viva.
Imagina una tienda cuya ficha de producto carga el texto principal tras una llamada a una API. Si esa llamada falla o tarda demasiado cuando pasa Googlebot, el HTML renderizado puede quedarse en un «producto no disponible» aunque tú, cinco minutos después, veas la ficha completa. Ahí el remedio está en el servidor o en cómo se renderiza la página, y un 404 o una redirección solo esconderían el problema.
Qué hago según el tipo de URL
Cuando el listado de soft 404 es largo, lo primero que hago es agruparlo por tipo de URL, porque cada grupo tiene una decisión distinta y tratarlas todas igual es lo que más tiempo hace perder. Esta es la tabla que uso como punto de partida.
| Tipo de URL | Qué suele pasar | Decisión habitual |
|---|---|---|
| Producto agotado o descatalogado | La ficha sigue respondiendo 200 con un aviso de «no disponible» y poco contenido más. | Depende de si el producto vuelve. |
| Listado, filtro o paginación vacíos | Una categoría o una página de filtro sin productos que devuelve 200 con una cuadrícula vacía. | Si la categoría debe existir, darle contenido; si el filtro no produce resultados, que responda 404. |
| Resultados de búsqueda interna sin resultados | La plantilla de «0 resultados» con estado 200. | Mantener esas URLs fuera del índice y fuera del enlazado. |
| Ruta dinámica en un framework JavaScript | Plantilla de «no encontrado» servida con 200. | Que el framework propague el error y devuelva un 404 real. |
| Páginas eliminadas redirigidas en masa a la home | Muchas URLs distintas que acaban todas en la portada. | 301 solo al equivalente real; si no existe, 404 o 410. |
El caso de las rutas dinámicas es el que con más frecuencia me encuentro en auditorías de webs con Next.js. La ruta no localiza el recurso, pinta su plantilla de «no encontrado» y responde 200, porque el framework no traslada el estado de error a la respuesta HTTP. Desde el lado del desarrollador todo parece correcto, y por eso cuesta tanto que el equipo técnico lo vea como un fallo.
La redirección masiva a la home merece una advertencia aparte, ya que guías como la de Ahrefs la recogen como causa habitual de soft 404 y mi criterio coincide, porque una ficha de producto concreta no tiene como equivalente la portada y redirigir ahí todo lo eliminado equivale a decirle a Google que cosas distintas son lo mismo. Si redirijo, uso un 301, porque Google lo trata como señal fuerte y a los 302 y 307 como señal débil.
La regla que aplico al cerrar el triaje cabe en tres casos: si el contenido se eliminó y no tiene reemplazo, 404 o 410; si se movió, 301 hacia el equivalente real; si sigue vivo, se arregla el renderizado o el servidor. Todo lo que no encaje ahí lo reviso a mano, URL por URL.
Cuándo puedes dejar un soft 404 como está
Hay avisos que no merecen tu tiempo, y el más claro es el de una URL de poca importancia que no tiene por qué estar indexada, como una página de resultados internos o un filtro sin salida comercial, donde el soft 404 es meramente informativo y corregirlo rara vez sale a cuenta.
Aquí hay una contradicción entre lo que cuenta Google y lo que repiten muchas guías. En julio de 2026, según Search Engine Journal, John Mueller y Martin Splitt comentaron que las etiquetas de «error» de Search Console confunden y que muchos de esos avisos no son problemas reales. Varias guías de SEO, en cambio, tratan el soft 404 como un fallo que hay que corregir cuanto antes porque, según sostienen, malgasta presupuesto de rastreo. Esa última afirmación es opinión de terceros, la documentación de Google que he usado para este artículo no la hace, y por eso yo la trato como hipótesis.
Mi criterio de prioridad es sencillo: primero arreglo lo que debería estar indexado y no lo está, porque ahí se pierde tráfico potencial, y después, si queda tiempo, limpio el resto. Un listado largo de soft 404 donde la mayoría sean filtros vacíos y unos pocos sean fichas de producto con el render roto se resuelve empezando por esas fichas.
Ante un informe lleno de avisos y sin saber a qué grupo pertenece cada uno, esa clasificación es una de las primeras cosas que reviso en una auditoría SEO técnica.
Preguntas frecuentes
¿Un soft 404 es lo mismo que un 404?
Un 404 devuelve ese código de estado y avisa al buscador de que la URL no existe; el soft 404 responde 200 con una página que dice que no existe, y Google lo detecta por el contenido que ve.
¿Debo redirigir a la home las URLs que dan soft 404?
Como norma general no, redirige con un 301 solo cuando exista un equivalente real de esa URL y, si no lo hay, lo coherente es un 404 o un 410, porque la portada rara vez sustituye a una ficha o a un artículo concretos.
¿Puedo pedir a Google que revalide la URL cuando la corrija?
Sí, una vez corregida la causa puedes usar la validación de la corrección que ofrece el informe de Search Console para ese estado. No te doy un plazo porque depende del sitio y de cuándo vuelva a rastrear Google esas URLs.
¿Puedo ignorar un soft 404?
Sí, siempre que la URL sea de poca importancia y no necesite estar en el índice. Si la página sí debería aparecer en Google, el aviso apunta a un fallo de contenido o de carga que hay que corregir.
Desarrollo, SEO, GEO y tecnología con una visión de negocio.