No se ha encontrado (404)

TL;DR — “Not found (404)” (“No se ha encontrado (404)”) en Search Console significa que Google pidió una página a su servidor y obtuvo una respuesta de “no encontrada”, por lo que no la indexó. Google encontró la URL por su cuenta —normalmente a partir de un enlace en algún sitio, o porque la página existía antes—, lo cual describe cómo la descubrió, no una prueba de que falte en su sitemap actual. Esto es normal y no suele ser un problema, pero solo en el caso de las URLs que realmente deben haber desaparecido. Solo hay que corregirlo si la URL debería funcionar, y en ese caso se restaura la página o se redirige a la sustituta adecuada.

Qué significa “No se ha encontrado (404)”

Esta etiqueta significa que Google recibió un HTTP 404 al solicitar la URL. Evidence for this claim Google reports Not found 404 when the page returned a 404 response when requested. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google trata las respuestas 4xx persistentes distintas de 429 como si el contenido no existiera. Evidence for this claim Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Abra el informe “Indexación de páginas” en Google Search Console y verá una lista de motivos por los que las páginas no se indexan. “No se ha encontrado (404)” es uno de ellos. Significa que Googlebot solicitó la URL y su servidor respondió con un HTTP 404 (Not Found), la respuesta estándar de “esta página no existe”. Como la página devolvió un 404, Google no la indexó.

La parte que sorprende a la gente: Google dice que encontró esta URL sin una petición explícita por su parte. Eso describe cómo la descubrió Google —normalmente en uno de los dos lugares que se indican abajo—, no una garantía de que falte en su sitemap actual. Si la misma URL sigue estando en un sitemap que usted envía, ese es un problema aparte y solucionable (una entrada de sitemap obsoleta), no una contradicción de lo que le está diciendo el informe:

• Un enlace. Algo en la web enlaza a esa URL —una de sus propias páginas o una página de otro sitio— y Google siguió el enlace.
• Una página que existía antes. La URL estuvo publicada e indexada y luego usted la eliminó o cambió la URL. Google la sigue recordando y la vuelve a comprobar.

¿Perjudican los 404 a mi SEO?

Esta es la pregunta que todo el mundo quiere ver respondida, así que aquí va por delante: no, no de forma automática. Los 404 son una parte normal del funcionamiento de la web. Se eliminan páginas, las URLs cambian y otros sitios enlazan de vez en cuando a direcciones que nunca existieron. Que una página devuelva un 404 cuando realmente ha desaparecido es el comportamiento correcto: la propia documentación de Google dice que las respuestas 4xx distintas de 429 no afectan a la frecuencia de rastreo de su sitio, y un 404 correcto no es una penalización para el resto del sitio.

Sin embargo, esa etiqueta de “correcto” solo se aplica a las URLs que realmente deben haber desaparecido. Un 404 en una página a la que usted sigue enlazando, que está en su sitemap o a la que otros sitios siguen enlazando no es inocuo solo porque sea técnicamente válido: es un enlace roto, valor de enlace (link equity) perdido o un visitante que llega a un callejón sin salida. Así que, en el caso de páginas realmente muertas y sin nada que apunte a ellas, ver “No se ha encontrado (404)” en su informe no es motivo de alarma. En el resto de los casos merece la pena echar un vistazo: véase la sección siguiente.

Cuándo merece realmente la pena corregir un 404

Los 404 que merecen su atención son los de URLs que deberían funcionar:

• Una página a la que usted sigue enlazando desde su navegación o su contenido (un enlace interno roto).
• Una URL que está en su sitemap (no debería estarlo: los sitemaps son para páginas publicadas e indexables).
• Una página a la que enlazan otros sitios (estaría desperdiciando esos enlaces).
• Una URL que todavía recibe tráfico o a la que la gente claramente quería llegar.

Para esas hay dos buenas opciones:

1. Restaurar la página si se eliminó por error.
2. Redirigirla a la página publicada más relevante (una redirección 301). Así se envía a los visitantes a algún sitio útil y, sobre todo, se transmite el valor de los enlaces que apunten a la URL antigua.

Una cosa que no hay que hacer: no redirija todas las URLs muertas a su página de inicio. Google trata una redirección irrelevante como esa como un “Soft 404”, que es un problema en sí mismo. Redirija a una página realmente relacionada o simplemente deje que devuelva un 404.

¿Quiere la versión completa —404 frente a 410 frente a 301 frente a noindex, cómo averiguar qué enlaza a un 404 y cuánto tiempo permanecen en el informe? Cambie a la pestaña Avanzado.

TL;DR — “Not found (404)” (“No se ha encontrado (404)”) significa que Googlebot solicitó una URL que Google describe como descubierta por su cuenta —un enlace o una página indexada anteriormente—, no mediante una petición explícita por su parte, y obtuvo un 404, por lo que no está indexada. Esa descripción explica el descubrimiento original, no es una prueba de que la URL falte en su sitemap actual. Los 404 son una parte normal de la web, y la propia documentación de Google dice que las respuestas 4xx distintas de 429 no afectan a la frecuencia de rastreo; un 404 para una página eliminada sin sustituta es correcto y no es una penalización para todo el sitio, pero un 404 en una URL que sí debería existir (enlazada internamente, en un sitemap, con backlinks o con tráfico) le sigue costando enlaces rotos, valor de enlace perdido o usuarios perdidos. Para esas: restaure la página o hágale un 301 a una página publicada realmente relevante, priorizando las que tienen enlaces entrantes para recuperar el valor de enlace. Deje el resto como 404. En mi propia experiencia el 410 tiende a caer un poco más rápido, aunque Google trata igual los códigos 4xx distintos de 429. No redirija en masa a la página de inicio (riesgo de Soft 404). Googlebot sigue volviendo a comprobar los 404 antiguos con una frecuencia decreciente, y por eso permanecen en el informe: eso es normal, no una penalización.

Qué le está diciendo Google en realidad

El informe indica el 404 observado; por sí mismo no explica qué enlace, URL histórica o ruta de la aplicación lo produjo. Evidence for this claim Google reports Not found 404 when the page returned a 404 response when requested. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report La documentación general de Google sobre 4xx describe el comportamiento de indexación. Evidence for this claim Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

La definición que da Google de este código de estado es breve: “This page returned a 404 error when requested.” (traducción) «Esta página devolvió un error 404 al solicitarla.» El contexto que la rodea es la parte que importa: Google descubrió la URL sin ninguna petición explícita ni sitemap por su parte. Eso es lo que separa “No se ha encontrado (404)” de los errores de indexación que usted mismo envió.

Esa frase describe cómo encontró Google la URL originalmente; no es una afirmación de que la URL nunca haya aparecido en uno de sus sitemaps, ni de que no esté ahora mismo en uno de ellos. Si consulta un sitemap publicado y la misma URL sigue apareciendo ahí, ese es un problema real (y aparte) que merece la pena corregir —una entrada de sitemap obsoleta—, no una contradicción de lo que el informe le está diciendo sobre el descubrimiento.

Así que la URL vino de una de estas fuentes:

• Un enlace interno o externo. Google extrae enlaces mientras rastrea. Un enlace interno con una errata, un enlace antiguo en el sitio de otra persona o un enlace en un comentario pueden dirigir a Googlebot a una URL que devuelve 404.
• Una página indexada anteriormente que usted eliminó o cuya URL cambió. Google recuerda las URLs que ha visto y las vuelve a solicitar durante mucho tiempo.
• URLs copiadas, mal formadas o inventadas. Otros sitios a veces estropean sus URLs, les añaden basura o se inventan rutas. Google puede probarlas. Nada de eso es culpa suya y nada de eso requiere que actúe.

Ese último punto merece interiorizarse: encontrar un 404 en este informe no significa que usted haya hecho algo mal. Google descubre URLs por toda la web.

¿Perjudica al SEO “No se ha encontrado (404)”? (primero el veredicto)

No, no de forma automática, y esta es la mayor idea equivocada sobre el informe. Los 404 son la forma en la que la web debe funcionar cuando el contenido ha desaparecido, y la propia documentación de rastreo de Google dice que los códigos de estado 4xx distintos de 429 no tienen ningún efecto sobre la frecuencia de rastreo de un sitio. Un 404 devuelto correctamente en una página que realmente ha desaparecido no es una penalización para todo el sitio.

Sin embargo, esa afirmación es más limitada que “los 404 nunca importan”. Un 404 no lastra por sí mismo al resto de su sitio, pero un 404 en una URL que sí debería funcionar —una con enlaces internos, backlinks externos o tráfico real— le sigue costando algo concreto: un enlace roto, valor de enlace perdido o un visitante que llega a un callejón sin salida. El problema no es el informe en sí; el problema es dejar sin corregir los 404 que no deberían existir.

Esto coincide con mi propia lectura de los códigos de estado HTTP en general: las respuestas 4xx hacen que la página concreta salga del índice, pero eso es la página desapareciendo limpiamente, no una penalización aplicada a su dominio. La página que devuelve 404 simplemente ya no está en el índice; todo lo demás queda igual.

La propia documentación de ayuda de Google sostiene lo mismo sobre la indexación en general: es correcto que una URL no esté indexada por los motivos adecuados, y “a 404 for a page that you’ve removed and have no replacement for” (traducción) «un 404 para una página que ha eliminado y para la que no tiene sustituta» es explícitamente uno de esos motivos adecuados. Un 404 en una página realmente muerta es el estado final correcto, no una tarea pendiente.

Qué hace Google internamente con un 404

Según la documentación de Google sobre códigos de estado HTTP, la mecánica es limpia: en el caso de una URL indexada anteriormente, el sistema de indexación la elimina del índice. Los 404 que se encuentran por primera vez simplemente no se procesan: no hay nada que indexar. Y Googlebot no olvida la URL de inmediato: sigue volviendo a solicitarla, con una frecuencia de rastreo que disminuye gradualmente con el tiempo.

Ese comportamiento de recomprobación es la razón por la que los 404 antiguos siguen apareciendo en su informe mucho después de que usted los haya resuelto. Google está confirmando periódicamente que la página sigue sin estar, por si volviera. No es señal de un problema y no consume una cantidad significativa de presupuesto de rastreo en un sitio de tamaño normal.

Cuándo merece la pena corregir un 404 y cuándo no

La regla de decisión es sencilla: corrija el 404 solo si la URL debería existir. Las señales de que una URL “debería existir”:

• Usted enlaza a ella internamente (un enlace roto en su navegación, su contenido o su pie de página).
• Está en su sitemap (no debería estarlo: los sitemaps solo deberían listar URLs publicadas e indexables).
• Tiene backlinks externos que apuntan a ella.
• Todavía recibe tráfico o encaja claramente con algo que la gente está buscando.

Si no se cumple ninguna de esas condiciones —la página realmente ha desaparecido y nada de valor apunta a ella—, déjela como 404. Esa es la respuesta correcta y no hay nada que hacer.

Cómo corregir los que importan

Para las URLs que deberían resolverse, el menú es corto:

• Restaure la página si se eliminó por error o si tiene contenido equivalente que volver a publicar.
• Redirija con un 301 a la página publicada más relevante. Es el movimiento habitual para una página eliminada que tiene una sustituta razonable. Como ya lo he expresado antes sobre las páginas que aparecen como 4xx: lo más probable es que solo tenga que redirigir cada una de ellas con un 301 a una página relevante. La redirección envía a los usuarios a algún sitio útil y transmite el valor de posicionamiento de los enlaces a la nueva URL.
• Déjela como 404 (o use 410) cuando la página realmente ha desaparecido y no tiene una buena sustituta. Esto no es un fracaso: es la respuesta correcta.

Priorice por enlaces entrantes. Los 404 de mayor valor son los que tienen backlinks externos, porque una URL muerta con enlaces está perdiendo valor de enlace que podría recuperar con una sola redirección a una página relevante. Extraiga las URLs 404 que tengan backlinks (una herramienta de backlinks o su informe de enlaces se los mostrará) y hágales el 301 primero. Un 404 sin enlaces y sin tráfico puede quedarse simplemente como 404: redirigirlo no consigue nada.

No redirija todo a la página de inicio. Una redirección a una página no relacionada —clásicamente, volcar todas las URLs muertas en /— Google la trata como un Soft 404, porque el destino no es una sustituta real de lo que se solicitó. Redirija a una página relevante o no redirija en absoluto.

404 frente a 410 frente a 301 frente a noindex

Estos se confunden constantemente. La tabla de decisión completa está en la pestaña Guías rápidas; la versión corta:

• 404 (Not Found) / 410 (Gone) — la página no existe. Ambos sacan la URL del índice, y la propia documentación de Google dice que trata igual los códigos de estado 4xx (distintos de 429). En mi propia experiencia como profesional, el 410 tiende a caer un poco más rápido, pero la diferencia es mínima en cualquier caso. Use 410 si quiere señalar “esto no va a volver nunca”; por lo demás, el 404 está perfectamente bien.
• 301 (Moved Permanently) — el contenido se ha movido; consolide las señales en la nueva URL. Es la herramienta para una página eliminada que tiene una sustituta relevante.
• noindex — la página existe y debe seguir publicada, pero usted no quiere que aparezca en las búsquedas. Es una herramienta distinta para un objetivo distinto: no recurra a ella en una página que realmente ha desaparecido.

Sobre el 404 frente al 410 en concreto, mi propio planteamiento ha sido que los 404 y los 410 reciben un tratamiento similar: ambos sacan páginas del índice y, en mi propia experiencia, los 410 van un poco más rápido, aunque la documentación de Google trata de forma idéntica los códigos 4xx (distintos de 429). Así que no se agobie con la elección: escoja 410 para “desaparecido para siempre”, 404 para todo lo demás, y siga adelante.

Cómo averiguar qué enlaza a un 404

Para corregir un 404 (o decidir si merece la pena), averigüe qué apunta a él:

• En GSC: abra el código de estado “No se ha encontrado (404)”, haga clic en una URL de ejemplo y consulte Referring page en Discovery. Trátelo como una pista posible, no como un inventario completo de enlaces: Google lo describe como una página que posiblemente usó para descubrir la URL, que puede ser un enlace directo, una página de nivel superior a través de la cual se encontró el enlace, o simplemente no estar disponible si no existe esa información. Combínelo con los métodos de abajo en lugar de quedarse ahí.
• Con un rastreador o una auditoría de sitio: Ahrefs Site Audit o Screaming Frog listarán sus enlaces internos rotos, los 404 propios que puede corregir directamente editando el enlace.
• Con una herramienta de backlinks: revise los backlinks rotos para encontrar URLs muertas de su sitio a las que enlazan sitios externos. Esas son sus prioridades para el 301.
• En los registros del servidor: la verdad de campo sobre qué URLs se están solicitando y qué códigos de estado devuelven a escala.

Validar la corrección y qué esperar

Una vez que haya restaurado o redirigido las URLs que deberían existir, puede pulsar Validate Fix en el informe “Indexación de páginas”. Es opcional, no obligatorio: Google dice que puede detectar una corrección por su cuenta la próxima vez que rastree la página, valide usted o no. Pulsar Validate Fix solo le permite seguir esa revisión mientras ocurre; no viene con un plazo garantizado ni con la promesa de un reprocesamiento más rápido. Tampoco espere que el recuento baje a cero de inmediato en ninguno de los dos casos: Google vuelve a rastrear los 404 con una cadencia decreciente, así que incluso las URLs tratadas correctamente pueden permanecer un tiempo en el informe. Esa permanencia es el comportamiento de recomprobación, no una señal de que la corrección no haya surtido efecto, y no hay un momento fijo en el que Google garantice que ha terminado. (Y no hay motivo para validar un 404 que es realmente correcto solo para intentar que desaparezca del informe: la validación sirve para confirmar una corrección, no para descartar un 404 que funciona.)

En sitios muy grandes que generan 404 falsos en masa (millones de URLs basura por una plantilla defectuosa o un spider trap), la eficiencia de rastreo sí pasa a ser una preocupación real y querrá correcciones basadas en patrones en lugar de trabajo uno por uno; pero en sitios normales el costo en presupuesto de rastreo de los 404 es insignificante.

Dónde encaja esto entre sus hermanos

“No se ha encontrado (404)” es el caso limpio: el servidor dijo correctamente “no encontrada”. Sus vecinos en el informe “Indexación de páginas” son situaciones distintas; no los confunda. Un Soft 404 es un mensaje de no encontrada servido con un 200 (o una redirección irrelevante), que Google marca por separado. Blocked due to other 4xx issue (“La URL se ha bloqueado debido a otro problema de tipo 4xx”) cubre los 401/403 y el resto de la familia 4xx. Redirect error (“Error de redirección”) es una redirección rota, distinta de la normal “Page with redirect” (“Página con redirección”). Y server error (5xx) (“Error del servidor (5xx)”) significa que el servidor falló, no que la página haya desaparecido. Las correcciones divergen, así que identifique primero qué código de estado está mirando en realidad.

Para el informe en su conjunto, consulte el hub GSC Page Indexing; para la mecánica subyacente de cómo los bots solicitan URLs en primer lugar, consulte rastreo.

Resumen con IA

Una versión condensada de la versión Advanced:

• Qué significa: Googlebot solicitó una URL que Google describe como descubierta por su cuenta —un enlace o una página indexada anteriormente—, no mediante una petición explícita por su parte, y obtuvo un HTTP 404, así que la página no está indexada. Definición de Google: “This page returned a 404 error when requested.” (traducción) «Esta página devolvió un error 404 al solicitarla.» Eso es una descripción del descubrimiento, no una prueba de que la URL falte en su sitemap actual: una URL que siga listada ahí es un problema aparte que merece la pena corregir.
• De dónde vino la URL: enlaces internos o externos, páginas que eliminó o renombró, o URLs copiadas, mal formadas o inventadas procedentes de otros sitios. Encontrar un 404 aquí no significa que usted haya hecho algo mal.
• Impacto en SEO: no es automático. La propia documentación de Google dice que los códigos de estado 4xx distintos de 429 no afectan a la frecuencia de rastreo, y un 404 devuelto correctamente para una página eliminada sin sustituta no es una penalización para todo el sitio. Pero un 404 en una URL que sí debería funcionar —enlazada, en un sitemap, con backlinks o con tráfico— sigue costando enlaces rotos, valor de enlace perdido o usuarios perdidos.
• Qué hace Google: elimina del índice una URL indexada anteriormente; no procesa los 404 que encuentra por primera vez; sigue volviendo a comprobar la URL con una frecuencia decreciente, y por eso los 404 antiguos permanecen en el informe (es normal, no una penalización).
• Cuándo corregirlo: solo las URLs que sí deberían existir: enlazadas internamente, en un sitemap, con backlinks o con tráfico.
• Cómo corregirlo: restaure la página o hágale un 301 a una página publicada realmente relevante. Priorice los 404 con enlaces entrantes para recuperar valor de enlace. Deje las páginas realmente desaparecidas como 404 (o 410, que Google trata igual que el 404 en su propia documentación, aunque en la experiencia de los profesionales tiende a caer un poco más rápido).
• No haga esto: redirigir en masa todo a la página de inicio; las redirecciones irrelevantes se tratan como Soft 404.
• 404 frente a 410 frente a 301 frente a noindex: 404/410 = desaparecida (ambos la sacan del índice); 301 = movida (consolidar en una sustituta); noindex = mantener la página publicada pero fuera de las búsquedas.
• Encuentre los enlaces mediante Referring page de GSC (una pista posible, no una lista completa de enlaces), un rastreador (enlaces internos rotos), una herramienta de backlinks (backlinks rotos) o los registros del servidor. Validate Fix es opcional: Google puede detectar una corrección sin él, y ninguna de las dos vías tiene un plazo garantizado.

Documentación oficial

Documentación de fuente primaria de los motores de búsqueda.

Google

• Informe de indexación de páginas — el informe en el que vive este código de estado, incluida la definición de “Not found (404)” (“No se ha encontrado (404)”) y la indicación de que “it’s fine for a URL not to be indexed for the right reasons” (traducción) «es correcto que una URL no esté indexada por los motivos adecuados».
• Códigos de estado HTTP, errores de red y errores de DNS — cómo gestiona Google los 4xx: eliminando las URLs indexadas anteriormente, sin procesar los 404 recién encontrados, y la frecuencia de rastreo que disminuye gradualmente.
• Redirecciones y la Búsqueda de Google — cómo configurar las redirecciones 301 que usará para enviar los 404 que sí deberían existir a páginas publicadas relevantes.
• Cómo retirar una página de la búsqueda (bloquear la indexación) — cuando quiere sacar de las búsquedas una página publicada (noindex), que es un objetivo distinto de un 404.

Bing / Microsoft

• Bing Webmaster Tools — Site Explorer & URL inspection — la información de rastreo de Bing muestra los 404 de la misma manera; las indicaciones de gestión coinciden con las de Google (corregir los que importan y dejar que las páginas realmente muertas devuelvan 404).

Citas de la fuente

Declaraciones oficiales de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — la definición de “Not found (404)” (“No se ha encontrado (404)”)

• “This page returned a 404 error when requested.” (traducción) «Esta página devolvió un error 404 al solicitarla.» — Ayuda de Google Search Console, informe “Indexación de páginas”. Ir a la cita

Google — es correcto que una URL no esté indexada

• “It’s fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you’ve removed and have no replacement for.” (traducción) «Es correcto que una URL no esté indexada por los motivos adecuados; por ejemplo, una regla esperada de robots.txt en su sitio, una etiqueta noindex en la página, una URL duplicada o un 404 para una página que ha eliminado y para la que no tiene sustituta.» — Ayuda de Google Search Console, informe “Indexación de páginas”. Ir a la cita

Google — cómo se gestiona el 4xx en la indexación

• “In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed.” (traducción) «En el caso de la Búsqueda de Google, el sistema de indexación elimina la URL del índice si estaba indexada anteriormente. Las páginas 404 que se encuentran por primera vez no se procesan.» — Google Search Central, documentación sobre códigos de estado HTTP. Ir a la cita
• “The crawling frequency gradually decreases.” (traducción) «La frecuencia de rastreo disminuye gradualmente.» — Google Search Central, documentación sobre códigos de estado HTTP. Ir a la cita

Los modelos mentales

1. Descubierta ≠ enviada. “Not found (404)” (“No se ha encontrado (404)”) significa concretamente que Google encontró la URL por su cuenta —un enlace, una página indexada antigua, una URL estropeada de otro sitio—, no a partir de su sitemap. Así que la primera pregunta no es “cómo lo corrijo”, sino “¿debería existir siquiera esta URL?”.

2. El 404 es la respuesta correcta para una página muerta. Un 404 no es un error que haya que eliminar; es la respuesta HTTP adecuada cuando el contenido ha desaparecido. No es una señal de calidad ni una señal de posicionamiento. El objetivo es la exactitud —que las URLs devuelvan lo que es realmente cierto—, no un recuento de cero en el informe.

3. Corrija solo lo que debería existir. Pase cada 404 por una única prueba: ¿está enlazado internamente, está en un sitemap, tiene enlaces externos que lo respalden o sigue recibiendo tráfico? Sí → restaure o haga un 301 a una página relevante. No → déjelo como 404. Esta única regla resuelve la mayor parte del informe.

4. Recupere el valor de enlace antes de recuperar URLs. Entre los 404 que merece la pena corregir, los que tienen enlaces externos entrantes van primero: un 301 a una página relevante recupera el valor de esos enlaces. Un 404 sin enlaces y sin tráfico puede dejarse tranquilamente; redirigirlo no le aporta nada.

5. Redirección relevante o ninguna redirección. Un 301 solo ayuda cuando aterriza en una página realmente relacionada. Una redirección irrelevante (todo → página de inicio) se trata como un Soft 404. Cuando no hay un buen destino, lo correcto es mantener el 404, no inventarse uno.

Cómo clasificar su lista de “No se ha encontrado (404)”

Trabaje el informe de arriba abajo:

• Abra el código de estado “Not found (404)” (“No se ha encontrado (404)”) en el informe “Indexación de páginas” y revise las URLs de ejemplo.
• Para cada URL, entre y consulte Referring page en Discovery: una pista posible sobre dónde encontró Google el enlace, no un inventario completo garantizado.
• Marque cualquier URL que esté enlazada internamente y corrija el enlace interno roto en su origen (esta es la victoria más limpia).
• Marque cualquier URL que esté en su sitemap: no debería estarlo; quítela o restaure la página.
• Extraiga las URLs 404 que tengan backlinks externos (informe de backlinks rotos): esas son sus prioridades para el 301 para recuperar valor de enlace.
• Compruebe qué 404 siguen recibiendo tráfico o encajan claramente con la intención del usuario.
• Para cada URL que “debería existir”: restaure la página o hágale un 301 a una página publicada realmente relevante (no a la página de inicio).
• Deje como 404 las URLs realmente desaparecidas sin enlaces ni tráfico (o como 410 si quiere una caída algo más rápida).
• Confirme que no haya redirecciones en producción que vuelquen URLs no relacionadas en / (riesgo de Soft 404).
• Opcionalmente, pulse Validate Fix (Google también puede detectar una corrección real por su cuenta) y luego espere una caída lenta, no un cero instantáneo, sin ningún plazo fijo.
• Confirme que está clasificando el código de estado correcto (no un Soft 404, otro 4xx, un error de redirección o un 5xx: las correcciones son distintas).

Playbook: responder a un pico repentino de 404

1. Confirme que el pico es real. Compare los ejemplos de Search Console con un rastreo en directo o con las respuestas del servidor; los informes pueden ir por detrás del comportamiento actual.
2. Agrupe por causa y por plantilla. Busque un despliegue, un cambio de patrón de URL, un fallo de enlazado interno, una sección eliminada o una URL generada mal formada, en lugar de corregir filas de una en una.
3. Priorice las URLs con valor. Restaure o redirija las URLs que deberían existir, que tienen backlinks o tráfico significativos, o que siguen en enlaces internos y sitemaps.
4. Deje en paz las eliminaciones legítimas. Una URL realmente desaparecida y sin sustituta debería seguir devolviendo 404 o 410; no la redirija a una página irrelevante.
5. Repare el origen. Actualice las plantillas, los enlaces internos y la generación del sitemap para que dejen de producir o promocionar el patrón roto.
6. Valide y vigile la reaparición. Pruebe URLs representativas y monitorice el patrón. Salga cuando las URLs valiosas se resuelvan correctamente y los 404 recién descubiertos vuelvan a la línea base esperada.

Hojas de referencia rápida sobre los 404

Qué respuesta para cada situación

¿Debo corregir este 404? — flujo de decisión

Datos rápidos

• “Not found (404)” (“No se ha encontrado (404)”) = Google describe que encontró la URL sin una petición explícita por su parte; eso es cómo la descubrió, no una prueba de que falte en su sitemap actual.
• Un 404 devuelto correctamente no es automáticamente una penalización de calidad o de posicionamiento para todo el sitio, pero un 404 en una URL que debería funcionar sigue costando enlaces, tráfico o usuarios.
• Google elimina del índice una URL indexada anteriormente cuando devuelve 404; no procesa los 404 nuevos.
• Googlebot sigue volviendo a comprobar los 404 antiguos con una frecuencia decreciente → permanecen en el informe.
• 404 frente a 410: la documentación de Google trata igual los códigos 4xx (excepto el 429); según la experiencia de los profesionales, el 410 cae un poco más rápido.
• No redirija todo a la página de inicio → Soft 404.
• El costo en presupuesto de rastreo de los 404 es insignificante, salvo en sitios muy grandes con URLs falsas en masa.

Problemas habituales

El recuento de 404 se dispara de repente en el informe “Indexación de páginas”

Causa probable: una plantilla defectuosa está generando URLs basura (parámetros de paginación erróneos, un fallo en la navegación por facetas, IDs de sesión filtrándose en los enlaces), un spider trap, u otro sitio está copiando y estropeando sus URLs. Solución: extraiga una muestra de las nuevas URLs 404 y busque un patrón compartido (un parámetro de consulta, un prefijo de ruta). Si es su propia plantilla, corrija el código que genera los enlaces erróneos. Compruébelo con los registros del servidor o con /tools/log-file-analyzer para confirmar el patrón y ver si es volumen de rastreo real o solo un puñado de ejemplos.

Corrigió una URL pero semanas después sigue mostrando “No se ha encontrado (404)”

Causa probable: Googlebot vuelve a comprobar los 404 con una cadencia decreciente, así que el recuento del informe va por detrás de la corrección real; esto es lo esperado, no una señal de que la corrección haya fallado. Solución: confirme que la URL en directo está devolviendo ahora el código de estado correcto (200 si la restauró, 301 si la redirigió) usando curl -I o /tools/http-status-checker. Puede pulsar opcionalmente Validate Fix en GSC —no es obligatorio, ya que Google también puede detectar una corrección por su cuenta— y espere que el recuento baje gradualmente en lugar de caer de golpe, sin un plazo fijo para cuando se resuelva.

Una URL eliminada aparece como “Soft 404” en lugar de “No se ha encontrado (404)”

Causa probable: la página está devolviendo un HTTP 200 con un mensaje que parece de “no encontrada” en lugar de un código de estado 404/410 real, o está redirigiendo a una página irrelevante. Solución: compruebe el código de respuesta con curl -I o /tools/http-status-checker; si es un 200, configure el servidor (o el CMS) para que devuelva un 404/410 real para esa ruta en lugar de una página de error blanda.

Un 301 que configuró aparece como “Soft 404” para el destino

Causa probable: la página de destino no es una sustituta real de lo que se solicitó; Google lee un destino de redirección desajustado igual que lee uno irrelevante. Solución: vuelva a comprobar el destino con /tools/redirect-checker y apunte el 301 a una página que realmente coincida con el tema de la URL original, no a la página de categoría más cercana ni a la página de inicio.

El informe lista una URL que usted nunca creó ni enlazó

Causa probable: una URL copiada, mal formada o inventada procedente de otro sitio, o una página de hace años que Google todavía recuerda y vuelve a comprobar periódicamente. Solución: haga clic en la URL en el informe y consulte Referring page en Discovery: una pista posible, no una fuente garantizada, ya que Google puede no tener ese dato disponible. Si es externa y claramente estropeada, no hace falta actuar: no es algo que usted haya roto.

Scripts y fragmentos de código

Comprobar el código de estado en directo de una URL (macOS/Linux)

Confirme qué código de estado está devolviendo realmente una URL antes de decidir si necesita corrección:

curl -I https://example.com/old-page

Mire la primera línea de la respuesta (p. ej. HTTP/2 404 o HTTP/2 301). Si es una redirección, curl muestra la cabecera location: con el destino.

Comprobar el código de estado en directo de una URL (PowerShell)

$response = Invoke-WebRequest -Uri "https://example.com/old-page" -Method Head -UseBasicParsing
$response.StatusCode

Añada -MaximumRedirection 0 si quiere ver el 301/302 en crudo sin que PowerShell lo siga automáticamente.

Buscar con grep las peticiones 404 en los registros del servidor (regex)

Ejecute esto contra un registro de acceso de Apache/Nginx en formato “combined” para extraer todas las peticiones que devolvieron un 404:

grep -oP '"\S+ \K\S+(?=.*" 404 )' access.log

Desglose de los grupos de captura: "\S+ \K salta el método HTTP (GET/POST) y lo descarta de la coincidencia; \S+ captura la ruta solicitada; el lookahead (?=.*" 404 ) exige que el resto de la línea del registro contenga un código de estado 404 antes de coincidir. La salida es una lista simple de las URLs que devolvieron 404; pásela por sort | uniq -c | sort -rn para ordenarlas por frecuencia.

Consola de DevTools — comprobar el código de estado sin salir de la página

Pegue esto en el panel Console para comprobar el código de estado de una URL concreta desde el navegador en el que ya está:

fetch("https://example.com/old-page", {method: "HEAD"}).then(r => console.log(r.status, r.url));

Bookmarklet — comprobar el código de estado de la página actual

Arrastre esto a su barra de marcadores (es un bookmarklet: haga clic en él mientras esté en cualquier página para comprobar el código de estado de respuesta de esa misma página):

javascript:(function(){fetch(location.href,{method:"HEAD"}).then(function(r){alert(r.status+" "+r.url);});})();

Herramientas para encontrar y corregir 404

Las herramientas de este sitio

• /tools/http-status-checker — compruebe el código de estado HTTP en directo de cualquier URL antes de decidir si necesita una redirección, una restauración o nada en absoluto.
• /tools/redirect-checker — confirme que un 301 que configuró se resuelve realmente en un solo salto hasta el destino previsto, sin cadenas ni bucles.
• /tools/log-file-analyzer — analice los registros del servidor para ver las URLs reales a las que Googlebot accede y que devuelven 404, y con qué frecuencia.
• /tools/site-audit-lite — rastree su propio sitio para detectar enlaces internos rotos (los 404 que puede corregir directamente editando el enlace en su origen).

Herramientas de terceros

• Google Search Console — el propio informe “Indexación de páginas”; abra un ejemplo de “No se ha encontrado (404)” y use la vista Referring pages para ver qué enlazaba a él, y Validate Fix una vez que haya hecho un cambio.
• Bing Webmaster Tools — la superficie equivalente de errores de rastreo en Bing.
• Ahrefs o Screaming Frog — rastreos de sitio completo que listan enlaces internos rotos, e informes de backlinks que muestran backlinks rotos (sitios externos que enlazan a una URL muerta de su sitio), su lista de prioridades para los 301.

Validar la corrección de un 404

Ejecute estas pruebas después de restaurar o redirigir una URL que debería existir, para confirmar que la corrección surtió efecto de verdad en lugar de darlo por supuesto.

Comprobación del código de estado en directo de la URL corregida

Prueba a ejecutar: curl -I sobre la URL, o /tools/http-status-checker. Resultado esperado: 200 si restauró la página, o un 301 al destino correcto si la redirigió. Interpretación del fallo: que siga dando 404, un 5xx o una redirección que apunte a la página equivocada significa que la corrección no llegó a desplegarse. Ventana de monitorización: inmediata. Disparador de reversión: código de estado erróneo o destino erróneo; corrija la regla del servidor y vuelva a comprobarlo antes de seguir.

Comprobación de la ruta de redirección

Prueba a ejecutar: /tools/redirect-checker sobre la URL antigua. Resultado esperado: un 301 de un solo salto que aterrice directamente en la página publicada relevante, sin cadenas ni bucles. Interpretación del fallo: varios saltos, un bucle o aterrizar en una página no relacionada (riesgo de Soft 404). Ventana de monitorización: inmediata. Disparador de reversión: cualquier cadena, bucle o destino irrelevante; corrija la regla de redirección.

Validate Fix en GSC

Prueba a ejecutar: en el informe “Indexación de páginas”, abra “No se ha encontrado (404)” y pulse Validate Fix (opcional: Google también puede detectar por su cuenta una corrección real sin ello). Resultado esperado: el estado pasa por “Validation started” hasta “Passed”, y el recuento de URLs afectadas va bajando. Interpretación del fallo: la validación falla, o el recuento no se mueve durante un periodo prolongado; vuelva a comprobar que la URL en directo esté realmente corregida y que nada siga enlazando a la antigua. Ventana de monitorización: continua, sin fecha fija de finalización (Google vuelve a comprobar los 404 con una cadencia decreciente, no al instante, y no da ningún plazo garantizado). Disparador de reversión: fallo repetido de la validación; vuelva a verificar la corrección a nivel de servidor.

Comportamiento de rastreo en los registros del servidor

Prueba a ejecutar: /tools/log-file-analyzer sobre las peticiones a la URL antigua. Resultado esperado: los accesos de Googlebot a la URL antigua van disminuyendo con el tiempo mientras las peticiones se desplazan a la URL nueva. Interpretación del fallo: que Googlebot siga accediendo a la URL antigua a un ritmo invariable mucho después del cambio, lo que sugiere que no ha captado la redirección (o que algo sigue enlazando directamente a la URL antigua). Ventana de monitorización: continua, durante un periodo prolongado (la frecuencia de rastreo disminuye gradualmente, según la propia documentación de Google, sin un calendario fijo). Disparador de reversión: que no haya disminución después de un periodo prolongado; confirme que la redirección es del lado del servidor (no una redirección con JavaScript ni mediante meta refresh) y audite si quedan enlaces internos a la URL antigua.

Cuestionario

Cinco preguntas para comprobar qué se queda realmente de “No se ha encontrado (404)”.

Registro de cambios