Gestión de comercio electrónico desde casa con PrestaShop. Organización, café y apuntes para optimizar la tienda online.
¿Qué hacer si aparecen URLs de productos duplicados o errores 404 en PrestaShop? 🛒🔎
Hay pocas cosas tan incómodas para una tienda online como descubrir que Google está rastreando varias URLs para el mismo producto o que, de pronto, una ficha que ayer vendía hoy responde con un elegante y funerario 404. El catálogo sigue ahí, las imágenes también, el precio no se ha movido… pero la URL se ha evaporado como una huella en arena mojada.
En PrestaShop, las URLs duplicadas de productos y los errores 404 no suelen aparecer por generación espontánea. Casi siempre son el síntoma visible de algo más profundo: rutas mal configuradas, cambios en las URLs amigables, problemas con el archivo .htaccess, módulos SEO demasiado entusiastas, migraciones incompletas, productos desactivados, categorías eliminadas, reglas canónicas ausentes o una multitienda que ha decidido comportarse como un pequeño principado independiente.
La ironía es fina: trabajamos durante semanas para que una tienda sea más “amigable” para el usuario, activamos las URLs amigables, instalamos módulos de optimización, limpiamos slugs, eliminamos IDs… y de pronto el sitio es tan amigable que ni Google ni PrestaShop saben cuál es la puerta correcta. Una tienda ordenada por fuera, laberíntica por dentro. Como un almacén con etiquetas preciosas y pasillos que no llevan a ninguna parte.
Esta guía está pensada para propietarios de tiendas, responsables SEO, desarrolladores y técnicos que necesitan una respuesta clara: cómo diagnosticar, corregir y prevenir URLs duplicadas y errores 404 en PrestaShop sin romper más cosas en el camino. Porque sí, también hay que decirlo: en mantenimiento web, a veces el remedio aplicado con prisa deja más cicatrices que la enfermedad.
Contenido de la guía
- Por qué las URLs duplicadas y los 404 dañan tu tienda
- Cómo diferenciar un duplicado SEO de un 404 real
- Causas habituales de URLs duplicadas en PrestaShop
- Causas frecuentes de errores 404 en productos
- Método profesional de diagnóstico paso a paso
- Soluciones prácticas en PrestaShop
- Redirecciones 301, canónicas y cuándo usar cada una
- Casos delicados: multitienda, idiomas y módulos SEO
- Cómo evitar que vuelva a ocurrir
Por qué las URLs duplicadas y los errores 404 no son un detalle menor ⚠️
Una URL duplicada no siempre rompe la tienda. Ahí está el problema: puede parecer inofensiva. El producto carga, el botón de compra funciona, el cliente quizá ni se entera. Pero para los buscadores, varias URLs con el mismo contenido son como varias llaves para una misma habitación: ¿cuál debe guardar, cuál debe mostrar, cuál debe ignorar?
En SEO técnico, esa confusión tiene consecuencias:
- Dilución de autoridad: los enlaces externos o internos pueden repartirse entre varias versiones de una misma página.
- Rastreo ineficiente: Googlebot desperdicia presupuesto de rastreo en URLs redundantes.
- Indexación irregular: Google puede elegir una URL distinta a la que tú consideras principal.
- Problemas de contenido duplicado: aunque no exista una “penalización automática” por duplicados internos, sí puede haber pérdida de claridad semántica y visibilidad.
- Métricas distorsionadas: en Analytics, Search Console o herramientas SEO, el rendimiento del producto queda fragmentado.
Los errores 404 en PrestaShop, por su parte, son todavía más explícitos. Un 404 le dice al navegador y a los bots: “aquí no hay nada”. Y a veces no hay nada de verdad, lo cual es sano. El problema aparece cuando sí debería haber algo: un producto activo, con stock, enlazado desde categorías, campañas de email, anuncios de Google Ads o resultados orgánicos.
El comercio electrónico vive de la continuidad. Una URL rota en una tienda no es solo una página caída; es un mostrador cerrado en plena hora punta. Y el cliente, como los gatos y los compradores impacientes, rara vez espera una explicación técnica.
Primero: no todo duplicado es igual y no todo 404 es un desastre
Antes de tocar configuraciones, conviene separar los casos. PrestaShop puede mostrar situaciones parecidas con causas muy distintas. Confundirlas lleva a soluciones torpes: redirigir lo que debería corregirse, indexar lo que debería bloquearse, borrar lo que solo necesitaba una ruta limpia.
| Situación | Ejemplo | Riesgo principal | Acción recomendada |
|---|---|---|---|
| Producto accesible desde varias URLs | /camisetas/12-camiseta.html y /ofertas/12-camiseta.html |
Duplicidad SEO, autoridad dividida | URL canónica, redirección 301 o revisión de ruta |
| Producto antiguo eliminado | /123-zapatilla-modelo-2021.html |
404 en URLs con tráfico o enlaces | 301 a producto equivalente, categoría o 410 si procede |
| Cambio de slug o URL amigable | /45-bolso-rojo.html pasa a /45-bolso-de-piel-rojo.html |
Pérdida temporal de posicionamiento | Redirección 301 desde la URL antigua |
| Error de servidor o reescritura | Todas las URLs amigables devuelven 404 | Tienda parcialmente inaccesible | Regenerar .htaccess, revisar Apache/Nginx |
| Parámetros de filtrado o tracking | ?utm_source=..., ?q=Color-Rojo |
Rastreo e indexación de variantes innecesarias | Canonical, robots, Search Console, configuración facetas |
El matiz importa. En una tienda real, una URL 404 puede ser correcta, incluso deseable. Si eliminaste un producto sin reemplazo y no tiene demanda, dejarlo en 404 o devolver 410 Gone puede ser más honesto que enviarlo a la home, esa costumbre tan extendida como poco elegante. Redirigir todo a la portada es el equivalente digital de responder “por allí” señalando a la niebla.
Causas habituales de URLs de productos duplicadas en PrestaShop 🧩
PrestaShop tiene una arquitectura flexible para generar URLs: tienda, idioma, categoría, producto, ID, slug, dominio, protocolo, rutas personalizadas. Flexibilidad: esa palabra luminosa que, sin gobierno, se convierte en selva.
1. Producto asignado a varias categorías
Un mismo producto puede pertenecer a varias categorías. Por ejemplo, una chaqueta puede estar en Ropa, Ofertas y Novedades. Si la estructura de URL incluye la categoría, podrían aparecer rutas como:
https://www.tienda.com/ropa/123-chaqueta-azul.html
https://www.tienda.com/ofertas/123-chaqueta-azul.html
https://www.tienda.com/novedades/123-chaqueta-azul.html
En muchas instalaciones modernas, PrestaShop intenta utilizar la categoría por defecto del producto para construir la URL principal. Pero plantillas, módulos de menú, módulos de filtros, personalizaciones del tema o desarrollos propios pueden generar enlaces alternativos usando categorías secundarias. Así nacen duplicados que no siempre se ven desde el back office.
Qué revisar:
- Categoría por defecto del producto.
- Enlaces generados por el tema en listados, carruseles, bloques de productos relacionados y módulos de navegación.
- URLs indexadas en Google Search Console.
- Etiqueta
rel="canonical"de cada versión.
2. Configuración de rutas SEO modificada
En PrestaShop 1.7, 8 y versiones recientes, la configuración de URLs se encuentra normalmente en Parámetros de la tienda > Tráfico y SEO. Allí se pueden definir las rutas para productos, categorías, proveedores, fabricantes y páginas CMS.
Una ruta de producto habitual puede incluir variables como:
{category:/}{id}-{rewrite}.html
El {id} es importante. Puede parecer poco estético, sí. A nadie le emociona un número incrustado en una URL, salvo quizá a un contable en primavera. Pero ese ID evita colisiones entre productos con nombres similares o slugs repetidos. Algunos módulos SEO prometen eliminar IDs para dejar URLs “más limpias”; a veces lo hacen bien, y otras veces convierten la tienda en un baile de máscaras donde dos productos reclaman la misma dirección.
Recomendación técnica: si eliminas IDs de las URLs en PrestaShop, hazlo solo con un módulo fiable, compatible con tu versión y probado en staging. PrestaShop, por diseño, utiliza identificadores para resolver rutas con seguridad. Quitar esa pieza sin una lógica robusta puede generar duplicados, 404 o conflictos de enrutamiento.
3. HTTP y HTTPS, con o sin www
Una tienda puede tener varias versiones accesibles:
http://tienda.com/producto
http://www.tienda.com/producto
https://tienda.com/producto
https://www.tienda.com/producto
Para el usuario parecen la misma casa con cuatro timbres. Para un rastreador, son cuatro URLs distintas si no hay redirecciones correctas. El contraste es cruel: el navegador perdona, Google registra.
Qué hacer:
- Forzar HTTPS desde PrestaShop y desde el servidor.
- Elegir una versión canónica: con www o sin www.
- Configurar redirecciones 301 coherentes.
- Verificar el dominio en Parámetros de la tienda > Tráfico y SEO y, si aplica, en Parámetros avanzados > Multitienda.
4. Idiomas y prefijos mal resueltos
En tiendas multilingües, una ficha puede existir en español, francés e inglés. Eso es normal. Lo problemático aparece cuando las versiones lingüísticas se mezclan, cuando un producto en español responde también bajo una ruta inglesa, o cuando las etiquetas hreflang no acompañan correctamente.
Ejemplo:
/es/123-zapatos-rojos.html
/en/123-zapatos-rojos.html
/fr/123-zapatos-rojos.html
Si el contenido cambia de idioma, no hablamos de duplicado puro. Si no cambia, o si se generan rutas vacías, incompletas o traducidas a medias, hay un problema técnico y editorial. Una tienda multilingüe descuidada parece cosmopolita por fuera y monolingüe por dentro, como esos restaurantes con carta en cinco idiomas y platos que nadie revisó desde 2016.
5. Parámetros, filtros y facetas indexables
Los módulos de navegación por facetas pueden generar multitud de URLs con parámetros: talla, color, marca, precio, disponibilidad. Esto es útil para el usuario, pero peligroso para el rastreo si no se controla.
/camisetas?q=Color-Rojo
/camisetas?q=Talla-M/Color-Rojo
/camisetas?order=product.price.asc
Aunque no siempre son URLs de producto, pueden enlazar hacia fichas con variantes de parámetros, generar rutas alternativas o saturar el rastreo. En catálogos grandes, esta multiplicación funciona como una enredadera: al principio decora, luego tapa la ventana.
6. Módulos SEO o temas que generan enlaces inconsistentes
No todos los duplicados vienen del núcleo de PrestaShop. Muchos nacen en módulos de:
- Menús avanzados.
- URLs sin ID.
- Redirecciones automáticas.
- Filtros y facetas.
- Blogs integrados.
- Productos relacionados o packs.
- Sitemaps personalizados.
Un módulo mal mantenido puede seguir generando URLs antiguas después de una migración. Otro puede ignorar la categoría por defecto. Otro puede construir enlaces manualmente en lugar de usar la clase nativa de PrestaShop para generar URLs. Pequeñas desobediencias, grandes incendios.
Causas frecuentes de errores 404 en productos PrestaShop 🚧
Un error 404 es una respuesta HTTP legítima: indica que el recurso no existe en esa dirección. Lo anómalo no es el código, sino que aparezca donde no debe.
1. URLs amigables activadas sin reescritura correcta
Cuando activas las URLs amigables en PrestaShop, el servidor debe saber cómo traducir esas rutas bonitas en peticiones internas. En Apache, esto depende normalmente de mod_rewrite y del archivo .htaccess. En Nginx, las reglas se configuran en el bloque del servidor.
Si el servidor no aplica la reescritura, la tienda intenta servir una ruta física que no existe. Resultado: 404. Hermoso por fuera, roto por dentro.
Síntomas típicos:
- La home carga, pero productos y categorías dan 404.
- Las URLs no amigables funcionan, pero las amigables no.
- El problema aparece tras migrar de hosting.
- El archivo
.htaccessfalta, está vacío o tiene permisos incorrectos.
2. Archivo .htaccess desactualizado
Cada vez que cambias la configuración de URLs, dominio, idioma, tienda o rutas, conviene regenerar el .htaccess. En PrestaShop suele hacerse desactivando y reactivando las URLs amigables, o guardando de nuevo la configuración de tráfico y SEO.
También puede ser necesario borrar caché. Porque PrestaShop, como cualquier sistema con memoria, a veces recuerda lo que ya no existe y olvida lo que acabas de arreglar.
3. Producto desactivado, eliminado o no asociado a la tienda correcta
En PrestaShop, un producto desactivado puede devolver 404 en el frontal. Si trabajas con multitienda, además, el producto puede existir en la base de datos pero no estar asociado a la tienda actual. Desde el back office parece vivo; desde el escaparate, está ausente.
Revisa:
- Estado del producto: activo o inactivo.
- Asociación con la tienda correcta en multitienda.
- Visibilidad: en todas partes, solo catálogo, solo búsqueda o ninguna.
- Categoría por defecto activa.
- Disponibilidad por idioma y por tienda.
4. Categoría por defecto eliminada o desactivada
Si la URL de producto depende de la categoría y esa categoría se desactiva, se mueve o se elimina, pueden surgir rutas rotas. El producto quizá sigue existiendo, pero su mapa interno perdió una coordenada.
Esto suele verse después de limpiezas de catálogo: alguien elimina categorías “viejas” sin comprobar qué productos las usaban como categoría principal. Se barre el polvo y, sin querer, también la escalera.
5. Cambios de slug o nombre reescrito
El campo URL amigable o link_rewrite determina parte de la dirección del producto. Si cambias:
/87-cafetera-italiana.html
por:
/87-cafetera-moka-acero.html
la URL antigua puede quedar en 404 si no existe redirección. PrestaShop no siempre crea automáticamente redirecciones históricas para cada cambio de slug. Algunos módulos sí lo hacen; otros lo prometen con la solemnidad de un político en campaña.
6. Migraciones incompletas
Las migraciones de PrestaShop —de versión, dominio, hosting o estructura— son terreno fértil para 404. Los problemas más comunes:
- Dominio antiguo no redirigido correctamente.
- Base URI mal configurada.
- Rutas SEO distintas entre la tienda anterior y la nueva.
- IDs de productos cambiados.
- Slugs regenerados de forma masiva.
- Sitemap nuevo enviado antes de aplicar redirecciones.
- Módulos antiguos incompatibles con la versión actual.
Una migración sin mapa de redirecciones es como mudar una biblioteca lanzando los libros por la ventana y confiando en que caigan ordenados por autor.
Método profesional de diagnóstico paso a paso 🧪
Antes de corregir, hay que mirar. No adivinar. No “tocar un poquito aquí”. Mirar. La diferencia entre un arreglo técnico y una superstición con teclado está en el diagnóstico.
1. Recopila ejemplos concretos
Necesitas una lista de URLs afectadas. No basta con “hay muchos 404” o “Google dice duplicadas”. Extrae datos desde:
- Google Search Console: informes de indexación, páginas no encontradas, duplicadas sin URL canónica seleccionada por el usuario.
- Logs del servidor: solicitudes con código 404, user agents, frecuencia, origen.
- Crawlers SEO: Screaming Frog, Sitebulb, Ahrefs, Semrush, JetOctopus u otras herramientas.
- Sitemap XML: URLs enviadas oficialmente.
- Enlaces internos: menús, categorías, bloques, breadcrumbs, productos relacionados.
Si tienes acceso por consola, una comprobación rápida con curl ayuda mucho:
curl -I https://www.tienda.com/123-producto.html
Observa el código HTTP:
200: la página responde correctamente.301: redirección permanente.302: redirección temporal.404: no encontrada.410: recurso eliminado de forma permanente.500: error del servidor.
2. Comprueba si las URLs duplicadas muestran exactamente el mismo contenido
Dos URLs pueden parecer duplicadas pero no serlo del todo. Revisa:
- Título SEO.
- Meta description.
- H1.
- Producto mostrado.
- Precio.
- Idioma.
- Canonical.
- Breadcrumbs.
- Datos estructurados.
Si todo apunta al mismo producto y la única diferencia es la ruta, tienes un duplicado técnico. Si cambia el idioma o una variante sustancial, quizá el problema sea de hreflang, indexación o parametrización.
3. Revisa la URL canónica en el código fuente
Abre el código fuente de la página y busca:
<link rel="canonical" href="https://www.tienda.com/url-principal-del-producto" />
La canónica debe apuntar a la versión preferida. Si cada URL duplicada se declara canónica a sí misma, tienes señales contradictorias. Es como si tres personas se proclamaran simultáneamente jefes de cocina: puede salir comida, pero no esperes armonía.
4. Verifica la configuración de “Redirigir a URL canónica”
En muchas instalaciones de PrestaShop encontrarás una opción llamada Redirigir a URL canónica, normalmente en la sección de SEO y URLs. Puede ofrecer opciones como:
- No redirigir.
- Redirección temporal 302.
- Redirección permanente 301.
Para una tienda en producción, si la estructura definitiva ya está clara, suele convenir usar 301. Si estás probando cambios o no tienes certeza, evita decisiones permanentes precipitadas.
5. Inspecciona las rutas configuradas
En el back office, revisa la ruta de productos. En PrestaShop es frecuente ver patrones similares a:
{category:/}{id}-{rewrite}.html
O, según la instalación:
{id}-{rewrite}
Lo importante es comprobar que:
- La ruta contiene variables necesarias.
- No genera conflictos con categorías, CMS u otros recursos.
- No ha sido alterada por un módulo incompatible.
- Es coherente con el sitemap y los enlaces internos.
6. Comprueba la base de datos con prudencia
Antes de consultar o modificar la base de datos: realiza una copia de seguridad completa de archivos y base de datos. Una consulta mal ejecutada puede convertir un problema SEO en una tarde larga, amarga y muy cara.
En instalaciones avanzadas, puede ser útil revisar slugs repetidos o productos sin asociaciones correctas. El prefijo de tablas puede variar; aquí se usa ps_ como ejemplo.
Buscar slugs repetidos por idioma:
SELECT id_lang, link_rewrite, COUNT(*) AS total
FROM ps_product_lang
GROUP BY id_lang, link_rewrite
HAVING total > 1;
Comprobar productos activos por tienda:
SELECT p.id_product, ps.id_shop, ps.active, ps.id_category_default
FROM ps_product p
LEFT JOIN ps_product_shop ps ON p.id_product = ps.id_product
WHERE p.id_product = 123;
Revisar la URL de tienda en multitienda:
SELECT *
FROM ps_shop_url
WHERE active = 1;
No se trata de editar a ciegas. La base de datos es una radiografía, no un campo de batalla.
Soluciones prácticas para corregir URLs duplicadas y errores 404 en PrestaShop 🛠️
1. Regenera el archivo .htaccess
Si estás en Apache y las URLs amigables fallan, este es uno de los primeros pasos razonables:
- Accede al back office.
- Ve a Parámetros de la tienda > Tráfico y SEO.
- Desactiva temporalmente las URLs amigables y guarda.
- Vuelve a activarlas y guarda de nuevo.
- Borra la caché de PrestaShop.
- Comprueba varias URLs de productos y categorías.
También revisa permisos. El archivo .htaccess debe existir en la raíz correspondiente de la tienda y ser legible por el servidor. Si PrestaShop no puede escribirlo, los cambios no se aplicarán.
2. Revisa mod_rewrite o configuración Nginx
En Apache, confirma que mod_rewrite está activo y que la configuración del virtual host permite usar .htaccess, normalmente mediante AllowOverride.
En Nginx no se usa .htaccess. Las reglas deben estar en la configuración del servidor. Un patrón demasiado genérico puede provocar 404 o redirecciones inesperadas. No hay una regla universal que sirva para todas las tiendas, porque depende de la ruta de instalación, PHP-FPM, multitienda, idiomas y versión de PrestaShop.
Una configuración Nginx debe revisarse con documentación oficial, entorno de pruebas y logs abiertos. Improvisar aquí es tocar violín con guantes de boxeo.
3. Define una única versión del dominio
Elige una versión oficial:
https://www.tienda.com- o
https://tienda.com
Después fuerza redirecciones 301 desde las variantes no preferidas. Comprueba también:
- Dominio de la tienda.
- Dominio SSL.
- URI física.
- URI virtual, si aplica.
- Configuración del certificado SSL.
- Cloudflare, proxy o CDN, si existe.
Una tienda detrás de un CDN mal configurado puede generar bucles de redirección, mezclar HTTP y HTTPS o servir canónicas incorrectas. Y entonces el problema ya no está en PrestaShop, aunque PrestaShop cargue con la culpa, como suele pasar con el que da la cara.
4. Configura correctamente la URL canónica
Para productos accesibles desde varias rutas, la URL canónica debe apuntar siempre a la versión principal. En PrestaShop, esto suele depender del tema, del núcleo y de módulos SEO instalados.
Buenas prácticas:
- La URL canónica debe usar HTTPS.
- Debe apuntar a la versión con dominio preferido.
- No debe incluir parámetros innecesarios.
- No debe apuntar a una URL 404, 302 o bloqueada por robots.
- Debe ser coherente con el sitemap XML.
Regla de oro: el sitemap, los enlaces internos, la etiqueta canonical y las redirecciones deben contar la misma historia. Si cada uno dice algo distinto, Google escogerá por su cuenta. Y Google no siempre tiene tu plan de negocio sobre la mesa.
5. Corrige enlaces internos que apuntan a versiones antiguas
Una redirección 301 es útil, pero no debe ser una muleta eterna. Si tus menús, categorías, banners o módulos siguen enlazando a URLs viejas, estás haciendo que los usuarios y bots pasen por un desvío innecesario.
Revisa especialmente:
- Menú principal.
- Footer.
- Bloques HTML personalizados.
- Landings de campañas.
- Blogs integrados.
- Descripciones de categorías con enlaces manuales.
- Productos destacados y relacionados.
- Sitemap XML generado por módulos externos.
6. Actualiza el sitemap XML
El sitemap debe contener solo URLs canónicas, indexables y con respuesta 200. Si incluye productos desactivados, URLs antiguas o versiones duplicadas, estás enviando a Google una lista de deseos escrita con tinta invisible.
Después de corregir rutas y redirecciones:
- Regenera el sitemap XML.
- Comprueba manualmente algunas URLs.
- Envíalo en Google Search Console.
- Revisa si aparecen errores de procesamiento.
7. Limpia cachés
Tras cambios técnicos, limpia:
- Caché de PrestaShop.
- Caché del tema.
- Caché de módulos SEO o de rendimiento.
- Caché de servidor: Varnish, LiteSpeed Cache, FastCGI cache.
- CDN: Cloudflare, Bunny CDN, Akamai u otro.
- Caché del navegador al probar.
Más de una vez he visto una tienda “rota” durante media hora solo en el navegador del técnico. Pequeña escena doméstica: taza de café frío, tres pestañas de incógnito, un cliente al teléfono y el problema escondido en una caché que nadie había purgado. No es épico, pero es real.
Redirecciones 301, canonical, 404 o 410: qué usar en cada caso 🔁
Una de las decisiones más importantes es elegir la señal adecuada. No todo se arregla con una redirección. No todo debe llevar canonical. No todo 404 es malo. Aquí conviene ser quirúrgico.
| Caso | Qué usar | Motivo |
|---|---|---|
| Producto cambia de URL pero sigue existiendo | 301 desde URL antigua a nueva | Conserva señales SEO y evita pérdida de tráfico |
| Varias URLs muestran el mismo producto | Canonical y, si procede, 301 | Consolida la versión principal |
| Producto eliminado con sustituto claro | 301 a producto equivalente | Mejora experiencia y recupera autoridad |
| Producto eliminado sin sustituto pero categoría relevante | 301 a categoría relacionada, con criterio | Puede ser útil si la intención del usuario se mantiene |
| Producto obsoleto sin alternativa ni tráfico útil | 404 o 410 | Indica que el recurso ya no está disponible |
| Parámetros de filtros o tracking | Canonical, noindex en casos concretos, control de rastreo | Evita indexación de combinaciones innecesarias |
Cuándo usar 301
La redirección 301 indica que una URL se ha movido permanentemente. Es apropiada cuando:
- Cambiaste la URL amigable de un producto.
- Migraste de dominio.
- Pasaste de HTTP a HTTPS.
- Consolidaste versiones con y sin www.
- Eliminaste un producto pero existe un reemplazo muy similar.
Evita cadenas largas de redirecciones:
URL A → URL B → URL C → URL D
Lo ideal es:
URL A → URL D
Las cadenas ralentizan, confunden y desperdician rastreo. Son como hacer escala en tres aeropuertos para visitar al vecino.
Cuándo usar canonical
La etiqueta canonical es una sugerencia fuerte, no una orden absoluta. Sirve cuando varias URLs son accesibles pero quieres indicar cuál debe considerarse principal.
Úsala en:
- Productos visibles por rutas de categoría distintas.
- Variantes con parámetros que no cambian el contenido principal.
- Páginas ordenadas o filtradas que no deben competir con la URL principal.
No uses canonical para intentar salvar páginas rotas. Una canonical hacia una URL que devuelve 404 es un mensaje absurdo: “la versión oficial de esta página inexistente es otra página inexistente”. Pasa más de lo que debería.
Cuándo dejar 404
Un 404 puede estar bien si:
- La URL nunca debió existir.
- No tiene enlaces externos valiosos.
- No recibe tráfico relevante.
- No hay sustituto razonable.
Google acaba retirando de su índice las URLs 404 persistentes. No hace falta redirigir cada sombra del pasado. A veces limpiar también significa dejar que algo desaparezca.
Cuándo usar 410
El código 410 Gone indica que el recurso fue eliminado de forma permanente. Puede acelerar la desindexación en algunos casos, aunque no es obligatorio. Úsalo con criterio para productos retirados definitivamente, páginas generadas por error o URLs basura tras ataques, filtros mal indexados o módulos defectuosos.
Casos delicados: multitienda, idiomas, combinaciones y módulos SEO 🌐
Multitienda: cuando una tienda tiene varias personalidades
La funcionalidad de multitienda de PrestaShop es potente, pero exige disciplina. Un producto puede estar activo en una tienda y no en otra. Una URL puede pertenecer a un dominio, subdominio o carpeta específica. Una categoría puede existir en un contexto y estar ausente en otro.
Revisa:
- Asociación del producto con cada tienda.
- Dominio y dominio SSL por tienda.
- URI física y virtual.
- Categorías compartidas o independientes.
- Sitemaps separados por tienda.
- Canónicas que no crucen dominios por error.
Un fallo común: una ficha en tienda-a.com declara como canonical una URL de tienda-b.com. Técnicamente elegante, comercialmente suicida.
Idiomas y hreflang
Si vendes en varios idiomas, cada versión debe tener:
- URL propia y estable.
- Contenido traducido de verdad.
- Etiqueta
hreflangcorrecta. - Canonical hacia sí misma, no hacia otro idioma, salvo casos muy justificados.
El error clásico consiste en poner canonical de todas las versiones hacia el idioma principal. Eso puede hacer que Google ignore versiones internacionales. Es una forma muy refinada de invitar al mundo entero y luego cerrar la puerta salvo a los de casa.
Combinaciones de producto
Las combinaciones —talla, color, material— no suelen tener una URL independiente completa en PrestaShop, aunque pueden generar parámetros o anclas. Algunos módulos crean URLs específicas para variantes. Esto puede ser útil si cada variante tiene demanda SEO diferenciada, por ejemplo “zapatillas rojas talla 42” o “sofá verde terciopelo”. Pero si se generan cientos de páginas casi idénticas, el catálogo se infla como pan mal fermentado.
Decide si las variantes deben:
- Consolidarse en una única ficha de producto.
- Tener canonical hacia el producto principal.
- Ser indexables solo cuando tengan contenido, stock y demanda propia.
Módulos para quitar IDs de las URLs
Eliminar IDs puede mejorar la estética de las URLs, pero en PrestaShop no es una decisión trivial. Si se hace mal, aparecen:
- Conflictos entre slugs iguales.
- 404 intermitentes.
- Problemas al importar productos.
- Redirecciones duplicadas.
- Sitemaps incoherentes.
- Errores tras actualizar PrestaShop.
Si usas un módulo de este tipo, verifica que:
- Sea compatible con tu versión exacta de PrestaShop.
- Genere redirecciones desde URLs antiguas con ID.
- Resuelva slugs duplicados.
- No rompa categorías, fabricantes ni CMS.
- No afecte al checkout, al buscador ni a módulos de terceros.
- Tenga soporte activo.
Procedimiento recomendado para reparar una tienda ya afectada 🧭
Si ya tienes URLs duplicadas y 404 en producción, sigue un orden. En asuntos técnicos, el orden no es burocracia; es supervivencia.
- Haz copia de seguridad completa: archivos y base de datos.
- Exporta datos actuales: sitemap, URLs con tráfico, URLs con errores en Search Console, logs 404.
- Clasifica las URLs: duplicadas, productos eliminados, slugs antiguos, errores de servidor, parámetros.
- Define la estructura oficial: dominio, HTTPS, patrón de rutas, idioma, con o sin ID.
- Corrige configuración de PrestaShop: URLs amigables, canonical, rutas, dominio, SSL.
- Regenera
.htaccesso ajusta Nginx: según servidor. - Aplica redirecciones 301: desde URLs antiguas relevantes hacia destinos correctos.
- Corrige enlaces internos: no dependas solo de redirecciones.
- Regenera sitemap: incluye solo URLs finales, canónicas y con código 200.
- Limpia cachés: aplicación, servidor y CDN.
- Rastrea de nuevo: comprueba códigos HTTP, canonical, indexabilidad y profundidad de clic.
- Valida en Search Console: solicita reindexación de páginas importantes y monitoriza evolución.
Qué revisar en Google Search Console 📊
Search Console no muestra todo ni lo muestra siempre en tiempo real, pero ofrece pistas valiosas. Presta atención a estos informes:
- No se ha encontrado 404: URLs que Google intentó rastrear y no encontró.
- Duplicada: Google eligió una canónica diferente a la del usuario: señal de que tus canónicas no convencen o tus enlaces internos contradicen.
- Duplicada sin URL canónica seleccionada por el usuario: páginas similares sin señal clara.
- Rastreada actualmente sin indexar: puede indicar baja calidad, duplicidad o poca relevancia.
- Descubierta actualmente sin indexar: posible problema de rastreo, rendimiento o prioridad.
- Página con redirección: normal si son URLs antiguas, preocupante si el sitemap las sigue enviando.
Cuando corrijas un lote de URLs, no esperes milagros en veinticuatro horas. Google rastrea según prioridad, autoridad, frecuencia de cambio y señales internas. La paciencia aquí no es resignación; es parte del proceso.
Errores comunes que conviene evitar 😬
- Redirigir todos los 404 a la home: mala experiencia, señal confusa y práctica poco recomendable.
- Bloquear en robots.txt URLs duplicadas que necesitan canonical: si Google no puede rastrearlas, quizá no vea la canonical.
- Enviar en el sitemap URLs redirigidas: el sitemap debe mostrar destinos finales.
- Cambiar la estructura de URLs varias veces: cada cambio obliga a Google a recalcular señales.
- Eliminar IDs sin estrategia: especialmente peligroso en catálogos grandes.
- Ignorar enlaces internos antiguos: una redirección no sustituye una arquitectura limpia.
- No probar en staging: la tienda en producción no debe ser un laboratorio con caja registradora.
- Actualizar módulos SEO sin revisar rutas: algunas actualizaciones cambian comportamientos de URL.
- Olvidar idiomas y multitienda: lo que funciona en una tienda puede romper otra.
Cómo prevenir futuros duplicados y 404 en PrestaShop ✅
La prevención no tiene glamour. No aparece en capturas bonitas ni se vende como “hack definitivo”. Pero sostiene el negocio. Una tienda técnicamente estable es como una carretera bien asfaltada: nadie la celebra cuando funciona, todos la maldicen cuando se rompe.
1. Define una política de URLs
Antes de modificar rutas, decide:
- Si usarás IDs en productos.
- Si incluirás categoría en la URL.
- Si habrá sufijo
.htmlo no. - Cómo se gestionarán idiomas.
- Qué dominio será el principal.
- Qué hacer con productos descatalogados.
Documenta esa política. No hace falta un tratado, basta con un documento claro. El futuro desarrollador, el responsable SEO y tu yo de dentro de seis meses lo agradecerán.
2. Crea redirecciones al cambiar slugs o eliminar productos
Cada vez que cambies una URL relevante, crea una redirección 301. Si eliminas un producto, decide si debe ir a:
- Un producto equivalente.
- Una categoría superior.
- Una página de marca.
- Un 404 o 410 si no hay alternativa útil.
No redirijas por redirigir. La intención del usuario manda. Si alguien busca una batería para un modelo concreto, enviarlo a la home no es ayuda; es una evasiva.
3. Audita la tienda periódicamente
Programa rastreos mensuales o trimestrales, según el tamaño del catálogo. Revisa:
- URLs con estado 404.
- Redirecciones 301 y cadenas.
- Canónicas incorrectas.
- Páginas duplicadas por título o H1.
- Sitemap XML.
- Enlaces internos rotos.
- URLs con parámetros indexables.
- Páginas huérfanas.
4. Controla importaciones masivas
Muchas tiendas PrestaShop se alimentan mediante CSV, ERP, PIM o integraciones con proveedores. Ahí pueden nacer slugs duplicados, productos sin categoría, nombres reescritos vacíos o cambios de ID.
Antes de importar:
- Valida campos obligatorios.
- Normaliza slugs.
- Evita caracteres problemáticos.
- Comprueba categorías por defecto.
- Detecta duplicados.
- Prueba con un lote pequeño.
5. Mantén módulos y tema bajo control
Actualiza, sí. Pero no a ciegas. Cada módulo que toca SEO, URLs, filtros, sitemap, caché o redirecciones debe probarse antes. Una actualización puede corregir una vulnerabilidad y, al mismo tiempo, cambiar la forma en que se generan enlaces. Antítesis pura: más seguridad, menos estabilidad; mejor código, peor noche.
6. Monitoriza logs del servidor
Los logs son menos vistosos que un panel SEO, pero más sinceros. Te dicen qué piden los bots, qué URLs fallan, cuántas veces, desde dónde y con qué frecuencia. Si Search Console es el parte médico, los logs son el pulso.
Busca patrones como:
- 404 repetidos sobre productos antiguos.
- Rastreo excesivo de parámetros.
- URLs generadas por bots maliciosos.
- Rutas con mayúsculas y minúsculas mezcladas.
- Errores después de campañas o newsletters.
Checklist rápido para técnicos y responsables de tienda 📝
- ¿La tienda fuerza HTTPS con redirección 301?
- ¿Solo una versión del dominio responde como principal?
- ¿Las URLs amigables están activas y funcionan?
- ¿El archivo
.htaccessestá regenerado y actualizado? - ¿Nginx tiene reglas compatibles con PrestaShop, si aplica?
- ¿La ruta de producto incluye variables seguras como el ID?
- ¿La categoría por defecto del producto está activa?
- ¿Los productos afectados están activos y asociados a la tienda correcta?
- ¿Las canónicas apuntan a URLs 200, indexables y finales?
- ¿El sitemap contiene solo URLs canónicas?
- ¿Hay redirecciones 301 desde URLs antiguas con tráfico o enlaces?
- ¿Se han eliminado cadenas de redirecciones?
- ¿Los módulos SEO están actualizados y son compatibles?
- ¿Los filtros y parámetros están controlados?
- ¿Search Console muestra menos errores tras las correcciones?
Una forma sensata de mirar el problema
Las URLs duplicadas en PrestaShop y los errores 404 de productos rara vez son un único fallo aislado. Son más bien pequeñas grietas en la arquitectura: una ruta cambiada, una categoría desactivada, una canonical tímida, un módulo que improvisa, una migración con prisas. Nada dramático al principio. Luego Google indexa, los usuarios hacen clic, las campañas empujan tráfico, y la grieta se convierte en gotera.
La solución profesional no consiste en tapar todo con redirecciones ni en instalar otro módulo esperando que traiga orden como quien llama a un exorcista. Consiste en entender cómo PrestaShop construye sus URLs, elegir una estructura estable, alinear servidor, tienda, sitemap, canonical y enlaces internos, y medir después. Técnica con paciencia. SEO con criterio. Mantenimiento con memoria.
Una tienda online sana no es la que nunca cambia, sino la que cambia sin perder sus caminos. Que cada producto tenga una dirección clara. Que cada URL antigua sepa a dónde ir. Que cada 404 tenga una razón. Y que Google, ese visitante incansable y algo maniático, encuentre el catálogo tan ordenado por dentro como atractivo por fuera. 🛍️✨