Durante una migración PrestaShop 1.7 a 8, un cambio de tema, una reorganización del árbol, o simplemente una modificación de slug producto, cientos incluso miles de URL cambian silenciosamente. Cada una de estas URL acumula jugo SEO, enlaces entrantes, y figura quizás en los resultados Google con un buen posicionamiento. Sin redirección 301 a la nueva URL, este capital desaparece.
Lo peor: la pérdida no es inmediata. Ves el tráfico caer lentamente en 3 a 6 semanas, sin incidente claro. Cuando lo entiendes, has perdido del 30 al 50 % del tráfico SEO y harán falta 6 a 12 meses para recuperarlo — si lo consigues.
Este artículo desgrana la mecánica de las redirecciones 301 en PrestaShop: lo que hace el nativo, lo que pasa por alto, cómo implementar un monitoreo 404 limpio, y cómo automatizar el reflejo «cambio de slug → redirección 301».
Por qué las redirecciones 301 son críticas para el SEO
Una redirección 301 («Moved Permanently») dice a Google y a los usuarios: esta URL se ha mudado definitivamente, aquí está la nueva dirección. Google transmite entonces el PageRank, el historial de la URL, los backlinks acumulados. La nueva URL hereda el capital SEO.
Sin 301, la URL inicial devuelve un 404 («Not Found»). Google pone la página en cola de desindexación, los backlinks apuntan al vacío, el PageRank se disipa. Tras 3-6 meses, la URL se retira del índice. El capital se pierde.
Algunas cifras de auditoría, en una tienda post-migración sin gestión 301 limpia:
- Del 40 al 60 % de las URL indexadas Google responden en 404 en los 6 meses.
- El tráfico SEO cae del 25 al 50 % en el trimestre siguiente.
- Las posiciones en las consultas de cola larga (a menudo las más rentables) se desploman primero.
- Los backlinks externos (prensa, blogs, directorios) se vuelven obsoletos y pierden su jugo.
Lo que PrestaShop gestiona nativamente (y lo que pasa por alto)
El módulo SEO & URLs nativo
PrestaShop 8 y 9 propone una pestaña «Redirecciones» en Preferencias > Tráfico > SEO & URLs. Permite añadir manualmente redirecciones 301 / 302 / 410 por par (URL fuente, URL destino).
Límites:
- Sin gestión por regex o wildcard. Para redirigir toda una antigua categoría
/productos-antiguos/*a/ofertas/, hay que crear manualmente cada URL. - Sin redirección automática al cambio de slug. Si modificas el slug de un producto, la antigua URL se va en 404 sin redirección.
- Sin monitoreo 404 en las URL efectivamente visitadas.
- Rendimiento limitado. Más allá de algunos miles de redirecciones, el módulo ralentiza el routing.
- Sin importación/exportación en CSV para gestionar en masa.
El archivo .htaccess
Alternativa manual: escribir reglas RewriteRule en .htaccess. Eficiente (Apache procesa las reglas aguas arriba), pero:
- Sensible a los errores de sintaxis (una coma mal colocada y todo el sitio cae en 500).
- Difícil de mantener para los no técnicos.
- No funciona en Nginx (que usa su propia sintaxis).
- Sin interfaz BO ni trazabilidad.
La stack que se debería tener
1. Redirección automática al cambio de slug
Cuando un producto, una categoría o un CMS cambia de slug, la antigua URL debe registrar automáticamente una 301 hacia la nueva. Sin manipulación manual, sin riesgo de olvido. Es la red de seguridad número 1.
2. Monitoreo de los 404
Todas las URL que se van en 404 deben ser logueadas con su frecuencia y su referente. Una URL llamada 200 veces al mes en 404 es un bug a tratar prioritariamente. Una URL en 404 una vez al año puede esperar.
3. Redirecciones en masa por regex y wildcard
Para las migraciones, necesitamos patrones. /categoria-antigua/(.*) → /categoria-nueva/$1 debe poder configurarse en una regla, no en 200 entradas.
4. Importación/exportación CSV
Antes de una migración, se prepara la tabla de correspondencia en CSV desde la exportación del sitemap antiguo y el sitemap nuevo. Se importa de una vez en lugar de capturar a mano.
5. Detección de las cadenas de redirección
Una URL que redirige hacia una URL que redirige hacia una URL es un anti-patrón SEO. Google desprecia las cadenas de más de 2 saltos. Una buena herramienta detecta y señala las cadenas.
6. Trazabilidad y auditoría
¿Quién ha creado tal redirección, cuándo, por qué motivo? En caso de problema (caída de tráfico post-migración), poder auditar las reglas 301 es crucial.
El caso particular del cambio de slug producto
En una tienda activa, los slugs cambian constantemente. Un producto cuyo nombre evoluciona («Vestido verano 2025» → «Vestido lino verano 2025»), una optimización SEO de título, una corrección de typo — cada modificación del link_rewrite en ps_product_lang cambia la URL canónica.
Si la 301 no se crea automáticamente, la antigua URL se va en 404. En 12 meses, en un catálogo de 5 000 productos con un 10 % de slugs modificados, esto representa 500 URL «perdidas». Si cada una drenaba en promedio 50 visitas/mes, hablamos de 25 000 visitas SEO perdidas al año, sin incidente visible.
El reflejo correcto: un hook sobre actionObjectProductUpdateAfter que detecta el cambio de link_rewrite y crea la 301 automáticamente, por idioma y por tienda multi-shop.
La trampa de las cadenas de redirección
Escenario clásico: un producto A cambia de slug 3 veces en 6 meses. Sin gestión fina, te encuentras con:
/slug-1.html → /slug-2.html/slug-2.html → /slug-3.html/slug-3.html → /slug-4.html
Una petición en la primera URL hace 3 saltos antes de llegar. Google desprecia las cadenas de más de 2 redirecciones. El crawl budget se consume inútilmente, y el PageRank se disipa en cada salto (pérdida del 5 al 10 % por salto según los estudios Moz).
La regla: aplanar las cadenas. Cuando se crea una nueva redirección, el sistema debe buscar si la URL fuente era ya el destino de otra 301, y reescribir la antigua para apuntar directamente al nuevo destino. Sin más cadena, sin más salto.
Nuestro módulo dfredirects: gestor 301 completo
Implementar esta stack a mano requiere 7 a 12 días de dev en PrestaShop, más el mantenimiento. Nuestro módulo dfredirects para PrestaShop 8 y 9 industrializa toda la mecánica:
- Redirecciones 301, 302, 410 configurables desde el BO, con interfaz filtrable y paginada.
- Patrones regex y wildcard: una regla puede cubrir cientos de URL (
/old-cat/(.*)$ → /new-cat/$1). - Redirección automática al cambio de slug producto, categoría, fabricante, proveedor, CMS — multilingüe y multitienda.
- Monitoreo 404 con frecuencia, última visita, referente. Orden por volumen para priorizar.
- Aplanamiento automático de las cadenas: sin redirecciones en cascada.
- Importación/exportación CSV para gestionar en masa antes de migración.
- Trazabilidad: autor, fecha, motivo opcional por regla.
- Compatible PS 8 y 9, sin dependencia Apache/.htaccess (funciona también en Nginx).
- Rendimiento: tabla optimizada con índice, hasta 100 000 reglas sin degradación.
Por 49 €, evitas la pérdida de tráfico post-migración e instalas una red de seguridad duradera contra la deriva 404.
Procedimiento de migración SEO-safe
Paso a paso, el procedimiento que aplicamos en las migraciones PrestaShop 1.7 → 8 o las refundiciones mayores:
- Antes de la migración: exportación del sitemap.xml antiguo. Contiene todas las URL indexadas.
- Crawl completo del sitio antiguo con Screaming Frog o equivalente, para recuperar todas las URL (incluso las páginas fuera de sitemap: filtros, paginaciones).
- Mapping antiguo → nuevo en CSV: cada URL antigua recibe su URL nueva. Para las URL desaparecidas, elegir un destino alternativo pertinente (categoría padre, página de inicio como último recurso).
- Importación del CSV en dfredirects antes o durante la conmutación.
- Test: 50 URL aleatorias verificadas en 301 directamente, sin cadena, hacia el buen destino.
- Envío del nuevo sitemap.xml a Google Search Console.
- Monitoreo 404 diario durante el primer mes: toda 404 recurrente se convierte en 301.
- Auditoría a 30, 60, 90 días: cobertura Search Console, consultas perdidas, verificación de la estabilidad del tráfico.
FAQ
¿Qué diferencia entre 301 y 302?
La 301 es definitiva y transmite el PageRank. La 302 es temporal y no transmite. Para una migración o un cambio de slug, usar siempre 301. La 302 se reserva a los casos explícitamente temporales: mantenimiento, test A/B, redirección estacional.
¿Y la 410 (Gone)?
La 410 dice a Google: esta URL ya no existe y no volverá, desindexa inmediatamente. Más rápido que la 404 para la limpieza del índice. Útil para los productos definitivamente retirados sin equivalente. Pero usar con moderación: una vez la 410 devuelta, el PageRank se pierde.
¿Cuánto tiempo tarda Google en tener en cuenta una 301?
El crawl Google de la URL antigua puede tardar unos días a varias semanas según la frecuencia de crawl. La transmisión completa del PageRank a la nueva URL toma en la práctica 1 a 3 meses. Enviar el nuevo sitemap acelera el proceso.
¿Se puede redirigir en HTTPS y cambiar de dominio al mismo tiempo?
Sí, e incluso es frecuente. Una 301 puede combinar protocolo (HTTP → HTTPS), dominio (antiguo.com → nuevo.com) y ruta. La regla: una sola 301 por URL, no una cadena. Aplanar al máximo.
¿Las redirecciones impactan en el rendimiento?
Una 301 simple añade unos 100-200 ms al tiempo de respuesta para la primera petición. Con caché del navegador (Cache-Control sobre la 301), las visitas siguientes van directamente a la nueva URL sin el salto. El coste es insignificante fuera de cadenas múltiples. Una cadena de 3 saltos, en cambio, puede añadir 500 ms — de ahí el aplanamiento.
Para ir más allá
La gestión de las redirecciones es uno de los pilares de la migración SEO-safe. Tres temáticas complementarias: preparar, ejecutar, asegurar.
