← Estados de Indexación Google Search Console
seo

Corregir los errores 404 en Google Search Console | IndexProbe

Corregir los errores 404 en Google Search Console no es vaciar una lista, es un triaje. Detecta las 404 que importan (página perdida, 404 enlazada) y la regresión invisible.

IndexProbe·22 de junio de 2026·15 min de lectura

Corregir los errores 404 en Google Search Console

Corregir los errores 404 en Google Search Console: un triaje, no una lista que vaciar; la mayoría de las 404 son normales y lo difícil es aislar las pocas que cuestan

En Google Search Console, «No encontrada (404)» significa que Googlebot solicitó una URL y recibió un código 404. No todas hay que corregirlas: una 404 en una URL de spam que nunca creaste es normal. Lo correcto no es corregirlo todo, sino triar: ignorarla, devolver un 410, redirigir con un 301 o restaurar la página.

Abre el informe «Indexación de páginas» de Google Search Console y el estado «No encontrada (404)» muestra un contador que parece una lista de tareas. La intuición es simple: tantas filas como errores que corregir. Es falsa. La mayoría de esas 404 son normales, y algunas incluso son deseables: una página eliminada debe devolver un 404, es exactamente lo que Google espera.

La verdadera dificultad se desplaza entonces. ¿Cuál de estas URLs merece realmente una acción? Y para esa, ¿hay que redirigirla, dejarla morir limpiamente o restaurarla? Y sobre todo: ¿por qué la 404 que más le cuesta a tu tráfico ni siquiera aparece en el informe 404?

El trabajo no es la lista, es el triaje. Lo difícil no es corregir una 404, es encontrar cuál corregir.

«No encontrada (404)»: qué señala Google exactamente

«No encontrada (404)» significa que Googlebot solicitó una URL y tu servidor respondió con un código HTTP 404. La página no existe. Google no la indexa, y la retira del índice si estaba en él. Es una constatación técnica en bruto, no un juicio de gravedad: el estado describe una respuesta del servidor, no dice nada sobre la importancia de la página perdida.

Conviene distinguirlo de entrada de un caso que se le parece: el Soft 404. Ahí, el servidor responde con un código 200 («la página existe») cuando en realidad la página está vacía o no aporta ningún valor. Google detecta la incoherencia y la señala bajo su propio estado. Un 404 «duro» envía el código correcto; un Soft 404 miente sobre su propio estado. Los dos problemas no tienen ni la misma causa ni la misma corrección. Volvemos sobre el Soft 404 más abajo, y el artículo dedicado al estado No encontrada (404) detalla la lectura del informe.

¿Una 404 es siempre un problema?

No, y es el punto que la mayoría de las auditorías pasan por alto. Google es explícito: una respuesta 404 no es necesariamente un problema si la página se retiró sin reemplazo. Una página que eliminaste a propósito devuelve un 404, y ese es el comportamiento esperado. John Mueller, desde Google, repite con frecuencia que las 404 forman parte del funcionamiento normal de un sitio: su mera presencia en el informe no exige ninguna corrección.

La distinción útil no es «404 o no 404», sino «404 sin coste» frente a «404 costosa».

Una 404 normal, de coste nulo, es una URL que ya nadie importante referencia:

  • una URL de spam o inventada por un scraper, que nunca creaste;
  • una errata en un enlace que alguien colocó en otro sitio;
  • una página que eliminaste a propósito, sin equivalente, que ya no tiene razón de existir.

Una 404 costosa es lo contrario: una página que tenía valor y desapareció.

  • Una página útil perdida por accidente: una eliminación involuntaria, una URL cambiada sin redirección, un despliegue fallido. Tenía tráfico, enlaces, posiciones.
  • Una 404 a la que tu propio sitio sigue apuntando: un enlace interno activo, o una entrada todavía presente en tu sitemap. Mandas a visitantes y a Googlebot a un callejón sin salida.

Es precisamente ese segundo grupo el que Google recomienda tratar. Su criterio es tajante: corrige solo las 404 que enlazas tú mismo o que listas en un sitemap. Todo lo demás puede quedarse como está.

Las causas de una 404

Una 404 siempre tiene un origen técnico preciso, y es ese origen el que dicta la corrección. Las causas se ordenan sobre todo por su accionabilidad: las que vienen de tu sitio, que puedes corregir, y las fabricadas en otro lugar, sobre las que no tienes ningún control.

Desde tu propio sitio (a corregir)

  • Eliminación sin redirección. Retiras una página que tenía un equivalente, sin apuntar una redirección hacia él. La 404 se convierte en un callejón sin salida evitable.
  • Enlaces internos rotos. Un enlace en tu contenido apunta a una URL errónea (una errata, una estructura antigua). El destino no existe, aunque quizá una buena página esté justo al lado.
  • Redirecciones rotas. Una cadena de redirecciones cuyo destino final también ha sido eliminado. El visitante encadena saltos para acabar en un 404.

Desde fuera (a menudo para ignorar)

  • Backlinks rotos. Otro sitio te enlaza con una URL obsoleta o mal copiada. No controlas ese enlace, pero si apuntaba a una página útil, puedes recuperar su valor con una redirección.
  • URLs nunca creadas, spam, erratas externas. Direcciones inventadas, variantes generadas por bots. La 404 es la respuesta correcta: nada que corregir.

Un último caso merece citarse sin detenerse en él: algunas páginas aparecen no como «No encontrada (404)» sino como «Bloqueada por otro problema 4xx» (códigos 401, 403…). Es un estado vecino, con sus propias reglas, que trataremos en un próximo artículo.

Soft 404: el 404 disfrazado de página válida

Un Soft 404 es una página que responde con un código 200 («todo bien») cuando su contenido señala en realidad una ausencia. Google la trata como una 404 porque no aporta nada, pero no aparece en el informe «No encontrada (404)»: tiene su propio estado.

Los desencadenantes clásicos:

  • una página de categoría o de resultados vacía («no hay productos en esta sección») que aun así devuelve un 200;
  • una página con mensaje de error («esta ficha ya no existe») servida con un código 200 en lugar de un 404 real;
  • una página renderizada en cliente (JS/CSR) cuyo contenido no llega a cargarse para Googlebot: solo ve un cascarón vacío.

El principio es directo: las páginas que de verdad no existen deben devolver un 404 real, no un 200. Servir un 200 en una página sin contenido crea más confusión que un 404 honesto. El mecanismo completo, sus causas y sus correcciones se detallan en el artículo Soft 404.

El árbol de decisión: ignorar, 410, 301 o restaurar

Para cada 404 que merece tu atención, solo cuatro salidas. La elección correcta depende de lo que era la página y de lo que la reemplaza, no de una regla uniforme aplicada a toda la lista.

  1. Ignorar. La página no tiene equivalente ni valor residual, y ya nadie importante apunta a ella. Deja el 404: es la respuesta correcta. Hacerla desaparecer del informe no sirve de nada.
  2. Devolver un 410 (Gone). La página está eliminada de forma definitiva y asumida, y quieres señalarlo sin ambigüedad. El 410 afirma la intención de eliminar.
  3. Redirigir con un 301. La página tiene un verdadero equivalente. Una redirección 301 a ese equivalente transfiere visitantes y señales al destino correcto.
  4. Restaurar. Una página útil desapareció por error. Vuelve a publicarla en la misma URL.

Sobre la elección entre 404 y 410, mantén el sentido de la proporción. En la práctica, Google trata todos los errores 4xx del mismo modo: en ambos casos la URL acaba desindexada y el contenido deja de usarse. El 410 solo dice «eliminada para siempre» de forma más explícita. Resérvalo para las eliminaciones deliberadas y asumidas (promociones antiguas, fichas descatalogadas por lotes). Para todo lo demás, un 404 por defecto es perfectamente válido. No tiene sentido migrar en masa tus páginas muertas a 410: la ganancia es marginal y el esfuerzo real.

Este árbol es fácil de recorrer con cinco URLs. La dificultad empieza cuando el informe cuenta cientos.

Triar tus 404 a escala

Triar cientos de 404 se reduce a cruzar tres datos por URL: su tráfico pasado, los enlaces internos que aún recibe y su presencia o no en el sitemap. Es ese cruce el que clasifica cada 404 en una rama del árbol. El problema es que la herramienta de inspección de URL de Search Console trata una sola URL cada vez: inspeccionas, lees, pasas a la siguiente. Con un puñado de direcciones, es viable. Más allá, el triaje manual se vuelve impracticable.

Ese es el muro que IndexProbe derriba: la versión en masa de la herramienta de inspección de URL de Google. Consulta la API oficial de Search Console para inspeccionar, en un solo análisis, la lista de URLs que le proporcionas (importación CSV, sitemap, copiar y pegar) o la que construyes desde tu propia Search Console. Para cada URL devuelve el código de rastreo oficial que Google tiene registrado (404, 410, 200, redirección) y la fecha del último paso de Googlebot. De un vistazo distingues las URLs realmente en 404, las que vuelven a responder 200 tras una corrección y las que ahora apuntan a una redirección.

Reparto de los códigos de rastreo que Google devuelve sobre una lista de URLs analizada: porción de 200, 301, 404 y 410 — Vista IndexProbe
Datos de ejemplo (10.000 URLs ficticias). Reparto de los códigos de rastreo por URL, incluida la porción de 404 | Vista IndexProbe.

Pero el triaje no termina en los códigos de rastreo. La 404 más peligrosa para tu tráfico no está en el informe 404. Es una página que sigue respondiendo 200, que tenía clics en Search Console y que ya no tiene impresiones recientes. Técnicamente, nunca devolvió un 404: ningún informe de error la señala. Y sin embargo ha dejado de posicionarse, lo que delata una probable salida del índice, una regresión silenciosa. Es el tipo de señal que un triaje por código HTTP nunca revela y que el cruce de los clics pasados con las impresiones recientes saca a la luz.

Lo que obtienes del análisis depende de la lista que aportes. IndexProbe no rastrea tu sitio para descubrir URLs: inspecciona las que le das, y solo esas.

  • Una selección de páginas estratégicas (tus páginas clave, tu sitemap de páginas a indexar). Cualquier página importante que aparezca en 404 es una señal inmediata: una página útil perdida, a restaurar o a redirigir a su equivalente. No hay que extrapolar, el veredicto recae sobre páginas cuyo valor ya conoces.
  • Una exportación completa de tus URLs (sitemap entero, exportación de rastreo). El desglose por tipo de página muestra dónde se concentran las 404 (un blog antiguo, una familia de productos retirada) y orienta una decisión por segmento en lugar de caso por caso.
Histograma de las páginas en 404 repartidas por segmento de URL: un blog antiguo y productos retirados concentran las 404, las páginas clave tienen pocas — Vista IndexProbe
Datos de ejemplo (análisis de una exportación completa de URLs). Concentración de las 404 por segmento de URL | Vista IndexProbe.

💡 ¿Quieres saber cuáles de tus 404 cuentan de verdad, y detectar las páginas que se descolgaron sin devolver ningún 404? IndexProbe inspecciona tu lista de URLs a través de la API de Search Console y te da la respuesta en un análisis. Probar IndexProbe en acceso anticipado →

Corregir: la acción correcta según el veredicto del árbol

Una vez triadas tus 404, aplica la acción que corresponde a cada caso. Estas son las cuatro situaciones y su corrección.

  1. Enlace interno erróneo → corrige la URL del enlace a la página correcta. El destino ya existe, solo el enlace era falso.
  2. Página movida → coloca una redirección 301 al equivalente real, y comprueba que no se intercale ninguna cadena de redirecciones. Una redirección que apunta a otra redirección diluye la señal y ralentiza el rastreo; apunta al destino final en un solo salto. El estado asociado se detalla en Página con redirección.
  3. Página eliminada definitivamente → deja el 404, o pasa a 410, y luego retira la URL de tu sitemap y de tus enlaces internos. Mientras un enlace interno o una entrada de sitemap apunte a la página muerta, sigues enviando a Googlebot allí.
  4. Página útil perdida → restáurala en la misma URL. Restablecer la dirección original recupera los enlaces y las posiciones que la página había ganado.

Una trampa que hay que denunciar sin paliativos: nunca redirijas una página eliminada al inicio «para recuperar el jugo de enlaces». Google trata una redirección a una página sin relación como un Soft 404: cambias un 404 honesto por otro problema, y el beneficio esperado nunca se materializa. La redirección solo se justifica hacia un equivalente real.

Del lado del CMS, la mecánica varía pero la lógica es la misma. En WordPress, una extensión de redirecciones (o el .htaccess) gestiona los 301, y hay que limpiar los enlaces internos dentro de los artículos. En Shopify, la herramienta de redirecciones de URL integrada cubre los productos y colecciones eliminados. En Magento, las reglas de reescritura de URL y la gestión de los productos desactivados pilotan el comportamiento 404 y las redirecciones. En todos los casos, el árbol de decisión precede a la herramienta: primero eliges la acción, luego la aplicas con los medios del CMS.

Comprobar que la corrección aguantó

Corregir no basta, hay que confirmar que Google tomó nota. Tras tus acciones, solicita un nuevo rastreo de las URLs tratadas en Search Console, y luego sigue la evolución en el tiempo: las páginas movidas deben responder con un 301 a su equivalente, las páginas restauradas volver a 200 y reincorporarse al índice, y las 404 enlazadas desaparecer de tu sitemap y de tus enlaces. Un único análisis no lo dice; es la comparación entre un estado antes y un estado después la que lo demuestra.

Vista Comparación de IndexProbe antes/después de las correcciones: URLs que pasaron de 404 a 200 o 301, y el número de 404 enlazadas que cae — Vista IndexProbe
Datos de ejemplo. Evolución entre dos análisis: 404 corregidas a 200 o 301, y regresiones detectadas | Vista IndexProbe.

La vista COMPARACIÓN de IndexProbe responde a esa necesidad: pone dos análisis frente a frente y cuantifica los cambios de código por URL, cuántas 404 volvieron a 200 o a 301, y cuántas regresiones nuevas aparecieron entre las dos pasadas. Un punto de vigilancia: una página restaurada en la misma URL no se reincorpora al índice al instante. Mientras Google la vuelve a rastrear y decide reindexarla, puede transitar por el estado Explorada, actualmente no indexada. Una 404 corregida pero todavía no reindexada no es, por tanto, un fracaso: es una etapa que hay que vigilar en el tiempo, no un veredicto definitivo.

Preguntas frecuentes

¿Hay que corregir todos los errores 404? No. Según Google, una 404 en una página retirada sin reemplazo es normal y no exige ninguna acción. Corrige solo las 404 que sigues enlazando internamente o que aparecen en tu sitemap, y restaura las páginas útiles que desaparecieron por error. El resto puede quedarse como está.

404 o 410: ¿qué elegir? Ambos le indican a Google que la página ya no está, y la URL acaba desindexada en los dos casos. El 410 («Gone») afirma una eliminación definitiva de forma más explícita. Resérvalo para las eliminaciones deliberadas y asumidas (promociones antiguas, fichas descatalogadas por lotes). Para todo lo demás, un 404 por defecto basta; no tiene sentido migrar en masa a 410.

¿Hay que redirigir una 404 al inicio? No. Redirigir una página eliminada a una página sin relación, como el inicio, es tratado por Google como un Soft 404: reemplazas un problema por otro. Redirige solo a un equivalente real; si no, deja el 404 y retira los enlaces internos que apuntan a la página.

¿Cómo encontrar todas mis 404? Search Console las lista en el informe «Indexación de páginas», pero su herramienta de inspección trata una sola URL cada vez para verificar el detalle de cada una. Para triar a escala, una herramienta como IndexProbe inspecciona la lista de URLs que le proporcionas a través de la API oficial y devuelve, por URL, el código de rastreo y la fecha del último paso de Googlebot.

¿Qué diferencia hay entre una 404 y un Soft 404? Una «No encontrada (404)» devuelve realmente un código 404: la página no existe, y esa es la respuesta correcta. Un Soft 404 devuelve un código 200 («la página existe») cuando su contenido está vacío o no aporta valor. Google los clasifica en dos estados distintos y los corrige de forma diferente.

¿Una 404 perjudica al SEO? Una 404 en una página eliminada a propósito no perjudica: es el comportamiento esperado. El daño viene de dos casos concretos. Una página útil perdida por error hace desaparecer su tráfico y sus posiciones, y una 404 que sigues enlazando malgasta presupuesto de rastreo y manda a tus visitantes a un callejón sin salida. Son esas 404 las que hay que tratar, no el simple contador del informe.

¿Cómo comprobarlo en un gran número de URLs? El inspector de URL de Search Console trata una sola URL cada vez, lo que hace impracticable el control a escala. IndexProbe inspecciona tu lista de URLs en un solo análisis a través de la API de Search Console y muestra, para cada una, el código de rastreo oficial y la fecha del último paso de Googlebot. La vista COMPARACIÓN pone dos análisis frente a frente para medir el efecto de tus correcciones.


Deja de tratar tus 404 como una lista de errores que vaciar. IndexProbe se conecta a la API oficial de Search Console e inspecciona tu lista de URLs en un solo análisis: código de rastreo por URL (404, 410, 200, redirección), fecha del último paso de Googlebot, y triaje de las 404 por enlaces entrantes, presencia en el sitemap y tráfico pasado. En minutos aíslas las pocas 404 que importan, detectas las páginas que se descolgaron sin devolver ningún 404, y verificas tus correcciones de un análisis al siguiente gracias a la vista COMPARACIÓN.

Probar IndexProbe en acceso anticipado →

Corregir los errores 404 en Google Search Console | IndexProbe | IndexProbe