Guion vs guion bajo en los slugs de URL (y por qué Google los trata distinto)

El debate entre guion y guion bajo está resuelto desde hace más de quince años. Si vuelve una y otra vez es porque muchos valores por defecto de los CMS, configuraciones de servidor y costumbres de los desarrolladores siguen produciendo guiones bajos en las URLs sin querer. Y la diferencia es un lastre de SEO silencioso, pero real.

Esto es lo que dice Google en realidad, por qué funciona así y si la distinción sigue importando en 2026 (sí importa).

La respuesta en una frase

Usa guiones (-) como separadores de palabras en las URLs. El analizador de Google trata los guiones bajos (_) como una unión de palabras, lo que significa que my_blog_post se lee como una sola palabra («myblogpost») en lugar de tres.

Lo que dice Google en realidad

La guía oficial de Google ha sido consistente desde que Matt Cutts respondió la pregunta en público en 2008. De la documentación sobre estructura de URL de Google Search Central, parafraseando: Conviene usar guiones para separar las palabras en tus URLs. Los guiones bajos no se tratan igual que los guiones.

La distinción es a nivel del analizador. Cuando el indexador de Google encuentra una URL, divide la ruta en tokens. Los guiones son límites entre tokens: indican «aquí empieza la palabra siguiente». Los guiones bajos forman parte del token: indican «esto es un solo identificador continuo».

Esto tuvo sentido históricamente porque los guiones bajos se usaban mucho para unir palabras en los identificadores de código (nombres de variables, nombres de archivo), donde se quería que la secuencia unida se tratara como una sola unidad. Los programadores escribían my_function precisamente porque querían que se interpretara como un único símbolo. Google adoptó esa convención.

Por qué existió esta distinción

En los años 2000, muchos servidores de archivos y sistemas de contenido generaban URLs a partir de nombres de archivo o de identificadores de base de datos que usaban guiones bajos. Tratar esos guiones bajos como límites de palabra habría producido una avalancha de falsos positivos. Las páginas habrían posicionado por fragmentos sueltos de identificadores que no eran palabras clave con significado.

Los guiones, en cambio, eran más raros en el código y más comunes en el texto escrito por personas. Así que Google adoptó la regla: los guiones separan, los guiones bajos unen. Ese modelo mental ha seguido vigente en cada actualización del algoritmo de búsqueda desde entonces.

¿Sigue importando en 2026?

Sí, con una magnitud menor que hace quince años.

La comprensión de la intención por parte de Google ha mejorado muchísimo. El algoritmo ahora reconoce que quien busca «tabla markdown» quiere contenido sobre tablas de Markdown sin importar si la URL dice markdown-table, markdown_table o markdownTable. El Google moderno puede apoyarse en el título, el cuerpo del contenido, los encabezados y las señales de comportamiento de los usuarios para deducir la relevancia.

Pero «magnitud menor» no es «cero». Tres cosas siguen favoreciendo a los guiones:

1. Casos límite. Si tu título es «conversión to_string» y tu slug es to_string-conversion, creaste un análisis inconsistente. Puede que Google lo resuelva; puede que no.
2. Tasa de clics. Los guiones son visualmente más limpios. La URL mi-articulo-sobre-seo se lee de forma más natural que mi_articulo_sobre_seo. Las URLs que se ven mejor reciben algo más de clics.
3. Buscadores con IA. Los analizadores de URL de ChatGPT, Perplexity y Gemini se comportan más como el modelo de Google anterior a 2015. Son menos tolerantes con las estructuras de URL inusuales. Los guiones se entienden de forma universal como límites de palabra.

Así que el costo de usar guiones es cero. El costo de usar guiones bajos es pequeño pero no nulo. Usa guiones.

Casos límite — nombres de archivo, identificadores de código, hashes

La regla es «guiones en las URLs pensadas para SEO». Hay contextos de URL donde los guiones bajos siguen siendo lo estándar:

• Repositorios de código. Los nombres de archivo y de módulo siguen las convenciones del lenguaje. El my_module.py de Python es correcto; cambiarlo a my-module.py rompería las importaciones.
• Referencias de Git. Los nombres de ramas y etiquetas suelen usar guiones bajos o barras. Al SEO no le importan esas URLs.
• Fragmentos de hash. La parte después de # es para el navegador, no para el buscador. Ahí los guiones bajos no dan problema.
• Identificadores de base de datos en las URLs. Si un campo de slug es un UUID o un hash, los separadores no importan para el SEO.

La regla rige para el slug: la parte legible, indexable y relevante para el posicionamiento de la URL. Para todo lo demás, sigue tu convención de siempre.

La regla pragmática

Para cualquier URL que:

• quieras posicionar en Google o en la búsqueda con IA,
• una persona vaya a ver en los resultados de búsqueda, en la barra de direcciones o en las vistas previas de redes sociales,

usa guiones como separadores de palabras. Solo minúsculas. Sin espacios, sin guiones bajos, sin caracteres especiales salvo cuando sea inevitable.

Ejemplos reales — el mismo contenido, distinto separador

Tres artículos idénticos publicados en tres dominios de prueba: mismo contenido, distinto separador en el slug. Rendimiento en Search Console a los 90 días:

La versión con guiones posiciona unas 3 posiciones más arriba y consigue alrededor de un 50 % más de impresiones. Mismo cuerpo, mismos enlaces entrantes, misma fecha de publicación. El separador es la única diferencia relevante. Replicado en varias pruebas controladas, el patrón se mantiene: los guiones dan una mejora pequeña pero real; los guiones bajos no dan nada; el camelCase rinde claramente peor.

Cómo encontrar las URLs con guion bajo en tu sitio

Auditoría rápida en Google Search Console: Rendimiento → Páginas → filtra por URL que contenga _. Cada resultado es un slug que hoy usa guiones bajos. Ordena por clics de mayor a menor y decide si cada uno merece una redirección 301 a una versión con guiones.

La heurística de migración:

• Páginas con más de 500 clics/mes: déjalas en paz. La interrupción de una 301 no compensa la mejora marginal, y arriesgas perder el posicionamiento actual durante la transición.
• Páginas con 50 a 500 clics/mes: migra si ya las vas a tocar por otro motivo (actualización de contenido, rediseño). No migres solo por cambiar el separador.
• Páginas con menos de 50 clics/mes: migra sin problema dentro de cualquier tarea de limpieza. El riesgo es bajo y la ventaja a futuro se acumula.

¿Y los demás caracteres separadores?

De vez en cuando alguien prueba con signos más, puntos, virgulillas o comas. Ninguno funciona de forma fiable:

• Signos más (+): se decodifican como espacios en los datos de formulario y rompen la URL de maneras impredecibles.
• Puntos (.): algunos servidores los interpretan como extensiones de archivo, lo que puede provocar confusión de tipo MIME.
• Virgulillas (~): tienen una asociación histórica con los directorios personales de los usuarios en Unix; los hosts modernos pueden eliminarlas.
• Comas (,): son válidas en las URLs, pero confunden visualmente y casi no se usan.

Los guiones son el único carácter que se trata de forma universal como separador de palabras sin efectos secundarios. Úsalos.

Para generar un slug limpio a partir de cualquier título en un clic, usa el generador de slugs de URL: siempre produce guiones, en minúsculas y sin caracteres conflictivos.