404 masivos y contenido borrado en WordPress
Search Console tiene nueve mil errores 404 y la mayoría aparecieron el mismo día. Nadie rediseñó nada, nadie migró nada. Simplemente un día dejaron de existir miles de direcciones que llevaban años funcionando.
Esto le pasa sobre todo a los sitios que acumulan: periódicos y revistas en línea con archivos de ocho o diez años, blogs corporativos con miles de entradas, tiendas con catálogos históricos. Y pasa casi siempre por una de tres razones mundanas: se llenó el disco, alguien pasó un plugin de limpieza de base de datos, o alguien decidió "ordenar" borrando lo viejo.
Lo primero que hay que entender, y lo que casi nadie te dice, es esto: un 404 por sí solo no te hace daño. Google lo dice desde hace años y lo mantiene en su documentación: para una página retirada de forma permanente, lo correcto es devolver un 404 o un 410. El daño no está en el código de respuesta. Está en haber perdido las direcciones que tenían tráfico, enlaces y años de historial — y en lo que el servidor estaba haciendo mal cuando eso ocurrió.
Qué pasó en tu caso
| Lo que ves | Qué pasó | Cómo se confirma |
|---|---|---|
| Miles de 404 con la misma fecha de detección, y el sitio va lento o se cayó esos días | Se llenó el disco. WordPress no pudo escribir, la base de datos empezó a fallar, y el gestor devolvió errores antes de devolver 404 | Cobertura ordenada por fecha de detección, contra el histórico de uso de disco del hosting y los logs de error |
| Desapareció el contenido más antiguo, de forma escalonada | Plugin de limpieza de base de datos. Suelen borrar revisiones y papelera, pero mal configurados se llevan entradas, metadatos o relaciones de taxonomía | Tabla wp_posts por fecha, y registro de actividad del plugin si lo tiene |
| Faltan secciones enteras, como una categoría o un autor | Taxonomías borradas. Al eliminar una categoría o reasignar autores en bloque, las entradas pueden quedar sin ruta accesible | Inspección de URL en tres entradas de la sección perdida |
| Las entradas existen en el administrador pero dan 404 en el sitio | No es borrado, es estructura. Enlaces permanentes, reglas de reescritura corruptas o conflicto de slugs tras una importación | Guardar los enlaces permanentes y volver a comprobar. Si se arregla, era eso |
| Hay miles de entradas duplicadas y alguien borró en bloque para limpiar | Importación descontrolada. El plugin duplicó, se borró a mano y se llevó también originales | Comparar conteo de entradas por mes contra el histórico de publicación |
| Alguien despublicó en masa "porque era contenido viejo" | Borrado deliberado. Suele ser la decisión más cara de revertir, porque fue intencional y nadie guardó la lista | Cobertura: aparecerán como 404 o como excluida por noindex según cómo se hizo |
| Las páginas 2, 3, 4… del archivo dan 404 | Paginación rota. Típico tras cambiar de tema en sitios con archivos largos | Recorrer la paginación a mano desde la página 2 |
El daño real no es el 404
Lo que Google dice de los 404: para páginas retiradas permanentemente, devolver 404 o 410 es lo correcto. Un 404 es una señal fuerte para que Google no vuelva a rastrear esa URL. Google no olvida una URL que conoció, pero deja de insistir. Nada de eso penaliza nada. Entonces, ¿dónde está el daño? En cuatro sitios concretos:
En las URLs que valían
Si de las nueve mil que se perdieron, cuatrocientas tenían tráfico de búsqueda y enlaces desde fuera, el problema son esas cuatrocientas. Las otras ocho mil seiscientas pueden morir en paz. El trabajo entero consiste en saber cuáles son las cuatrocientas, y eso solo lo dice Search Console con histórico y los logs.
En los soft 404
Si tu tema devuelve una página maquetada de "no encontrado" con código 200, Google la lee como contenido real, la clasifica como soft 404, y la sigue rastreando. Eso es lo peor de los dos mundos: ni se desindexa ni deja de consumir rastreo.
En lo que el servidor estaba haciendo cuando se llenó
Y esto es lo que casi nadie conecta. La capacidad de rastreo que Google asigna a tu sitio baja cuando el sitio se vuelve lento, cuando devuelve errores 5xx o cuando manda señales de limitación como un 429. Sube cuando responde de forma consistente. Así que un disco lleno no te costó solo el contenido: te costó también que Google te rastree menos durante el tiempo que estuvo así — justo cuando más rastreo necesitabas para recuperarte.
En el presupuesto de rastreo, si tu sitio es grande
Google considera esto un tema avanzado para sitios de más de un millón de páginas únicas con contenido que cambia semanalmente, para sitios de más de diez mil páginas únicas con cambios diarios, y para sitios con muchas URLs en Descubierta, actualmente sin indexar. Un periódico en línea con archivo de años y publicación diaria entra de lleno en el segundo caso. Y en esa situación, cada URL muerta que sigue rastreándose es rastreo que no se está usando en lo que publicaste hoy.
Mándame por WhatsApp el dominio y la fecha en que aparecieron los 404. Te digo si tu caso es de los que hay que reparar o de los que hay que cerrar bien y olvidar, que son dos presupuestos muy distintos.
Por qué los archivos de prensa son el caso difícil
Si administras un periódico o una revista en línea, tu situación tiene tres particularidades que no tiene un sitio corporativo.
El volumen cambia las reglas
Diez mil entradas no se tratan a mano. El triaje tiene que ser por datos —tráfico histórico, enlaces entrantes, fecha— y la decisión se aplica por lotes, no URL por URL.
El contenido viejo sigue trayendo gente
En un sitio corporativo, una página de 2017 no vale nada. En un medio, una nota de 2017 sobre un tema que vuelve a ser noticia puede traer tráfico ocho años después. Borrar por antigüedad es, en un medio, destruir el activo.
La publicación diaria compite consigo misma por el rastreo
Mientras hay nueve mil URLs muertas en la cola, lo que publicaste esta mañana se rastrea más tarde. En un medio, llegar tarde al rastreo es llegar tarde a la noticia.
Aquí va el caso del periódico digital: número de entradas perdidas, cuántas se recuperaron y de dónde. Es el caso que más vende esta página porque es exactamente el perfil del visitante. Si no se autoriza el nombre, va en anónimo con las cifras y el sector.
La tabla de decisión
Cada URL perdida cae en uno de cuatro cajones, y meterla en el cajón equivocado cuesta dinero en las dos direcciones:
Tenía tráfico, tenía enlaces, y el contenido se puede recuperar
Se hace: recuperar y republicar en la misma dirección.
Por qué: es la única opción que devuelve el tráfico íntegro. Vale el esfuerzo solo aquí.
Tenía tráfico, pero existe contenido equivalente en el sitio
Se hace: redirección 301 a ese equivalente.
Por qué: transfiere las señales. Ojo: equivalente de verdad, no "lo más parecido que encontré".
No tenía tráfico ni enlaces, y no va a volver
Se hace: 410.
Por qué: le dice a Google que se fue y no vuelve. Deja de consumir rastreo antes que con un 404 genérico.
Es un duplicado, un adjunto o una URL generada por un plugin
Se hace: 410 y revisar qué lo genera.
Por qué: si no se corta el origen, vuelven a aparecer solas.
Lo que no es un cajón: redirigir todo a la portada. Es el atajo que parece resolver la lista de errores de un plumazo y lo que consigue es lo contrario — Google puede leer ese destino irrelevante como soft 404, así que no transfiere nada, la URL sigue en la cola de rastreo, y encima el visitante que buscaba una nota concreta aterriza en una portada que no le sirve. El 404 honesto es mejor que eso en los tres frentes.
De dónde se recupera contenido borrado
Cuando no hay copia de seguridad —que es el caso habitual, porque si la hubiera no me habrías escrito— quedan cuatro fuentes y se usan en este orden:
La base de datos, antes de dar nada por perdido
Mucho "contenido borrado" está en realidad en la papelera, como borrador, con el autor huérfano o con el estado cambiado. Se recupera en una tarde y es gratis. Siempre se mira primero.
El archivo de la web
Conserva copias de muchas páginas públicas. No están todas y las que hay pueden estar incompletas, pero para un archivo de prensa suele cubrir las notas que tenían visitas, que son precisamente las que interesan.
La caché de los buscadores y los agregadores
Cada vez menos fiable, pero para contenido reciente a veces sirve.
Copias del propio hosting
Muchos proveedores guardan respaldos más tiempo del que el cliente cree, incluso cuando el panel no los muestra. Vale la pena pedirlos por soporte antes de reconstruir nada a mano.
Lo que se recupera así no es idéntico: pueden faltar imágenes, metadatos o comentarios. Pero la URL vuelve a responder con el contenido que la hizo posicionar, y eso es lo que Google necesita.
No sabes cuánto de tu archivo se puede recuperar. Pide el diagnóstico técnico: sales con el número exacto de URLs perdidas, cuántas tenían tráfico, cuántas son recuperables y de qué fuente. Por escrito y es tuyo.
El procedimiento
| Fase | Qué se hace | Qué recibes |
|---|---|---|
| 1 · Parar la hemorragia | Identificar y detener la causa: disco, plugin de limpieza, proceso programado, permisos de quien borró | Confirmación de que dejó de perderse contenido, y el motivo por escrito |
| 2 · Inventario y triaje | Lista completa de URLs perdidas cruzada con tráfico histórico, enlaces entrantes y fecha. Clasificación en los cuatro cajones de la tabla | Hoja de cálculo auditable con la decisión tomada para cada URL |
| 3 · Recuperación de contenido | Rescate desde base de datos, archivo de la web, caché y respaldos del hosting, en ese orden, solo de lo que el triaje marcó como recuperable | Las entradas republicadas en su dirección original, con informe de lo que falta en cada una |
| 4 · Cierre del resto | 301 donde hay equivalente, 410 donde no, corrección de los soft 404 del tema, sitemap depurado | Mapa de redirecciones y lista de 410, auditables |
| 5 · Reindexación priorizada | Solicitudes por orden de tráfico histórico, no alfabético ni cronológico | Calendario de reindexación con prioridades |
| 6 · Vigilancia de tres meses | Cobertura, posiciones de lo recuperado, alertas de disco y de nuevos 404 en bloque | Informe mensual, y una alerta configurada para que esto no vuelva a pasar en silencio |
La fase 1 va primero por una razón práctica: he visto reconstruir dos mil entradas en un servidor que seguía llenándose, y perderlas otra vez seis semanas después.
Lo que no funciona
Redirigir todo a la portada
Ya está arriba y es el error más caro. Soft 404, cero transferencia, rastreo consumido.
Bloquear las URLs muertas en robots.txt
Google lo dice directamente: usar robots.txt para liberar presupuesto de rastreo no lo reasigna, salvo que ya estés en el límite de capacidad de tu sitio. Y además las URLs bloqueadas permanecen más tiempo en la cola y se vuelven a rastrear cuando se levanta el bloqueo. Es trabajo para quedarte peor.
Dejar la página 404 del tema con código 200
Es el defecto más silencioso y el más extendido. Se comprueba en diez segundos y se arregla en diez minutos.
Recuperar todo "por si acaso"
Si ocho mil de las nueve mil URLs no tenían una visita en tres años, reconstruirlas es pagar por contenido que nadie va a leer y encima diluir el sitio. El triaje existe precisamente para no hacer esto.
Borrar contenido viejo para "mejorar el SEO"
En un medio, eso es la causa, no la solución. Si el objetivo es limpiar, lo que se consolida son duplicados y páginas vacías, no el archivo.
Lo que viene en 2027
La presión sobre el rastreo va a aumentar. La capacidad que Google asigna depende de cómo responde tu servidor, y los sitios con archivos grandes y publicación diaria ya están en el tramo donde eso se nota. Con más rastreadores pidiendo contenido —los de búsqueda y los de los sistemas generativos— el coste de tener nueve mil URLs muertas en la cola deja de ser teórico.
El archivo vuelve a valer, y de otra forma. Cuando una parte creciente de las consultas se contesta dentro de una respuesta generada, lo que se cita es contenido que existe y responde. Un archivo de diez años en buen estado es un activo difícil de replicar; un archivo con nueve mil direcciones rotas es un activo que nadie puede citar. Eso cambia el cálculo de recuperar contenido viejo: hace dos años era nostalgia, ahora es inventario.
Y una cosa que conviene no esperar: no va a aparecer una herramienta que desindexe en bloque ni que recupere contenido borrado automáticamente. Esto va a seguir siendo inventario, triaje y decisiones. Lo digo porque cada año alguien promete lo contrario.
Preguntas frecuentes
No. Google dice que para páginas retiradas de forma permanente lo correcto es un 404 o un 410, y que un 404 es una señal fuerte para no volver a rastrear esa URL. Lo que te está costando tráfico es haber perdido las direcciones que lo traían, no el código de respuesta.
Hace falta, pero no lo que la mayoría cree. Hay que identificar qué URLs de las perdidas valían, recuperar esas, cerrar el resto bien, y arreglar lo que esté devolviendo soft 404. Lo que no hace falta es reconstruir nueve mil páginas.
Es el primer paso, no el último. Mientras el disco estaba lleno tu servidor devolvía errores, y la capacidad de rastreo que Google te asigna baja cuando eso pasa. Ampliar el disco detiene la causa; recuperar el rastreo y el contenido es otro trabajo.
A menudo sí, y en un orden concreto: primero la base de datos —mucho "borrado" está en papelera o como borrador—, después el archivo de la web, después las cachés, y después los respaldos del hosting, que suelen existir aunque el panel no los muestre. Lo que se recupera puede venir sin imágenes o sin metadatos.
Por el inventario. Search Console con histórico dice qué URLs tenían tráfico, los logs dicen qué sigue pidiendo Google, y el sitemap archivado dice qué existía. Cruzando los tres sale la lista real, y encima sale ordenada por lo que más valía.
El plugin es la herramienta para aplicar las decisiones, no para tomarlas. Y en sitios con miles de reglas, los plugins de redirección en base de datos añaden carga a cada petición: por encima de cierto volumen conviene llevarlas al servidor. Lo evalúo en el diagnóstico.
Sí, y va incluido en la fase 6. Lo que falló la primera vez no fue solo el disco: fue que nadie se enteró durante semanas. Una alerta de espacio y una de 404 en bloque cuestan muy poco y habrían ahorrado todo esto. Eso vive dentro de un mantenimiento con vigilancia de espacio en disco.
Elige por dónde entrar
Te aparecieron miles de 404 y no sabes qué significan. Mándame por WhatsApp el dominio y la fecha en que aparecieron. Te digo si hay que reparar o solo cerrar bien, que son dos presupuestos distintos.
Escribir por WhatsAppQuieres saber cuánto de tu archivo es recuperable antes de decidir. El diagnóstico técnico se paga y se entrega: URLs perdidas, cuántas tenían tráfico, cuántas son recuperables y de qué fuente.
Pedir el diagnóstico técnicoYa sabes qué falta y quieres el presupuesto de la recuperación. Dime cuántas entradas tenía el sitio, cuántas faltan y desde cuándo. Te mando propuesta con fases.
Solicitar propuestaÚltima revisión: octubre de 2026.