Guiones vs guiones bajos en URLs: el estándar que tu automatización debe exigir

Cuando la automatización genera cientos de páginas, las pequeñas decisiones de URL dejan de ser cosméticas y pasan a ser infraestructura.

Una de las más pequeñas es el carácter entre palabras: un guion o un guion bajo.

Google documenta una preferencia clara, y las herramientas de rastreo tratan la diferencia como un problema detectable.

Si tu pipeline de publicación aplica una sola convención, evitas una clase de problemas que es tedioso corregir después.

Lo que Google realmente recomienda

La guía de Google sobre la estructura de URLs es directa: usa guiones en lugar de guiones bajos para separar palabras en las URLs.

La razón indicada es que los guiones ayudan a los usuarios y a los buscadores a identificar mejor los conceptos en la URL.

El razonamiento es histórico.

Los guiones bajos se usan comúnmente en lenguajes de programación para denotar conceptos que deben mantenerse juntos, como una función llamada format_date.

Google explica que ese uso heredado es la razón por la que no recomienda guiones bajos como separadores de palabras.

La documentación de Google sobre estructura de URLs contrasta una ruta de ropa de verano escrita con guiones frente a guiones bajos.

En términos prácticos, una URL como example.com/summer-clothing comunica dos palabras separadas.

La versión con guion bajo corre el riesgo de leerse como un solo token.

Google no promete ningún cambio de posicionamiento para páginas individuales en ningún caso.

Pero la recomendación es inequívoca, y seguir la guía documentada es la posición más barata de mantener.

Por qué importa más cuando la automatización escribe las URLs

Una persona que escribe diez URLs notará una inconsistencia.

Un pipeline automatizado que escribe miles no lo hará.

La generación de slugs normalmente deriva de un campo de título o palabra clave, y la lógica de separador que configures se aplica de manera uniforme.

Si esa lógica emite guiones bajos, cada página generada lleva la convención no recomendada, y ninguna página individual se marca como rota.

Este es el argumento central para tratar la regla del guion como un estándar exigido y no como una preferencia.

El costo de exigirla en el momento de la generación es casi cero.

El costo de corregirla después es una migración: cada URL cambiada necesita una redirección, los enlaces internos deben actualizarse y los sitemaps deben regenerarse.

Para una sección programática grande, eso es un proyecto.

Para una función de slug, es una línea.

La misma lógica aplica a convenciones de URL adyacentes que Google documenta.

Las URLs distinguen mayúsculas de minúsculas en cuanto al manejo de Google, así que /Apple y /apple son URLs distintas.

Google aconseja convertir el texto a una sola forma de mayúsculas cuando tu servidor las trata igual, lo que facilita confirmar que las URLs apuntan a una sola página.

La misma guía también recomienda usar la menor cantidad posible de parámetros en la URL y recortar los que no cambian el contenido.

Un estándar de automatización puede exigir todo esto junto: minúsculas, separación con guiones y parámetros mínimos.

Cómo los rastreadores revelan el problema

No tienes que fiarte solo de la palabra de Google.

El SEO Spider de Screaming Frog incluye un filtro dedicado de Underscores entre sus problemas de URL.

También comprueba mayúsculas, barras múltiples, espacios y rutas repetitivas.

La documentación de problemas de la herramienta lista los guiones bajos como una comprobación de primera clase, así que auditores y agencias los marcarán.

Eso importa para los líderes de operaciones que coordinan entre equipos y proveedores.

Si se ejecuta una auditoría externa, las URLs con guion bajo aparecen como un problema listado, causen o no un daño medible.

Ejecutar el mismo rastreo internamente antes de una auditoría convierte un hallazgo sorpresa en un elemento conocido del backlog, o mejor, en nada, porque el estándar lo previno.

La documentación de pestañas de Screaming Frog también señala convenciones relacionadas que vale la pena incluir en el mismo estándar.

Las URLs con espacios se consideran inseguras y pueden romperse al compartirlas, y se deben usar guiones como separadores de palabras en su lugar.

Las barras múltiples en una ruta suelen ser errores que pueden crear URLs duplicadas.

La guía de usuario las presenta como comprobaciones de buenas prácticas, no como garantías de posicionamiento.

Qué debe incluir un estándar de publicación

Una convención de URL viable para publicación automatizada es lo bastante corta para escribirla y exigirla en código.

Con base en la guía documentada anterior, debe cubrir:

• Guiones, nunca guiones bajos, entre palabras del slug.
• Letras en minúsculas en todo el slug, ya que el manejo de URLs distingue mayúsculas.
• Sin espacios, que son inseguros y pueden romper los enlaces compartidos.
• Una sola barra entre secciones de la ruta, sin barras dobles.
• La menor cantidad posible de parámetros, y ninguno que no cambie el contenido.
• Slugs derivados de texto de título limpio, sin puntuación que requiera codificación.

Google también recomienda codificar con porcentaje los caracteres no ASCII en las URLs.

Si tu automatización genera páginas a partir de temas que incluyen alfabetos no latinos o caracteres acentuados, decide deliberadamente si los codificas o transliteras el slug.

Ambas opciones pueden funcionar; una mezcla sin codificar aplicada de forma inconsistente en una sección grande es lo que genera ruido en auditorías.

La guía de Google advierte sobre estructuras de URL que generan cantidades muy grandes de URLs similares, como los filtros aditivos.

También señala parámetros irrelevantes como IDs de sesión y códigos de referencia, además de calendarios sin límites.

Si tu automatización produce vistas filtradas o parametrizadas, esa advertencia merece su propia revisión, separada de la cuestión del separador.

La documentación de Google sugiere el bloqueo mediante robots.txt como un remedio, una decisión que debes tomar con tu equipo técnico y no por defecto.

Puntos de exigencia en un pipeline automatizado

Un estándar solo se sostiene si algo lo exige.

En un pipeline de publicación hay tres puntos de control prácticos.

Primero, el generador de slugs.

Aquí es donde pertenece la regla.

Deriva el slug del título, reemplaza espacios y guiones bajos por guiones, convierte todo a minúsculas y elimina los caracteres que requerirían codificación.

Pruébalo con entradas incómodas: títulos con puntuación, siglas en mayúsculas y minúsculas mezcladas, y palabras no ASCII.

Segundo, el paso de revisión.

Si personas aprueban las páginas generadas antes de publicar, la URL debe ser visible en la vista de aprobación.

Un revisor que ve el slug puede detectar uno mal formado en segundos.

Si la aprobación es automatizada, agrega una validación que rechace los slugs que violen la convención en lugar de publicarlos en silencio.

Tercero, el ciclo de auditoría.

Los rastreos periódicos detectan lo que la generación omite.

Incluyen URLs creadas por otros sistemas, páginas heredadas o integraciones que construyen enlaces de forma independiente.

Los filtros de guion bajo, mayúsculas, espacios y barras múltiples de Screaming Frog se corresponden con el estándar anterior.

Así, un rastreo puede verificar el cumplimiento sin scripts personalizados.

La lista de problemas muestra que estas comprobaciones se ubican junto a verificaciones más amplias de higiene de URL, como parámetros y códigos de seguimiento.

Estos puntos de control reflejan cómo los equipos disciplinados tratan otros estándares de automatización.

El mismo pensamiento de captura y revisión de un estándar operativo de intake de automatización aplica aquí: define la regla una vez, exígela en la entrada y verifica aguas abajo.

Cambiar URLs existentes con guion bajo

Si un rastreo encuentra URLs existentes con guion bajo, resiste el impulso de renombrarlas en masa de inmediato.

Cada cambio de URL necesita una redirección de la dirección antigua a la nueva, y los enlaces internos deben apuntar a la URL final en lugar de encadenar redirecciones.

Para un número pequeño de páginas esto es rutina.

Para una sección programática grande, secuéncialo: prioriza las páginas que reciben tráfico o enlaces, redirige el resto por lotes y actualiza el enlazado interno sobre la marcha.

También corrige la fuente antes de corregir las páginas.

Si un generador de slugs o una plantilla del CMS produjo los guiones bajos, cambiar las URLs sin cambiar el generador garantiza que el problema regrese.

Este es el mismo principio detrás de un estándar operativo de cambios de automatización: corrige el sistema, no solo el resultado.

Una advertencia sobre el alcance.

La recomendación de Google sobre guiones trata de separadores de palabras en rutas.

No establece que toda URL con guion bajo rinda peor, ni que reescribirlas produzca un cambio de posicionamiento predecible.

Trata la reescritura como trabajo de higiene y consistencia, y verifica los resultados con tus propios datos de rastreo y analítica en lugar de asumir un resultado específico.

Dónde encaja esto en decisiones más amplias de URL

Los separadores son una pequeña parte de la estructura de URL para páginas automatizadas.

Cuánta jerarquía de tema codificar en la ruta, cómo manejar la paginación y cuándo usar subdirectorios frente a parámetros son preguntas mayores con sus propios tradeoffs.

Si dudas entre publicar de forma automatizada o contratar una agencia, automatización SEO frente a agencia (en inglés) cubre quién debe ser dueño de estándares como este.

Y si la pregunta más amplia es qué partes del marketing automatizar, la comparación entre agencia y sistema de automatización (en inglés) plantea esa elección para fundadores.

La regla del separador, en cambio, no necesita debate.

Google recomienda guiones, los rastreadores marcan los guiones bajos, y exigirlo cuesta una línea de lógica de slug.

Escribe el estándar, ponlo en el generador y verifícalo en tu próximo rastreo.

Cómo puede ayudar Meshline.

Conecta la automatización, el Marketing Orgánico (generación de demanda) y la gestión del ciclo de vida del cliente (Revenue Intelligence).

Lleva la planificación de temas, la publicación de contenido y el feedback de rendimiento a la conversación sobre tu flujo de trabajo. Reserva una demo de Meshline.