Evitar errores con URL amigables en Prestashop y WordPress

Los errores con URL amigables en Prestashop y WordPress suelen aparecer cuando varias instalaciones comparten dominio, subdirectorios o reglas de reescritura. El problema no siempre está en el mismo punto: a veces falla el CMS, a veces el .htaccess y otras veces la configuración del servidor.

Esto se ve mucho en escenarios como estos:

• dominio.com en producción y dominio.com/blog para WordPress
• dominio.com con WordPress y dominio.com/tienda con PrestaShop
• una instalación principal y otra en dominio.com/pruebas

En todos ellos, el síntoma suele ser parecido: la portada carga, pero las URLs internas devuelven 404, se crean bucles, las redirecciones pisan otra instalación o el cambio solo funciona en Apache y no en nginx.

Aquí vamos a centrarnos en diagnosticar qué está fallando y cómo corregirlo sin mezclar soluciones que solo sirven en casos concretos.

Tabla de Contenidos:

Por qué fallan las URL amigables en WordPress y PrestaShop

Las URL amigables funcionan gracias a una capa de reescritura. El CMS recibe una URL limpia, como /blog/mi-articulo/ o /tienda/camiseta-azul.html, y la traduce a su ruta interna real.

Cuando esa traducción falla, el error suele venir de uno de estos frentes:

• El CMS no ha regenerado bien sus reglas
• La ruta base no coincide con la carpeta real
• El servidor no está aplicando la reescritura como espera el CMS
• Otra instalación del mismo dominio está interfiriendo

WordPress y PrestaShop no fallan exactamente igual.

WordPress depende mucho de los enlaces permanentes y, en Apache, del bloque correcto en .htaccess. PrestaShop genera su propio .htaccess desde el panel y además necesita que la tienda tenga bien resueltas su URL principal, su ruta física y sus redirecciones.

La parte importante es esta: una URL amigable rota no significa automáticamente que el .htaccess esté mal. También puede haber un ajuste incorrecto dentro del CMS, una instalación movida a un subdirectorio sin terminar de ajustar o un servidor nginx intentando resolver una configuración pensada para Apache.

Errores más comunes al usar WordPress y PrestaShop en el mismo dominio

El patrón se repite bastante cuando varias aplicaciones conviven dentro del mismo dominio.

dominio.com y /blog

Aquí suele haber una instalación principal en la raíz y WordPress en /blog.

Los fallos típicos son estos:

• La raíz responde bien, pero /blog/entrada/ devuelve 404
• WordPress genera enlaces con una base incorrecta
• El .htaccess de la raíz redirige o reescribe antes de que WordPress procese su parte
• En nginx no existe un bloque específico para /blog/

dominio.com y /tienda

Este caso es muy habitual cuando la web corporativa va por un lado y la tienda por otro.

Los errores más comunes son:

• PrestaShop genera URLs simplificadas, pero el servidor no las resuelve
• La tienda arranca en /tienda, pero algunas rutas intentan abrirse desde la raíz
• Aparecen 404 en productos o categorías después de cambiar la configuración SEO
• Una redirección global en la raíz pisa las rutas de la tienda

Instalación principal y /pruebas

Es el escenario más delicado porque se mezclan producción, staging y reglas heredadas.

Aquí conviene revisar sobre todo:

• Si la instalación de pruebas está indexando o redirigiendo como si fuera la principal
• Si comparte reglas de reescritura que no debería
• Si la URL base de la copia sigue apuntando al dominio principal
• Si hay caché o redirecciones antiguas todavía activas

En algunos montajes de Apache aparece la directiva RewriteOptions IgnoreInherit. Hay que tratarla como un caso técnico concreto, no como una receta universal. Si el problema real está en la URL base del CMS, en los enlaces permanentes o en nginx, esa línea no te va a arreglar nada por sí sola.

Cómo detectar si el problema está en .htaccess, en el CMS o en el servidor

Lo más útil es seguir un orden y no empezar tocando reglas a ciegas.

1. Comprueba si falla toda la web o solo las URLs internas

Si la portada carga y el panel de administración también, pero fallan entradas, productos o categorías, lo normal es que el problema esté en la reescritura y no en PHP ni en la base de datos.

Si falla todo, el problema puede ser más amplio: ruta rota, dominio mal resuelto, error 500 o configuración del servidor.

2. Revisa primero el CMS

Antes de editar archivos, entra en el panel.

En WordPress, vuelve a guardar los enlaces permanentes en Ajustes > Enlaces permanentes.

En PrestaShop, revisa SEO y URLs y vuelve a regenerar el archivo .htaccess si procede. Si necesitas repasar la parte más básica, puedes echarle un vistazo a nuestro post sobre cómo activar URLs amigables en PrestaShop.

Si con eso vuelve a funcionar, el problema estaba en el CMS o en un archivo no actualizado.

3. Revisa el archivo .htaccess desde Plesk

En Loading, lo lógico es empezar por el Administrador de archivos de Plesk.

Busca estas señales:

• Que el archivo exista en la carpeta correcta
• Que no haya un bloque de WordPress copiado en la instalación equivocada
• Que no existan redirecciones globales demasiado agresivas
• Que PrestaShop no tenga mezcladas reglas manuales dentro de su bloque autogenerado

Un bloque básico y correcto de WordPress en Apache suele verse así:

# 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

Si WordPress está en /blog, la base debe reflejarlo:

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

4. Distingue Apache de nginx

Este punto ahorra mucho tiempo.

Si el servidor usa Apache, .htaccess y mod_rewrite importan.

Si el servidor usa nginx, .htaccess no se interpreta. En ese caso la lógica tiene que estar en la configuración del servidor, no en el archivo del CMS.

Un ejemplo muy básico en nginx para una instalación en /blog sería este:

location /blog/ {
    try_files $uri $uri/ /blog/index.php?$args;
}

Y para una tienda en /tienda:

location /tienda/ {
    try_files $uri $uri/ /tienda/index.php?$args;
}

Si en nginx tocas .htaccess y no pasa nada, eso es normal. Ese archivo no se está usando.

5. Si el panel no abre, revisa la URL base en phpMyAdmin

Cuando no puedes entrar al CMS, la pista puede estar en la base de datos.

En WordPress, revisa siteurl y home en la tabla wp_options.

En PrestaShop, revisa domain, domain_ssl y physical_uri en ps_shop_url.

Si estos valores apuntan a la raíz cuando la instalación vive en /blog, /tienda o /pruebas, las URL amigables van a salir mal aunque el .htaccess esté perfecto.

Errores habituales de URL amigables en WordPress

WordPress suele fallar por cuatro motivos muy concretos.

Enlaces permanentes cambiados pero reglas no aplicadas

Es el clásico. Cambias la estructura, guardas, y las entradas devuelven 404.

En Apache, WordPress necesita poder escribir o al menos mostrar las reglas correctas. Si tu instalación no puede actualizar el archivo automáticamente, tendrás que revisar el bloque manualmente.

La documentación oficial de WordPress explica cómo se comportan los enlaces permanentes y qué ocurre cuando la estructura cambia. Si además estás moviendo la instalación a una carpeta propia o sirviendo la web desde raíz con WordPress en subdirectorio, también conviene revisar la guía oficial de WordPress sobre instalaciones en directorio propio.

WordPress en subdirectorio con dirección mal configurada

Aquí se mezclan dos campos distintos:

• Dirección de WordPress
• Dirección del sitio

Si WordPress está físicamente en /blog pero alguna de esas URLs sigue apuntando a la raíz, empiezan los fallos de enlaces permanentes, las redirecciones raras y los recursos cargados desde rutas incorrectas.

Si trabajas con un entorno optimizado de hosting WordPress, esta parte suele venir más encauzada, pero aun así hay que revisar la ruta cuando mueves instalaciones o clonas una web a /pruebas.

.htaccess correcto para raíz, pero incorrecto para /blog

Copiar el bloque de una instalación en raíz dentro de otra que vive en subdirectorio rompe muchas rutas.

Por ejemplo, si WordPress vive en /blog, no deberías dejar una base como esta:

RewriteBase /
RewriteRule . /index.php [L]

Lo coherente sería ajustar la base a la carpeta real:

RewriteBase /blog/
RewriteRule . /blog/index.php [L]

Nginx sin try_files para la instalación concreta

Si la portada carga pero las entradas no, y el servidor usa nginx, el error suele estar aquí.

WordPress necesita una regla que envíe las rutas no resueltas a index.php. Si no existe, la URL amigable termina en 404 aunque la configuración del CMS sea correcta.

Un ejemplo mínimo sería este:

location /blog/ {
    try_files $uri $uri/ /blog/index.php?$args;
}

Redirecciones antiguas o pruebas mal clonadas

Cuando copias una web a /pruebas, es fácil arrastrar:

• Redirecciones al dominio principal
• URLs absolutas antiguas
• Caché de plugins o del propio servidor
• reglas que fuerzan HTTPS, www o una ruta antigua

Si el error aparece solo en la copia, piensa primero en configuración arrastrada, no en el CMS desde cero.

Errores habituales de URL amigables en PrestaShop

En PrestaShop el patrón cambia un poco. Aquí el fallo suele estar en la regeneración del archivo, en la URL de tienda o en rutas que se pisan con otra instalación.

URL simplificadas activadas, pero sin efecto real

Puedes activar la opción en el panel y seguir viendo errores 404 si el servidor no aplica la reescritura o si el archivo generado no está donde toca.

Lo correcto es empezar por el back office y no por editar a mano. Revisa SEO y URLs, guarda cambios y, si hace falta, regenera el archivo .htaccess.

Si tu tienda está en un entorno específico de hosting PrestaShop, esta parte suele ser más previsible, pero los fallos siguen apareciendo cuando la tienda comparte dominio con otra aplicación o cuando se mueve a /tienda o /pruebas.

Tocar a mano el bloque que PrestaShop genera automáticamente

Aquí hay un error muy común: editar dentro del bloque que PrestaShop reconstruye.

La propia documentación de PrestaShop recuerda que el .htaccess se genera automáticamente y que ese bloque no conviene tocarlo a mano. Puedes revisarlo en la guía oficial sobre el archivo .htaccess de PrestaShop.

El bloque suele ir delimitado con comentarios de este tipo:

# ~~start~~ Do not remove this comment, PrestaShop uses it to build your .htaccess file
...
# ~~end~~

Si necesitas una redirección puntual, es mejor dejarla fuera de ese bloque y probarla con cuidado.

Por ejemplo:

Redirect 301 /categoria-antigua.html /categoria-nueva.html

La tienda vive en /tienda, pero la URL base sigue apuntando a la raíz

Este error da síntomas muy claros:

• Productos que abren mal
• Categorías con 404
• Imágenes o recursos que se llaman desde rutas incorrectas
• Redirecciones que te sacan de /tienda

Si el back office no carga, revisa ps_shop_url en phpMyAdmin y confirma que physical_uri apunta a /tienda/ o a la carpeta real que corresponda.

Productos y categorías que cambian de URL sin redirección

PrestaShop puede resolver bien la estructura general y aun así dejarte 404 concretos en productos, categorías o páginas CMS.

Suele pasar cuando:

• Cambias el slug
• Desactivas un producto sin revisar su destino
• Borras categorías o fichas antiguas
• Mueves la tienda entre producción y pruebas

Aquí no basta con que la URL amigable funcione. También necesitas que la tienda redirija correctamente y no deje rutas huérfanas.

Conflictos entre la tienda principal y una copia en /pruebas

Si has clonado una tienda para probar cambios, revisa esto antes de culpar a las URL simplificadas:

• dominio y SSL en la copia
• physical_uri
• caché de PrestaShop
• reglas manuales heredadas del entorno principal

En este escenario es muy fácil que la copia intente comportarse como la tienda original.

Apache y nginx no gestionan las URL amigables de la misma forma

Este es uno de los errores de enfoque más habituales.

En Apache sí cuentan .htaccess y mod_rewrite

Cuando trabajas sobre Apache, WordPress y PrestaShop dependen de reglas de reescritura para convertir URLs limpias en rutas internas válidas.

Eso significa que aquí sí tiene sentido revisar:

• RewriteEngine On
• RewriteBase
• reglas de paso a index.php
• redirecciones manuales mal colocadas

En nginx la lógica va en el servidor

nginx no lee .htaccess.

Por eso, si migras una instalación que funcionaba en Apache y copias solo el CMS, puedes encontrarte con una web que carga la portada pero rompe todas las URLs internas. No faltan reglas en el CMS. Faltan reglas en nginx.

Dónde encaja RewriteOptions IgnoreInherit

Esta directiva merece una aclaración, porque viene del caso original del post.

RewriteOptions IgnoreInherit no arregla cualquier conflicto entre raíz y subdirectorios. En Apache se usa para evitar la herencia de reglas cuando existe una configuración padre que está propagando reglas de reescritura a niveles inferiores, por ejemplo con InheritDown o InheritDownBefore.

Un esquema simplificado sería este:

# Contexto padre
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions InheritDown
</IfModule>

# Contexto hijo
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions IgnoreInherit
</IfModule>

¿Cuándo tiene sentido?

• Cuando sabes que existe herencia real de reglas
• Cuando el conflicto está en Apache
• Cuando la instalación hija necesita aislar su propia lógica de reescritura

¿Cuándo no te va a sacar del problema?

• Si el error está en siteurl, home o ps_shop_url
• Si el servidor es nginx
• Si el bloque de WordPress o PrestaShop apunta a una base incorrecta
• Si una copia en /pruebas sigue usando el dominio de producción

Dicho de forma simple: puede ser útil en un caso concreto, pero no sustituye al diagnóstico.

Conclusión

Cuando WordPress y PrestaShop comparten dominio o subdirectorios, los errores de URL amigables casi nunca se resuelven bien con una única línea copiada de otro sitio.

Lo que mejor funciona es revisar el problema por capas: CMS, ruta base, .htaccess si hay Apache, configuración del servidor si hay nginx y valores guardados en base de datos. A partir de ahí ya puedes corregir el origen real del fallo, tanto en dominio.com/blog como en dominio.com/tienda o en una copia dentro de /pruebas.

Preguntas frecuentes sobre URL amigables en Prestashop y WordPress (FAQ)

Síguenos en:

• Facebook
• Instagram
• Twitter