¿Permitir caracteres no ingleses (ASCII) en la URL para SEO?

Question

Tengo un montón de contenido UTF-8 que quiero insertar en la URL para fines de SEO. Por ejemplo, publicar etiquetas que quiero incluir en el URI (site.com/tags/id/TAG-NAME). Sin embargo, solo los caracteres ASCII están permitidos por los estándares.

caracteres permitidos en un URI pero que no tienen un propósito reservada son llamada sin reservas. Estos incluyen letras mayúsculas y minúsculas, dígitos decimales, guión, punto, subrayado y tilde.

El solution seems a ser:

• Convierte la cadena de caracteres en una secuencia de bytes utilizando la codificación UTF-8 codificación
• Convertir cada byte que es no una carta ASCII o dígitos a% HH, donde HH es el valor hexadecimal de el byte

Sin embargo, eso convierte las palabras legibles (y SEO valiosas) into mumbo-jumbo. Entonces, me pregunto si Google todavía es lo suficientemente inteligente como para manejar búsquedas en URL que contienen datos codificados, o si debo intentar convertir esos caracteres no ingleses a sus contrapartes semi ASCII (lo que podría ayudar con los idiomas latinos).

Answer 1

En primer lugar, los motores de búsqueda realmente no se preocupan por las URL. Ayudan a los visitantes: los visitantes se vinculan a los sitios, y los motores de búsqueda se preocupan por eso. Las URL son fáciles de enviar, si se preocupan, habrá un incentivo para el correo no deseado. No hay grandes buscadores que lo quieran. El allinurl: es simplemente una función de Google para ayudar a los usuarios avanzados, no algo que se incluye en las clasificaciones orgánicas. Cualquier beneficio que obtenga al usar una URL más natural probablemente sea un beneficio marginal del PR de un buscador inferior que indexe su sitio, y hay alguna evidencia de que esto puede ser negativo con la aparición de relaciones públicas negativas también.

De Google Webmaster Central

¿Eso significa que debe evitar reescritura de URLs dinámicas en absoluto?

Eso es nuestra recomendación, a menos que sus reescrituras se limitan a la eliminación de parámetros innecesarios, o eres muy diligente en la eliminación de todas las parámetros que podrían causar problemas. Si transforma su URL dinámica a para que se vea estática, debe ser consciente de que es posible que no podamos interpretar la información correctamente en en todos los casos.Si desea servir un equivalente estático de de su sitio, es posible que desee considerar la transformación de en el contenido subyacente al servir un reemplazo que es verdaderamente estático. Un ejemplo sería generar archivos para todas las rutas y hacerlas accesibles en algún lugar de su sitio. Sin embargo, si está utilizando la reescritura de URL (más bien que haciendo una copia del contenido) a produce URL de aspecto estático desde un sitio dinámico , podría estar haciendo daño en lugar de hacerlo bien. Siéntase libre de servir su URL dinámica estándar y nosotros encontrará automáticamente los parámetros que son innecesarios.

Personalmente, no creo que importe tanto como obtener un poco más de clics y ayudar a los usuarios. En cuanto a Unicode, no entiende cómo funciona esto: la solicitud va al destino Unicode codificado en hexadecimal, pero el motor de representación debe saber cómo manejar esto si desea decodificarlos de nuevo a algo visualmente atractivo. Google will render (aka decode) unicode (encoded) URL's properly.

Algunos navegadores lo hacen un poco más complejo al codificar siempre la parte de nombre de host, debido a phishing attacks using ideographs that look the same.

Yo quería mostrar un ejemplo de esto, aquí es la solicitud de http://hy.wikipedia.org/wiki/Գլխավոր_Էջ emitido por wget:

Hypertext Transfer Protocol 
    GET /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB HTTP/1.0\r\n 
     [Expert Info (Chat/Sequence): GET /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB HTTP/1.0\r\n] 
      [Message: GET /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB HTTP/1.0\r\n] 
      [Severity level: Chat] 
      [Group: Sequence] 
     Request Method: GET 
     Request URI: /wiki/%D4%B3%D5%AC%D5%AD%D5%A1%D5%BE%D5%B8%D6%80_%D4%B7%D5%BB 
     Request Version: HTTP/1.0 
    User-Agent: Wget/1.11.4\r\n 
    Accept: */*\r\n 
    Host: hy.wikipedia.org\r\n 
    Connection: Keep-Alive\r\n 
    \r\n 

Como se puede ver, WGET como cualquier otro navegador se acaba de cifrar la URL de destino para que, y continuar la solicitud al destino codificado en url. El dominio url decodificado solo existe como una conveniencia visual.

Answer 2

¿Sabes en qué idioma estará todo? ¿Está todo basado en latin?

Si es así, sugiero construir una especie de tabla de búsqueda que convierta UTF-8 en ASCII cuando sea posible (y sin colisiones). Algo así podría convertir Ź en Z y cosas así, y cuando hay una colisión o el personaje no existe en tu tabla de búsqueda, entonces solo usa% HH.