---
title: "Permalinks en WordPress: qué estructura usar y cómo cambiarla sin perder SEO"
description: "Qué estructura de enlaces permanentes elegir en WordPress, cómo escribir buenos slugs y cómo cambiar las URL de un sitio publicado con redirecciones 301 en Apache y Nginx sin llenarlo de errores 404."
url: https://wpdirecto.com/permalinks-wordpress-seo-estructura-redirecciones/
date: 2026-11-10
modified: 2026-11-05
author: "Editor WPDirecto"
image: https://wpdirecto.com/wp-content/uploads/2026/11/ai-photorealistic-aerial-view-of-a-city-road-interchange-at-gol-1T5wlW.png
categories: ["Guías", "SEO y marketing"]
tags: ["error 404", "htaccess", "nginx", "permalinks", "redirecciones 301", "seo", "URLs"]
type: post
lang: es
---

# Permalinks en WordPress: qué estructura usar y cómo cambiarla sin perder SEO

**La estructura de los enlaces permanentes (permalinks) de WordPress se fija en Ajustes > Enlaces permanentes y conviene decidirla antes de publicar, porque cambiarla después modifica las URL de todo el contenido y obliga a redirigir cada dirección antigua con un 301 para no perder visitas ni posicionamiento.** La mayoría de los problemas que aparecen tras el cambio, como los errores 404 o los bucles de redirección, se deben a una mala planificación de esas redirecciones o a reglas del servidor que no se actualizan.

**Las claves de los permalinks de WordPress y el SEO en 30 segundos**

- WordPress ofrece estructuras predefinidas y otra personalizada con etiquetas como %postname%, %category% o %year%.
- Según la documentación oficial, una estructura personalizada debe terminar en %post_id% o %postname%.
- Google recomienda palabras descriptivas separadas por guiones y recuerda que distingue mayúsculas de minúsculas.
- Al cambiar URL ya indexadas hay que redirigir con 301, actualizar enlaces internos y sitemap, y mantener las redirecciones al menos un año.
- Los 404 posteriores suelen venir de las reglas de reescritura del servidor.

El asunto reaparece cada vez que alguien migra, rediseña o hereda un WordPress con URL del tipo `/?p=123`. wpdirecto ya explicó en 2019 [cómo crear permalinks personalizados en WordPress](https://wpdirecto.com/como-crear-permalinks-personalizados-en-wordpress/), y la parte de configuración apenas ha cambiado desde entonces. Lo que sí se ha precisado es la documentación de Google sobre migraciones: ahora detalla cuánto tiempo mantener las redirecciones, cuántos saltos tolerar y por qué no conviene enviar todo a la portada.

## Qué estructura elegir y cómo escribir el slug

La pantalla de ajustes ofrece varias opciones predefinidas y un campo para una estructura propia:

| Opción | Ejemplo de URL | Qué tener en cuenta |
| --- | --- | --- |
| Simple | /?p=123 | No describe el contenido |
| Día y nombre | /2026/11/10/mi-entrada/ | Fecha completa en la URL |
| Mes y nombre | /2026/11/mi-entrada/ | Año y mes en la URL |
| Numérico | /archives/123 | Identificador sin palabras |
| Nombre de la entrada | /mi-entrada/ | Corta y descriptiva |
| Estructura personalizada | /blog/%postname%/ | Se combina con etiquetas |

La documentación de WordPress enumera diez etiquetas para construir la estructura personalizada: `%year%`, `%monthnum%`, `%day%`, `%hour%`, `%minute%`, `%second%`, `%post_id%`, `%postname%`, `%category%` y `%author%`. Pone una condición: la estructura debe acabar en `%post_id%` o en `%postname%`. Con `%category%` hay dos detalles que conviene conocer. Las subcategorías aparecen como directorios anidados, y si una entrada tiene varias categorías solo una entra en la URL, elegida por orden alfabético salvo que un plugin permita marcar una principal. Mover una entrada de categoría cambia, por tanto, su dirección.

Para un blog nuevo, `/%postname%/` es la opción más estable: no depende de fechas ni de cómo se reorganicen las categorías. Un prefijo fijo como `/blog/%postname%/` tiene sentido cuando el blog convive con una web corporativa o una tienda y se quiere separar esa sección. Las fechas en la URL ayudan a ordenar archivos muy voluminosos, pero hacen que una guía actualizada siga pareciendo antigua.

El slug es la parte final de la URL. WordPress lo genera a partir del título, en minúsculas, sin tildes y con guiones; la documentación pone el ejemplo de «This Is A Great Post!», que se convierte en `this-is-a-great-post`. Las pautas de Google coinciden: palabras legibles en lugar de identificadores, guiones y no guiones bajos, y cuidado con las mayúsculas, porque para Google `/Apple` y `/apple` son URL distintas. Los caracteres no ASCII, como la eñe, deben ir codificados, y por eso que WordPress los normalice evita direcciones llenas de `%C3%B1`. Lo práctico es revisar el slug antes de publicar y recortar las palabras que no aportan, porque editarlo después es otro cambio de URL.

## Cómo cambiar la estructura de un sitio ya publicado

Cambiar los permalinks de un sitio con tráfico es, a efectos de Google, una migración con cambio de URL. Su guía para estos casos se resume en estos pasos aplicados a WordPress:

1. Hacer inventario de las URL actuales (sitemap, Search Console, analítica) y asignar a cada una su nueva dirección, empezando por las que más tráfico reciben.
2. Hacer una copia completa y probar el cambio en un entorno de pruebas.
3. Cambiar la estructura en Ajustes > Enlaces permanentes. En Apache, WordPress reescribe el `.htaccess` si tiene permisos; si no, muestra las reglas para copiarlas a mano.
4. Crear redirecciones 301 (o 308) del lado del servidor, de cada URL antigua a su equivalente, sin cadenas.
5. Actualizar enlaces internos, menús y el sitemap, y enviarlo a Search Console.

WordPress tiene un mecanismo propio, `wp_old_slug_redirect()`, que redirige con 301 cuando una entrada cambia de slug o de fecha. Pero su código muestra que solo actúa cuando la URL ya da 404 y que no lo hace con páginas ni otros tipos jerárquicos, así que no sirve como plan para un cambio de estructura completo. Para pasar de `/año/mes/entrada/` a `/entrada/`, una sola regla en el servidor resuelve todas las entradas a la vez. Estas dos se probaron en Nginx 1.24 y Apache 2.4; la condición `(?![0-9]+/?$)` evita que los archivos por día, como `/2019/02/10/`, se redirijan por error:

```
# Apache: en el .htaccess, antes de # BEGIN WordPress
RedirectMatch 301 ^/[0-9]{4}/[0-9]{2}/(?![0-9]+/?$)([^/]+)/?$ /$1/

# Nginx: dentro del bloque server {}
location ~ "^/[0-9]{4}/[0-9]{2}/(?![0-9]+/?$)([^/]+)/?$" {
    return 301 /$1/;
}Lenguaje del código: PHP (php)
```

La regla no cubre otras variantes, como los feeds de cada entrada o las páginas de comentarios, que necesitan sus propias líneas. Antes de activarla en producción conviene pasar por ella la lista completa de URL antiguas. Quien prefiera no tocar el servidor puede crear las redirecciones con un plugin; wpdirecto repasó en su día [Redirection, el veterano plugin para gestionar redirecciones](https://wpdirecto.com/redirection-el-veterano-plugin-que-sigue-salvando-el-seo-de-miles-de-sitios-wordpress/).

Google aconseja mantener las redirecciones al menos un año, y si es posible para siempre, evitar cadenas de más de tres o cuatro saltos y no mandar URL antiguas a una página sin relación, como la portada, porque las trata como un 404 encubierto (*soft 404*). También avisa de que las fluctuaciones de posiciones son normales durante semanas en sitios medianos. Cada página nueva debe declarar su propia URL como canónica, algo que WordPress y los plugins de SEO hacen solos si las redirecciones están bien.

## Errores 404 y bucles después del cambio

Si las URL nuevas devuelven 404, lo primero es volver a guardar Ajustes > Enlaces permanentes sin cambiar nada, lo que regenera las reglas de reescritura. En Apache hay que comprobar que `mod_rewrite` está activo, que el servidor permite usar `.htaccess` y que el bloque de WordPress está intacto. La documentación oficial publica el bloque básico para restaurarlo:

```
# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPressLenguaje del código: PHP (php)
```

Nginx no lee `.htaccess`, así que WordPress no puede escribir sus reglas y guardar los ajustes no arregla nada. Lo que hace falta es que la configuración del sitio envíe a `index.php` todo lo que no sea un archivo o un directorio real. El manual de administración avanzada lo resuelve con esta línea, y advierte de que la parte `?$args` es necesaria para no romper las URL con parámetros:

```
location / {
    try_files $uri $uri/ /index.php?$args;
}Lenguaje del código: PHP (php)
```

Si las nuevas funcionan pero las antiguas dan 404, el fallo está en las redirecciones. Si el navegador avisa de demasiadas redirecciones, suele haber reglas que se contradicen, por ejemplo una en el servidor y otra en un plugin. Para ver la cadena completa, `curl -sIL https://tusitio.com/2019/02/mi-entrada/ | grep -iE "^HTTP|^location"` muestra cada salto con su código. Y si los cambios parecen ir y venir, hay que vaciar la caché de páginas, la del CDN y la del navegador. El último control está en Search Console: el informe de indexación y los errores de rastreo de las semanas siguientes dicen si Google ha encontrado direcciones sin destino.

## Preguntas frecuentes

### ¿Cuál es la mejor estructura de permalinks para SEO?

Para la mayoría de sitios, «Nombre de la entrada» (/%postname%/), porque es corta, descriptiva y no depende de fechas ni categorías. Lo importante es elegirla antes de publicar y mantenerla.

### ¿Pierdo posicionamiento si cambio los permalinks?

Puede haber fluctuaciones durante semanas, según Google. Con redirecciones 301 de cada URL antigua a su equivalente, enlaces internos actualizados y un sitemap nuevo, las señales se trasladan a las direcciones nuevas.

### ¿WordPress redirige solo las URL antiguas?

Solo en parte: redirige entradas cuyo slug o fecha ha cambiado, pero no páginas ni todos los cambios de estructura. Para un cambio completo hay que crear redirecciones en el servidor o con un plugin.

### ¿Por qué salen errores 404 en Nginx tras cambiar los enlaces?

Porque Nginx no usa .htaccess y necesita una regla try_files que envíe las URL amigables a index.php. Sin ella, guardar los ajustes de WordPress no cambia nada.

**Fuentes:**

- [WordPress.org: Customize permalinks](https://wordpress.org/documentation/article/customize-permalinks/)
- [WordPress Advanced Administration: Apache HTTPD / .htaccess](https://developer.wordpress.org/advanced-administration/server/web-server/httpd/)
- [WordPress Advanced Administration: Nginx](https://developer.wordpress.org/advanced-administration/server/web-server/nginx/)
- [WordPress Developer Resources: wp_old_slug_redirect()](https://developer.wordpress.org/reference/functions/wp_old_slug_redirect/)
- [Google Search Central: URL structure best practices](https://developers.google.com/search/docs/crawling-indexing/url-structure)
- [Google Search Central: Site moves with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)
- [ServerAvatar: WordPress permalinks](https://serveravatar.com/wordpress-permalinks/)