Qué es realmente un soft 404 (y por qué a Google le importa)

Un “soft 404” es la forma en que Google dice: “Esto parece una página inexistente, aunque tu servidor no envió un 404 correcto”. Normalmente el servidor devuelve 200 OK (o a veces 302 o 403) junto con contenido que se parece a una página de error, una página casi vacía, una página de “sin resultados” o una plantilla genérica.

El trabajo de Google es mantener la porquería fuera del índice. Si una URL devuelve 200 pero se comporta como “lo siento, aquí no hay nada”, indexarla contaminaría los resultados de búsqueda. Por eso Google intenta inferir la intención: contenido faltante, contenido delgado, plantilla duplicada o comportamientos engañosos causados por redirecciones/caché.

Operativamente, los soft 404 no son “solo cosa de SEO”. Son un problema de sistemas distribuidos: cachés, CDN, lógica de redirección, bordes de autenticación, tratamiento de bots y códigos de estado inconsistentes. Googlebot es solo otro cliente con opiniones fuertes.

Una regla práctica: tu sitio debería ser aburrido para los rastreadores. Códigos de estado predecibles, contenido consistente, pocas sorpresas. Las sorpresas son para lanzamientos de producto, no para respuestas HTTP.

Por qué los sitios WordPress activan soft 404

1) Páginas 404 “bonitas” que devuelven 200

Muchos temas de WordPress muestran una hermosa página de “Página no encontrada” pero olvidan la parte en la que el servidor envía 404 Not Found. A veces es el tema, a veces un plugin, a veces una capa de caché que almacenó una página 404 y la sirve como 200.

2) Resultados de búsqueda, archivos por etiquetas y paginación que parecen vacíos

WordPress puede generar muchas URLs: /tag/, /author/, /page/99/, resultados de búsqueda del sitio, archivos por fecha. Cuando esas páginas tienen poco contenido (o “No posts found”), Google puede tratarlas como soft 404—especialmente si devuelves 200 con una plantilla que es mayormente boilerplate.

3) “Limpieza” por redirecciones que borra el significado

Los plugins que “arreglan” enlaces rotos redirigiendo todo a la página principal son máquinas clásicas de soft 404. Desde la perspectiva del usuario parece amable. Desde la perspectiva de Google es una discrepancia: una URL específica que debería estar ausente está siendo reemplazada por una página genérica. Eso no es arreglar; es ocultar la evidencia.

4) Modos de mantenimiento, WAF y bloqueos de bots demasiado ingeniosos

Algunos sitios devuelven 200 con contenido de “mantenimiento”, o bloquean bots y devuelven una página HTML de “Acceso denegado” con 200. Googlebot indexa la página de denegación o la declara soft 404. Si necesitas bloquear, hazlo con códigos de estado correctos (503 para mantenimiento con Retry-After, 401/403 para auth) y comportamiento consistente.

5) Renderizado inconsistente: el bot ve una cosa y los humanos otra

Reglas por geolocalización, tests A/B, personalización, banners de consentimiento y problemas de renderizado con JS pueden cambiar el contenido de la página. Si Googlebot recibe una página despojada, un intersticial o una concha vacía, puede catalogarla como “ausente”. A veces no hay “error” en tu lado—hasta que pruebas como Googlebot y ves la triste verdad.

Broma #1: Un soft 404 es como tu compañero de trabajo que dice “no me voy” mientras mete sus cosas en una caja.

Guion de diagnóstico rápido (compruébalo en este orden)

Si buscas rapidez, deja de adivinar. Usa un bucle cerrado: comprueba el código de respuesta, revisa el contenido servido, verifica si cambia para Googlebot y luego rastrea la capa de origen.

Primero: verifica el estado HTTP y el destino final

• ¿La URL devuelve 200 mientras muestra un mensaje 404?
• ¿Hay una cadena de redirecciones que termina en la página principal?
• ¿El canonical apunta a otra parte?

Segundo: compara lo que recibe Googlebot vs lo que ves tú

• Obtén la URL con un user agent de Googlebot. Compara longitud del HTML, título, meta robots, canonical y contenido del body.
• Verifica si un WAF/CDN está inyectando desafíos o intersticiales.

Tercero: aisla la capa que miente

• ¿El servidor de origen (WordPress/PHP) devuelve un estado incorrecto?
• ¿La capa de caché reescribe o cachea páginas de error incorrectamente?
• ¿Un plugin crea redirecciones o manejo “inteligente” de 404?

Cuarto: decide la intención de la URL

• ¿Debería existir? Hazla sustancial y indexable.
• ¿Debería desaparecer? Devuelve 404 o 410 y no la redirijas a páginas irrelevantes.
• ¿Debería existir pero no indexarse? Devuelve 200 con noindex, pero mantén contenido útil para usuarios.

Cómo decide Google que una página es “soft 404”

Google no publica el clasificador completo (y no querrías que lo hicieran), pero podemos inferir las señales:

• Similitud de contenido con plantillas de error conocidas: “Not found”, “no longer available”, “nothing here”, etc.
• Contenido delgado: mayormente navegación, header/footer, sin contenido principal.
• Redirecciones inesperadas: muchas URLs faltantes redirigiendo a una página genérica.
• Bajo valor único: archivos facetados o páginas auto-generadas con casi nula diferenciación.
• Anomalías de fetch/render: recursos bloqueados, errores JS, intersticiales, muros de consentimiento, desafíos WAF.
• Consistencia en el tiempo: la misma URL alternando entre “contenido real” y “vacía” según el estado de la caché o la geolocalización.

Google también observa el patrón a nivel del sitio. Si miles de URLs se comportan como “páginas vacías” con 200, el rastreador se vuelve escéptico rápido.

Una cita operativa que debería estar en todos los runbooks de on-call: Si lo construyes, lo operas. — Werner Vogels

Tareas prácticas: comandos, salidas y decisiones

A continuación hay comprobaciones prácticas que puedes ejecutar desde un servidor o estación de trabajo. Cada tarea incluye: un comando, una salida de ejemplo, qué significa y la decisión que tomas a continuación. Hazlas en orden si estás depurando. Hazlas selectivamente si auditas.

Task 1: Check the final HTTP status and redirect chain

cr0x@server:~$ curl -sSIL https://example.com/suspect-url | sed -n '1,25p'
HTTP/2 301
date: Sat, 27 Dec 2025 10:12:11 GMT
location: https://example.com/
cache-control: max-age=3600
server: nginx

HTTP/2 200
date: Sat, 27 Dec 2025 10:12:11 GMT
content-type: text/html; charset=UTF-8
cache-control: max-age=300
server: nginx

Qué significa: La URL redirige a la página principal. Si esto ocurre con páginas inexistentes, Google a menudo marca soft 404 porque el destino es irrelevante.

Decisión: Si la URL realmente no existe, deja de redirigirla a la página principal. Devuelve 404 o 410. Si se movió, redirige a la página equivalente más cercana, no a una genérica.

Task 2: Verify the body contains a “not found” template despite 200

cr0x@server:~$ curl -sS https://example.com/missing-page | grep -Ei 'not found|404|no posts found|nothing here' | head
404
Sorry, the page you are looking for could not be found.

Qué significa: Tu sitio le dice a los usuarios que falta, pero puede que todavía estés devolviendo 200.

Decisión: Corrige los códigos de estado en la fuente (tema/plantilla o hooks de WordPress), y vuelve a probar. Una 404 bonita está bien; una 404 servida como 200 no lo está.

Task 3: Compare what Googlebot sees vs a normal browser

cr0x@server:~$ curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/product/widget | sed -n '1,20p'
<html>
<head>
<title>Access Denied</title>
<meta name="robots" content="noindex,nofollow">
</head>
<body>Request blocked.</body>

Qué significa: Una regla WAF/CDN está tratando a Googlebot de forma distinta. Incluso si los humanos ven la página de producto, Google ve una página de bloqueo.

Decisión: Arregla el acceso para bots. Permite Googlebot (con precaución), o devuelve un estado honesto (403) y acepta que no se indexará. No sirvas “Access denied” como 200.

Task 4: Confirm the real status code from origin (bypass CDN if possible)

cr0x@server:~$ curl -sSIL --resolve example.com:443:203.0.113.10 https://example.com/missing-page | sed -n '1,12p'
HTTP/2 200
date: Sat, 27 Dec 2025 10:14:02 GMT
content-type: text/html; charset=UTF-8
server: nginx
x-cache: MISS

Qué significa: Al forzar la resolución DNS hacia la IP de origen, ves que el origen devuelve 200. El bug probablemente está en WordPress/tema o en la configuración de origen, no en el CDN.

Decisión: Arregla el manejo en WordPress (plantilla, reglas de reescritura, plugins) para que las páginas faltantes produzcan 404/410.

Task 5: Check headers for caching of error-like pages

cr0x@server:~$ curl -sSIL https://example.com/missing-page | egrep -i 'HTTP/|cache-control|age|x-cache|cf-cache-status|vary|location'
HTTP/2 200
cache-control: public, max-age=86400
age: 43122
x-cache: HIT
vary: Accept-Encoding

Qué significa: Tu CDN/proxy está cacheando la experiencia de “página faltante” por un día. Si esa página es en realidad un error transitorio o una petición mal enrutada, Google verá repetidamente la versión mala.

Decisión: No cachees plantillas 404 como 200. Establece códigos de estado correctos y considera TTLs distintos para respuestas de error. Purga las entradas de caché malas tras corregir.

Task 6: Inspect robots directives and canonical tags

cr0x@server:~$ curl -sS https://example.com/suspect-url | egrep -i 'rel="canonical"|meta name="robots"' | head

Qué significa: El canonical apunta a la página principal. Eso puede ser legítimo en casos raros, pero si muchas páginas se canonicalizan a la home, Google las tratará como duplicados o basura tipo soft 404.

Decisión: Corrige la generación de canonicales. Cada página real debe canonicalizarse a sí misma; las páginas verdaderamente no canónicas deben gestionarse con redirecciones o noindex con una razón clara.

Task 7: Find WordPress “empty archive” patterns in access logs

cr0x@server:~$ sudo awk '$7 ~ /\/tag\/|\/author\/|\/page\/[0-9]+\/|\/\?s=/' /var/log/nginx/access.log | tail -n 5
198.51.100.21 - - [27/Dec/2025:10:10:01 +0000] "GET /tag/obsolete/ HTTP/2.0" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.51.100.21 - - [27/Dec/2025:10:10:03 +0000] "GET /author/ghostwriter/ HTTP/2.0" 200 18012 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.51.100.21 - - [27/Dec/2025:10:10:06 +0000] "GET /page/99/ HTTP/2.0" 200 17655 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Qué significa: Googlebot está rastreando URLs tipo archivo delgadas/vacías que a menudo producen banderas de soft 404.

Decisión: Decide si esos archivos merecen indexación. Si no, añade noindex en ellos, o ajusta el enlazado interno y la generación del sitemap para que no invites a los rastreadores a URLs inútiles.

Task 8: Check if WordPress is sending the right status for 404 pages

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/this-should-404 | head -n 8
HTTP/2 200
date: Sat, 27 Dec 2025 10:16:31 GMT
content-type: text/html; charset=UTF-8
server: nginx

Qué significa: Alerta clara. Una página inexistente devuelve 200.

Decisión: Arregla en el origen: verifica el manejo de 404 en WordPress, desactiva plugins sospechosos, revisa reglas de reescritura y asegúrate de que tu servidor no reescriba URLs faltantes a index.php sin lógica 404 adecuada.

Task 9: Identify “redirect everything” rules in Nginx

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'try_files|error_page|return 301|rewrite' | head -n 25
45:    try_files $uri $uri/ /index.php?$args;
88:    error_page 404 =200 /index.php;
132:   rewrite ^/old/(.*)$ / permanent;

Qué significa: error_page 404 =200 /index.php; es una trampa típica. Convierte un 404 real en una respuesta 200, sirviendo a menudo una plantilla 404 del tema como éxito.

Decisión: Elimínala o corrígela. Si necesitas páginas de error personalizadas, conserva el estado 404. En Nginx, prefiere error_page 404 /404.html; (sin forzar =200), o deja que WordPress maneje los 404 pero asegurándote de que envía el estado correcto.

Task 10: Inspect Apache for error document misconfiguration

cr0x@server:~$ sudo apachectl -t -D DUMP_VHOSTS 2>/dev/null | head
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/000-default.conf:1)

cr0x@server:~$ sudo grep -R "ErrorDocument 404" -n /etc/apache2/sites-enabled /var/www 2>/dev/null | head
/etc/apache2/sites-enabled/000-default.conf:23:ErrorDocument 404 /index.php

Qué significa: Si Apache enruta 404s a /index.php sin preservar el estado 404, WordPress puede acabar respondiendo 200 con una página que parece 404.

Decisión: Usa un documento 404 dedicado que mantenga el estado, o asegura que la capa PHP/WordPress establezca el código correcto cuando renderice “no encontrado”.

Task 11: Confirm WordPress can produce a true 404 via WP-CLI evaluation

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp eval 'echo is_404() ? "is_404\n" : "not_404\n";'
not_404

Qué significa: Si ejecutas esto fuera de un contexto de petición es más complicado, pero como comprobación de cordura puede revelar que WordPress no trata ciertos patrones “faltantes” como 404 (común con rewrites personalizados o plugins).

Decisión: Audita reglas de reescritura y el enrutamiento de tipos de contenido personalizados. Si un plugin secuestra el enrutamiento, desactívalo y vuelve a probar. Si es código personalizado, corrige la query y el manejo 404 para que WordPress invoque correctamente un 404.

Task 12: Detect “soft 404 by thinness” using content length

cr0x@server:~$ curl -sS https://example.com/tag/obsolete/ | wc -c
8123

cr0x@server:~$ curl -sS https://example.com/real-article/ | wc -c
128944

Qué significa: La página de etiqueta es pequeña comparada con contenido real. Eso no siempre está mal, pero si es mayormente plantilla más “No posts found”, Google probablemente la marque como soft 404.

Decisión: O la mejoras (añade texto único, muestra elementos reales) o la marcas con noindex y dejas de enlazarla como si fuera una página central.

Task 13: Check sitemap entries for URLs that shouldn’t exist

cr0x@server:~$ curl -sS https://example.com/sitemap.xml | grep -Eo '<loc>[^<]+' | head
https://example.com/
https://example.com/tag/obsolete/
https://example.com/page/99/

Qué significa: Tu sitemap está anunciando URLs finas/vacías. Google las rastreará, las juzgará y luego te reportará. Con razón.

Decisión: Corrige la generación del sitemap (configuración del plugin SEO). Solo incluye URLs dignas de indexación. Los sitemaps son un contrato; no firmes contratos que no puedas cumplir.

Task 14: Verify the server returns 410 for permanently removed content

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/old-campaign-2019 | head -n 6
HTTP/2 410
date: Sat, 27 Dec 2025 10:20:09 GMT
content-type: text/html; charset=UTF-8
server: nginx

Qué significa: 410 Gone comunica claramente permanencia. Google típicamente elimina estas URLs más rápido que un 404.

Decisión: Usa 410 para contenido eliminado intencionalmente que no piensas reemplazar, especialmente si siguen siendo rastreadas. Usa 404 para URLs desconocidas/errores tipográficos.

Task 15: Verify no “helpful” redirect plugin is masking 404s

cr0x@server:~$ wp plugin list --status=active
+---------------------+----------+--------+---------+
| name                | status   | update | version |
+---------------------+----------+--------+---------+
| redirection         | active   | none   | 5.4.2   |
| wp-super-cache      | active   | none   | 1.9.4   |
| seo-plugin          | active   | none   | 21.2    |
+---------------------+----------+--------+---------+

Qué significa: Los plugins de redirección están bien—hasta que alguien activa una regla global tipo “redirigir todos los 404 a la home”.

Decisión: Audita las reglas. Elimina reglas globales 404-a-home. Reemplázalas por redirecciones 301 específicas que mapeen URLs antiguas a las más cercanas posibles.

Task 16: Confirm your 404 page is marked as 404 (not cached as 200)

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/definitely-missing | egrep -i 'HTTP/|cache-control|age|x-cache|via'
HTTP/2 404
cache-control: no-cache, must-revalidate, max-age=0
x-cache: MISS

Qué significa: Esto es lo que quieres: estado correcto y caché conservadora.

Decisión: Publícalo. Luego purga cualquier 200 obsoleto en caché y solicita recrawl en Search Console para las URLs clave tras los arreglos.

Tres microhistorias corporativas desde el campo

Microhistoria #1: El incidente causado por una suposición errónea

Una empresa de e-commerce mediana migró desde un CMS antiguo a WordPress con un tema nuevo y brillante. El equipo hizo lo que siempre hacen los equipos: probaron manualmente las 50 páginas principales. Todo “funcionaba”. Lo lanzaron un viernes por la tarde, porque claro.

En una semana, Search Console se llenó de soft 404 en URLs de producto. Las páginas de producto seguían ahí para humanos, pero Google empezó a descartarlas. El tráfico de pago seguía convirtiendo, el orgánico cayó y el CEO aprendió la frase “informe de cobertura del índice”.

La suposición equivocada: “Si la página se carga, el estado debe ser 200 y eso está bien”. El tema mostraba una plantilla “producto no disponible” cuando el inventario era cero—pero devolvía 200 y además asignaba el canonical a la página de categoría. Eso no era una página de producto; era una página disfrazada de faltante.

Lo arreglaron haciendo que las páginas sin stock devolvieran 200 solo si incluían detalles reales del producto y alternativas. Los productos verdaderamente descatalogados devolvían 410 con redirecciones relevantes cuando era posible. También corrigieron los canonicales para que los productos reales se canonicalizaran a sí mismos. La indexación se recuperó gradualmente a medida que Google re-rastreaba; la clave fue consistencia y evitar comportamiento oscilante.

Microhistoria #2: La optimización que salió mal

Un sitio de medios quiso reducir la carga de origen. Empujaron una caché agresiva en el CDN y añadieron una regla: cachear HTML durante 24 horas, incluyendo “páginas de error”, porque mejoraba la tasa de aciertos y hacía que los paneles se vieran tranquilos.

Después la base de datos de WordPress tuvo un breve fallo. Durante unos minutos, muchas páginas renderizaron una plantilla mínima que decía “No posts found” (porque las consultas fallaron). El origen siguió devolviendo 200 ya que la capa PHP no lanzó un error duro. El CDN caché esas respuestas felizmente por un día.

Los humanos se quejaron primero, pero el daño real fue más silencioso: Googlebot rastreó durante la ventana mala, vio un montón de páginas casi vacías con 200 y las marcó como soft 404. Incluso después de que la base de datos se recuperó, Google seguía viendo vacíos cachéados.

La solución fue poco glamorosa: dejar de cachear respuestas HTML que coincidan con patrones de error, cachear 5xx por poco tiempo y dar a los 404 un TTL sensato. También añadieron una puerta de salud a nivel de aplicación: si WordPress no puede consultar contenido, devolver 503, no una página “exitosa” vacía. Las métricas de rendimiento empeoraron un poco; la indexación y la confianza de usuarios mejoraron. Elige tu veneno con cuidado.

Microhistoria #3: La práctica aburrida pero correcta que salvó el día

Una empresa B2B SaaS regulada usaba WordPress para documentación y landing pages. Su equipo de SRE insistió en algo que parecía burocrático: un trabajo semanal de rastreo y verificación que muestreaba URLs del sitemap y comprobaba estado, canonical y longitud de contenido.

No era nada sofisticado. Se ejecutaba desde un runner de CI con curl y volcaba resultados en una hoja de cálculo y en un canal de alertas. Marketing ponía los ojos en blanco a veces. SRE se los bajaba a veces. Reinaba la paz.

Durante una actualización de un plugin, un plugin de caché empezó a servir la plantilla 404 para algunos archivos paginados debido a un bug en un caso límite. Las páginas devolvían 200 con “Nothing Found”. El trabajo semanal detectó la anomalía en horas, no semanas, y revertieron antes de que Google re-procesara una porción significativa del sitio.

La práctica no ganó premios. Evitó un desastre de indexación, que es lo más cercano a ganar premios para operaciones.

Broma #2: La forma más rápida de crear soft 404 es “simplificar redirecciones” justo antes de un fin de semana festivo. La segunda más rápida es decirlo en voz alta.

Errores comunes: síntoma → causa raíz → solución

1) “Soft 404” en URLs que muestran un mensaje 404 a los usuarios

Síntoma: La página dice “No encontrado”, pero el servidor devuelve 200.

Causa raíz: El tema renderiza la plantilla 404 mientras el estado del servidor permanece en 200, o Nginx/Apache reescribe 404 hacia index.

Solución: Asegura que la respuesta HTTP sea 404. Elimina patrones como error_page 404 =200. Verifica con curl -I y con un user agent de Googlebot.

2) Páginas faltantes redirigidas a la página principal

Síntoma: Muchas URLs antiguas redirigen a /; Search Console marca soft 404.

Causa raíz: Plugin de redirección “útil” que envía todos los 404 a home, o reglas blanket de reescritura.

Solución: Reemplaza redirecciones globales por 301s específicos a reemplazos relevantes. Si no hay reemplazo, devuelve 404 o 410.

3) Páginas de archivo marcadas como soft 404

Síntoma: URLs de etiqueta, autor, fecha o paginación listadas como soft 404.

Causa raíz: Archivos vacíos o páginas ultra-delgadas con principalmente boilerplate.

Solución: Decide: o las haces valiosas (contenido curado, texto introductorio significativo, enlazado interno real), o les aplicas noindex y las eliminas de los sitemaps.

4) Picos de “Soft 404” tras habilitar caché CDN

Síntoma: Search Console empieza a marcar muchas URLs tras cambios de caché.

Causa raíz: La caché almacenó respuestas vacías/transitorias de error como 200 y se las sirvió a Googlebot por mucho tiempo.

Solución: Ajusta reglas de caché: no cachées plantillas de error, mantén TTL conservadores para 404/5xx, purga tras arreglar y evita cachear respuestas personalizadas o desafiadas a bots.

5) Google ve “Acceso denegado” o páginas intersticiales

Síntoma: Soft 404 o “Crawled – currently not indexed” para URLs importantes; fetch-as-bot muestra página de bloqueo.

Causa raíz: WAF, protección de bots, reglas geográficas o muros de consentimiento servidos a Googlebot.

Solución: Permite a Googlebot (verifica por reverse DNS si eres estricto), o sirve 403/401 y acepta la no indexación. No sirvas páginas de bloqueo como 200.

6) Etiquetas canonical que colapsan muchas páginas en una

Síntoma: Muchas URLs tienen canonical apuntando a la home o a la raíz de una categoría; la indexación cae.

Causa raíz: Configuración errónea del plugin SEO, bug del tema o un hack para “evitar duplicados”.

Solución: Establece canonical a sí misma en páginas reales. Usa la canonicalización de forma intencional, no como botón de pánico.

7) Endpoints JSON/REST o URLs con query indexadas y marcadas

Síntoma: Search Console muestra soft 404 para URLs raras como queries o endpoints API.

Causa raíz: Enlaces de búsqueda interna expuestos, páginas parametrizadas rastreables o plugins que generan URLs basura.

Solución: Deja de generar rutas rastreables: restringe enlaces internos, considera noindex en resultados de búsqueda y asegura que endpoints no HTML no aparezcan en sitemaps.

Listas de verificación / plan paso a paso

Paso 1: Triaje de URLs

• Bucket A: Deben existir y estar indexadas (páginas de ingresos, documentos clave).
• Bucket B: Deben existir pero no indexarse (búsquedas internas, algunos archivos).
• Bucket C: No deben existir (campañas eliminadas, errores tipográficos, URLs spam).

No uses un comportamiento global para todos los buckets. Ahí es donde surgen los soft 404—y las reuniones.

Paso 2: Para Bucket A, haz que la página sea indudablemente real

• Devuelve 200 con contenido principal sustancial.
• Asegura que el canonical se refiera a sí misma.
• Evita páginas de “sin resultados” disfrazadas de páginas de contenido.
• Corrige diferencias de renderizado para Googlebot.
• Asegura que la página no esté bloqueada por WAF, auth o directivas robots.

Paso 3: Para Bucket B, sé honesto e intencional

• Devuelve 200 pero añade noindex vía meta robots (o X-Robots-Tag si controlas cabeceras).
• Elimínalas de los sitemaps XML.
• Reduce enlaces internos que las promocionen como importantes.

Paso 4: Para Bucket C, hazlas desaparecer correctamente

• Devuelve 404 para URLs desconocidas/erróneas.
• Devuelve 410 para contenido eliminado intencionalmente que no vas a reemplazar.
• Solo redirige cuando exista un reemplazo relevante. Redirigir a home rara vez es relevante.

Paso 5: Arregla comportamientos de la plataforma que generan soft 404 a escala

• Tema: Verifica que las plantillas 404 no sobrescriban códigos de estado.
• Plugins: Audita plugins de redirección y SEO por reglas globales y comportamiento de canonicales.
• Configuración del servidor: Elimina reescrituras 404-a-200 y hacks “catch-all”.
• CDN: No cachees respuestas vacías transitorias como HTML de larga duración.
• Monitorización: Añade un rastreo programado que muestree URLs importantes y verifique estado y tamaño del contenido.

Paso 6: Valida y luego pide a Google que reevalúe

• Vuelve a probar con curl -I y user agent de Googlebot.
• Purge caches tras la corrección.
• En Search Console, solicita reindexación para las URLs afectadas principales. No pierdas tiempo con miles; arregla problemas sistémicos y deja que el rastreo haga lo suyo.

Hechos y contexto histórico (útil, no trivia)

• Hecho 1: “Soft 404” no es un estado HTTP. Es una clasificación del motor de búsqueda sobre tu respuesta real.
• Hecho 2: Los servidores web antiguos a menudo servían páginas de error personalizadas, pero el código de estado HTTP seguía importando; los buscadores aprendieron a desconfiar de “errores bonitos” con 200.
• Hecho 3: La flexibilidad de permalinks y rewrites de WordPress es una espada de doble filo: hace que muchas URLs “resuelvan”, incluso cuando no existe contenido.
• Hecho 4: La tendencia hacia SPAs y temas muy dependientes de JS aumentó los casos donde los rastreadores reciben “conchas vacías”, que pueden parecer soft 404 cuando el renderizado falla.
• Hecho 5: La adopción de CDN mejoró el rendimiento pero amplificó bugs: una mala respuesta cacheada globalmente puede cambiar lo que ven los rastreadores por días.
• Hecho 6: Los motores de búsqueda tratan las redirecciones masivas a la página principal desde URLs eliminadas como un problema de calidad; se asemeja a “redirecciones engañosas” y comportamiento de bajo valor.
• Hecho 7: 410 Gone existe en HTTP desde hace décadas pero está infrautilizado; puede acelerar la eliminación cuando realmente significa “se fue para siempre”.
• Hecho 8: Parámetros y navegación facetada explotaron con e-commerce y etiquetas CMS; los buscadores empezaron a clasificar muchas combinaciones casi vacías como de bajo valor o tipo soft-404.
• Hecho 9: La gestión de bots creció hasta convertirse en una categoría de producto; desafiar o bloquear accidentalmente a Googlebot es ahora una causa común de anomalías de indexación.

Preguntas frecuentes

1) ¿Un soft 404 es siempre malo?

Es malo si afecta a URLs que quieres indexadas. Si Google marca una URL basura como soft 404, eso puede ser un servicio de limpieza gratuito. El problema es cuando tus páginas importantes son mal clasificadas.

2) ¿Debo redirigir todos los 404 a la página principal para “salvar SEO”?

No. Eso es un disparador clásico de soft 404. Redirige solo cuando haya un reemplazo relevante. Si no, devuelve 404 o 410.

3) ¿Qué es mejor: 404 o 410?

404 significa “no encontrado (posible temporal)”. 410 significa “gone (intencional)”. Usa 410 para eliminaciones deliberadas que no piensas restaurar, sobre todo si siguen siendo rastreadas.

4) ¿Solo el contenido delgado puede causar soft 404?

Sí. Si una página es mayormente boilerplate con poco contenido principal único, Google puede tratarla como efectivamente ausente. Esto ocurre con archivos de etiquetas vacíos, páginas de resultados de búsqueda y paginación profunda.

5) Mi página 404 de WordPress se ve bien—¿por qué Google se queja?

Porque a Google le importan el código de estado y la intención. Si devuelves 200 con un mensaje tipo 404, o canonicalizas todo a la home, Google lo llamará por su nombre: no es una página real.

6) ¿La caché puede causar soft 404 aunque el origen ahora esté correcto?

Absolutamente. Un CDN puede cachear una respuesta vacía transitoria como 200. Googlebot alcanza la versión cacheada, no tu origen recién corregido, hasta que expire el TTL o purges.

7) ¿Debería “noindex” las páginas que son soft 404?

Si la página debería existir e indexarse, arréglala en lugar de noindexarla. Si debería existir pero no indexarse (como resultados de búsqueda internos), noindex es apropiado—siempre que siga siendo útil para usuarios.

8) ¿Cuánto tarda Google en recuperarse tras las correcciones?

Depende de la frecuencia de rastreo y del tamaño del sitio. Páginas importantes pueden actualizarse en días; URLs de cola larga pueden tardar semanas. La vía más rápida es: arregla problemas sistémicos, purga cachés y solicita reindexación para las URLs prioritarias.

9) ¿Necesito cambiar el core de WordPress para arreglar esto?

Normalmente no. La mayoría de las causas son comportamiento del tema, plugins de redirección/canonicales, configuración del servidor (reescrituras 404-a-200) y reglas de caché/WAF. Comienza por ahí.

10) ¿Por qué Google marcaría una página real como soft 404 durante una migración?

Las migraciones suelen crear cadenas de redirección, canonicals desajustados, páginas plantilla delgadas o respuestas de mantenimiento temporales servidas como 200. Google ve inconsistencia y clasifica con cautela.

Conclusión: siguientes pasos que realmente mueven la aguja

Los soft 404 no son místicos. Son una discrepancia entre lo que tu servidor afirma (200) y lo que tu contenido comunica (“no hay nada aquí”), a menudo amplificada por redirecciones y cachés. Arregla la discrepancia y Google normalmente se tranquiliza.

1. Elige 10 URLs marcadas y ejecuta el guion de diagnóstico rápido: estado, redirecciones, vista de bot, comportamiento de caché.
2. Elimina redirecciones globales 404-a-home. Reemplázalas por mapeos específicos o devuelve 404/410.
3. Haz que los 404 sean 404 reales. Audita reglas de Nginx/Apache y el comportamiento del tema que fuerza 200.
4. Decide qué merece indexación. Si archivos/búsquedas son delgados, o los enriqueces o les aplicas noindex y los eliminas de sitemaps.
5. Ajusta la política de caché para que la vacuidad transitoria no se convierta en una verdad global de 24 horas.
6. Añade un rastreo semanal aburrido. Aburrido = fiable. Fiable = rentable.

Si haces lo anterior, Search Console dejará de quejarse, Googlebot dejará de desconfiar de tu sitio y recibirás menos pings de emergencia sobre “tráfico que cae misteriosamente”. Que es el verdadero KPI.