caso de que sea /about_us o /quienes-somos?URL: Dash vs subrayado
Desde el punto de vista de la usabilidad, personalmente creo que /about-us es mucho mejor para el usuario final pero Google y la mayoría de los otros sitios web (y frameworks de JavaScript) utilizan un patrón de nomenclatura de subrayado. ¿Es solo cuestión de estilo? ¿Hay algún problema de compatibilidad con los guiones?
Esta es sólo una suposición, pero parece que escogieron el que la gente lo más probablemente haría no uso en un nombre. De esta forma, puede tener un nombre que incluya una palabra con guiones y aún utilizar la barra inferior como delimitador de palabras, p. Ej. Use Two-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 a una sola cadena de caracteres que no son blancos.
Adivina razonable, pero resulta ser totalmente falso. -1. –
¿Tiene una referencia para ese @MarkAmery? La pregunta giraba en torno a por qué Google usaría guiones bajos. Si está sugiriendo que no es así, ese no es el problema de esta respuesta, sino el problema de la pregunta. – billjamesdev
Primero, como adivinan, es bastante razonable. Agregaría como parte de la suposición de que los programadores usan el dash como resta, por lo que se usa el subrayado; quizás las URL, creadas por programadores, siguen esa convención. Sin embargo, una explicación real sería mejor. Mark escala con -1 sin ninguna copia de seguridad; desearía poder dar el comentario a -1. –
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 conocimientos debate
Personalmente, yo evitaría el uso sobre-nosotros o about_us, y sólo tiene que utilizar aproximadamente.
/about/us/no/seriously/this/is/it :) –
y esta es su solución? Bien, ¿qué pasa con "about_our_customers" o cualquiera de una miríada de "totales" que podría llegar a ser relevante? ¡Ignorando un problema! = Solución. – billjamesdev
¿Qué pasa con '/ delete_answer'? –
estoy más cómodo con 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 nunca tienen guiones bajos. Para elegir un ejemplo realmente estúpido, "país del estado nación" es diferente f rom "país del estado nación". 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 de los caracteres en las 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.
Solo una nota al margen, los lenguajes como Lisp o Scheme usan nombres de variable/función habituales separados por guiones, porque menos es solo un identificador de función como cualquier otro (y de hecho, permiten un juego de caracteres más grande en los identificadores). –
Algunos servidores de alojamiento web y DNS anteriores tienen problemas al analizar los guiones bajos de las URL, por lo que pueden formar parte de convenciones como estas.
Sí, pero eso es solo en nombres de host. – Anirvan
Jeff tiene algunas ideas sobre esto: https://blog.codinghorror.com/of-spaces-underscores-and-dashes/
hay algunas desventajas para ambos. Sugeriría que escojas uno y seas consecuente.
+1 porque menciona cómo Google lo espera, lo que supongo que es más importante de lo que parece. – tj111
Los subrayados reemplazan los 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
Tengo que estar en desacuerdo con esto. En estos días, es costumbre usar solo guiones. Los no programadores encuentran que los guiones bajos son visualmente poco atractivos. No hay nada malo con el primer ejemplo. De hecho, es más amigable de leer. – allesklar
Semánticamente tienes razón, pero la distinción puede ser más confusa que útil para el uso en las URL. Es más probable que las personas recuerden "a-b-c-d-e" que "a-b_c-d_e". –
En serio mal consejo. – Robs
Para la vista del usuario final prefiero "sobre-nosotros" o "acerca de nosotros" no "about_us"
yo personalmente evite todos los guiones bajos y guiones bajos y opte 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. Que ascienden a
Si el usuario va a 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
¿Cómo sabría el motor de búsqueda dónde comienza o termina una palabra? –
¿Por qué el motor de búsqueda no podría tratar con PascalCase como cualquier otro delímetro, ya sea un _, - o: para el caso? –
Un buen consejo ... es que esta pregunta fue sobre el código. Las URL son [generalmente] insensibles a mayúsculas y minúsculas, y generalmente se muestran en minúsculas. – Armstrongest
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 de 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 en general que los programadores, es que cuando un hipervínculo con guiones bajos está subrayado, no puede ver el guión bajo. Los usuarios avanzados lo resolverán, pero Joe Public probablemente no lo haga.
Sin embargo, aún se usan guiones bajos en el código con preferencia a los guiones: los programadores los entienden, la mayoría de las otras personas no.
Los espacios están permitidos en las URL, por lo que puede usar "/ sobre nosotros" en un enlace (aunque se codificará en "/ about% 20us". Pero se honesto, esta siempre será una preferencia personal, por lo que hay una respuesta real a dar aquí.
me gustaría ir con la convención de que los guiones pueden aparecer en las palabras, por lo que los espacios deben ser convertidos en guiones.
Google no trató de subrayado como un separador de palabra en el pasado , lo cual pensé que era una locura, pero aparentemente lo es ahora. Debido a esta historia, se prefieren los guiones. Aunque los guiones bajos ahora son permisibles desde un punto de vista SEO, todavía creo que los guiones son los mejores.
Una de las ventajas es que es mucho más probable que un navegante web semi-analfabeto promedio sea capaz de escribir un guion en el teclado, incluso es posible que ni siquiera sepa cuál es el guión bajo.
Es poco probable que la persona que practica surf en la Web promedio de semi-computadora sepa la diferencia entre la barra de direcciones y la búsqueda. El usuario promedio también tiene MUCHO más probabilidades de hacer clic que de escribir. Solo digo ' – Armstrongest
Google todavía NO trata el guión bajo como separador de palabras: http://www.youtube.com/watch?v=AQcSFsQyct8 – Sembiance
El gurú de SEO Jim Westergren tested this volvió en 2005 desde una estricta perspectiva de SEO y llegó a la conclusión de que + (más) era realmente 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.
Prefiero los guiones sobre la base de que un subrayado puede quedar oscurecido en cierta medida por el subrayado de un 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.
Donde 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.
No se trata sólo dash vs subrayado:
¡Bienvenido a Wild Wild Web! –
Considere utilizar la puntuación en sus URL . La URL http://www.example.com/green-dress.html nos es mucho más útil que http://www.example.com/greendress.html. Recomendamos que use guiones (-) en lugar de guiones bajos (_) en sus URL .
Google no explicó por qué? Supuestamente, ¿tiene algo que ver con su forma de analizar las direcciones? O probablemente sea solo un problema para el usuario final. –
también vale la pena señalar que underscored_text se puede seleccionar como un todo haciendo doble clic en algunos dispositivos y pulsando prolongadamente en los móviles, mientras que con el texto separado por guiones las mismas acciones seleccionan cada palabra separada. Piensa si un usuario alguna vez trataría de copiar algo de la url. – Titus
. Creo que podrías haber tocado un círculo de causalidad en @Titus, ya que eso es completamente contrario al real ... Inglés, que tiene guiones en las palabras, pero no lo hace. t tiene guiones bajos. – billjamesdev
Éstos son algunos puntos a favor de los guiones:
Mejor uso. -/como separadores, porque _ parece no ser un separador.
http://www.sistrix.com/blog/832-how-long-may-a-linktext-be.html
¿Por qué no */Índice ____ 1125.aspx * (que es cuatro guiones bajos, muy importante!) –
Oh, vamos. Estoy interesado en esta pregunta y en las respuestas. La pregunta tiene 52 envíos, ¿y la cerraste? Se trata de programar. Programación web.Decidir cómo nombrar directorios en un sitio web que se está desarrollando. – Kaydell
[Pregunta duplicada en un sitio donde este problema es * definitivamente sobre el tema *.] (Http://webmasters.stackexchange.com/questions/374/urls-should-i-use-hyphens-underscores-or-plus- símbolos) –