Cuándo una 410 es mejor que una 404 (y cómo implementarla de verdad)

Una 410 no es solo una 404 más enfadada

En nuestro artículo 301 o 404, la 410 aparecía en una sola línea de una lista de decisión, como la alternativa más fuerte a la 404 para un contenido que ha desaparecido para siempre. Merece su propia explicación, porque es el único de los cuatro códigos de estado (301, 302, 404, 410) que exige una certeza, y no solo una constatación. Una 404 es casi siempre la respuesta automática por defecto de un servidor o de una aplicación cuando algo no responde: nadie la «elige» activamente línea por línea, simplemente llega cuando nada coincide. Una 410, en cambio, siempre debe declararse de forma voluntaria, mediante una regla que alguien ha puesto deliberadamente al construir el sitio, porque comunica algo que el servidor no puede saber por sí solo: no únicamente «de momento aquí no hay nada» (eso ya lo dice una 404), sino «aquí no volverá a haber nada nunca, y lo sabemos con certeza».

Esta diferencia tiene una consecuencia práctica en el comportamiento de los buscadores: un robot que se encuentra con una 404 deja abierta la posibilidad de que la URL vuelva (un error temporal, un despliegue a medias, un producto que vuelve a tener stock) y por lo general sigue comprobando esa URL durante un tiempo antes de retirarla realmente del índice. Una 410 es una señal deliberada de eliminación definitiva, y el propio Google ha indicado en varias ocasiones que tiende a tratarla más rápido para retirar una URL de los resultados, aunque ninguno de los dos casos es instantáneo. La diferencia, por tanto, no es «la gravedad del error», sino «cuán seguro está usted de que nunca más vivirá nada en esa dirección».

Cuándo una 410 hace daño de verdad

Precisamente porque una 410 comunica una certeza, usarla cuando esa certeza no existe es el error más costoso de los cuatro códigos. Dos casos típicos en los que se vuelve en su contra:

• Contenido de temporada o suspendido temporalmente. Un producto descatalogado para siempre es un buen candidato para una 410. Un producto agotado que volverá dentro de dos meses no lo es: una 410 desalienta al buscador de volver a comprobar esa URL justo en el momento en que, unas semanas después, usted querría que lo hiciera. En ese caso, la herramienta correcta sigue siendo una 404 (o, si es realmente temporal y con fecha conocida, una 302 hacia una página informativa), no una 410.
• Reglas demasiado amplias. Una 410 aplicada a un patrón genérico o a una condición sobre la query string debe escribirse con el mismo cuidado que una regla de cortafuegos: una condición demasiado genérica puede disparar la 410 en URL legítimas que solo comparten una parte del patrón, cerrando definitivamente la puerta a tráfico real en lugar de al único tráfico que usted quería detener. A diferencia de una 301, en la que un error de destino envía igualmente al visitante a alguna parte, una 410 errónea simplemente cierra la puerta, y si no era la puerta correcta, el único que se da cuenta es quien se da de bruces con ella.

Cómo es en realidad una 410 bien implantada

En nuestro propio módulo de redirecciones, la 410 se elige en el menú del tipo de regla, junto a la 301 y la 302, y para este tipo de regla la dirección de destino no hace falta y se ignora: no hay un «adónde enviar» al visitante, solo un «aquí ya no hay nada, definitivamente». Lo técnicamente interesante es el punto donde se genera la respuesta: debe salir lo antes posible en el ciclo de vida de la petición, antes de que la aplicación construya el tema, recupere el producto de la base de datos o prepare el renderizado de la página; si no, habrá desperdiciado igualmente todo el trabajo que una 410 debe evitar. Una respuesta correcta incluye tres elementos que a menudo se olvidan cuando una 410 se escribe a mano en un archivo de configuración:

• Un verdadero estado HTTP 410 Gone, y no un 200 con un texto «producto no disponible» (el mismo error de soft 404 ya tratado en el artículo anterior, que aquí se aplica igual).
• Una cabecera X-Robots-Tag: noindex, que refuerza la señal para los robots que leen esa cabecera con independencia del código de estado.
• Un cuerpo de página mínimo, traducido al idioma del visitante, en lugar de una página en blanco: una 410 sigue siendo una respuesta a la que puede llegar una persona de verdad al hacer clic en un enlace antiguo, no solo algo que ve un robot.

Un caso real: un robot que no dejaba de pedir un parámetro envenenado

En nuestra propia tienda, un robot (el de Meta) no dejaba de pedir URL con la forma /login?back=... que todavía contenían, en el valor del parámetro, el dominio antiguo de la tienda anterior a un cambio de dirección: más de 36.000 peticiones en una sola noche, más del 90 % de todo el tráfico recibido por el servidor, cada una atendida con una respuesta 200 y un renderizado completo de la página, es decir, el mismo coste de CPU que una petición real. El problema no era la URL en sí (/login es una dirección perfectamente legítima), sino la combinación con ese valor concreto del parámetro, que ningún visitante real produciría jamás.

Comprobamos que una sola regla 410 con una condición sobre la query string resuelve exactamente este caso, sin tocar el servidor web y sin tocar el tráfico legítimo: la regla solo se dispara cuando el parámetro back contiene el dominio antiguo, no en cada petición a /login. Resultados de las pruebas, en tres versiones distintas de PrestaShop:

• /login?back=http%3A%2F%2Fold-domain.example%2Fx devuelve 410
• /login?back=https%3A%2F%2Fold-domain.example%2Flogin devuelve 410
• /login?back=/my-account (tráfico legítimo) sigue devolviendo 200, sin cambios

Es el ejemplo más claro de lo que distingue una 410 bien construida de una 410 hecha a la carrera: la regla no dice «bloquear /login», dice «bloquear únicamente la combinación exacta de la que sabemos que causa el problema», y comprueba esa condición antes de construir una sola línea de la página.

En resumen

La 404 es casi siempre un valor por defecto; la 410 es siempre una elección deliberada, y solo debe usarse cuando existe una certeza real de que la URL no volverá nunca. Bien hecha, es un verdadero estado HTTP generado lo antes posible en el ciclo de vida de la petición, con la cabecera para robots correspondiente, sin desperdiciar el trabajo que debe evitar; hecha con una regla demasiado amplia, puede cerrar definitivamente la puerta a un tráfico que era legítimo. Para quien quiera gestionar estas reglas sin tocar la configuración del servidor, un módulo como cll_seoredirect es una opción, pero el criterio para decidir cuándo una 410 es la elección correcta sigue siendo el mismo con cualquier herramienta.

Guía de instalación y configuración del módulo

Redirecciones SEO - Gestión 301/302/404 (SEO Redirects)Gestiona redirecciones 301/302 (simples, wildcard o regex seguras), monitoriza los 404 y conviértelos en…49,99 €Ver producto