Discourse ahora responderá con una cabecera X-Robots-Tag: noindex cuando la página solicitada no sea la página canónica de un recurso.
Si bien Discourse utiliza un diseño de desplazamiento automático tanto para las listas de temas como para los temas, esto no es lo que mostramos a los rastreadores de motores de búsqueda, como GoogleBot. Los motores de búsqueda ven temas paginados, con 20 publicaciones en cada página. Sin embargo, dado que los usuarios pueden enlazar a publicaciones específicas en sus propias publicaciones y lo harán utilizando el formato de URL /t/title/topic_id/post_id, estos serán captados por los rastreadores y agregarán contenido duplicado a los resultados de búsqueda de su sitio y desperdiciarán el valioso y limitado presupuesto de rastreo que tiene su dominio.
Para aliviar este problema, nuestra comunidad de usuarios sugirió agregar X-Robots-Tag: noindex a URL como las URL específicas de publicaciones, lo que logramos expandir a todas las URL no canónicas en Discourse. Esto se lanzó como una configuración de sitio oculta y deshabilitada por defecto hace 3 meses, durante los cuales experimentamos con esta cabecera habilitada en sitios comunitarios, así como en meta.discourse.org.
Dado que los resultados de este período parecen buenos hasta ahora, acabamos de activar esta configuración para que esté en vigor por defecto.
Si por alguna razón no desea este comportamiento en su instancia, aún puede habilitar la indexación de páginas no canónicas ejecutando docker exec -i app rails runner \"SiteSetting.allow_indexing_non_canonical_urls = true\" en su servidor.
No espere cambios drásticos en el rastreo y los resultados de búsqueda de la noche a la mañana, pero durante los próximos meses debería ver una disminución de los rastreos y resultados de búsqueda en páginas específicas de publicaciones, lo que resultará en que se dedique más tiempo de rastreo a los nuevos temas de su sitio y al contenido que aún no se ha indexado debido a las restricciones de presupuesto de rastreo en su dominio.
TL;DR: No bloquees páginas no canónicas; simplemente señálalas a una URL correcta mediante \u003clink rel=\"canonical\" … \u003e; para eso está hecha.
Esta función podría perjudicar la creación de enlaces SEO a largo plazo:
¡Todos los enlaces profundos a respuestas dentro de temas están ahora en páginas noindex! ¿Le gusta esto a Google?
En realidad, una etiqueta canonical que siempre apunte a la URL del tema, incluso para las páginas que enlazan profundamente a una respuesta, debería hacer el trabajo perfectamente, sin añadir X-Robots-Tag: noindex:
En la primera rastreo de una página de respuesta con enlace profundo, Google reconoce que la URL de la página (respuesta dentro del tema) no coincide con la URL canónica y luego decide rastrear solo la URL canónica (tema).
¿Podemos añadir \u003ca rel=\"nofollow\" …\u003e a todos los enlaces que realizan este enlace profundo de tema-respuesta? Edición: no, ver Search engines now blocked from indexing non-canonical pages - #9 by j127
De este modo, podríamos ahorrar aún más de este valioso y limitado presupuesto de rastreo de los motores de búsqueda:
el motor de búsqueda no extraerá el enlace en primer lugar ni realizará una llamada a la URL. Como llamar a la URL da como resultado una respuesta con una cabecera http X-Robots-Tag: noindex que hace que la respuesta sea “descartada” al añadir la URL a la lista interna de “noindex” de los motores de búsqueda.
Algunos ahorros más en el presupuesto de rastreo con nofollow añadido a las URL de los feeds RSS:
Creo que la función no debería estar activada por defecto. Es peligrosa desde el punto de vista del tráfico, incluso si solo está activada por un breve período, por lo que cualquiera que actualice ahora podría tener una sorpresa desagradable.
La etiqueta canonical es la forma que Google recomienda para solucionar ese problema, y ya parece estar funcionando. Hacer cosas raras con las etiquetas canónicas puede llevar a problemas extraños con Google, y un error de noindex podría ser difícil de recuperar.
Estoy de acuerdo con la primera parte de tu publicación, pero no creo que el nofollow interno sea ideal. Los enlaces internos ayudan a indicar a los motores de búsqueda qué páginas del sitio son importantes. Google no seguirá todos los enlaces que vea, porque sabe que ya los ha visto antes. Si ven una URL como example.com/t/1234/5 pero ya la han rastreado y saben que su URL canonical es example.com/t/1234, probablemente no malgastarán sus recursos informáticos visitando la versión no canónica varias veces.
Eliminar ‘noindex’ para URLs enlazadas por sitios web externos
Lo siento, por “respuestas” me refiero a “publicaciones” en un tema:
Todos los enlaces profundos desde dominios externos a publicaciones (por ejemplo, forum.example.com/t/example-topic/5/11) ahora tienen una cabecera http X-Robots-Tag: noindex. Sugiero eliminar esta cabecera http de nuevo.
Sugiero que para <link rel="canonical" … > nunca se use una URL con un ancla de publicación (el último número en …/t/example-topic/1234/5) en ningún lugar. Las URL canónicas siempre deben apuntar a la URL del tema en sí (…/t/example-topic/1234). Creo que ya está implementado de esta manera.
Reescribir enlaces para motores de búsqueda si la URL de destino es “redirigida” por <link rel="canonical" … >
Muy buen punto, es mejor no añadir rel="nofollow" aquí.
Discourse tiene una vista especial para los rastreadores. Nueva sugerencia solo para la vista de rastreadores:
Convierte todos los enlaces internos que apuntan a una URL de publicación (example.com/t/1234/5) para que apunten a la URL del tema correspondiente (example.com/t/1234) en su lugar.
Intención: No anunciar URLs adicionales a los motores de búsqueda cuando estas URLs adicionales son “redirigidas” de todos modos por <link rel="canonical" … >.
Ubicaciones donde se encuentran dichos enlaces a publicaciones:
enlaces añadidos manualmente en contenido de usuario
enlaces generados automáticamente en
citas
primera publicación del tema: “enlaces de seguimiento entrantes” de otros temas
primera publicación del tema: “respuesta seleccionada”
primera publicación del tema - mapa del tema abierto: “enlaces de tema”/“enlaces de me gusta”
Excursus: ¿Dónde encuentra Google todas estas URLs?
“Enlaces de seguimiento entrantes” para motores de búsqueda
Precisamente por esta razón, los “enlaces de seguimiento entrantes de otros temas” generados automáticamente en la primera publicación de un tema también deberían ser visibles por los motores de búsqueda. Ahora mismo, estos “enlaces de seguimiento entrantes” faltan en la vista del rastreador. Edición: Ya están en la vista del rastreador.
Pero apuntando a la URL de la publicación en lugar de la URL del tema (ver fuente html)
<div class="crawler-linkback-list" itemscope="" itemtype="http://schema.org/ItemList">
<div itemprop="itemListElement" itemscope="" itemtype="http://schema.org/ListItem">
<a href="https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/26" itemscope="" itemtype="http://schema.org/DiscussionForumPosting" itemprop="item">
<meta itemprop="url" content="https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/26">
<span itemprop="name">Eliminar los enlaces /2, /3, /4, etc. para cada respuesta dentro de la URL de un tema</span>
</a>
<meta itemprop="position" content="2">
</div>
</div>
Este es un punto crucial. Una cosa es conseguir que todas tus páginas sean indexadas y otra muy distinta es conseguir una clasificación relevante para ellas. En mi experiencia (con sitios de grandes editores), los enlaces internos inteligentes son la clave para lograrlo.
Para cualquiera que actualice su sitio desde la fecha de publicación del OP.
Tenemos datos que muestran que la nueva cabecera reduce el tiempo de rastreo en esas páginas, y siempre tuvieron la canónica configurada.
Pero esas páginas no están destinadas a ser rastreadas de todos modos. Los metadatos con la URL se establecen a nivel de tema, no queremos que Google rastree el nivel de publicación, ya que es contenido duplicado.
Genial, así que no hay nada que cambiar aquí.
Hacer eso en tiempo de ejecución puede ser demasiado costoso en CPU, y guardar dos versiones de cada publicación sería costoso en disco.
Nuestros valores predeterminados son siempre lo que recomendamos. Sin embargo, mantenemos y anunciamos la configuración del sitio para que las personas puedan elegir de otra manera si sienten que un valor predeterminado no es ideal para su sitio.
Entonces, ¿podría haber problemas con sitemap_recent.xml que contenga enlaces como este? https://meta.discourse.org/t/category-moderator-improvements/158628?page=2
Veo una gran diferencia cuando hay un enlace externo a una URL de publicación.
# A:
Dominio Externo
|
|--(link juice)---> URL de publicación
|
|__/ rastreo: \---> URL de publicación no indexada y
\ cabecera noindex / el link-juice mayormente perdido
# B:
Dominio Externo
|
|--(link juice)---> URL de publicación
|
|__/ rastreo: \__|---> URL de publicación no indexada
\ respuesta canónica / |---> URL del tema indexada (de todos modos)
con transferencia de link-juice
Para los neófitos como yo en lo que respecta al SEO, ¿implica que es una mejora del SEO que podría conducir a un ligero aumento/beneficio en los resultados de búsqueda de Google?
Probamos el cambio en una comunidad de noticias tecnológicas durante unos meses y vimos un gran aumento pico a pico en las visitas anónimas a las páginas. Nuestro objetivo final es siempre hacer que todas las comunidades de Discourse sean más saludables en todos los frentes.
… Sugiero la siguiente implementación para obtener el mejor compromiso:
No agregue el encabezado http X-Robots-Tag: noindex.
– teniendo en cuenta [E] –
Mantenga las etiquetas canonical siempre apuntando a la URL del tema.
– disminuyendo rastreos [A] y considerando [C] –
Solo para la vista del rastreador: Convierta los enlaces generados automáticamente para que siempre enlacen a la URL del tema en lugar de a la URL de la publicación, para todos los enlaces en la primera publicación del tema “enlaces de seguimiento entrantes de otros temas” y “mapa del tema abierto: enlace de tema/enlaces gustados”.
– disminuyendo rastreos [A] y considerando [D], pero ignorando deliberadamente [B] –
En [B]: los gastos de CPU son solo para visitas de rastreadores y consisten en hacer un reemplazo de expresiones regulares para eliminar el último número de las URL internas que terminan en dos números, por ejemplo, …/t/ejemplo-tema/1234/5 → …/t/ejemplo-tema/1234 dentro de los límites de la primera publicación del tema “enlaces de seguimiento entrantes de otros temas” y “mapa del tema abierto” solamente.
Para todas las vistas: agregue nofollow interno a las citas y a los enlaces añadidos manualmente en el contenido del usuario.
– disminuyendo rastreos [A] y considerando [B], pero ignorando ligeramente [D] –
En [D]: los enlaces importantes ya se duplican automáticamente en el primer tema en la sección “mapa del tema abierto: enlace de tema/enlaces gustados” [ver 3.] y la mayoría de las citas permanecen dentro del propio tema de todos modos.
Para Google, el enlace va directamente a la URL canónica del tema …/1234, y Google no se entera de la URL de la publicación …/1234/5 a partir de esta sintaxis de enlace.
Para la navegación del usuario, un JavaScript adicional en la aplicación Ember hará el truco:
por ejemplo, reemplace href con routerLink.
Importante
