URL, canonical y redirecciones en PrestaShop

Qué haríamos

Clasificaríamos el trabajo antes de elegir herramientas: corregir la política actual de URL, cubrir una nueva necesidad de enrutamiento o trasladar la propia tienda. La vía adecuada depende de tu tienda actual: patrones configurados, módulos, tema, datos del catálogo, integraciones, idiomas y mercados, y quién mantendrá después las redirecciones. Incluye en esa evaluación los enlaces generados por el tema y los módulos, los slugs importados y los puntos de conexión de las integraciones.

Realiza el cambio acordado en una copia protegida en un entorno de pruebas con los mismos componentes de enrutamiento y datos representativos del catálogo. Aísla la copia de los correos a clientes reales, los pagos y las exportaciones de stock o al ERP en producción. Ensaya el mapa de rutas y los recorridos de compra; después planifica el cambio en producción con un responsable identificado, la configuración guardada y una forma de revertirlo. Conserva juntos el mapa aprobado y los resultados de pruebas para que la publicación utilice las reglas que realmente probaste.

Si quieres revisar las pruebas y las prioridades antes de implementar, PrestaShop SEO Audit & Action Plan ofrece una revisión de solo lectura y un plan ordenado de correcciones; la implementación se contrata aparte.

Comprende las URL nativas antes de cambiarlas

Inspecciona las rutas reales de la tienda antes de planificar una reestructuración. En versiones modernas, usa Parámetros de la tienda > Tráfico y SEO. En PrestaShop 1.6, usa Preferencias > SEO y URLs.

• URL amigable: PS_REWRITING_SETTINGS activa rutas legibles. Apache necesita una configuración de reescritura funcional; Nginx necesita sus propias reglas equivalentes de servidor.
• URL con acentos: PS_ALLOW_ACCENTED_CHARS_URL controla los slugs con acentos. Elige una política coherente de caracteres y prueba la codificación en vez de suponer que las URL no ASCII son inválidas.
• Redirección canonical: PS_CANONICAL_REDIRECT controla la redirección nativa a las URL preferidas de las páginas admitidas. Prueba la respuesta real, no solo el ajuste.

Las rutas nativas de productos, categorías y CMS usan identificadores. Los patrones de producto de PrestaShop 1.7/8 pueden contener información de categoría. La regla predeterminada de producto de PrestaShop 9 es {id}{-:id_product_attribute}-{rewrite}.html, sin categoría. Las tiendas actualizadas pueden conservar patrones configurados.

Asignar un producto a dos categorías no hace automáticamente que los enlaces nativos usen todas las categorías. Las solicitudes con rutas de categoría alternativas pueden resolverse, mientras la generación normal de enlaces y la redirección canonical las consolidan. Audita enlaces generados, etiquetas HTML canonical y respuestas HTTP antes de cambiar la estructura.

Conservar un ID es una decisión de diseño válida. Si necesitas un patrón sin ID como /blue-wallet, necesitas un enrutamiento que lo resuelva. Simplemente eliminar {id} o redirigir a una ruta embellecida no implementa esa ruta.

Cambia una estructura funcional para resolver un problema definido, como rutas rotas o enlaces persistentemente incoherentes. No supongas que eliminar ID, extensiones o un componente de categoría mejora por sí solo el posicionamiento.

Audita slugs, idiomas, tiendas y colisiones de rutas

Los valores link_rewrite residen en tablas de idioma como product_lang, category_lang y cms_lang. También pueden tener ámbito de tienda. Una auditoría de slugs debe conservar tanto el contexto de idioma como el de tienda.

Este ejemplo de solo lectura comprueba slugs de producto repetidos en la tienda 1 y el idioma 1. Sustituye el prefijo de tablas y el ámbito según necesites.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS distinct_products
FROM ps_product_lang
WHERE id_shop = 1 AND id_lang = 1
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1
ORDER BY distinct_products DESC, link_rewrite;

Un slug repetido no implica necesariamente una colisión en rutas nativas basadas en ID. Con un resolutor sin ID, comprueba la ruta generada completa entre productos, categorías, CMS, marcas, proveedores y rutas de módulos. Dos tipos de entidad distintos pueden reclamar la misma ruta aunque cada tabla no tenga duplicados internos.

Prueba la política de colisiones elegida y los sufijos que añada. Un gestor de URL legibles puede añadir un ID, incremento, referencia u otro elemento diferenciador. Nunca prometas que todas las URL resultantes carecerán de números.

Mantén un inventario de rutas por cada idioma y tienda publicados. Revisa slugs vacíos, codificaciones alternativas, mayúsculas, opciones de sufijo y barra final, prefijos de idioma y cualquier subdirectorio de instalación.

Alinea URL canonical, dominios y parámetros

Elige un único host preferido y su formato HTTPS. Cuando HTTPS funcione con un certificado válido, comprueba los ajustes «Activar SSL» y «Activar SSL en todas las páginas» de PrestaShop, incluidas las solicitudes a través de cualquier CDN o proxy. Prueba conjuntamente las variantes con y sin www y HTTP/HTTPS, también a través de la CDN. Utiliza el host de confianza configurado como destino de redirección para evitar bucles o comportamientos basados en cabeceras Host no fiables.

Configura la redirección canonical nativa como permanente cuando corresponda y prueba solicitudes de productos y categorías. En PrestaShop 1.7.8 y 9, PS_CANONICAL_REDIRECT usa 0 para no redirigir, 1 para 302 temporal y 2 para 301 permanente. La redirección canonical del núcleo se aplica a solicitudes GET, así que comprueba una respuesta GET real. Una etiqueta canonical es una señal de preferencia; no impide que los visitantes abran otra URL.

• Genera los enlaces internos en el formato preferido.
• Usa una canonical adecuada para variantes equivalentes con parámetros de seguimiento.
• Comprueba paginación y páginas filtradas según su contenido real y política de indexación.
• Mantén las alternativas de idioma apuntando a sus propias URL correctas e indexables.
• No consolides con canonical páginas realmente distintas solo porque sus direcciones se parezcan.

No apliques una regla global de eliminación de barras a archivos, directorios y rutas sin comprobar su semántica. Los parámetros funcionales pueden elegir combinación, filtro, idioma o acción de sesión. Son distintos del seguimiento de campañas prescindible.

Comprueba el código HTML, las cabeceras de respuesta, los enlaces internos y las entradas de sitemap para detectar señales contradictorias. Consulta la guía de Google sobre URL canonical.

Si el código fuente contiene etiquetas canonical contradictorias, identifica quién las emite: el tema, un módulo SEO o código personalizado. Acuerda qué componente se responsabiliza de esa salida en lugar de añadir otra etiqueta. Si la salida solo cambia después de vaciar la caché, comprueba las cachés de aplicación y CDN antes de juzgar la regla. Compara el idioma y la tienda afectados además del escaparate predeterminado; que una página en el idioma predeterminado sea correcta no demuestra que lo sean los demás contextos.

Crea el mapa de URL antiguas a finales

Inventaría el catálogo y la configuración actual de rutas, rastrea las páginas accesibles, inspecciona sitemaps y registros del servidor y añade datos de rendimiento y enlaces de Search Console y enlaces externos conocidos. El informe de indexación de Search Console ofrece ejemplos, no una lista completa de todas las URL indexadas; consulta su documentación del informe.

Registra URL antigua, tienda/idioma, estado, canonical actual, tráfico y enlaces entrantes pertinentes, URL final prevista y respuesta esperada. Mantén sin cambios las URL que no cambien. Incluye imágenes, descargas y páginas importantes de módulos si se trasladan.

Añade la fuente de las pruebas y la entidad que representa cada fila. Un rastreo actual no puede descubrir una dirección histórica a la que no enlaza ninguna página actual, y los registros solo cubren el periodo conservado. Marca los destinos desconocidos para revisión en lugar de descartarlos sin avisar. Prioriza las páginas de entrada valiosas y los enlaces de compra rotos, pero no interpretes una columna de tráfico vacía como prueba de que una dirección no se utiliza.

1. Configura y prueba primero el enrutamiento de destino.
2. Asigna las páginas cambiadas directamente a su destino final correspondiente.
3. Revisa las páginas importantes retiradas para encontrar un sustituto pertinente o una página consolidada equivalente.
4. Usa 404 o 410 cuando una página haya desaparecido y no tenga equivalente adecuado.
5. Reorienta las cadenas de redirección anteriores a la URL final.

Una categoría superior no es automáticamente un destino equivalente para un producto retirado. Las redirecciones generales a inicio o categorías pueden confundir a los usuarios y tratarse como errores soft 404. Un 410 no garantiza una eliminación más rápida que un 404; consulta la guía de Google sobre páginas eliminadas.

Usa 301 o 308 para traslados permanentes y el estado temporal adecuado para traslados temporales. Un 302 no impide categóricamente la consolidación de señales; su intención de indexación difiere. Las redirecciones permanentes no pierden necesariamente PageRank en cada salto. Acorta las cadenas para reducir latencia, mejorar el rastreo y limitar puntos de fallo. Consulta la guía de Google sobre redirecciones.

Prueba los destinos con ejemplos prácticos

Un producto tiene rutas de categoría antiguas

Supongamos que tu auditoría encuentra las direcciones históricas /bags/42-blue-wallet.html y /sale/42-blue-wallet.html para el mismo producto y apruebas /42-blue-wallet.html como ruta final. Confirma la identidad del producto antes de asignar ambos alias directamente a esa dirección. Si más adelante retiras el producto de Ofertas, el antiguo enlace de Ofertas no debe llevar a un listado genérico de ofertas.

Prueba un enlace guardado que también seleccione una combinación de producto. Síguelo hasta la página del producto, añade el artículo al carrito y revisa la talla, el precio y la opción de stock resultantes. Una redirección que termine en el producto correcto pero pierda silenciosamente la combinación seleccionada por el cliente no supera esta prueba. Comprueba el mismo recorrido desde un enlace de feed o campaña, en lugar de probar solo un enlace recién generado por la tienda.

Un producto y una página de contenido quieren el mismo slug

Supongamos que un producto sin ID en la URL y una página CMS solicitan ambos /summer-sale. Comprobar solo los slugs de productos no detectará este conflicto. Decide qué entidad conserva la dirección y asigna a la otra una ruta distinta antes de publicar cualquiera de los cambios. Registra esa pertenencia en el mapa; cambiar la prioridad de redirección no permite que una misma dirección sirva las dos páginas previstas.

Implementa redirecciones exactas en Apache

Coloca las reglas personalizadas fuera y antes del bloque generado de reescritura de PrestaShop. Guarda una copia de la configuración, valida el servidor y prueba en un entorno de pruebas antes de recargar producción. Usa un mecanismo de redirección deliberado; mezclar mod_alias y mod_rewrite puede dar sorpresas de orden.

Estos ejemplos corresponden al .htaccess de la raíz de la tienda para una instalación en la raíz. Asignan rutas antiguas exactas a rutas nativas finales probadas en el dominio ilustrativo.

RewriteEngine On
RewriteRule ^old-wallet\.html$ https://www.example.com/42-blue-wallet.html [R=301,L]
RewriteRule ^old-category/$ https://www.example.com/3-wallets [R=301,L]

Las anclas hacen exactas estas coincidencias de ruta. RewriteRule en este contexto no ve la barra inicial y compara la ruta sin argumentos de consulta. Estas reglas conservan por defecto los argumentos existentes. Usa QSD solo cuando los descartes deliberadamente y hayas confirmado que no contienen ningún estado necesario.

Para una tienda bajo /shop/, ajusta tanto el contexto de las reglas como las rutas de destino. Una solicitud antigua index.php?id_product=42&controller=product requiere un tratamiento que tenga en cuenta la consulta o un comportamiento canonical nativo probado; una regla basada solo en la ruta index.php coincidiría con muchas páginas sin relación.

La directiva simple Redirect usa coincidencia por prefijo de ruta y añade la parte no coincidente de la ruta. Usa RedirectMatch con anclas o una reescritura anclada probada para mapas exactos. Consulta la documentación de Redirect de Apache.

No uses una regla general para «eliminar el prefijo numérico» o «eliminar .html» hasta saber que todas las rutas de destino funcionan. Estas reglas pueden afectar a productos, categorías y endpoints sin relación y crear cadenas al ejecutarse secuencialmente.

Implementa un mapa de rutas en Nginx

Para un mapa mayor basado solo en rutas, define map en el contexto http y úsalo desde el bloque de servidor pertinente. Este ejemplo usa expresiones regulares ancladas y sensibles a mayúsculas y conserva deliberadamente los argumentos de consulta.

# http context
map $uri $migration_target {
    default "";
    ~^/old-wallet[.]html$ /42-blue-wallet.html;
    ~^/old-category/$ /3-wallets;
}

# inside the intended server block
if ($migration_target != "") {
    return 301 https://www.example.com$migration_target$is_args$args;
}

$uri es la ruta actual normalizada sin argumentos; $request_uri incluye la cadena de consulta original. Un mapa con claves de ruta comparadas con $request_uri no encontraría /old-wallet.html?utm_source=email. Elige la coincidencia de solicitud completa solo cuando la propia consulta forme parte de la clave prevista. Consulta las variables URI de Nginx.

Si un destino sustituye o descarta argumentos deliberadamente, modifica la construcción de la respuesta de redirección en consecuencia. Prueba los caracteres escapados y las barras repetidas según tu política de normalización. Coloca la lógica donde reciba la ruta prevista antes de que otras reescrituras internas cambien $uri.

Ejecuta nginx -t, revisa el resultado, recarga la instancia prevista y prueba solicitudes representativas. Los dominios y rutas de ejemplo describen un mapa concreto de muestra; genera tu mapa real desde destinos aprobados en vez de copiar la muestra en otra tienda.

Cambia de dominio y conserva las rutas multilingües

Un cambio de alojamiento con el mismo dominio público y las mismas rutas puede conservar las URL. Antes de cambiar el DNS, prueba el servidor nuevo con el nombre de host público y el certificado HTTPS previstos. Planifica cómo llegarán a la tienda activa las solicitudes que aún alcancen el servidor antiguo durante la propagación del DNS. Un dominio o directorio base nuevo también requiere actualizar la configuración de URL de la propia tienda, tener listos los certificados y mantener el enrutamiento de las direcciones antiguas a las nuevas.

1. Copia los archivos y la base de datos correspondientes al nuevo entorno y protege la copia durante las pruebas.
2. Actualiza la URL de la tienda prevista mediante los ajustes admitidos del back office. Verifica shop_url.domain, domain_ssl, physical_uri y cualquier URI virtual multitienda.
3. Comprueba los valores pertinentes de PS_SHOP_DOMAIN y PS_SHOP_DOMAIN_SSL en el contexto correcto.
4. Si cambia el acceso a la base de datos, actualiza app/config/parameters.php en versiones modernas. La ruta no es config/parameters.php. La antigua 1.6 usa config/settings.inc.php.
5. Vacía o reconstruye las cachés y regenera las reglas Apache aplicables o despliega las reglas Nginx equivalentes.
6. Instala y prueba redirecciones de cada página antigua a su equivalente final. Mantén operativos el dominio antiguo y su certificado HTTPS.
7. Actualiza callbacks de pago, tareas cron, enlaces de correo, feeds, analítica y destinos de anuncios.

Para catálogos multilingües, asigna cada idioma a su equivalente, conserva la diferenciación de idioma necesaria y revisa las referencias canonical y hreflang recíprocas. No redirijas todos los idiomas al inglés.

Un catálogo con 5.000 productos y cuatro idiomas puede tener aproximadamente 20.000 pares de URL producto-idioma antes de alias, categorías e historial antiguo. Genera el inventario desde las combinaciones realmente publicadas en vez de suponer que todos los productos tienen todas las traducciones.

Para la parte del cambio relativa a plataforma y datos, usa la guía de migración.

Usa módulos de URL y SEO para enrutamiento y metadatos

SEO Revolution ofrece gestión de redirecciones, revisión de errores 404, tratamiento de cadenas permanentes, reglas canonical/hreflang y flujos de sitemaps; su ayuda del módulo incluye la configuración y el comportamiento de coincidencia admitido.

Smart SEO Friendly URL Manager ofrece patrones de URL por entidad, políticas de colisiones e historial de redirecciones, incluida la condición de que una ruta antigua no pertenezca a una ruta actual; usa su ayuda del módulo para configurarlo y conocer la interacción con SEO Revolution.

Product Canonical Manager ofrece controles canonical por producto; consulta su ayuda del módulo antes de cambiar los destinos preferidos.

Hreflang Tags Manager ofrece gestión de alternativas de idioma; su ayuda del módulo cubre la configuración.

Prueba en una copia las rutas de módulos, coincidencia exacta y de consultas, reglas de prefijo, finales de cadenas, elegibilidad por idioma y prioridad de rutas actuales. Un módulo de redirecciones sigue necesitando un mapa de destinos comprobado; no puede elegir con seguridad equivalentes semánticos para todas las páginas ausentes.

Verifica el lanzamiento y supervisa los resultados

Actualiza las referencias internas a URL finales: navegación, contenido CMS y de productos, ventas cruzadas, plantillas de email, feeds y datos estructurados. Las redirecciones deben captar referencias externas antiguas en vez de añadir saltos a cada enlace interno nuevo.

Genera sitemaps con las URL canonical indexables previstas que devuelvan respuestas correctas. Comprueba todas las tiendas e idiomas. Elimina destinos redirigidos, ausentes y noindex. Un sitemap es una señal de descubrimiento y canonical, no una garantía de indexación; consulta la guía de Google sobre sitemaps.

Prueba la respuesta y el contenido final con un navegador normal y una solicitud por línea de comandos. Algunas aplicaciones tratan HEAD de otra forma, así que confirma también con GET.

curl -sS -D - -o /dev/null 'https://www.example.com/old-wallet.html?utm_source=email'
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' 'https://www.example.com/old-wallet.html'

• URL cambiadas: estado permanente esperado, Location correcto, sin bucle y una página final 200 con contenido correspondiente.
• URL sin cambios: 200 directo, contenido y canonical correctos.
• Páginas retiradas: 404/410 previsto, sin una página de éxito engañosa.
• Variantes: host, esquema, sufijo, mayúsculas, codificación, argumentos, idioma y subdirectorio de instalación.
• Flujos críticos: combinaciones, búsqueda/facetas, proceso de compra, cuenta y callbacks de pago.

Verifica las propiedades antiguas y nuevas de Search Console, envía el sitemap actual y usa Cambio de dirección para un cambio de dominio admitido. Revisa informes de rastreo e indexación, registros, tráfico orgánico de páginas de entrada y conversión. Conserva las redirecciones permanentes de migración al menos un año y más tiempo mientras haya enlaces o visitantes que las usen.

Conserva mediciones de referencia anteriores al cambio por página de entrada, idioma y tienda, y compara los destinos del mapa con sus equivalentes antiguos. Los totales de toda la tienda pueden ocultar un idioma que falla o una categoría valiosa ausente. Distingue un fallo de solicitud de un cambio de rendimiento en búsquedas: un bucle, un producto incorrecto o un destino bloqueado necesitan una corrección técnica, mientras que una URL que funciona pero recibe menos visitas requiere examinar la indexación, el contenido y la demanda. Registra el momento del cambio y las campañas o modificaciones de catálogo simultáneas para no atribuir sus efectos a una causa equivocada.

Los tiempos de procesamiento y los resultados de búsqueda varían. Las redirecciones no pueden garantizar la recuperación ni compensar contenido perdido, restricciones de indexación o cambios de competencia. Consulta la guía de Google sobre traslados de sitios.

Qué preguntar a tu desarrollador o agencia

Pide una entrega que puedas utilizar cuando llegue la siguiente importación, cambio de nombre o actualización de módulo.

• ¿Qué componente se responsabiliza de las redirecciones de host, el enrutamiento de páginas, las redirecciones históricas, las etiquetas canonical y hreflang, y en qué orden se ejecutan?
• ¿Qué filas del mapa siguen sin resolver, quién aprueba sus destinos y dónde están los resultados de las solicitudes y las comprobaciones de páginas finales?
• ¿Puede una importación del catálogo sobrescribir slugs manuales o crear nuevas colisiones y quién comprueba el resultado?
• ¿Qué enlaces del tema, feeds, callbacks y tareas programadas se probaron con el dominio y los idiomas de producción previstos?
• ¿Quién puede restaurar la configuración anterior, qué activa esa decisión y cómo se conservarán los pedidos y cambios de stock nuevos?
• ¿Quién se responsabiliza de la supervisión y de los avisos de enlaces rotos recibidos después de la entrega del proyecto?

Preguntas de los propietarios de tiendas

¿Podemos restaurar una copia de la base de datos para deshacer el cambio de URL?

No sobrescribas pedidos nuevos, cambios de clientes o movimientos de stock con la base de datos anterior al lanzamiento. Planifica la recuperación según la configuración de enrutamiento, el mapa de redirecciones y los cambios de datos concretos implicados. Los navegadores y los intermediarios pueden almacenar redirecciones permanentes en caché, así que prueba la recuperación para los visitantes que aún sigan los nuevos destinos publicados. Mantén esos destinos utilizables durante la recuperación. Si la reversión necesita reparar datos, tu desarrollador debe conciliar los registros escritos desde el lanzamiento en lugar de restaurar toda la tienda a ciegas.

¿Podemos reutilizar la dirección de un producto retirado para otro producto?

Comprueba su uso histórico antes de aprobarlo. Los marcadores, campañas y enlaces externos antiguos abrirían ahora el producto nuevo, y una redirección histórica podría dejar de ejecutarse cuando una ruta actual ocupe esa dirección. Conserva una dirección distinta cuando los productos no respondan a la misma intención; reserva los alias importantes en el inventario de rutas para que una importación no pueda reutilizarlos sin control.

¿Un cambio de dominio obliga a detener los pedidos?

Un ensayo de redirecciones no determina eso. Si también trasladas la base de datos, acuerda qué entorno acepta escrituras, cómo funciona la sincronización final de datos y si es necesario pausar el proceso de compra. Los pedidos, las notificaciones de pago y las actualizaciones de stock no deben repartirse entre copias independientes durante el cambio.

¿Quién mantiene el mapa después del lanzamiento?

Asigna a una persona concreta la responsabilidad de los destinos aprobados y del motivo de cada cambio. Conserva la configuración de redirecciones con los registros de publicación y revísala tras importaciones del catálogo o actualizaciones de enrutamiento. Incluye los avisos de páginas ausentes de atención al cliente: un enlace de compra roto puede ser importante aunque tenga poco tráfico de búsqueda.