practices - url structure
URLs: Dash vs. subrayado (18)
¿Debería ser / about_us o / about-us ?
Desde el punto de vista de la usabilidad, personalmente creo / about-us es mucho mejor para el usuario final pero Google y la mayoría de los otros sitios web (y frameworks de JavaScript) usan un patrón de nomenclatura de subrayado. ¿Es solo cuestión de estilo? ¿Hay algún problema de compatibilidad con los guiones?
Algunos servidores de hospedaje web y DNS más antiguos tienen problemas al analizar los guiones bajos de las URL, por lo que pueden formar parte de convenciones como estas.
Aquí hay algunos puntos a favor de los guiones:
- Dashes son recomendados por Google sobre guiones bajos ( fuente ).
- Los guiones son más familiares para el usuario final.
- Los guiones son más fáciles de escribir en un teclado estándar (no es necesario cambiar).
- Los guiones no se esconden detrás de los subrayados.
- Los guiones se sienten más nativos en el contexto de las URL, ya que están permitidos en los nombres de dominio.
Creo que dash es mejor desde la perspectiva del usuario y no interferirá con el SEO.
No estoy seguro de dónde o por qué comenzó la convención de subrayado.
Un poco más de debate informado
El gurú de SEO Jim Westergren probó esto en 2005 desde una estricta perspectiva de SEO y llegó a la conclusión de que + (más) era en realidad el mejor delimitador de palabras. Sin embargo, esto no parece razonable y puede deberse a un error en los algoritmos de los motores de búsqueda. Él recomienda - (guión) para la legibilidad y SEO.
Esto es solo una suposición, pero parece que escogieron la que la gente probablemente no usaría en un nombre. De esta manera, puede tener un nombre que incluya una palabra con guiones y aún utilizar la barra inferior como delimitador de palabras, por ejemplo, UseTwo-wayLinks podría convertirse a use_two-way_links.
En su ejemplo, / about-us sería un directorio llamado la palabra con guiones "about-us" (si existiera tal palabra, y / about_us sería un directorio llamado la frase de dos palabras "sobre nosotros" convertida en una sola cadena de caracteres no blancos.
Google no trató el guión bajo como separador de palabras en el pasado, lo cual me pareció una locura, pero aparentemente ahora sí. Debido a este historial, se prefieren guiones. Aunque los guiones bajos ahora son permisibles desde el punto de vista de SEO, todavía creo que los guiones son mejores.
Una de las ventajas es que es mucho más probable que un navegante web semi-analfabeto promedio sea capaz de escribir un guión en el teclado, incluso es posible que ni siquiera sepa cuál es el guión bajo.
Jeff tiene algunas ideas sobre esto: https://blog.codinghorror.com/of-spaces-underscores-and-dashes/
Hay inconvenientes para ambos. Sugeriría que escojas uno y seas consecuente.
Los espacios están permitidos en las URL, por lo que puedes usar "/ acerca de nosotros" en un enlace (aunque se codificará en "/ about% 20us". Pero se honesto, esto siempre será una preferencia personal, por lo que no hay una respuesta real para ser dado aquí.
Me gustaría ir con la convención de que los guiones pueden aparecer en palabras, por lo que los espacios deben convertirse en guiones bajos.
Los signos de subrayado reemplazan espacios donde no se permite el espacio en blanco. Los guiones (guiones) pueden ser parte de una palabra, por lo que unir palabras con guiones que ya incluyen guiones es feo / confuso.
Malo:
/low-budget-movies
Bueno:
/low-budget_movies
Mejor uso. - / como separadores, porque _ parece no ser un separador.
http://www.sistrix.com/blog/832-how-long-may-a-linktext-be.html
No es solo guión vs. guion bajo:
- texto con espacios
- texto sin espacios
- codificado% 20spaces% 20in% 20URL
- underscore_means_space
- dash-means-space
- más + significa + espacio
- el caso de Carmel
- PascalCase
- "texto entre comillas con espacios" (y comillas simples vs. comillas dobles)
- barra / medio / espacio
- dot.means.space
Para la vista del usuario final, prefiero "sobre-nosotros" o "sobre nosotros", no "sobre_us"
Personalmente, evitaría todos los guiones y guiones bajos y optaría por camelCase o PascalCase si está en el código.
El artículo de Wikipedia sobre camelCase explica un poco el razonamiento detrás de sus orígenes. Suman a
- Programadores perezosos que no les gustó alcanzar la tecla _
- Posible confusión sobre la legibilidad
- El teclado "Alto" en xerox PARC que no tenía tecla de guión bajo.
Si el usuario debe ver la cadena, entonces no haría ninguno de los anteriores y usar "Sobre nosotros". o "AboutUs" si tuviera que hacerlo, ya que camelCase se ha extendido al uso común en algunas áreas, como los nombres de los productos. es decir, ThinkPad, TiVo
Personalmente, evitaría usar about-us o about_us, y solo usar about.
Prefiero los guiones sobre la base de que un subrayado puede quedar oscurecido en cierta medida por un subrayado de enlace. Las URL textuales son principalmente para ser reconocidas a simple vista en lugar de ser gramaticalmente correctas, por lo que el argumento para preservar los guiones para su uso en palabras con guiones es limitado.
Cuando la precisión de una URL textual es importante es cuando la lees a alguien, en cuyo caso no debes confundir un guión bajo por un espacio (o viceversa).
A también encuentra rayas más estéticamente agradables, si eso cuenta para nada.
Solía usar caracteres de subrayado todo el tiempo, ahora solo los uso para partes de un sitio web que no quiero que nadie vincule directamente, archivos js, CSS, etc.
Desde un punto de vista SEO, los guiones parecen ser la forma preferida de manejarlo, para una explicación detallada, de la boca de los caballos http://www.mattcutts.com/blog/dashes-vs-underscores/ .
El otro problema que parece ocurrir, más con el público general que los programadores, es que cuando se subraya un hipervínculo con guiones bajos, no puede ver el guión bajo. Los usuarios avanzados lo resolverán, pero Joe Public probablemente no lo haga.
Sin embargo, aún usa guiones bajos en el código con preferencia a los guiones: los programadores los entienden, la mayoría de las otras personas no.
Desde Google Webmaster Central
Considere usar la puntuación en sus URL. La URL http://www.example.com/green-dress.html es mucho más útil para nosotros que http://www.example.com/greendress.html . Le recomendamos que use guiones (-) en lugar de guiones bajos (_) en sus URL.
Estoy más cómodo con los guiones bajos. En primer lugar, coinciden con mi experiencia habitual de programación de variable_names_are_not-subtraction , en segundo lugar, y creo que esto ya se mencionó, las palabras pueden tener guiones, pero que nunca tienen guiones bajos. Para elegir un ejemplo realmente estúpido, "país de estado nacional" es diferente de "país de estado nacional". El primero traduce algo así como "la tierra de los Estados-nación" ("¡aquí está el país de las armas! ¿Te mueves mejor, oye?"), Mientras que el último parece una lista de sinónimos en algún momento. http://example.com/nation-state-country/ no parece significar lo mismo que http://example.com/nation-state_country/ , y sin embargo, si los guiones son delimitadores / "espacio" s además a los personajes en palabras, puede. Este último parece más claro en cuanto al propósito real, mientras que el primero se parece más a esa lista, en todo caso.