search - practices - seo link length

¿Qué hace una "URL amigable"? (19)

Recientemente he leído una gran cantidad de discusiones (tanto en este sitio como en otros) sobre "URL amigables", pero no estoy seguro de qué es exactamente lo que hace que una URL sea "amigable" y por qué realmente nos importa (hasta cierto punto) . Ilustración:

El siguiente es un ejemplo de una URL que la mayoría de los desarrolladores web actuales sostendrían como "amigable":

www.myblog.com/posts/123/this-is-the-name-of-my-blog-post

Mientras que esto se consideraría "antipático" (es decir, malo, neandertal, ignorante, estúpido):

www.myblog.com/posts.aspx?id=123

Mis preguntas:

¿La URL "amigable" no contiene información de identificación duplicada sobre la publicación del blog en cuestión? En otras palabras, una vez que tienes la identificación (123) de la publicación, ¿por qué necesitas el título? ¿No sería esto una violación del mantra "no te repites"?
¿Qué diferencia tiene la forma de una URL en lo que respecta a los usuarios? ¿Alguna vez los usuarios realmente escriben las URL completas a mano (aparte del TLD, por supuesto)? ¿Alguna vez los usuarios miran la URL de una página para determinar de qué se trata la página? ¿Por qué necesitamos el título de la publicación del blog en la URL? ¿No es para eso para lo que sirve el contenido y la etiqueta <title> la página?
A menudo escucho el SEO como una razón por la cual se prefiere el formato de URL "amigable". ¿Por qué una araña de un motor de búsqueda se preocupa por la URL? ¿No son simplemente piezas automatizadas de software que rastrean páginas (y los enlaces a otras páginas que están contenidas en ellas)? Si los motores de búsqueda se escribieron como otros componentes de software (por ejemplo, componentes de acceso a la base de datos), la URL sería simplemente un identificador sin sentido (similar a un rowguid en una base de datos relacional) para ellos. Si estuviera diseñando un esquema de base de datos con algo así como la URL "amigable" que aparece arriba como la clave principal de una tabla, sería (muy correctamente) masticado.

Dije antes "hasta cierto punto" porque, obviamente, las URL pueden salirse de control. Aquí hay una URL real de Amazon.com que no creo que nadie en su sano juicio considere "amigable":

http://www.amazon.com/Bissell-Kitchen-Housewares/b/ref=amb_link_5001972_17?ie=UTF8&node=694500&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=gp-center-5&pf_rd_r=1ZXNJFE0CCFFDH4B9HGH&pf_rd_t=101&pf_rd_p=405478901&pf_rd_i=510080

Ahh ... el truco es a quién la URL es amigable. Los motores de búsqueda perciben que la primera URL es más amigable porque aparentemente tiene información de contenido en la URL y no parece que la misma página se repita con un parámetro diferente.

Por ejemplo, comparando

www.aTvShowSite.com/show.aspx?id=123 www.aTvShowSite.com/show.aspx?id=124

un robot dirá que está bien, no sé lo que son ... pero me parecen la misma página.

Considerando que comparando

www.aTvShowSite.com/shows/AmericanIdol www.aTvShowSite.com/shows/Lost

les hace ver como páginas diferentes (aunque puede ser la misma página aspx que les sirve), y los robots tienden a clasificarlos más alto.

EDITAR: Además, debe tenerse en cuenta que muchos robots miran el texto de la url para determinar la utilidad, por lo que una búsqueda de "Perdido" probablemente golpeará el segundo tipo de url más que el primero, incluso si el contenido de la página es idéntico.

Bueno, para empezar, trata de mantener a los personajes separados de (az, AZ, 0-9) y por supuesto: /._- fuera de la url. No todos tienen todos esos en sus teclados (por ejemplo, no tengo & en mi teclado, tampoco tengo ~)

Cuando, por ejemplo, hacer un análisis de url o algo similar, también ayuda si la sintaxis de url es "limpia"

Como para:

¿No sería esto una violación del mantra "no te repites"?

Eso se refiere a la aplicación CÓDIGO !! , ¡no la aplicación en sí!

Tiene todo el sentido tener

Título en la etiqueta <title>
En la URL
Y como primera línea en el contenido.

Y prácticamente en todas partes, el contenido lo necesita.

Lo que ese "mantra" se refiere si tu código debe verse así:

<title><%=obj.getTitle()%></title> Reading:<h1><%=obj.getTitle()%></h1> Link to this:<a href="getHrefFor( object.getTitle() )">obj.getTitle()</a> Etc. etc.

En lugar de tener diferentes métodos con código de copiar / pegar alrededor de su aplicación.

El término url legible también se usa mucho. Usar URL amigables / legibles es una técnica que nace de SEO y eso es todo. De lo contrario, cuanto más corto sea el camino, mejor. Hacer reglas de reescritura por lo general ralentiza el proceso de enviar la página rápidamente al cliente, así que tenlo en cuenta también.

El término url legible también se usa mucho. Usar URL amigables / legibles es una técnica que nace de SEO y eso es todo. De lo contrario, cuanto más corto sea el camino, mejor.

En esta situación, realmente no rompe el principio DRY, porque en lo que respecta a un motor de búsqueda, ''522466'' no es lo mismo que ''what-makes-a-friendly-url''

En general, para sitios como , el token es la única información importante; generalmente puedes poner lo que quieras después de ese punto y te llevará al mismo lugar (ignorado por el servidor web).

La descripción de la página solo está ahí para ayudar a los motores de búsqueda a identificar de qué se trata la página (lo cual es bueno)

En mi opinión, los ID y UUID nunca deben ser parte de la URL, nunca.

1) Algunas bases de datos NoSQL no usan ID en absoluto, usan UUID. Los UUID son largos, las porciones se separan mediante guiones. Google tratará un guion como un separador de palabras: eso significa que su url tendrá 5 palabras clave más inútiles.

2) Un ser humano no entiende los ID ni los UUID. Una persona entiende las palabras y las URL que hablan.

3) Si el título cambia, simplemente puede hacer una redirección como lo hace WordPress, como @TRiG señalado.

4) Finalmente, recuerde usar una fecha, para que pueda discernir entre dos artículos que tienen el mismo título y publicados en un año, mes o día diferente. Por ejemplo, puede tener dos revisiones (primera y segunda edición) del mismo libro.

http://example.com/2013/02/11/data-mining-concepts-and-techniques

http://example.com/2011/05/23/data-mining-concepts-and-techniques

5) Una fecha también ayudará a cualquier usuario a determinar si el contenido es reciente o no.

6) Una fecha agregará una palabra clave importante a su URL: el año. Supongamos que quiero ver a las chicas más bellas del mundo, escribiré en Google: "las chicas más bellas del mundo 2014". Mi url será:

http://example.com/2014/07/10/the-most-beatiful-girls-in-the-world

7) Por último, Chrome almacena en caché el sitio que visitó, por lo que puede encontrar el sitio anterior simplemente escribiendo en la barra de direcciones "chicas".

En primer lugar, son amigables con los rastreadores de motores de búsqueda. Google y otros le dan un alto valor a las palabras en la url que coinciden con las palabras en la página, por lo que si el título de su publicación de blog está en la URL, ayudará a su motor de búsqueda.

En segundo lugar, son amigables para las personas que no saben lo que están visitando. ¿Cuál de los enlaces que usaste para comparar es más probable que hagas clic si aparece tu twitter / email / IM / etc.?

Es un buen punto sobre cómo poner información innecesaria en la URL.

http://.com/questions/522466/what-makes-a-friendly-url

Una vez que se conoce el ID único 522466, el resto es inútil, por lo que sirve puramente para hacer que la URL se vea "bien" y proporcionar al usuario una idea de a qué se vincula la página. Pero esto crea otro problema. La mayoría de los sitios no "verifican" esa parte de la URL, por lo que podría poner:

http://.com/questions/522466/omg-goatse-bought-by-bill-gates

Sin embargo, todavía se vinculará a esta publicación. Puedes ver cómo esto puede causar más problemas de los que valen porque podrían usarse de manera maliciosa.

Siento que Digg ha tomado el enfoque correcto para esto. No usan ID en sus URL. Detrás de escena obtienen la identificación de su base de datos puramente del título dado.

http://digg.com/linux_unix/I_Like_Linux_so_my_aunt_sends_me_this_for_Christmas

Esto, para mí, es la url perfecta . Me da toda la información que necesito para sentirme seguro al hacer clic en el enlace.

De hecho, los títulos desempeñan un papel tan importante que, en el mundo de digg, las personas "ciegan digg" basadas puramente en el hecho de que les gusta el título, o están interesados en él. Si su URL parece interesante, es posible que esté recibiendo más tráfico a su sitio. Al mismo tiempo, lo hará más fácil de usar, más bonito, y los motores de búsqueda se lo agradecerán. Por lo que puedo ver, las URL amigas son ganar-ganar para todos.

Estoy de acuerdo con usted, pero shhh no se lo digas a nadie.

Es solo mi humilde opinión, pero me parece tonto que

http://.com/questions/522466/

http://.com/questions/522466/what-makes-a-friendly-url

son la misma página. Quiero decir, puedo ver que el título de la pregunta con guiones le da a la URL cierto contexto, pero a menos que sepas que la parte es opcional, la URL solo se alarga innecesariamente.

La URL "antipática" que muestra expone un detalle de implementación: ¿qué pasaría si, en algún momento en el futuro, decidiera eliminar ASP y usar algo más? Tendría que cambiar todas las URL (¡baad!) O utilizar un esquema de cambio de nombre.

Tener el título repetido en la URL tal vez no sea necesario, pero resulta útil cuando se realiza una gran cantidad de enlaces pegados, para verificar que estés enlazando al lugar correcto.

La segunda URL parece más fácil de usar, mientras que la primera parece amigable para los motores de búsqueda.

Los motores de búsqueda otorgan mayor relevancia a las palabras que aparecen en la URL. El nombre de dominio obtiene el más alto (porque no puede cambiar), el resto de la URL obtiene una alta prioridad porque la longitud es limitada y luego se analiza el cuerpo del documento.

Mi respuesta es bastante subjetiva, porque depende de si eres amigable con los humanos (fácil de escribir a mano o leyendo a un amigo) o si estás siendo amigable con los motores de búsqueda (mejorando tu clasificación).

Matt y @bigmattyh: SEO no es "hacks": es entender lo que significa "buen contenido" en la web. Los títulos de página son parte del contenido. Un buen texto de anclaje en los enlaces es "buen contenido" (en lugar de usar palabras como "haga clic aquí" como texto del enlace). Colocar enlaces en contexto en lugar de como una lista es "buen contenido".

Los títulos de las páginas son frutas fáciles de conseguir, pero siguen siendo una de las formas más sencillas de mejorar el SERP. Sí, los enlaces entrantes (y su calidad) son críticos, pero los títulos pueden hacer maravillas, especialmente a corto plazo. No tiene que usar el título de la página (que puede cambiar de vez en cuando) como título de la publicación: resuma el contenido manualmente.

No adivine sobre esto: (a) lea fuentes como SEOmoz.org y (b) analice su propio sitio rigurosamente.

Mis pensamientos sobre tus tres balas:

Yo diría que esa no es una URL óptima. No tengo idea de por qué uno mostraría tanto el identificador de la publicación como el título. Nunca incluí ID de publicación en mis URL, solo títulos y (a veces) fechas
Para los usuarios, más corto es mejor.
Los motores de búsqueda miran la url. Ya sea que tenga sentido o no, lo hacen. Tener palabras clave en la URL ofrecerá algún beneficio de SEO.

Nuestro sitio web utiliza las denominadas URL "poco amistosas", pero creamos URL especiales "amigables" para ubicaciones específicas que los miembros del público usan para funciones específicas, especialmente en material impreso.

Por ejemplo, nuestros boletos de estacionamiento tienen http://www.dnv.org/parking en ellos.

Otro punto: las personas a veces editan manualmente las URL para subir al árbol de directorios. Por lo tanto, pueden intentar cargar una página como http://site.com/a/b , obtener un error "No encontrado" y luego probar http://site.com/a o http://site.com . Por supuesto, si sus URL no se basan en un árbol de directorios real, es posible que esto no funcione. Pero aún puedes intentar apoyarlo.

Algunos navegadores incluso fomentan esto, como IE con sus mensajes de error, y Safari con un menú que aparece cuando haces clic con el botón derecho en el título de la página.

Para mí, URL amigable significa que ha habido algún intento de incluir información semántica en la URL para que sea más adecuada para el consumo humano. Es un ejemplo interesante de una interfaz computadora-computadora que se aumenta y se basa en una mejor interfaz hombre-computadora.

Entonces, en tus dos ejemplos:

www.myblog.com/posts/123/this-is-the-name-of-my-blog-post es amigable, porque ha incluido el título en la URL, le dice algo sobre la página.
www.myblog.com/posts.aspx?id=123 es amigable porque es críptico y oscuro: tiene mucho sentido para una base de datos, pero ninguna para usted o para mí.

Las URL amigables son fantásticas en algunas situaciones e inútiles en otras. Básicamente, si un usuario alguna vez va a estar expuesto a él, me gustaría hacer que la creación de URL amigable sea una prioridad, y no es solo una cuestión de estética. Hace que sea mucho más fácil volver a las URL de la barra de direcciones si puede ver y entender rápidamente cuáles son las distintas opciones, además de que es más obvio dónde se encuentra a punto de ir si sigue un enlace desde una web. página.

Combina todo eso con la increíble barra en Firefox 3+ (seguramente también en otros navegadores), y la autocompletación en la barra de direcciones se vuelve increíblemente poderosa cuando tratas con URL amigables.

Parece que hay mucha información contradictoria sobre el efecto que tiene la cadena de consulta sobre rastreadores, pero el consenso es que tener más de un par de parámetros daña tu SEO porque una variable de cadena larga indica contenido dinámico, por lo que la mayoría de los motores de búsqueda serán mucho indexación menos agresiva de su página.

Agregar un slug a su url, como this-is-the-name-of-my-blog-post de su ejemplo, también hace que sus enlaces sean más diferentes entre sí que un simple número de identificación, y agrega palabras más significativas en el url. Estas son todas las cosas que buscan los motores de búsqueda.

Personalmente encuentro que estas URL son mucho más fáciles de analizar visualmente porque hay menos caracteres de puntuación utilizados, y los pares de nombre y valor en la cadena de consulta pueden ser muy detallados y difíciles de recordar.

Tim Berners-Lee (el arquitecto de la WWW) escribió un gran artículo sobre este tema hace unos 10 años.

Su ejemplo es una URL incorrecta, pero no solo porque tiene una identificación y un "slug" (la forma abreviada y con guiones del título de la página). Poner el título de la página en su URL es problemático a largo plazo. El contenido cambiará con el tiempo. Si alguna vez cambia el título de esa publicación de blog, se verá obligado a elegir entre mantener la URL anterior o cambiar la URL para que coincida con el nuevo título. Al cambiar la URL se romperán los enlaces anteriores a esa página; y no cambiarlo significa que tendrá una URL que no coincide con la página. Ninguno de los dos es bueno para el usuario. Mejor ir con www.myblog.com/posts/123 .
Los usuarios a menudo necesitan escribir una URL, pero lo más importante es que a veces también editan las URL existentes para encontrar otras páginas en su sitio. Por lo tanto, a menudo es bueno tener URL visibles . Por ejemplo, si quiero ver la publicación # 124, podría ver fácilmente la URL actual y ver que la URL de la página que quiero ver es www.myblog.com/posts/124. Ese es un nivel de facilidad de uso que puede ser de gran ayuda para las personas que intentan encontrar lo que están buscando. Incluir otra información (como el tema de la publicación) puede hacer esto imposible, por lo que reduce mis opciones de exploración.
Olvídate de SEO . La tecnología de los motores de búsqueda ha estado reduciendo la efectividad de los hacks SEO durante algún tiempo. El buen contenido sigue siendo el rey y, a la larga, no podrás jugar con el sistema.