≡En resumen
- Reescribir es traducir la URL por dentro; redirigir es pedir al navegador que vaya a otra URL.
- Gracias a la reescritura, un CMS o un framework puede mostrar URL legibles sin tener un archivo por página.
- En Apache se hace con mod_rewrite; en Nginx, con try_files o rewrite; en los frameworks, con el sistema de rutas.
- Una misma regla puede reescribir o redirigir según su bandera: el detalle cambia por completo el efecto en SEO.
- Si después de reescribir sigue respondiendo la URL técnica antigua, tienes contenido duplicado: redirígela con 301.
01 ¿Qué es el URL rewriting?
La reescritura es lo que hace posible que un gestor de contenidos muestre direcciones legibles sin crear una carpeta por página. Por eso está detrás de cualquier URL friendly de WordPress, PrestaShop o una aplicación a medida.
También sirve para mantener URL estables aunque cambie la tecnología: si una web pasa de archivos .php a un framework moderno, puede seguir respondiendo en las mismas direcciones públicas y ahorrarse cientos de redirecciones.
02 Reescritura de URL frente a redirección
| Aspecto | Reescritura (rewrite) | Redirección (redirect) |
|---|---|---|
| Dónde ocurre | Dentro del servidor | Entre servidor y navegador |
| Barra de direcciones | No cambia | Muestra la nueva URL |
| Peticiones | Una | Dos o más |
| Código HTTP | El de la página final, normalmente 200 | 301, 302, 307 o 308 |
| Qué indexa Google | La URL que pidió el usuario | Normalmente el destino, si es permanente |
| Uso típico | URL amigables, front controller, ocultar la estructura interna | Traslados, cambios de dominio, unificar variantes |
03 URL rewriting en Apache con mod_rewrite
En Apache, la reescritura la hace el módulo mod_rewrite. Se activa con RewriteEngine On y se define con dos directivas: RewriteCond, que pone condiciones, y RewriteRule, que indica el patrón, la sustitución y unas banderas entre corchetes. Las reglas pueden ir en la configuración del servidor o en archivos .htaccess.
RewriteEngine OnRewriteBase /RewriteRule ^index\.php$ - RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php
Traducción: si la petición no corresponde a un archivo ni a una carpeta reales, pásala a index.php. WordPress lee la URL original y decide qué entrada mostrar.
[L]
Last: deja de procesar más reglas si esta se cumple.
[R=301]
Convierte la regla en una redirección externa con el código indicado.
[PT]
Pass through: entrega la URL reescrita a otros módulos, como Alias.
[QSA] y [NC]
QSA añade la consulta original a la nueva; NC hace que el patrón no distinga mayúsculas.
04 URL rewriting en Nginx: try_files y rewrite
Nginx no lee archivos .htaccess: las reglas van en la configuración del servidor. Para el caso más común, enviar a la aplicación todo lo que no sea un archivo real, se usa try_files. Es la configuración que propone la documentación de Laravel.
location / { try_files $uri $uri/ /index.php?$query_string;}
Nginx comprueba si existe el archivo, luego la carpeta, y si no, pasa la petición a index.php conservando la consulta.
Para cambios de ruta más complejos está rewrite, con cuatro banderas: last y break reescriben internamente; redirect devuelve un 302 y permanent un 301. Para redirecciones puras, return 301 https://…; es más claro y eficiente.
05 Routing en frameworks: la reescritura se muda al código
En las aplicaciones modernas el servidor solo hace una reescritura mínima: todo va al controlador frontal (public/index.php en Laravel). A partir de ahí, el sistema de rutas del framework compara la URL con las rutas declaradas y decide qué código ejecutar. Es la misma idea que el URL rewriting, pero escrita en PHP, JavaScript o Python en lugar de en expresiones regulares del servidor.
Route::get('/zapatillas/{slug}', [ProductController::class, 'show'])->where('slug', '+');
Hace el mismo trabajo que una RewriteRule con el patrón ^zapatillas/(+)/?$, pero con acceso a la base de datos, validación y respuesta 404 si el producto no existe.
Ventaja: control
Las rutas viven en el repositorio, se prueban y se versionan como el resto del código.
Ventaja: 404 reales
El framework sabe si el contenido existe y puede devolver el código correcto.
Riesgo: rutas duplicadas
Dos rutas pueden servir el mismo contenido si nadie define una política de URL.
Riesgo: SEO olvidado
Sin criterio, acaban publicadas rutas como /product/482 en vez de slugs legibles.
06 Cómo crear una regla de reescritura paso a paso
-
1
Define la URL pública
Escribe cómo quieres que se vea la dirección, por ejemplo /blog/mi-articulo/, y qué parte es variable (el slug).
-
2
Identifica la ruta interna
Localiza qué script y parámetros necesita la aplicación, por ejemplo /post.php?slug=mi-articulo.
-
3
Escribe el patrón
Traduce la parte variable a una expresión regular acotada, como ([a-z0-9-]+), sin capturar más de lo necesario.
-
4
Prueba en local o en preproducción
Comprueba con varias URL, incluidas las que no deben coincidir, que la respuesta es 200 y que no aparecen bucles.
-
5
Redirige la URL antigua
Si la ruta técnica ya estaba indexada, añade un 301 desde ella a la nueva URL pública para no duplicar contenido.
-
6
Actualiza enlaces y sitemap
Que menús, enlaces internos y sitemap usen ya la URL reescrita.
07 Errores habituales al reescribir URL
- ✓Reescribir a URL amigables y dejar la URL técnica antigua respondiendo con 200: dos URL con el mismo contenido.
- ✓Olvidar la bandera [L] y encadenar reglas que se pisan entre sí.
- ✓Expresiones regulares demasiado amplias que capturan también imágenes, CSS o la carpeta de administración.
- ✓Perder la consulta (?utm_source=…) al reescribir o redirigir.
- ✓Confundir reescritura con enmascaramiento: mostrar un dominio con el contenido de otro es URL masking, no rewriting.
- ✓Probar las reglas directamente en producción, donde un bucle tumba toda la web.
En appyweb configuramos rutas y reglas de servidor como parte del desarrollo web a medida, y revisamos las de webs existentes en cada auditoría SEO técnica, porque una regla mal escrita puede duplicar o esconder cientos de páginas y lastrar todo el posicionamiento web.
Preguntas frecuentes sobre URL rewriting
Es la reescritura de URL: el servidor transforma internamente la URL pedida en otra ruta o script antes de procesarla, sin que el navegador cambie de dirección.
La reescritura ocurre dentro del servidor y el usuario sigue viendo la misma URL; la redirección responde con un código 3xx y el navegador pide otra URL distinta.
Sirve para mostrar URL amigables desde aplicaciones que funcionan con scripts y parámetros, enviar todas las peticiones a un controlador frontal y mantener direcciones públicas estables aunque cambie la tecnología.
Con el módulo mod_rewrite habilitado, la línea RewriteEngine On y las reglas RewriteRule y RewriteCond en la configuración del servidor o en un archivo .htaccess.
No. Nginx no lee .htaccess; las reglas se escriben en su configuración con try_files, rewrite y return.
Es un único punto de entrada, normalmente index.php, al que el servidor envía todas las peticiones que no son archivos reales. Desde ahí el framework decide qué página mostrar según la URL.
Positivamente si produce URL legibles y únicas. Negativamente si deja activas las URL antiguas sin redirigir o si genera varias rutas para el mismo contenido.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗