# Cómo redirigir con 301 las páginas de paginación en WordPress sin afectar a las búsquedas internas
- Link: https://binariocero.com/linux/como-redirigir-con-301-las-paginas-de-paginacion-en-wordpress-sin-afectar-a-las-busquedas-internas
- Published: 2026-09-19T10:44:00+02:00
- Author: Juan José Fernández Durán
Si administras un sitio en WordPress y quieres eliminar las páginas de paginación
antiguas (por ejemplo, `ejemplo.com/page/2`, `ejemplo.com/page/3`, etc.) redirigiéndolas
con un 301 hacia la portada, hay un detalle importante que se suele pasar por alto:**
no todas las URLs que contienen `/page/N/` son iguales**. Algunas corresponden a
resultados de búsqueda internos del sitio (como `ejemplo.com/page/2?s=cocina`),
y normalmente **no** interesa redirigir esas, porque forman parte de la funcionalidad
del buscador y no de la paginación del blog.
#### El problema
Una regla de redirección demasiado genérica en el `.htaccess` capturaría ambos casos
por igual:
* `ejemplo.com/page/2` → paginación del blog (esta sí queremos redirigir)
* `ejemplo.com/page/2?s=cocina` → resultado de búsqueda en la página 2 (esta no
debería redirigirse)
Si no se distingue entre ambas, se rompe la funcionalidad de búsqueda del sitio
cada vez que un usuario navega a la segunda página de resultados.
#### La solución
La clave está en usar una condición de reescritura (`RewriteCond`) que compruebe
si la URL tiene o no una cadena de consulta (_query string_). Si no la tiene, es
paginación pura; si la tiene, probablemente es una búsqueda u otro parámetro que
debe respetarse.
apache
```wp-block-code
# BEGIN Redirect paginacion a home
RewriteEngine On
RewriteCond %{QUERY_STRING} ^$
RewriteRule ^page/([0-9]+)/?$ https://ejemplo.com/ [R=301,L]
# END Redirect paginacion a home
```
Este bloque debe colocarse en el `.htaccess`, **antes** del bloque `# BEGIN WordPress`
que WordPress genera automáticamente, ya que Apache procesa las reglas en el orden
en que aparecen.
#### Cómo funciona cada línea
* **``**: envuelve la regla para que, si por algún motivo
el módulo `mod_rewrite` no estuviera disponible en el servidor, Apache simplemente
ignore el bloque en lugar de devolver un error 500. Es el mismo patrón que usa
WordPress en sus propias reglas.
* **`RewriteCond %{QUERY_STRING} ^$`**: esta es la condición que marca la diferencia.
Solo permite que la regla siguiente se aplique cuando la cadena de consulta está
vacía, es decir, cuando no hay parámetros como `?s=cocina` al final de la URL.
* **`RewriteRule ^page/([0-9]+)/?$ ...`**: detecta cualquier ruta del tipo `page/
2`, `page/15`, etc. (con o sin barra final) y la redirige.
* **`[R=301,L]`**: indica que es una redirección permanente (301) y que Apache
debe dejar de procesar más reglas después de esta (`L` de _last_).
#### Resultado
Con esta configuración:
| URL | ¿Se redirige? |
| `ejemplo.com/page/2` | Sí → `ejemplo.com/` |
| `ejemplo.com/page/2/` | Sí → `ejemplo.com/` |
| `ejemplo.com/page/2?s=cocina` | No, se respeta |
| `ejemplo.com/page/2?utm_source=x` | No, se respeta (cualquier query string la excluye) |
#### Recomendaciones antes de aplicarlo
1. **Haz una copia de seguridad** del `.htaccess` original antes de modificarlo.
2. Si usas un **plugin de caché o de reglas de reescritura** (LiteSpeed Cache, WP
Rocket, etc.), comprueba que no sobrescriba tu bloque personalizado al regenerar
las reglas de permalinks.
3. Prueba ambos escenarios en modo incógnito tras el cambio: una URL de paginación
pura y una de búsqueda, para confirmar que el comportamiento es el esperado.
4. Ten en cuenta que un 301 es una redirección **permanente**: los navegadores y motores
de búsqueda la memorizan. Si más adelante necesitas revertirla, tendrás que limpiar
la caché del navegador o esperar a que expire.