Error soft 404 en Search Console. Cómo solucionarlo.
¿Google marca una URL como soft 404 aunque abra correctamente? Aprende a identificar el problema, comprobar su respuesta HTTP y aplicar la solución correcta en WordPress, Elementor, ecommerce o JavaScript, sin redirecciones innecesarias.
Cómo corregir un soft 404 en Google Search Console.
La respuesta corta
Un soft 404 aparece cuando Google interpreta que una URL muestra una página inexistente, vacía o de error, aunque la respuesta HTTP no refleje correctamente esa situación; el caso clásico es HTTP 200 OK + «Página no encontrada». Si la URL ha desaparecido, devuelve 404 o 410. Si se ha movido a una página realmente equivalente, aplica un 301. Si debería existir, revisa la respuesta, el contenido visible y lo que Google ha podido renderizar. Después verifica la corrección en Search Console. Documentación oficial de Google ↗.
Los códigos son una orientación de diagnóstico: Google decide la clasificación final a partir de su rastreo y del contenido recibido. Un HTTP 200 tampoco garantiza que una URL se indexe.
Qué es un error soft 404 y por qué no es un 404 normal.
«Soft» no significa un error pequeño ni un código HTTP alternativo. Es la interpretación de Google cuando lo que comunica la página no concuerda con la respuesta técnica esperada.
Imagina que alguien entra en /producto/lampara-azul/. El servidor contesta HTTP/2 200, como si la página estuviera disponible. Sin embargo, el HTML muestra «No hemos encontrado el producto», una plantilla vacía o una pantalla que no termina de cargar. Ese desacuerdo puede hacer que Google clasifique la URL como Soft 404 en el informe de indexación de páginas.
Google también documenta problemas de archivos JavaScript que no cargan, errores de base de datos, búsquedas internas sin resultados o ausencia de contenido principal. No toda página breve ni todo estado «Rastreada: actualmente sin indexar» es automáticamente un soft 404; hay que comprobar la evidencia de cada URL. Ver descripción de Google Search Console ↗.
El servidor comunica éxito, pero lo que recibe el usuario o Google parece un error o no contiene la página solicitada.
El servidor devuelve expresamente que la URL no está disponible. Puede mostrar navegación y enlaces útiles.
Google cree que está ante un error.
La URL no se publica en la Búsqueda como una página válida por esta clasificación. Si debería posicionar, conviene investigar y corregir la causa de fondo.
Que tengas que redirigir todo al inicio.
Un 404 real para una URL eliminada sin sustituto es normal. No necesitas inventar contenido ni enviar todas las URLs rotas a la home. Google desaconseja ese patrón.
Cómo detectar URLs soft 404 paso a paso.
No hace falta instalar ninguna herramienta de pago. Search Console permite localizar ejemplos afectados e inspeccionar cómo ha tratado Google cada URL.
Abre la propiedad adecuada.
Entra en Google Search Console y elige la propiedad que contiene la URL, incluyendo su versión de dominio si corresponde.
Ve a «Páginas».
En el menú, busca Indexación → Páginas. Dentro de los motivos por los que las páginas no están indexadas, localiza Soft 404.
Abre la incidencia.
Revisa los ejemplos de URL y su tendencia. Distingue contenido comercial vigente de URLs eliminadas o inventadas que no merecen reparación.
Inspecciona una URL concreta.
Usa Inspección de URLs. Examina los datos conocidos de Google, su último rastreo y la información disponible de indexación.
Haz la prueba en directo.
Pulsa Probar URL publicada para comprobar el estado actual. Si la prueba lo permite, abre Ver página probada y revisa HTML, recursos y captura.
Compara dos versiones.
La información indexada puede corresponder a un rastreo anterior. Una prueba en directo correcta no garantiza que el estado histórico cambie en ese mismo instante.
Las barras son decorativas: no muestran datos ni cifras reales. Las etiquetas de la interfaz pueden variar según idioma o cambios de Google.
Cómo interpretar la captura de «Ver página probada»
Si la imagen renderizada muestra únicamente cabecera, pie y un bloque vacío, investiga la carga del contenido principal. Si aparece un aviso «No disponible», comprueba si procede de la plantilla, un plugin, la API o la autenticación. Y si la captura muestra una página completa, compara la fecha del último rastreo, la respuesta HTTP y los posibles mensajes que puedan hacerla parecer un error. Según Google, la captura solo está disponible en una prueba en directo que haya finalizado correctamente. Ayuda de la Inspección de URLs ↗.
Consejo: revisa una URL por patrón, no solo la primera de la lista. Un archivo de producto eliminado, una página de servicio activa y una búsqueda interna vacía pueden aparecer agrupados bajo el mismo motivo pero requerir acciones completamente distintas.
Qué revisar antes de tocar una redirección. El orden importa.
El diagnóstico técnico consiste en reunir tres pruebas: estado HTTP, contenido real e intención de la URL. La recomendación surge de cruzarlas, no de una regla universal.
| Comprobación | Qué observar | Qué revela | Acción siguiente |
|---|---|---|---|
| 1 · Estado HTTP | ¿Devuelve 200, 404, 410, 301 o 5xx? | Si la respuesta del servidor coincide con el destino real de la URL. | Verificar GET y destino final; no quedarse solo en HEAD. |
| 2 · Contenido visible | ¿Existe título, contenido principal y datos relevantes? | Si la página sirve lo que promete o parece vacía/de error. | Revisar plantilla, CMS, base de datos y datos dinámicos. |
| 3 · Renderizado Google | ¿La captura y el HTML renderizado incluyen el contenido? | Si fallan scripts, recursos o dependencias al renderizar. | Comparar navegador y prueba en directo de Search Console. |
| 4 · Destino editorial | ¿La URL debe existir, se trasladó o se eliminó? | Qué código de estado y navegación esperan usuarios y buscadores. | Mantener 200, usar 301 equivalente o devolver 404/410. |
| 5 · Descubrimiento | ¿Tiene enlaces internos o aparece en el sitemap? | Por qué Google sigue visitando una URL que quizá no debería. | Actualizar sitemap y enlaces internos según la nueva situación. |
| 6 · Comprobación final | ¿Qué ve ahora Google y qué registra la próxima visita? | Si la solución está desplegada y Google puede comprobarla. | Probar URL publicada y validar la corrección si procede. |
Diagnóstico guiado de soft 404. Obtén una acción recomendada.
Selecciona lo que has comprobado en una URL afectada. El asistente no accede a tu dominio ni a Search Console: interpreta tus respuestas localmente y genera una orientación de trabajo descargable.
Describe lo que está pasando.
No envía información a servidores. La recomendación es orientativa y no sustituye la prueba en directo de Google.
Recupera el contenido de la URL.
Si la URL debe existir, pero entrega HTTP 200 con contenido vacío, primero necesitas reparar la plantilla o el sistema que genera la página.
Herramienta de decisión, no test automático. Para medir tu URL debes usar un cliente HTTP o una herramienta con acceso autorizado; un widget de Elementor no puede obtener de forma fiable el código de estado de cualquier dominio ajeno.
Las cuatro soluciones reales. Elige según la intención de la página.
La documentación de Google plantea tres grandes escenarios —retirada, traslado y contenido aún disponible—. Añadimos un cuarto, cuando la señal técnica o la observación de Search Console no bastan para confirmar el problema.
Devuelve 404 o 410 si no hay sustituto.
Una URL de producto antiguo o artículo eliminado definitivamente puede salir del índice. Si no existe una página que responda a la misma intención, no necesitas redirigirla a la home. El 404 indica «no encontrada»; el 410 expresa «retirada». Google trata ambos dentro de la familia 4xx para la indexación.
Después: elimina esa URL del sitemap y corrige enlaces internos que sigan conduciendo a ella. Una página 404 personalizada puede incluir navegación útil, pero la respuesta debe seguir siendo HTTP 404.
Redirecciona con 301 al contenido equivalente.
Si /servicios/seo-antiguo/ pasa a /servicios/seo/ y responde a la misma necesidad, una redirección permanente es adecuada. Comprueba que el destino existe, devuelve 200 y no inicia una cadena innecesaria.
Evita: enviar todos los productos agotados, artículos borrados o URLs aleatorias a la página de inicio. Una redirección sin relación temática puede ser interpretada por Google como soft 404.
Recupera el contenido que Google no ve.
Si la URL es válida y debe aparecer en Google, revisa los errores del CMS, plantilla, base de datos, API, JavaScript, recursos bloqueados y mensajes grandes de «no encontrado». Asegúrate de que la página muestre contenido principal realmente útil, no solo elementos comunes del tema.
Después: prueba la URL en directo, revisa el HTML generado y la captura cuando esté disponible, y solo entonces solicita una nueva comprobación.
Comprueba lo actual antes de cambiar código.
Si el GET devuelve 200 y la URL muestra contenido completo, compara fecha de rastreo, prueba en directo, acceso móvil, posibles variaciones por cookies y avisos de error que se muestren temporalmente. Una corrección ya desplegada no siempre se refleja de inmediato en el informe.
Evita: añadir texto de relleno solo para «engañar» al clasificador o cambiar URLs y canonicals sin verificar su causa.
noindex? No es el arreglo universal de un soft 404. Para una URL que no existe, la señal correcta suele ser 404/410. Para una URL válida que quieres indexar, noindex impediría tu objetivo. Google contempla noindex como una estrategia específica para páginas de error en aplicaciones SPA, pero no sustituye una gestión HTTP coherente cuando puede implementarse. Guía oficial de JavaScript ↗.Seis ejemplos para reconocer el patrón en tu web
Situaciones ilustrativas de diagnóstico; no son casos de clientes ni resultados inventados.
Una página 404 con HTTP 200.
El tema muestra «No encontrada», pero un plugin o una personalización modifica el estado de la respuesta.
Corregir el estado a 404.La landing aparece vacía para Google.
Solo se renderiza la cabecera; el cuerpo depende de scripts que fallan o no llegan a cargarse.
Reparar renderizado y contenido.Producto retirado sin alternativa.
La URL existe técnicamente, pero muestra únicamente «Producto no encontrado» con un 200.
404/410 o sustituto equivalente.Resultados internos vacíos.
Un buscador interno crea miles de URLs con la misma plantilla y sin resultados.
Definir política de rastreo/indexación.Todas las URLs antiguas van a inicio.
Una regla genérica 301 hace que páginas sin relación acaben en el mismo destino.
Mapear equivalencias o devolver 404.HTTP 200 para cualquier ruta.
El servidor envía la aplicación y esta muestra «No existe» solo en el navegador.
Gestionar la ruta y estado real.Cómo solucionar el soft 404 en WordPress.
En WordPress suele ser útil separar el HTML que ves de la respuesta HTTP enviada por PHP y el servidor. Elementor puede diseñar una plantilla 404, pero esa apariencia no demuestra por sí sola que el servidor responda 404.
1. Revisa la plantilla 404 del tema.
Visita una URL inventada y confirma su estado con curl o las herramientas de red del navegador. Si muestra una página 404 personalizada pero devuelve 200, revisa el enrutamiento, la plantilla del tema, snippets, caché y plugins que alteren el encabezado.
En un WordPress que identifica correctamente la petición como inexistente, la respuesta debe ser 404 aunque su diseño sea atractivo. Las funciones is_404() y status_header() están documentadas por WordPress para desarrolladores.
2. Comprueba el Theme Builder de Elementor.
Si usas una plantilla de error en Elementor Pro, revisa sus condiciones de visualización y asegúrate de que se aplica solo a solicitudes inexistentes. Una plantilla genérica insertada como página normal puede verse como un 404 mientras mantiene HTTP 200.
Para una URL que sí debe existir, confirma que Elementor publique el contenido real, sus recursos CSS/JS se carguen y la página no dependa de un estado de sesión que Google no tenga.
3. Investiga plugins y cachés.
Revisa extensiones de redirecciones, SEO, idiomas, seguridad, caché y mantenimiento. Un plugin puede servir HTML diferente a visitantes no autenticados, introducir avisos de error o redirigir URLs antiguas indiscriminadamente. Prueba tras vaciar la caché pertinente y sin asumir que la vista de administrador coincide con la pública.
Haz cambios sobre una copia o entorno de pruebas, especialmente en tiendas y webs con mucho tráfico.
4. Revisa WooCommerce y categorías vacías.
Un producto descatalogado con sucesor real puede redirigir a una ficha equivalente; uno eliminado sin alternativa debería responder 404/410. Una categoría temporalmente sin stock no debe convertirse automáticamente en 404 si sigue siendo útil para el usuario. Valora su propósito, contenido y ciclo de vida.
Las búsquedas internas vacías y los filtros combinatorios requieren una estrategia específica: no es correcto aplicar la misma regla a todo un catálogo.
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \
'https://ejemplo.com/pagina-que-no-existe-12345/'Si el problema afecta a una página que quieres posicionar
No te limites a «añadir más palabras». Comprueba que el título y la información principal existan en el HTML accesible, que no haya textos de error destacados, que las imágenes o scripts esenciales no estén bloqueados y que la página responda a una intención clara. Si una plantilla vacía se repite en decenas de URLs, repara la plantilla común antes de editar cada publicación por separado.
Comprueba el HTTP 200, las redirecciones y el HTML real.
Un soft 404 es, en gran parte, un problema de interpretación del resultado de una solicitud. Por eso merece la pena verificar cómo responde el servidor con una petición real y qué contenido entrega.
DevTools → Network.
En Chrome o Firefox, abre la URL, pulsa F12 y entra en la pestaña Red/Network. Recarga, filtra por Document, selecciona el documento principal y revisa Status Code, respuesta y posibles redirecciones.
Es una comprobación de navegador, no una simulación exacta del rastreo de Googlebot.
Usa GET si necesitas ver la respuesta.
Un curl -I envía HEAD: resulta rápido para encabezados, pero algunos servidores responden distinto a HEAD y GET. Si dudas, compara una petición GET real sin descargar en pantalla todo el HTML.
Revisa la URL final y los saltos si sigues redirecciones.
# Sustituye por la URL afectada (sin cambiarla en Search Console).
curl -sS -L -o /dev/null \
-w 'HTTP final: %{http_code}\nURL final: %{url_effective}\n' \
'https://ejemplo.com/url-afectada/'
# Comprueba también la respuesta sin seguir redirecciones.
curl -sS -o /dev/null -w 'HTTP inicial: %{http_code}\n' \
'https://ejemplo.com/url-afectada/'HTTP/2 200
content-type: text/html; charset=UTF-8
<main>
<h1>Página no encontrada</h1>
<p>Este contenido ya no existe.</p>
</main>
# Si la URL no existe: HTTP/2 404 (o 410 si fue retirada).¿Y si la URL usa React, Vue u otra SPA?
En una aplicación de página única el servidor puede entregar siempre index.html con HTTP 200, incluso para rutas inventadas. Después el router de JavaScript muestra un mensaje «No encontrado». Google identifica este patrón como un riesgo de soft 404. Lo preferible cuando sea viable es resolver la existencia de la ruta en el servidor o con renderizado que permita el estado HTTP adecuado.
Google documenta específicamente alternativas para páginas de error de SPA: redirigir a una URL cuyo servidor devuelva HTTP 404 o establecer noindex en las vistas de error cuando las restricciones del cliente lo requieren. No apliques noindex a una página válida que debe indexarse. Si el contenido es legítimo pero no aparece en la captura, comprueba los recursos y errores JavaScript, y estudia renderizado del lado del servidor o prerenderización cuando el proyecto lo necesite. Referencia técnica de Google ↗.
¿Puede un código 200 garantizar la indexación?
No. Google declara expresamente que un estado HTTP 2xx permite procesar la respuesta, pero no garantiza que la URL se indexe. Tampoco es lo mismo un soft 404 que una URL «Rastreada: actualmente sin indexar», una duplicada o una página excluida por noindex. Son estados que exigen diagnósticos distintos. Códigos HTTP según Google ↗.
Cómo validar la corrección y saber si ha funcionado.
El cambio se confirma primero técnicamente y después se comprueba cómo lo procesa Google. Son dos pasos distintos; que la prueba en directo funcione no obliga a que el informe histórico cambie al instante.
Publica y purga cachés.
Asegúrate de que el arreglo funciona en la URL pública, no solo en tu editor o entorno de pruebas.
Comprueba código y destino.
Repite la petición GET. Verifica 404/410 si fue retirada, 301 al equivalente si se movió, o 200 con contenido real si sigue activa.
Prueba la URL publicada.
En Search Console, usa Inspección → Probar URL publicada. Examina recursos y captura, si la prueba ofrece esa información.
Revisa enlaces y sitemap.
Mantén en el sitemap las páginas canónicas que deberían indexarse. Corrige enlaces internos hacia URLs retiradas o destinos incorrectos.
Solicita la validación.
En el detalle de Soft 404, utiliza Validar corrección si has resuelto las instancias afectadas. Para una URL válida, puedes solicitar indexación cuando proceda.
Revisa el resultado más adelante.
Las verificaciones tardan; Google indica que suelen requerir alrededor de dos semanas, a veces más. Si falla, inspecciona la URL que originó el fallo.
Checklist final antes de cerrar la incidencia
Lo que no debes hacer para «limpiar» Search Console.
Corregir cifras de un informe sin corregir la experiencia que recibe Google crea nuevos problemas. Evita estas soluciones aparentes.
Todas las URLs rotas a la home.
Si la página de destino no es equivalente, la redirección no resuelve la intención original y puede tratarse como soft 404.
Taparlo con robots.txt.
Bloquear el rastreo impide comprobar el estado y no es la forma correcta de informar que una URL fue eliminada. Revisa cada caso.
Rellenar una página vacía sin utilidad.
Añadir frases genéricas no soluciona un dato dinámico que no llega, un error de plantilla ni una URL que debería desaparecer.
Confundir Search Console con un test en vivo.
La etiqueta del informe puede proceder de un rastreo anterior. Compara información histórica, respuesta actual y renderizado.
Soft 404, 404, noindex y páginas no indexadas. No es lo mismo.
Varias exclusiones de Search Console pueden parecer similares a primera vista, pero tienen causas y soluciones diferentes.
| Estado en Search Console | Qué indica | Primera comprobación | Qué no debes asumir |
|---|---|---|---|
| Soft 404 | Google interpreta una respuesta como página no encontrada, vacía o de error. | HTTP + contenido + renderizado. | Que exista siempre un 404 HTTP real. |
| No se ha encontrado (404) | El servidor respondió con 404. | ¿Se eliminó sin sustituto o debería existir? | Que todos los 404 sean perjudiciales. |
| Bloqueada por noindex | Google detectó una instrucción para excluir la URL. | Etiquetas robots o encabezados X-Robots-Tag. | Que es el mismo problema que un soft 404. |
| Rastreada: actualmente sin indexar | Google la rastreó, pero no la incorporó al índice. | Contenido, intención, indexabilidad y contexto. | Que falta necesariamente devolver un 404. |
| Página con redirección | La URL lleva a otra ubicación. | Código, cadena y relevancia del destino. | Que una redirección sea siempre un error. |
Referencia: Informe «Indexación de páginas» — Ayuda de Search Console. La clasificación visible puede cambiar entre rastreos y versiones de la interfaz.
Preguntas frecuentes sobre el error soft 404.
Respuestas directas a los casos que más dudas generan después de revisar un informe de indexación.
¿Qué significa Soft 404 en Google Search Console?
Significa que Google considera que la respuesta de la URL se parece a una página de error, aunque no se haya indicado correctamente mediante un código HTTP 404. El ejemplo más habitual es un HTTP 200 con un mensaje «Página no encontrada» o sin contenido principal.
¿Cómo se soluciona un error soft 404?
Comprueba la URL, el HTTP y el contenido. Si desapareció sin reemplazo, devuelve 404/410; si se movió a un equivalente, 301; si sigue siendo válida, repara el contenido o el renderizado. Después usa la inspección en directo para comprobar el cambio.
¿Un soft 404 afecta al SEO?
Puede impedir que esa URL aparezca en los resultados de Google. Si se trata de una página importante, sí es un problema de visibilidad. Si es una URL eliminada correctamente, su exclusión puede ser totalmente normal. No existe una penalización automática a todo el dominio por tener un 404 legítimo.
¿Cuál es la diferencia entre 404 y soft 404?
En un 404 real, el servidor devuelve el código HTTP 404. En un soft 404, Google deduce que la página funciona como un error aunque su código no lo indique de la forma esperada, habitualmente porque recibe 200 y un contenido inexistente o vacío.
¿Puedo arreglarlo redirigiendo la URL a la home?
Solo si la home es realmente el sustituto pertinente, algo poco frecuente para páginas interiores específicas. Una redirección masiva a contenido no equivalente no suele resolver la necesidad del usuario y puede seguir clasificándose como soft 404.
¿Tengo que cambiar un 404 por un 410?
No necesariamente. Google acepta ambos para indicar que el contenido no existe. El 410 expresa una retirada intencional; no hace falta convertir automáticamente todos los 404 en 410. Lo fundamental es que el servidor dé una respuesta coherente.
¿Por qué veo soft 404 si la página funciona?
Es posible que Google haya visto una versión temporalmente vacía, una carga JavaScript incompleta o un mensaje de error durante un rastreo anterior. Comprueba la última fecha de rastreo, haz una prueba en directo y verifica las diferencias entre el navegador y el contenido renderizado.
¿Cómo detectarlo en WordPress y Elementor?
Prueba una URL inexistente, mira su código HTTP y confirma que la plantilla 404 conserva una respuesta 404. Si la URL debería existir, examina si su contenido se publica correctamente, el Theme Builder, plugins, caché y recursos de la página.
¿Una página con poco texto siempre es soft 404?
No. Google puede detectar como soft 404 páginas vacías o que parezcan errores, pero una página breve y útil no recibe automáticamente esa clasificación por su longitud. Revisa la intención, la información principal y la prueba real de Search Console.
¿Robots.txt o noindex corrigen el soft 404?
No son remedios universales. Robots.txt bloquea el rastreo, no comunica una página eliminada. Noindex impide indexar una URL válida, por lo que sería contraproducente si debe posicionar. En SPA, Google documenta noindex para vistas de error bajo circunstancias específicas.
¿Cuánto tarda Google en quitar el error?
Depende de cuándo vuelva a comprobar la URL y del proceso de validación. Google indica que una validación suele tardar unas dos semanas, aunque puede prolongarse. El informe no necesariamente se actualiza en el momento en que arreglas la web.
¿Debo eliminar la URL del sitemap?
Si ya no existe o redirige permanentemente, lo normal es que el sitemap incluya su destino canónico indexable, no la URL retirada. Si la página sigue vigente y quieres indexarla, debe conservar un estado 200 correcto y puede permanecer en el sitemap.
¿Qué pasa si mi tienda tiene muchos productos descatalogados?
Clasifica los productos por intención y sustitución: fichas con reemplazos equivalentes pueden tener 301, páginas retiradas sin sustituto 404/410, y fichas temporalmente sin stock pueden seguir publicadas si aportan utilidad. Evita una regla masiva de redirección a la home o categoría sin valorar cada caso.
¿Validar corrección garantiza que la URL vuelva a posicionar?
No. La validación comprueba el problema detectado, no garantiza indexación ni rankings. Una URL puede resolver el soft 404 y seguir excluida por otros motivos de rastreo, duplicación o selección de indexación.
Fuentes contrastadas y criterio de revisión.
Actualizado el 17 de octubre de 2026. Para definir estados, códigos y validación se han priorizado documentos de Google Search Central y Search Console; la documentación de WordPress se utiliza para explicar el papel del CMS.
Autor y alcance de esta guía
Contenido preparado para rogerllorens.com, con enfoque práctico de SEO técnico, Search Console y desarrollo WordPress. La prioridad es mostrar qué medir, qué cambiar y cómo validar sin recomendar soluciones masivas que puedan empeorar la arquitectura. Los ejemplos de URLs, los casos de diagnóstico y las pantallas recreadas son didácticos; no representan datos de una cuenta real ni constituyen una auditoría del dominio del lector.
Esta publicación trata la clasificación soft 404. No pretende sustituir una guía general sobre páginas 404 de WordPress o todos los errores de rastreo: esos temas merecen sus propios contenidos para responder a búsquedas distintas y evitar duplicidades. Antes de publicar, verifica los comportamientos actuales en el proyecto afectado.
