Estructura de URL: principios de URL optimizadas para SEO

Qué es la estructura de URL

La estructura de URL es el conjunto de reglas que determinan cómo se forman las direcciones de las páginas de un sitio: longitud, jerarquía de carpetas, formato del slug, uso de parámetros y protocolo. Una buena estructura es legible para las personas, comprensible para un rastreador y se mantiene sin cambios durante años. Una mala crea duplicados, rompe la indexación y obliga a reescribir redirecciones cada vez que cambia la estrategia de marketing.

La URL es una de las pocas señales de SEO que Google ha reconocido abiertamente como factor de posicionamiento desde hace más de quince años. No es el factor más fuerte, pero sí uno de los más baratos: se configura una vez durante el desarrollo y funciona durante años sin tocarla. Los errores en este nivel son caros de corregir: cada URL que cambia necesita una redirección 301 y una nueva evaluación por parte del buscador.

URL en cifras

Anatomía de una URL: siete partes

Antes de diseñar la estructura, veamos qué componentes tiene una URL. RFC 3986 describe siete componentes; en el contexto del SEO importan todos excepto el user-info y el fragmento:

https://www.example.com:443/blog/seo/url-structure/?utm=email#summary
│  │   │            │   │                          │            │
│  │   │            │   │                          │            └─ fragment (anchor)
│  │   │            │   │                          └────────────── query (GET parameters)
│  │   │            │   └─────────────────────────────────────── path
│  │   │            └─────────────────────────────────────────── port (usually hidden)
│  │   └──────────────────────────────────────────────────────── host (domain)
│  └──────────────────────────────────────────────────────────── subdomain
└─────────────────────────────────────────────────────────────── scheme (protocol)

Por qué importa la URL para el SEO

Las URL influyen en el posicionamiento de forma directa e indirecta. La contribución directa es pequeña: Google ha confirmado en varias ocasiones que una palabra clave en la URL solo aporta un impulso «muy pequeño». El impacto indirecto es mucho mayor: la URL condiciona el CTR del snippet, la confianza de los usuarios y lo previsible que resulta el sitio para el rastreador.

Estos factores se suman. Cada uno es débil por separado, pero juntos convierten la URL en una ventaja silenciosa y constante, sobre todo en la cola larga, donde la competencia por cada punto de CTR es decisiva.

Nueve reglas de una buena URL

Las recomendaciones de Google sobre las URL apenas han cambiado en quince años. Las nueve reglas siguientes compilan documentación oficial e investigaciones empíricas de Backlinko, Ahrefs y Moz. Sirven para cualquier stack, desde WordPress hasta Next.js.

• Usa caracteres latinos (salvo que tu audiencia sea solo local). Técnicamente, el cirílico funciona mediante punycode, pero se copia mal en los mensajeros, se rompe al imprimirse y reduce el CTR en los resultados internacionales. /blog/url-structure/ es mejor que una ruta con caracteres cirílicos.
• Separa las palabras con guiones, no con guiones bajos. Google recomienda explícitamente los guiones. Los guiones bajos _ unen las palabras al analizarlas: para el bot, url_structure es un único token y no dos palabras.
• Solo minúsculas. Técnicamente, las URL distinguen mayúsculas de minúsculas (en servidores UNIX). /Page/ y /page/ son dos direcciones distintas que generan duplicados. Fuerza las minúsculas a nivel de servidor.
• Longitud: más corta de lo que parece necesario. El rango óptimo es de 50–75 caracteres. Si la URL es más larga, normalmente tiene palabras de más en el slug o categorías redundantes.
• Profundidad de carpetas: como máximo tres niveles. /category/subcategory/page/ es el límite para la mayoría de los sitios. El rastreador llega con menos frecuencia a las páginas más profundas, y a los usuarios les cuesta navegar.
• Sin palabras vacías. Quita del slug las palabras vacías, como «de», «y», «o» y «el»: /como-corregir-error/ es mejor que /como-corregir-un-error-en-el-codigo/. Las palabras vacías no ayudan ni al posicionamiento ni a la legibilidad.
• Palabra clave: una vez y cuanto antes. No repitas la palabra clave dos veces (/seo/guia-seo/). Colócala lo más cerca posible del dominio: cuanto más cerca de la raíz, mayor peso.
• Sin IDs ni hashes en el slug. /articulo-12384/ o /post-a3f9b2c8/ no dicen nada a las personas y no aportan semántica. Usa slugs descriptivos que traduzcan el tema.
• La URL no debe cambiar. Una dirección publicada es un compromiso. Cualquier cambio exige una redirección 301 y pierde algo de autoridad. Piensa en la estructura desde el principio.

Profundidad y jerarquía de carpetas

La estructura de carpetas de una URL no es solo estética: es un mapa del sitio para el rastreador y para el usuario. La profundidad de clic (el número de clics desde la página de inicio hasta una página) guarda relación con la frecuencia con la que Google vuelve a rastrear una página y con la rapidez con la que descubre contenido nuevo.

La profundidad de la URL no es lo mismo que la profundidad de clic. Una página puede estar físicamente en /shop/laptops/macbook-pro-14/ y, aun así, estar a un clic de la página de inicio gracias a un enlazado interno sólido. El buscador tiene en cuenta ambas señales: la ruta de la URL y la distancia real en el grafo de enlaces.

www, HTTPS, barra final y mayúsculas

Cuatro ajustes técnicos generan duplicados con más frecuencia. Cada uno se resuelve una sola vez en el servidor, pero si lo omites, el buscador ve hasta ocho versiones de la misma página:

http://example.com/page
http://example.com/page/
https://example.com/page
https://example.com/page/
http://www.example.com/page
http://www.example.com/page/
https://www.example.com/page
https://www.example.com/page/

HTTPS

Obligatorio desde 2018: Chrome marca los sitios HTTP como «no seguros» y Google usa HTTPS como una señal de posicionamiento débil. La configuración consiste en una sola redirección en nginx o apache:

# nginx — 301 from HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

www o sin www

Técnicamente son equivalentes. A nivel de DNS, www es un subdominio, pero Google y Yandex lo tratan como un alias cuando hay una redirección 301 configurada. Sin www es un poco más corto y moderno; con www resulta más cómodo para las cookies (se pueden separar por subdominio). La regla clave: elige una variante y redirige todo el tráfico a ella con 301.

# nginx — 301 from www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Barra final

La barra final (/page/ frente a /page) son dos direcciones distintas para el servidor. La convención es que los directorios terminan en / y los archivos no. En los sitios modernos, cada página es un directorio, así que conviene una sola estrategia: siempre con barra final o siempre sin ella. Next.js y WordPress usan la barra final por defecto.

// next.config.ts — enforced trailing slash
const nextConfig = {
  trailingSlash: true,  // /blog/page/  instead of  /blog/page
};
export default nextConfig;

Mayúsculas

Las URL distinguen mayúsculas de minúsculas en la mayoría de los servidores (Linux/UNIX). /Page/ y /page/ son dos URL y, por tanto, dos duplicados. Fuerza toda la ruta a minúsculas en el proxy inverso o en la aplicación:

# nginx — redirect URLs to lowercase (Lua module)
location ~ [A-Z] {
    rewrite ^/(.*)$ /$1 last;
    set_by_lua_block $lower_uri {
        return ngx.var.uri:lower()
    }
    return 301 $lower_uri;
}

Plantillas de URL por tipo de página

Cada tipo de contenido necesita una plantilla de URL distinta. A continuación tienes patrones probados para seis tipos de página que aparecen en el 90 % de los sitios web.

En comercio electrónico el tema es aparte. Una ficha de producto puede seguir dos esquemas: /shop/category/product/ (con categoría) o /shop/product/ (plano). El primero es mejor para el SEO de categoría, porque la URL indica a qué categoría pertenece el producto; el segundo facilita mover productos entre categorías sin redirecciones. La elección depende de la frecuencia con la que cambian de categoría.

Localización y URL multilingües

En un sitio multilingüe, las URL son una parte básica de la estrategia. Google recomienda tres enfoques, cada uno con sus pros y sus contras:

En el 80 % de los casos, las subcarpetas son la mejor opción. Son más fáciles de gestionar, más baratas en SSL y en hosting, y toda la autoridad de enlace trabaja para un solo dominio. Es justo el enfoque que usa seohead.tech: el idioma principal en la raíz y el segundo en /en/.

Los slugs en las URL localizadas son un tema polémico. Traducir el slug (/en/url-structure/ ↔ /struktura-url/) mejora el CTR en cada idioma y precisa mejor la relevancia. El inconveniente es que cuesta más mantenerlo: hay que gestionar hreflang y las redirecciones cuando cambian las traducciones. En la mayoría de los proyectos, el compromiso es traducir solo los slugs del blog y mantener un único slug para las páginas técnicas.

Errores frecuentes y cómo corregirlos

Estos son los ocho errores de URL más habituales en las auditorías de SEO. Cada uno se corrige en un sprint; no hacer nada supone una pérdida gradual de posiciones y de presupuesto de rastreo.

• Duplicados por parámetros GET. Las etiquetas UTM, las ordenaciones y los filtros crean cientos de variantes de una misma página. Solución: rel="[canonical](/glossary/canonical)" hacia la URL principal y configurar los parámetros de URL en GSC.
• Barra final inconsistente. Algunas páginas terminan en / y otras no. El buscador ve duplicados. Solución: una sola convención y redirecciones 301 desde todas las variantes que no coincidan.
• Cirílico en las URL de un proyecto global. Una ruta con palabras en cirílico se convierte en una cadena codificada, como /%D1%83%D1%81%D0%BB%D1%83%D0%B3%D0%B8/. Solución: transliteración (/uslugi/).
• Jerarquía demasiado profunda. /shop/electronics/computers/laptops/apple/macbook-pro/ tiene seis niveles. Solución: una estructura plana con las categorías como facetas.
• IDs en la URL en lugar de un slug. /article?id=12384 o /post/12384/. Solución: pasar a URL semánticas y redirigir con 301 desde los IDs antiguos.
• Cambiar una URL sin 301. Cualquier cambio de dirección sin redirección equivale a perder autoridad y tráfico. Solución: configura siempre una 301 al renombrar.
• Mayúsculas en las URL. /Catalog/ y /catalog/ son dos duplicados. Solución: forzar las minúsculas en el servidor.
• Cadenas de redirecciones largas. A → B → C → D. Cada salto resta peso. Solución: redirige siempre con 301 directamente a la URL final.

# Check redirect chains via curl:
curl -sILo /dev/null -w "%{http_code} %{url_effective}\n" \
     -L https://example.com/old-page/

# Find URLs with uppercase letters in nginx logs:
grep -E 'GET /[a-z]*[A-Z]' /var/log/nginx/access.log | head

# URL audit via Screaming Frog:
# 1. Run a full site crawl
# 2. Open the URL tab → Underscores / Uppercase / Non ASCII Characters
# 3. Export the list of problematic URLs and plan redirects

Preguntas frecuentes

Respuestas a las preguntas más habituales sobre la estructura de URL que surgen en las auditorías y en los rediseños.

Resumen

La estructura de URL es una decisión que tomas una vez y con la que convives durante años. Una buena URL es corta, legible para las personas, refleja la jerarquía del contenido y es estable en el tiempo. Tres principios básicos (minúsculas latinas, guiones en lugar de guiones bajos y un máximo de tres niveles de carpeta) resuelven el 80 % de los errores habituales.

Empieza por una auditoría de las URL actuales: en Screaming Frog, los informes «Underscores», «Uppercase» y «Non ASCII Characters». En una hora tendrás un mapa de problemas. Después, crea una tabla old → new, configura las 301 y actualiza los enlaces internos. No te apresures con una migración masiva en plena temporada alta: Google tarda entre 4 y 8 semanas en reevaluar.