routing - practices - url length seo

Pretty URLs para páginas de búsqueda

Question

Realmente disfruto tener URL "bonitas" (por ejemplo, /Products/Edit/1 lugar de /products.aspx?productID=1 ), pero no sé cómo hacer esto para las páginas que te permiten buscar por un gran número de variables.

Por ejemplo, digamos que tiene una página que le permite al usuario buscar todos los productos de un tipo particular con un cierto nombre y cerca de una dirección específica. ¿Harías esto con URL "bastante" realmente largas?

/Products/Search/Type/{producttype}/Name/{name}/Address/{address}

o simplemente recurrir al uso de parámetros de URL

/Products/Search?productType={producttype}&name={name}&address={address}

Answer 1

Como se mencionó anteriormente, usar HTTP Post sería lo mejor, pero luego se pierde la posibilidad de que las personas envíen el enlace a las personas o lo marquen como favorito. Dejar la cadena de consulta en la URL no va a ser tan malo. Lo tengo configurado para que la cadena de URL sea así:

http://example.com/search/?productType={producttype}&name={name}&address={address}

Y luego, para paginar los resultados de búsqueda, agregue el número de página antes de la cadena de consulta (para que la cadena de consulta sea personalizable si es necesario).

• Página 1: http://example.com/search/?productType= {producttype} & name = {name}
• Página 2: http://example.com/search/2/?productType= {producttype} & name = {name}
• Página 3: http://example.com/search/3/?productType= {producttype} & name = {name}

etc ...

Al final del día, al rey de la búsqueda ''Google'' no le importa dejar la cadena de consulta en la URL para que no sea tan malo :)

Answer 2

El marco MVC (Model View Controller) está diseñado específicamente para abordar este problema. Utiliza una forma de reescritura de URL para redirigir acciones a páginas y proporciona solo la funcionalidad que está buscando. Hace que manejar urls bonitas sea muy fácil.

Con respecto a la longitud de las URL, el ID todavía usa URLs bonitas, pero una URL particularmente larga puede ser una indicación de que es posible que desee reconsiderar su agrupación de los elementos, modifique la clasificación si así lo desea Products / {NAME} / {Address} sin partes de url intermedias.

Los ejemplos del marco MVC se pueden encontrar en:

.Net - http://www.asp.net/mvc/

PHP - http://www.phpmvc.net/

Java - http://struts.apache.org/

Answer 3

Puede usar un reescritura de URL o crear uno propio. ¿En qué idioma se desarrolló su sitio?

Answer 4

Tenemos una reescritura de url similar, y utilizando IIS 6, tenemos la redirección definida como:

/content.aspx?url=$S&$P

Esto toma una url de la forma

/ content / page / press_room y lo hace en el formato

/content.aspx/url=/page/pressroom&

No estoy seguro de las opciones synyax completas que tiene IIS, pero estoy seguro de que lo que desea se puede hacer de forma similar.

Answer 5

Esta pregunta trata principalmente sobre el diseño de URL y solo incidentalmente sobre la reescritura. Una vez que haya diseñado las URL para que sean geniales , existen muchas maneras de hacerlas funcionar, incluida la reescritura en el nivel del servidor o el uso de un marco web que hace un despacho basado en URL (creo que la mayoría de los marcos web modernos lo hacen actualmente).

La belleza está en el ojo del espectador, pero estoy de acuerdo con usted en que muchas URL de búsqueda son feas. ¿Qué los hace así? Creo que lo principal que hace que las URL sean feos es cruxt en la URL que no agrega significado semántico sino que es el resultado de un detalle de implementación, como (.aspx) u otras extensiones. Mi regla es que si una URL devuelve (X) HTML de lo que no debería tener una extensión, de lo contrario debería hacerlo.

En el caso de una búsqueda, el hecho es que la sintaxis de búsqueda estándar agrega significado: indica que la página es una búsqueda, indica que los argumentos son nombrados y reordenados. La fealdad proviene principalmente de los caracteres? & =, Pero realmente cualquier otra cosa que hagas será reemplazar estos mismos personajes con caracteres más atractivos como | - /, pero a costa de hacer que la URL sea opaca con cualquier software que desee analizarlo como una araña, un servidor proxy de caché u otra cosa.

Así que piense cuidadosamente sobre no usar la sintaxis estándar y asegúrese de tener una buena razón para hacerlo. Creo que si tus argumentos tienen un orden natural y todos deben definirse para que la búsqueda tenga sentido y sean compactos, podrías insertarlos en la URL. Por ejemplo, en una URL de blog puede tener:

/weblog/entries/2008
/weblog/entries/2008/11
/weblog/entries/2008/11/22

Para una búsqueda que defina las entradas de 2008, nov 2008 y 22 de noviembre de 2008, respectivamente. Tus URL deben ser únicas e inequívocas; a veces las personas ponen en / - / para los parámetros de búsqueda faltantes, que creo que es bastante compacto. Sin embargo, evitaría presionar parámetros potencialmente largos, como una consulta de texto de forma libre, en la URL. / weblog / entries / containing / here% 20is% 20some% 20freeform% 20text% 20blah% 20blah no es más atractivo que usar la sintaxis de la consulta.

Si vas a utilizar la sintaxis de consulta estándar, elegir nombres de argumento que sean significativos podría mejorar el atractivo, de alguna manera. products / search? description = "blah", aunque es más largo, es probablemente mejor que products / search? q = "blah". En este punto, está disminuyendo el rendimiento, creo.

Answer 6

Puede encontrar una respuesta sobre enrutamiento en .NET aquí:

¿Cuál es el mejor método para lograr la reescritura dinámica de URL en ASP.Net?

Allí puedes encontrar diferentes recursos sobre el tema.

Answer 7

Puedes obtener las URL "bonitas", pero no a través de los medios más bonitos ...

Puedes configurar tu URL para que sea algo así como:

/Products/Search/Type/{producttype}/Name_{name}/Address_{address}

Entonces una regla mod_rewrite algo así como:

RewriteRule ^Products/Search/Type/([a-z]+)(.*)?$ product_lookup.php?type=$1&params=$2 [NC,L]

Esto le dará 2 parámetros en su archivo product_lookup :

$type = {producttype}
$params = "/Name_{name}/Address_{address}"

A continuación, puede implementar un poco de lógica en su archivo product_lookup.php para recorrer $params , dividirlo en "/", convertirlo en tokenización de acuerdo con lo que esté antes del "_" y luego usar los parámetros resultantes en su búsqueda como siempre. , p.ej

// Split request params first on /, then figure out key->val pairs
$query_parts = explode("/", $params);
foreach($params as $param)
{
    $param_parts = explode("_", $param);
    // Build up associative array of params
    $query[$param_parts[0]] = $param_parts[1];
}
// $query should now contain the search parameters in an assoc. array, e.g.
// $query[''Name''] = {name};

Tener los parámetros como URL "bonitas" en lugar de POST les permite a los usuarios marcar búsquedas particulares más fácilmente.

Un ejemplo de esto en acción es http://www.property.ie/property-for-sale/dublin/ashington/price_200000-550000/beds_1/ - los parámetros seleccionados del usuario se indican con el "_" (rango de precios y camas) ) que se puede traducir internamente en cualquier formato de parámetro que necesite, manteniendo una URL legible.

El código anterior es un ejemplo trivial sin verificación de errores (delimitadores de delincuentes, etc. en la entrada), pero debería darle una idea de por dónde empezar.

También asume una pila LAMP (Apache para mod_rewrite y PHP) pero podría hacerse en la misma línea usando asp.net y un IIS mod_rewrite equivalente .