Redirecciones 301 en WordPress que se pierden · WordPin 003

La web llevaba años activa. Una empresa de reformas integrales con sede en Valencia que, como muchas de su sector, había ido cambiando servicios, renombrando secciones y reorganizando su catálogo de trabajos varias veces. Cada reestructuración dejaba atrás un puñado de URLs que ya no servían, y alguien —en algún momento— se había encargado de redirigirlas a sus destinos actuales. Durante meses, todo funcionó. Las rutas antiguas llevaban a donde debían. Google las tenía indexadas con sus destinos correctos. Ningún aviso en Search Console. Ningún cliente perdido por un enlace roto.

Hasta que un martes, sin que nadie tocase nada visible, varias de esas URLs antiguas empezaron a devolver 404. No todas. Pero sí suficientes como para que Google Search Console lanzara una alerta de páginas no encontradas. Revisé el panel del plugin de redirecciones y estaba abierto, activo, sin errores visibles. Las redirecciones 301 que habían funcionado durante meses parecían haberse evaporado. El plugin seguía ahí, pero algo dentro había cambiado.

La primera sospecha apuntaba a una actualización o a un conflicto reciente. Pero no había registro de cambios en plugins ni en el core de WordPress esa semana. Esto no encajaba.

Cuando las redirecciones 301 dejan de responder sin dar señales

Lo primero que hice fue confirmar el síntoma desde fuera. Usé Screaming Frog para lanzar un rastreo contra una lista de 40 URLs antiguas que sabía que habían estado redirigidas. El resultado fue claro: 26 de las 40 devolvían 404. Las otras 14 seguían respondiendo con 301 hacia sus destinos correctos. Un patrón parcial. No era un fallo total ni un apagón limpio. Unas reglas seguían vivas y otras no.

La primera hipótesis fue el .htaccess. Si las reglas de redirección estaban escritas ahí y algo las había borrado o sobreescrito, el síntoma encajaría. Accedí por SFTP y revisé el archivo. Lo que encontré fue el bloque estándar de WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Ninguna regla de redirección manual. Ningún bloque añadido por el plugin. El .htaccess estaba limpio y genérico. Si las redirecciones 301 no vivían ahí, no podía ser el culpable. Descartado.

La segunda pista apuntaba a la caché del servidor. El hosting usaba LiteSpeed con caché activa, y cabía la posibilidad de que las respuestas 404 fueran páginas cacheadas antes de que las redirecciones se aplicasen, o al revés: que la caché estuviera sirviendo una versión antigua sin pasar por el plugin. Hice una prueba directa con curl añadiendo un parámetro aleatorio para forzar el bypass:

curl -I "https://ejemplo.com/reforma-banos-valencia/?nocache=1"

HTTP/1.1 404 Not Found
X-LiteSpeed-Cache: miss

La respuesta no venía de una página cacheada. La petición estaba llegando al sitio y terminaba en un 404 limpio. No era un problema de caché entregando respuestas antiguas. La redirección simplemente no existía para WordPress en ese momento. El síntoma apuntaba a una cosa, pero los datos decían otra.

Lo que el panel de redirecciones 301 ya no tenía dentro

Volví al panel del plugin Redirection. Esta vez no miré si estaba activo, sino qué contenía. Y ahí estaba la señal que había pasado por alto al principio: la lista de reglas mostraba solo 14 entradas. Hacía tres meses, cuando revisé este sitio por última vez, había más de 200. Las 14 que sobrevivían coincidían exactamente con las 14 URLs que seguían redirigiendo en el rastreo de Screaming Frog. Las demás no estaban desactivadas ni en conflicto. Directamente no existían.

El plugin funcionaba. La lógica de redirección funcionaba. Lo que faltaba eran los datos. Y un plugin sin sus registros es como un motor sin combustible: arranca, gira, pero no mueve nada.

Abrí el log de acciones del plugin dentro de su propio panel. No había registro de borrado masivo. Nadie había eliminado reglas manualmente. Eso dejaba una posibilidad que todavía no había explorado: que la pérdida no viniera del plugin, sino de la base de datos.

El rastro que no sobrevivió a la restauración

Pregunté al responsable del sitio si había habido algún cambio reciente en el servidor o en la base de datos. La respuesta fue clave: dos semanas antes, habían tenido un problema con unos pedidos de presupuesto que no se guardaban correctamente, y el equipo de hosting había hecho una restauración parcial de la base de datos desde un backup anterior para recuperar la tabla de un plugin de formularios.

Ahí estaba el origen. El plugin Redirection almacena sus reglas en tablas propias dentro de la base de datos de WordPress: wp_redirection_items, wp_redirection_groups, entre otras. Estas tablas no forman parte del núcleo de WordPress. No están en wp_posts, ni en wp_options, ni en ninguna tabla estándar. Cuando la restauración parcial se ejecutó, las tablas del core se recuperaron, pero las tablas del plugin de redirecciones fueron sobreescritas con una versión antigua del backup que solo contenía las 14 reglas originales. Las otras 186 se habían añadido después de la fecha de ese backup.

Las redirecciones 301 no se habían borrado por un fallo del plugin ni por un conflicto. Se perdieron porque la restauración de base de datos no distinguió entre tablas críticas del core y tablas generadas por plugins. Y nadie revisó qué más se había restaurado —o destruido— junto con la tabla que necesitaban recuperar.

Para confirmar, accedí a la base de datos a través de phpMyAdmin y ejecuté una consulta de lectura sobre la tabla del plugin:

SELECT COUNT(*) FROM wp_redirection_items;
-- Resultado: 14

SELECT MAX(last_access) FROM wp_redirection_items;
-- Resultado: 2023-06-14

La fecha del último acceso registrado en esas 14 reglas era anterior a la restauración. Todo lo que se había creado después de esa fecha había desaparecido. La evidencia era clara: los datos del plugin fueron revertidos a un estado anterior, y con ellos se fueron casi todas las reglas activas. Que una redirección exista en un plugin no significa que esté a salvo. Si sus datos viven en una tabla propia y esa tabla no se protege, la regla desaparece sin avisar.

El impacto SEO no era menor. Google tenía indexadas las URLs antiguas con sus destinos correctos. Al recibir 404 en lugar de 301, empezaría a desindexar esas rutas y a perder la autoridad que transmitían. Cada día sin redirecciones 301 activas era un día de señales rotas hacia Google.

Reconstruir el mapa sin repetir el error

La primera tentación fue reintroducir las reglas a mano. Abrir el plugin, añadir las 186 redirecciones que faltaban una por una, y cerrar el caso. Pero eso planteaba dos problemas: primero, reconstruir de memoria o desde hojas de cálculo antiguas más de ciento ochenta rutas era lento y propenso a errores; segundo, si volvía a ocurrir otra restauración parcial, las reglas se perderían exactamente igual.

Separar lo que debía vivir en el plugin de lo que no podía depender de él

Revisé los backups disponibles en el panel del hosting. Había un backup completo de la base de datos de tres días antes de la restauración parcial. Ese backup sí contenía la tabla wp_redirection_items con las 206 reglas completas. Exporté solo esa tabla y la de grupos asociados desde el backup, sin tocar el resto de la base de datos actual.

Antes de importar, crucé la lista exportada contra las URLs activas del sitio. Algunas de las redirecciones apuntaban a destinos que también habían cambiado en las últimas semanas. Importar a ciegas habría restaurado reglas que redirigían a páginas que ya no existían, creando cadenas de redirección o bucles. Identifiqué 9 reglas cuyos destinos ya no eran válidos y las corregí en el archivo SQL antes de la importación.

La importación se hizo en un entorno de staging primero. Verifiqué que el plugin reconocía las reglas, que los grupos estaban asignados y que las rutas respondían con 301. Todo limpio. Entonces repliqué la importación en producción.

Pero el caso no terminaba ahí. Las redirecciones 301 más críticas —las que recibían tráfico orgánico real según Search Console— no podían depender solo del plugin. Si la base de datos volvía a sufrir una restauración, esas rutas se perderían de nuevo. Así que seleccioné las 23 redirecciones con más tráfico y las escribí directamente en el .htaccess, por encima del bloque de WordPress:

# Redirecciones críticas - no dependen del plugin
Redirect 301 /reforma-banos-valencia /reformas/banos
Redirect 301 /presupuesto-cocina-integral /reformas/cocinas
Redirect 301 /ofertas-reformas-2021 /reformas/ofertas-actuales
# [... 20 reglas más ...]

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

De esta forma, las rutas críticas se resolvían antes de que WordPress procesara la petición. El plugin seguía gestionando las demás redirecciones 301 del sitio —las menos sensibles—, pero las que importaban de verdad al negocio ya no dependían de una tabla que cualquier restauración podía barrer.

Lancé un rastreo final con Screaming Frog contra toda la lista de URLs antiguas. Las 206 reglas respondían correctamente con código 301 hacia sus destinos validados. Ningún 404 residual. Ninguna cadena de redirección. Ningún bucle.

Por último, documenté en el procedimiento de backup del hosting que cualquier restauración futura debía incluir explícitamente las tablas wp_redirection_items y wp_redirection_groups, o al menos verificar su estado después de cada operación sobre la base de datos.