Elimina una ficha de producto, cambias la estructura de tus URLs o migras a un nuevo CMS. Unas semanas después, Google Search Console muestra decenas de errores 404. El reflejo clásico consiste en redirigir todas hacia la página de inicio. Es una falsa buena idea que crea otros problemas.
Soft 404 y 404 clásico: la distinción que cambia tu estrategia SEO
Un error 404 clásico devuelve un código HTTP 404 (o 410) al navegador y a Googlebot. El servidor dice claramente: esta página ya no existe. Google entiende la señal, retira progresivamente la URL de su cola de exploración y pasa a otra cosa.
La verdadera trampa se encuentra en otro lugar. Un soft 404 devuelve un código 200 OK mientras que la página está vacía o muestra un mensaje de error. Desde el punto de vista de Google, esta URL parece existir. El robot continúa visitándola en cada paso, lo que consume presupuesto de rastreo sin necesidad.
En un sitio de unas pocas decenas de páginas, la diferencia es insignificante. En un catálogo de comercio electrónico o un sitio editorial con miles de URLs, los soft 404 acumulados ralentizan la exploración de las páginas que realmente importan. Antes de lanzarte a hacer correcciones, la prioridad es saber corregir un error 404 en Google distinguiendo estos dos casos.
Los sitios construidos con frameworks de JavaScript (React, Vue, Angular) están particularmente expuestos. Cuando una ruta no existe, la aplicación muestra un mensaje “página no encontrada” del lado del cliente, pero el servidor devuelve un código 200. Google trata este comportamiento como un soft 404, y la página permanece en la cola de rastreo.
Clasifica tus errores 404 antes de corregirlos: método de priorización
No todos los errores 404 merecen el mismo tratamiento. Una URL que nunca ha recibido un enlace externo, nunca ha generado tráfico y que corresponde a un contenido obsoleto puede permanecer en 404 sin ningún daño SEO. Google lo confirma: los 404 legítimos son parte del funcionamiento normal de la web.
¿Ya has consultado el informe “Páginas” de Google Search Console sin saber por dónde empezar? Aquí te mostramos cómo clasificar tus 404 por orden de prioridad:
- Las URLs que aún reciben backlinks externos: transmiten autoridad. Sin redirección, este capital SEO desaparece. Identifícalas cruzando los datos de Search Console con una herramienta de rastreo.
- Las URLs que generaban tráfico orgánico antes de su eliminación: una redirección 301 hacia la página más cercana en contenido permite recuperar parte de ese tráfico.
- Las URLs resultantes de errores tipográficos, bots o parámetros de URL erróneos: déjalas en 404. Redirigir estas URLs crearía redirecciones innecesarias que sobrecargan tu configuración del servidor.
Prioriza los 404 que tienen backlinks o tráfico histórico. El resto puede esperar, o nunca ser tratado.
Redirecciones 301 y código 410: elegir la respuesta HTTP correcta
La redirección 301 es el reflejo por defecto. Funciona bien cuando existe una página equivalente en el sitio. ¿Has renombrado una categoría o fusionado dos artículos? La 301 transfiere la mayor parte de la autoridad de los enlaces a la nueva URL.
Cuando la redirección 301 plantea problemas
Redirigir una antigua ficha de producto hacia la página de inicio no ayuda a nadie. El usuario llega a una página sin relación con su búsqueda, y Google termina tratando esta redirección como un soft 404. Una redirección 301 debe apuntar hacia un contenido temáticamente cercano, no hacia una página genérica.
El código 410 para señalar una eliminación definitiva
El código HTTP 410 (Gone) indica a Google que la página ha sido eliminada voluntariamente y que no volverá. Google desindexa estas URLs más rápidamente que con un simple 404. Utiliza el 410 para las páginas de productos retiradas definitivamente, los contenidos jurídicamente problemáticos o las URLs de prueba que nunca debieron ser indexadas.
El 410 acelera la desindexación en comparación con el 404 clásico. En un sitio con un volumen importante de páginas eliminadas, esta diferencia de velocidad libera presupuesto de rastreo más rápido.
Página 404 personalizada: transformar un error en navegación útil
Aún con un trabajo de redirección riguroso, los visitantes caerán en páginas inexistentes. Un enlace compartido en un foro, una URL escrita de memoria con un error: el 404 cero no existe.
Una página 404 personalizada no corrige el problema técnico, pero limita la pérdida de usuarios. Para que sirva de algo, debe ofrecer:
- Un campo de búsqueda interno visible de inmediato, sin necesidad de desplazarse.
- Enlaces a las categorías principales o los contenidos más consultados del sitio.
- Un mensaje claro que confirme que la página no existe, sin jerga técnica.
El punto técnico que no debes perder de vista: tu página 404 personalizada debe devolver un verdadero código HTTP 404. Si tu servidor o tu CMS devuelve un código 200 para esta página, estás creando exactamente el problema de soft 404 descrito anteriormente. Prueba el código de respuesta con la herramienta de inspección de URL en Search Console.
Errores 404 en un sitio JavaScript: verificar el renderizado del lado del servidor
Las aplicaciones de una sola página (SPA) gestionan la navegación del lado del cliente. Cuando un visitante accede a una ruta que no existe, el framework muestra un componente “error” sin que el servidor intervenga. El código HTTP permanece en 200.
Para que Googlebot interprete correctamente la situación, la respuesta 404 debe venir del servidor. Dos enfoques funcionan: el renderizado del lado del servidor (SSR) que genera la página con el código HTTP correcto antes de enviarla al navegador, o el prerenderizado estático que produce archivos HTML con los encabezados correctos.
Un mensaje “página no encontrada” mostrado por JavaScript con un código 200 es tratado como un soft 404 por Google. Verifica el código de estado real en la pestaña Red de las herramientas de desarrollo de tu navegador, o directamente a través de Search Console.
En un sitio clásico bajo WordPress o un CMS similar, este problema generalmente no se presenta: el servidor gestiona nativamente el código 404. La vigilancia se centra sobre todo en las arquitecturas desacopladas (headless CMS + frontend JavaScript).
