Como en anteriores ocasiones vamos desgranar todo el contenido en distintos puntos, en este caso hablaremos sobre 12 cosas que es importante que sepas sobre estos archivos. Algunas serán sabidas, otras espero que te sorprendan y, por supuesto, algunas serán válidas para unos proyectos u otros.

Qué son y qué deberías saber sobre los sitemaps.xml

Los Sitemap no son más que una vía que nos ofrecen los buscadores para que nosotros mismos les digamos qué páginas deberían rastrear. Como casi todo en herramientas de indexación son sólo sugerencias y Google, en realidad, visitará las páginas que le de la gana en el orden que él quiera. Sin embargo, en muchos proyectos en los que las arañas van un poco perdidas (más por defecto de la web que de las arañas de Google), los sitemaps.xml han demostrado ser de gran utilidad para guiarlas y ayudarlas a encontrar el contenido.

Los sitemaps.xml son uno de los primeros archivos que Google se preocupó por que conociésemos y eso ha conseguido que exista muchísima documentación sobre cómo crearlos. A día de hoy, la mejor referencia oficial que tenemos la encontramos en «sitemaps.org» en muchísimos idiomas. El protocolo es muy simple, pero tiene algunas peculiaridades.

Este es el formato normal de un archivo sitemaps.xml bien hecho:

   
     http://blog.ikhuerta.com
     2017-09-29
     monthly
     1.0

De esta estructura lo importante es sobre todo la declaración inicial. Si no definimos el sitemap como un XML y sus atributos xmlns, no será bien interpretado. Luego sólo se trata de ir añadiendo nodos <url> con sus detalles (de los que sólo <loc> es obligatorio). De hecho, la inmensa mayoría de los sitemaps verás que solo contienen el nodo «loc» y ningún otro detalle de las URLs.

La codificación de caracteres también es muy importante, sólo se admite UTF-8 así que hay que revisarla. Además, el sistema nos prohíbe de forma explícita el uso de ciertos caracteres. Si queremos usarlos tenemos que «escapearlos» en HTML, es decir, debemos usar un código HTML para identificar el carácter exacto que realmente deseamos incorporar.

Por suerte estos no son muchos:

Todo muy lógico, y no es nada que a un site con un poco de SEO On Page bien hecho le vaya a afectar. Pero tengámoslo en cuenta. Por ejemplo, ¿qué pasa con esta URL: «http://midominio.com?categoria=2&producto=25»? pues que en realidad en nuestro sitemap deberíamos incluirla como «http://midominio.com?categoria=2&amp;producto=25».

Por último, también hay que tener en cuenta que existe una restricción de tamaño:

• Máximo se nos permiten 50.000 URLs por archivo sitemap.xml
• Y el peso del archivo no podrá ser superior a los 50MB (así que cuidado con ajustar a 50.000 URLs como muchos hacen, para evitar problemas).

Bien, hasta aquí la teoría, pasamos a las cosas que a parte de la documentación básica deberíamos todos tener contempladas para hacer un buen uso de estos archivos.

1. La mayoría de sites no necesitan un sitemap.xml para nada

Esto no es sólo verdad, sino que si hacemos mal el archivo sitemap.xml podemos perjudicar más nuestra indexación que beneficiarla. Este es otro de los puntos clásicos de los SEOs que están empezando: en clase les dicen que los sitemaps.xml son esenciales y de ahí muchos entienden que cualquier site que no los tenga no indexará bien y mejoraría su indexación con ellos.

Esto no es cierto, estos archivos son una guía para que las arañas no se pierdan y sepan dónde acceder. Pero ¿qué pasa si no se pierden? Les estoy aportando algo con este archivo. Puede que sí, si tienes alguna estrategia de trabajo con ellos (veremos varios ejemplos más adelante), pero solo por subirlo con URLs y nada más no ganarás absolutamente nada con ello.

Así que, por ejemplo, para sites pequeños (normalmente con pocos recursos de desarrollo) y donde no vemos un problema de estructura evidente, nosotros desde IKAUE no solemos pedir archivos sitemaps.xml. El SEO siempre debe jugar en la línea de la rentabilidad y sin duda gastar tiempo de desarrollo en algo que no aporta absolutamente nada, no tiene sentido. Y no, la solución no es subir un archivo sitemap.xml estático que creas tú con cualquier programa… ¿Qué sentido tiene? ¿Vas a usar un crawler menor para ayudar a uno que es mucho más potente que el que tú usas? ¿Qué esperas encontrar que Google no pueda encontrar por sí mismo?

Como contra, además, tenemos a toda esas personas que por desconocimiento suben un sitemap sin tener mucha idea de SEO y encima provocan problemas de indexación que antes no tenía. Esto pasa más de lo que podría parecer en el sector. Os pongo algunos ejemplos de problemas que podemos provocar con sitemaps.xml mal realizados.

• Para empezar, si no lo haces bien puedes darle muchas URLs que en SEO te importan más bien poco su indexación. Esto pasa cuando los generas automáticamente. Le dices que te indexe páginas corporativas que antes no tenía indexadas y cosas así…
• También cuando te los generan desde desarrollo sin que pase nadie las indicaciones de qué deben contener, te puedes encontrar con cosas como URLs del entorno privado de usuario o páginas de gracias en el sitemap… ¿No quieres enseñarle eso a Google, verdad?
• Otro clásico, parecido al primero es cuando nos fiamos de nuestro CMS o de algún plugin  que lo genera todo. Ahí WordPress, Drupals y demás son unos expertos en conseguir indexar contenido basura. Taxonomías a las que no habías ofrecido URLs en tu página, Páginas de autor, de Archivos Mensuales, o peor aun, diarios… No todo suma. Por el contrario, todo esto resta.
• Finalmente, otro problema sucede con sites donde el rastreo de Google no llega a todas las páginas (con problemas de crawl budget). Nos encontramos con que le cuesta llegar a URLs muy profundas y decidimos subirlas al sitemaps «para ayudarle a encontrarlas». En estos casos podemos provocar que la araña ataque a páginas que tienen menos prioridad de posicionamiento del que tú les dabas en tu estructura. Por ejemplo, en una estructura web has relegado el posicionamiento de artículos muy viejos que no estaban bien enfocados hacia el target real de tu web a varios clics desde la home (asumiendo que muchos no se indexarán). Subes un sitemap y te alegras porque mejora la indexación de estos artículos. Pero, por otro lado, no te das cuenta de que el crawl budget sigue siendo el mismo que tenías (no lo has mejorado) y que la araña visite estos contenidos tan despriorizados acaba provocando, al cabo de un tiempo, la desindexación de otros que tampoco estaban en primera línea de indexación pero que tenías más priorizados que estos que ahora estás empezando a recoger. Cuidado con ese tipo de cosas que cuando pasan puedes no darte cuenta de que el problema lo has provocado tú mismo, ansiando mejorar la indexación. El crawl budget es el que es y el sitemap.xml no lo mejora.
• Por último, un problema (para mi menor) es que estamos poniendo a disposición de cualquiera que sea capaz de localizar este archivo todas nuestras URLs y todos los datos que pongamos sobre ellas a su alcance. La competencia en SEO se audita también y ponérselo un poco difícil no está de más. A mi me parece que, salvo excepciones, no es problemático que la competencia vea nuestros sitemaps, pero todo depende. Si esto te preocupa, es fácil de evitar: pongámosle a los archivos un nombre que no sea obvio y declarémoslos en Google Search Console y no en Robots.txt.

En definitiva, dos cosas a destacar:

1. En muchas webs no notarás ninguno de estos problemas por añadir un sitemap y
2. si no te lo tomas en serio puedes empeorar tu indexación en lugar de mejorarla. Como norma general, si no hay una estrategia clara detrás, no hagas un sitemap.

2. Declárale la guerra a los archivos de «mapa del sitio», esos no son los buenos.

Si es que en realidad es muy obvio que no ayudan pero sigue sucediendo. La gente lee sitemap y hace asociaciones raras. No es lo mismo un archivo XML de Sitemaps que un Mapa del sitio montado en una o varias páginas de la web.

Un sitemap.xml:

Es un archivo muy concreto que tus usuarios no ven y que sólo le ofreces a los rastreadores. Sólo cumple funciones SEO, no afecta a la usabilidad del site.

Un Mapa del sitio (o sitemap HTML o sitemap a secas):

Son páginas web que se usaban hace muchos años para suplir carencias de estructura en la web. Lo que hacían estas páginas era ofrecer una vía secundaria de indexación ante sites que no permitían a las arañas alcanzar el contenido saltando de link en link. Vamos, que se solucionaban carencias básicas del site creando páginas nuevas en el mismo.

Esto hace unos años era muy común. Teníamos Menús que se montaban en iframes o con flash. Las webs las hacían diseñadores, sin directrices y la UX ni tenía nombre…

Más adelante aún se usaron para casos específicos. Por ejemplo, era algo muy usado en Webs basadas en un buscador (clasificados, páginas de vuelos, etc.). La página tal y como estaba diseñada no ofrecía links hacia el contenido, así que se colocaba un link abajo de «mapa del sitio» donde link a link el contenido acababa siendo accedido por las arañas. Eran otros tiempos y las arañas eran mucho más tontas y nosotros sabíamos menos sobre cómo gestionarlas.

A día de hoy los mapas del sitio no tienen sentido. Existen métodos mucho mejores para conseguir que las arañas encuentren el contenido. Lo primero, es una arquitectura bien planificada y aprovechar los propios menús y bloques de enlaces del site. Si esto no es suficiente, es probable que necesitemos dar vías de acceso secundarias (las aerolíneas siguen haciéndolo) pero con una estructura muy cercana a una real de un site y con contenidos, no con simples páginas llenas de enlaces…

Lo peor de este sistema es que, quien lo tiene, cree que ha solucionado la papeleta y no es verdad… Lo dicho: muerte a los mapas del sitio. No los relaciones nunca con los sitemaps.xml. Estos últimos son una herramienta estupenda para hacer SEO, mientras que los desfasados mapas de sitio son sólo un vestigio del pasado tenebroso del SEO.

3. Podemos enviar a Google el sitemap de varias formas, no sólo mediante Google Search Console.

Este es uno de los puntos básicos pero vitales para que Google lea nuestro sitemap. El sitemap no es como el archivo robots que siempre queda alojado en la misma URL, sino que prácticamente podemos ponerle cualquier nombre. Así que hay que decirle a Google (o a Bing) donde buscar. Esto se hace mediante Google Search Console, donde encontraremos una sección llamada sitemap en la que podemos indicar esta URL. A esta acción la mal-llamamos «subir el sitemap». No subes nada, pero se le ha quedado este nombre.

Veremos más adelante que ésta es la mejor vía posible, pues nos da ciertas estadísticas sobre errores y su lectura, pero no es la única, en realidad podemos usar dos vías más para indicarle a Google estos archivos.

Indincándolo en el robots.txt:

Es una de las vías recomendadas y puede suponer una gran ventaja cuando hacemos implementaciones genéricas en muchos sites a la vez, o bien, por lo que sea, no podemos acceder al Google Search Console de cada dominio por separado. También puede ser una buena opción para buscadores menores. Por ejemplo, si vamos a trabajar sobre todo Google pero queremos que, ya de paso, Bing lea nuestros sitemaps (aunque no vayamos a trabajarlos en Bing) podemos añadirlo al Robots.txt y además darlos de alta en Google Search Console.

Es tan sencillo como declarar todos los archivos sitemaps que deseemos con la declaración «siteamap:» al principio de la línea.

Sitemap: http://www.midominio.com/mi-bonito-sitemap-1.xml
Sitemap: http://www.midominio.com/mi-bonito-sitemap-2.xml
Sitemap: http://www.midominio.com/mi-bonito-sitemap-3.xml
Sitemap: http://www.midominio.com/mi-bonito-sitemap-4.xml

Los buscadores los rastrearán, pero no nos darán la información de indexación y errores que sí veríamos en Search Console.

Haciendo «ping»:

Otra forma es hacer «ping» a una URL del buscador al que deseamos informar con la URL a leer. Un «ping» no es más que una solicitud a esta URL, sin más complejidades. Se carga la URL y el sistema se da por enterado. Esta solución también es válida para varios buscadores. Enviamos un ping a una URL con el siguiente formato:

 «{dominio buscador}/ping?sitemap={URL del Sitemap}»

Por ejemplo, para enviar a Google el ping de mi dominio llamaríamos a la siguiente URL:

http://www.google.es/ping?sitemap=http://www.midominio.es/sitemaps.xml

Esta es la forma más descontrolada, aunque puede servirnos para pegarle un toque de atención al buscador y que venga a mirar algo. Mucha gente lo usa, además, para intentar forzar rastreos: ante un update lanzamos pings de sitemaps que contienen las URLs con update intentando que la araña las visite. Si bien es cierto que subir sitemaps de URLs a realizar updates parece que algo sí que afecta. Yo al menos no he tenido mucha diferencia en hacer ping o no a sus sitemaps la verdad.

4. Los sitemaps.xml sólo afectan a archivos que están en su directorio o a mayor profundidad de éste.

Es decir, «midominio.com/carpeta1/carpeta2/sitemaps.xml» no debe contener enlaces a archivos de «midominio.com/carpeta1» o «midominio.com/» solo a los de «midominio.com/carpeta1/carpeta2/…»

Así que, por ejemplo, crear la típica carpeta de /sitemaps/ y alojar uno en «midominio.com/sitemaps/posts.xml» no es una buena idea, ya que en teoría estos enlaces no se seguirían.

Lo mejor que podemos hacer es que todos nuestros sitemaps queden en la raíz de nuestro dominio (así garantizamos que no tendremos este tipo de restricciones). También existe la posibilidad de tener las cosas bien organizadas y, por ejemplo, tener «/blog/sitemaps.xml» que solo tenga links a «/blog/…». No obstante, es más fácil equivocarse con estas URLs que obligando a que los archivos se queden en la raíz del dominio (sin usar carpetas).

Si realmente tenemos esta necesidad, lo que solemos hacer nosotros para ordenarlos es jugar con el nombre de los archivos. Por ejemplo, imagina que tienes un sitemap destinado al blog de la tienda de Madrid del site. Como no acabamos de fiarnos de meterlo en la carpeta «dominio.com/madrid/blog/sitemap.xml» porque algunas URLs podrían no estar en esta estructura, lo que sí podemos es emular algo parecido con en el nombre, poniéndole por ejemplo: «/sitemap-dominio-com–madrid–blog.xml».

5. Google no sólo admite sitemaps en XML, hay más formatos.

Y es que el sitemap.xml es sólo uno de los formatos admitidos (y el más completo y estándar, claro) pero hay otros que nos pueden ser muy muy útiles en otros casos. Puedes verlos todos en la documentación de Google sobre formatos de sitemap.

Podemos subir archivos sitemap.txt:

Estos están formados por un archivo muy simple que tan sólo contenga todas las URLs del site, una detrás de otra, cada una en una línea distinta. Google los lee igual y nos podemos evitar complejidades técnicas si tenemos prisa o trabajamos con el típico proyecto con recursos técnicos limitados…

Como sitemap básico funcionará igual, pero este sistema, por supuesto, no es el más recomendado por la sencilla razón de que perdemos muchas de las funcionalidades que veremos más adelante (dado precisamente a que solo indicamos URLs y nada más con ellos).

También podemos subir un RSS o Feed del site:

Esta es otra opción, aun menos conocida. Estos son archivos que se usan para sindicar el contenido, es decir, para que ciertas herramientas puedan ver las últimas publicaciones de una plataforma y leerlas. Son archivos XML que solo tienen contenido y no diseño. Si nunca has visto ninguno, puedes ver el de cualquier blog en WordPress añadiendo «/rss» al final de su URL. Por ejemplo, éste es el Feed de esta web. Subir este tipo de archivos suele suponer una mejora en la velocidad de indexación de nuevo contenido. Son sitemaps bastante consultados que, por lo general, sólo contienen 10 o 20 elementos y, por lo tanto, Google puede leerlos muy rápidamente.

6. Tenemos sitemaps de varios tipos, no solo de URLs.

Estamos acostumbrados a que los Sitemaps.xml se refieran a páginas HTML concretas, pero en realidad pueden contener otros tipos de información. Google tiene especificados 4 tipos de sitemap, entre los que destaca el estándar (URLs):

🔗 Estándar

🔗 Vídeo

🔗 Imagen

🔗 Noticias

Por supuesto, cuando lo que queremos es indexar contenido multimedia (algo que no siempre os recomendaría), los sitemaps especializados en vídeos e imágenes pueden ser muy útiles. Los de noticias también son útiles y podrían aprovecharse en sitios de noticias.

Por último mencionar que incluso podemos mezclar estas tipologías de sitemaps creando archivos que contengan sitemap de URLs, imágenes, vídeos, lo-que-quieras a la vez… Yo no lo haría porque no ayuda a entender las cosas mejor, pero existe esa posibilidad.

7. Muchos campos (que cuesta tiempo desarrollar) Google los ignora muchas veces  («por no hacerlo bien» dice).

Y aquí viene el gran dilema al trabajar con sitemaps… ¿ponemos todos los atributos o no?

Los sitemaps nos ofrecen 3 campos a añadir a la URL:

• lastmod: fecha de último cambio en la página
• changeFreq: cada cuánto tiempo aprox. cambia el contenido de esta página.
• Priority: de 0.1 a 1.0 (y solo en relación a las páginas del propio sitemap) cuán importantes son unas y otras.

Sobre su interpretación tenemos históricamente mensajes muy contradictorios por parte de Google, pero que a la que los lees te das cuenta de que todos tienen un hilo común. No voy a replicarlos porque son bastantes, pero os los resumo: por un lado, nos dicen que se ignora la fecha de modificación y la frecuencia porque nadie lo hacía bien. Por otro lado, que se ignora la prioridad porque no aportaba la información esperada. Pero siempre, en cada comentario que nos hacen, encontramos la coletilla «en la mayor parte de los casos».

Al final, todo esto significa que estas etiquetas bien gestionadas no se ignoran, pero que solemos gestionarlas mal y, cuando eso sucede, Google no les hace caso. Esto cuadra, casi en todos los aspectos es así: si Google no lo ve claro, ignora tus etiquetados. Así que asumamos que sí podemos usarlas, pero solo para usarlas bien, no para hacer el bruto.

Os comento algunos ejemplos de mala gestión que harían que Google ignorase estas etiquetas:

Sobre lastmod

• lastmod cuando usamos generadores de sitemaps.xml nos lo ponen a la fecha de creación del sitemap, lo cual no tiene sentido y más aún cuando todas las URLs tienen la misma fecha
• lastmod tampoco tiene sentido cuando lo usamos para manipular al buscador. Google sabe cuándo modificamos el contenido… si mentimos nos pilla.
• Por último, en contenidos donde la fecha aparece en el HTML, o bien, la tenemos marcada con schema, no podemos esperar que si no son fechas iguales nos haga caso.

¿Qué hacer con esta directriz?

Pensemos en su utilidad de cara al SEO. Realmente incorporarlo tan solo nos sirve para indicar a Google que se está perdiendo una actualización en uno de nuestros contenidos. Esperamos con ello que, al ver que su fecha de modificación es más reciente que la que él tiene en caché, venga a ver el contenido antes. Por ese motivo, yo os recomendaría lo siguiente:

• No lo marquéis en páginas o sitemaps que no podéis garantizar que su fecha implique sí o sí la última revisión del contenido único de la página.
• Marquémoslo solo en páginas de contenido (un lastmod en un listado es muy difícil de trabajar con seguridad).
• Usémoslo solo si realmente hacemos reediciones en el contenido y nuestra reindexación es tan lenta que tenemos que ayudar a Google a darse cuenta de que lo hemos cambiado.

Para todo lo demás. creo que es preferible no usarlo a usarlo mal y que eso invalide toda la etiqueta al leer nuestros sitemaps.

Sobre ChangeFreq

De nuevo, esta etiqueta suele usarse muy mal:

• Muchos sitemaps usan el daily para todo, esperando que así su contenido se revise más a menudo.
• Otros escriben incluso mal el texto, tan solo se permite especificado por la documentación.
• Y otros simplemente la lían mucho haciendo un etiquetado arbitrario, que nada tiene que ver con la realidad del cambio del contenido.

¿Cómo deberíamos usarlo?

• Para empezar, no lo indiquemos si no estamos dispuestos a trabajarlo bien y de forma bien automatizada (esta etiqueta no nos ayuda en sitemaps.xml estáticos). Partamos de la idea de que si nos pilla mintiéndole a nuestro favor, ignorará la etiqueta.
• Aún así, en muchos casos esta directriz ni siquiera va a tener sentido. ¿Cada cuánto cambia un contenido? Lo correcto sería indicar «never» pero, ¿queremos decirle a Google eso? ¿y si nos hiciese caso y nunca la revisitase? Pero lo cierto es que un contenido puede no cambiar nunca y todo lo que no sea un «never» es mentir al buscador.
• En listados muy dinámicos un «daily» en contraposición a los «never» o «yearly» de las fichas haciendo más que evidente que queremos más indexación en estos listados dinámicos.

En la práctica nosotros en IKAUE prácticamente nunca la indicamos porque son matices muy particulares y creemos poco en que las arañas vayan a cambiar su cola de indexación por esta directriz. Pero puestos a usarla yo solo la usaría en listados, para marcar diferencias entre los que añaden nuevos elementos constantemente (daily) y los que solo reciben nuevos elementos cada pocos días (weekly), esperando así optimizar mejor nuestro crawl budget, detectando mejor nuevos items en la web.

Sobre Priority

Como las anteriores, ésta también suele usarse muy mal:

• Los generadores automáticos de sitemaps nos marcan todo el site a priority «1.0» lo cual es como no decir nada.
• Muchos SEOs la intentan aprovechar para posicionar contenidos TOP que luego no se respaldan en absoluto por links, menús, autoridad, ni por ninguna otra señal.
• Otros intentan hacer cambios en sus sitemaps para provocar la reindexación de contenidos. Por ejemplo, tengo todo mi sitemap a 0.5 y cuando quiero que se reindexe un contenido cambio la prioridad de este a 1.0 esperando que esto provoque la visita de la araña. Esto no suele funcionar (aunque si lo que hacemos es subir otro sitemap nuevo a veces sí).

¿Cómo usar la directriz de priority?

Cuando no tenemos problemas de indexación el uso más lógico que podemos hacer del sitemap es ayudarnos a reforzar la estructura de la web marcando la importancia de cada una de nuestras webs. En estos sites subir el típico archivo de sitemaps donde todo el sitemap tiene priority «1.0» ya sabemos que es estúpido. Lo que tenemos que hacer es aprovechar este campo para reforzar la estructura/arquitectura del site. La misma definición de menús, URLs, Breadcrumbs e inlinks, debería ser consecuente con los datos indicados en priority.

Lo que buscamos es que Google vea que nuestras prioridades sí tienen sentido para que nos haga caso y así ayudarle a matizar lo más importante. Así encontrar que la home y secciones principales tienen prioridad 1.0 y vamos bajando hasta encontrar los productos estrella en prioridad 0.7 o 0.6 puede tener sentido. Haciéndolo así, no se nos permite colocar estos productos en máxima prioridad (mintiendo a Google) pero sí, al menos, diferenciar los importantes de los que no lo son (por ejemplo, marcando los importantes a 0.7 y los menos importantes a 0.5).

Hay que partir de nuestra definición de arquitectura web y luego hacer pequeñas modificaciones sin cosas demasiado drásticas que invaliden la directriz totalmente para Google.

8. Un sitemap nos permite suplir otras etiquetas de indexación como hreflang o canonical (aunque no es igual de potente).

Y aquí viene otra utilidad secundaria de los sitemaps. Todos sabemos que el proyecto web perfecto no existe… Todos tienen uno, dos o incluso muchos problemas. Hay cosas que sencillamente resulta un problema etiquetar en ciertas web. Abordamos ya cómo solucionar problemas de indexación desde cabeceras o indexación desde el robots, pero veamos dos posibilidades que sí que nos aportan los sitemaps para suplir a etiquetas concretas.

Marcar los hreflang desde el sitemap:

Los hreflang son una suerte de implementación en sites con orientación a varias regiones geográficas o simplemente idiomas. Su definición es en realidad sencilla: desde cada página web debo indicar en su cabecera y mediante etiquetas <link rel=»alternate» hreflang /> sus URLs equivalentes en otro idioma.

Esto que parece muy simple en la práctica si tu web por detrás no tiene estas equivalencias ya hechas (algo muy común en CMSs libres donde esta orientación multidioma no se había planeado desde un principio), o bien, si las maquetas son especialmente rígidas, puede ser un infierno para los programadores.

En estos casos, debemos saber que contamos con otra posibilidad: indicar estas relaciones en los archivos sitemap en lugar de (o además de) en la web. Su uso es igual de simple: en cada <url/> del sitemap indicamos además del nodo <loc> varios nodos <xhtml:link/> con las equivalencias de esa URL con otros idiomas. El problema sigue siendo el mismo: debemos identificar en cada URL todas sus posibles traducciones, pero al menos disponemos de otro lugar (muchas veces más programado a medida del SEO) donde hacer este trabajo.

Puedes ver cómo desarrollar estos sitemaps aquí, o simplemente guiarte por el ejemplo que te copio a continuación:

  
    http://www.midominio.com/como-hacer-sitemaps
    
    [... otras traducciones ...]
  
  [... otras urls ...]

Evitar canibalizaciones del contenido:

Y este es un método que desde luego no es equivalente a una buena etiqueta canonical pero sí que puede ayudarnos en ciertos momentos en los que tenemos canibalizaciones de contenido (entiéndase canibalizado como contenido duplicado interno en el cual uno posiciona por encima de otro haciendo a la segunda URL totalmente inútil).

En estos casos, lo que solemos hacer es decidir cuál de los dos contenidos queremos que sea el que se posicione y añadir una etiqueta canónica (sino un 301 directamente) desde las URLs secundarias a la principal. Pero sabemos que esto no es siembre fácil

Sin embargo, ¿sabías que ante duplicados internos, Google escoge casi siempre la URL que esté en el sitemap.xml? Lo indican ellos mismos en su documentación, mencionando que es un posible sustituto de etiquetas canónicas. Para ello, solo tenemos que tener un sitemap bien hecho, en el que evitemos incluir ninguna etiqueta que tenga riesgo de ser canibalizada. Es decir, en estos casos en los que varias URLs tienen el mismo contenido o apuestan por la misma keyword nos basta con solo incluir la URL principal en el sitemap, para que ésta sea la que muestre Google en sus resultados.

Salvo que por links recibidos nuestra elección de URL principal no tenga ningún sentido (por ejemplo: le indicamos una URL sin links internos dejando fuera a la URL que se enlaza desde todos los menús), Google nos hará caso.

No nos engañemos, esto no es como un canonical: no traspasa autoridad y ni siquiera tenemos garantías de que nos haga caso siempre (bueno, con los canonicals tampoco), pero es una vía secundaria que tener en cuenta cuando tenemos este tipo de limitaciones.

9. Los índices para sitemaps son lo mejor que puedes usar, ¡aprovéchalos siempre!

Dado que los Sitemaps.xml son finitos (tienen peso y URLs máximas) tuvieron que idear una forma por las que despiezarlos en distintos archivos. Para poder hacer eso, existe un tipo de archivo sitemap de índice. Son archivos en los que podemos indicar otros archivos sitemap. Las ventajas son claras: subimos un único archivo y desde éste controlamos todos los que ofrecemos a Google, automatizando su fragmentación.

Y es que al final intentar centralizar todo el sitemap en un único archivo tiene muchos riesgos:

• Corremos el riesgo de pasarnos del tamaño máximo.
• Nos cuesta mucho encontrar en él todas las URLs.
• Nos cuesta auditar sus prioridades.

Lo mejor es que para cada concepto, sección, lo-que-sea de la web creemos un sitemap distinto y usemos estos índices para organizarlo todo.

Crear un índice es sencillo y está bien documentado en siteamps.org, tan solo tenemos que indicar una rama «sitemapindex» donde podemos incluir elementos «sitemap» que tienen su localización y, de forma opcional, su última modificación con «lastmod» (al que aplicaríamos los mismos comentarios que al lastmod de las URLs).

   
      http://www.midominio.com/sitemap1.xml
   
      http://www.midominio.com/sitemap2.xml

10. ¡IMPORTANTE! Los sitemaps son la única forma de comprobar el porcentaje de indexación de nuestras URLS.

Uno de los mejores indicadores que nos dan los sitemaps cuando los subimos vía Google Search Console es el estado de indexación de la lista de URLS que les pasamos en ellos.

Esto lo hace para cada sitemap: lo subimos y al poco tiempo ya nos dice, para cada uno, cuántas URLs contenía y de ellas cuántas ha indexado. Solo tendremos que dividir una cifra sobre la otra para saber el porcentaje de indexación de dicho sitemap.

Pensando un poco sobre esto, no es difícil llegar a la conclusión de que no queremos subir sitemaps enormes a nuestro site: lo suyo es que subamos siempre un índice que apunte a una colección más o menos grande de sitemaps.xml parciales del site. ¿Cuántos? Depende de cuánta información quieras realmente recoger.

Por cada sitemap.xml fragmentado que creemos, tendremos un nuevo grupo de URLs del que conocer el estado de su indexación. Así que, a mayor cantidad de información que queramos saber sobre la indexación del site, más deberíamos fragmentar los sitemaps para conocerla. Ésta es una técnica medianamente conocida pero que aún conociéndola se usa poco y se aplica sin pensar demasiado en ella.

Os pongo dos ejemplos para que quede claro:

1. Imaginad que tenemos un blog del que vamos a subir los sitemaps.xml fragmentados en distintas piezas para conocer el estado de indexación de cada tipo de página. Una fragmentación básica nos haría crear los siguientes sitemaps:
   – Home.xml
   – Categorías.xml
   – Tags.xml
   – Posts.xml
   Con esto podremos saber qué porcentaje de cada tipo de página tenemos indexado. Seguramente si el blog tiene mucho tiempo y poco SEO técnico nos encontraremos con que cada tipología de contenido tiene gran cantidad de URLs sin indexar.
   Y esto esta bien saberlo pero, si solo vemos este tipo de cosas, no podremos accionarlo, no sabemos qué hacer para mejorar estas situación y no tenemos nada que hacer con esta información. Este suele ser el problema.
2. Ahora pensemos en aplicar a nuestra fragmentación del sitemap una lógica SEO. Pensamos en cada tipología de página, cuál puede ser su problemática de indexación. Por ejemplo, escogemos los posts donde estamos viendo el mayor porcentaje de contenido no indexado, los analizamos y vemos que es probable que se trate de un problema de antigüedad: a mayor antigüedad del post, más creemos que se habrá desindexado… Así que hacemos nuestra fragmentación del sitemap buscando obtener información justo por este criterio y, en lugar de subir un único sitemap de post, subimos la siguiente colección:
   – posts-novedad.xml –> Indexación 90%
   – post-ultimo-mes.xml –> Indexación 100%
   – posts-2-meses.xml –> Indexación 98%
   – post-3-6meses.xml –> Indexación 89%
   – posts-7-12-meses.xml –> Indexación 50%
   – post-1-2-anos.xml –> Indexación 55%
   – posts-2-3-anos.xml –> Indexación 57%
   Etc…
   La cantidad de indexación de cada uno de estos sitemaps sí que es un dato accionable. Puedo encontrarme con que a partir de los 6 meses empiezan a perder la indexación y descubrir que tengo problemas de rastreo profundos. O que los posts de hace más de 5 años siguen indexados pero los actuales no se indexan tan bien (demostrando un problema de autoridad y de calidad del contenido)…

Se pueden hacer muchas estrategias de este tipo. Incluso jugar a cambiar el patrón por el que dividimos estos sitemaps. Piensa, por ejemplo, en pasar Screaming Frog, sacar las URLs por distancia de rastreo desde la home y subir un sitemap temporal según distancia de rastreo para ver a partir de cuántos saltos empieza a sufrir la indexación. Sacamos el dato, lo accionamos y luego volvemos a usar los sitemaps de siempre…

Otra opción es simplemente hacer seguimiento, apuntar estos datos cada semana y así observar cómo mejora o empeora la indexación por zonas de la web.

11. Puedes alojar los sitemaps fuera de tu dominio.

Alguno habrá arqueado la ceja al leer este título… Y es que esto es raro pero tiene grandísimas ventajas sobre todo si llevas el SEO desde fuera de la web (como freelance, agencia, consultoría, etc.). Nunca os recomendaría alojar el sitemap general de vuestro site en otro dominio distinto al del propio site, pero para ciertas acciones y pruebas viene muy bien tener la posibilidad de poder ir haciendo subidas sin molestar a los desarrolladores de la web. Pensad solo en muchas de las posibilidades que hemos comentado en este post y veréis que tener un espacio donde no depender de IT para subir ciertos sitemaps bajo tu control te va a permitir realizar más acciones (o al menos de forma más rápida) de este tipo.

La idea es sencilla: a parte de los propios sitemaps de la web quiero tener la posibilidad de subirle sitemaps que no se alojen en ese dominio. ¿Dónde se alojarán? Pues en un dominio mío, uno en el que no dependo de IT y puedo acelerar ciertas acciones mientras IT responde a las guías y funcionales que les hemos pasado.

Para esto hay varias opciones:

A. Usar los sitemaps para sites múltiples:

Esto está documentado en esta URL y básicamente nos permite subir el sitemap de un dominio de la forma normal, solo que indicándole dentro del sitemap URLs de otros dominios.

Para esto, básicamente tenemos que hacer que el usuario que suba el sitemap.xml sea ADMIN del Google Search Console de los dos dominios. Así que en realidad nada impide que creemos un dominio tonto (sitemaps-seo.midominio.com), lo demos de alta en GSC y en él subamos nuestros propios sitemaps.xml para nuestros clientes. Esto siempre y cuando nos hayan dado privilegios sobre sus propios GSCs.

B. Indicar el sitemap.xml en el robots.txt ya directamente apuntando a otro dominio:

Este es otro recurso documentado incluso en la propia documentación de los sitemaps.org. Ahí nos dicen que podemos incluir en la directriz «sitemap: » del archivo robots un sitemap sin que importe que se encuentre o no en el dominio indicado.

Es decir, que si en midominio.com dispongo de un robots.txt que acaba con las siguientes líneas:

sitemap: http://midominio.com/sitemap-general.xml
sitemap: http://dominioAgenciaSeo.com/sitemap-agencia.xml

Leerá ambos. Si sumamos esto a que estos sitemaps pueden ser índices que controlan dónde leer cada archivo ya tenemos un mecanismo similar al de Google Search Console.

Que todo esto tiene sus riesgos, por supuesto, pero bien hecho es una puerta nueva que no hay que desaprovechar solo porque nos de miedo usarla.

12. Puedes usar sitemaps para alentar a las arañas a que visiten URLs que quieres que se miren (aunque no por ello que se indexen).

Por último y con una utilidad muy práctica si lo ligamos al punto anterior (subir sitemaps por tu cuenta), tenemos una vieja técnica que se basa en subir sitemaps.xml para forzar su rastreo. Es sabido que al ir haciendo actualizaciones de los sitemaps las URLs que ahí se contienen acaban tarde o temprano siendo visitadas, pero esto es por lo general aún más rápido (aunque tampoco va a ser inmediato) si lo que hacemos es subir sitemaps nuevos.

Así que tenemos una herramienta (la subida de nuevos sitemaps) que nos permite crearle a Google listas de URLs pendientes de rastrear y que nos puede venir muy bien sobretodo en ocasiones en las que por no ofrecer ya links a estas páginas o por tener un rastreo lento no nos acabamos de fiar del trabajo de las arañas.

Os listo algunos de estos casos:

• En una migración dejar el sitemap antiguo o incluso, mejor aún, subir un nuevo sitemap de URLs con 301 ayuda a que éstas se lean antes y asegura que todas terminen siendo leídas.
• Lo mismo para 301. Después de arreglos masivos de errores 404 que han sido sustituidos por 301, una subida de sitemap con estas URLs ayuda a que las arañas las recojan y asimilen.
• Ante una actualización de desindexación con meta-robots subir el sitemap también puede ayudar a agilizar su lectura.
• Subir un sitemap de URLs AMP en teoría no es estándar y no «es necesario» pero en algunos casos donde la indexación de páginas AMP se atasca nos ha resultado de mucha ayuda.
• No es bueno crear errores en nuestros sitemaps pero para validar el bloqueo de URLs en grandes listados también podemos subir un sitemap con todas las URLs que deberían estar bloqueadas en el site y ver que, efectivamente, el validador nos da errores al tener éstas bloqueadas.

Y bueno, en definitiva, nos ayuda a comprobar o intentar agilizar la indexación tras nuestras actualizaciones en la web. Siempre que queramos que las arañas pesen por sitios atípicos por los que normalmente tardarían en pasar, una subida puede ponerlas en marcha, nunca será algo excesivamente rápido pero ayudará a que no se eternice.

Como decía, si unimos este punto además al anterior, por el cual podemos subirle a un cliente sitemaps.xml en nuestro propio dominio, tenemos un sistema de control de la indexación que no afecta al desarrollo de la web y que nos aportará en ciertos momentos el extra que necesitamos.

Conclusión

Los sitemaps son unos archivos muy poco mimados por gran cantidad de SEOs. Como son fáciles de definir y no arrojan grandes complicaciones más allá de conseguir el propio listado de URLs, para muchos el trabajo queda ahí. Incluso como decíamos al principio es una zona que mucha gente acaba cuidando tan poco que hacen más mal que bien…

Sin embargo, son una herramienta que trabajadas al detalle pueden ser un gran aliado tanto para mejorar nuestra indexación, para hacer un análisis de la indexación o para suplir distintas carencias técnicas del SEO de nuestro site.

El problema con estos archivos sigue siendo siempre el mismo: la base hay que programarla para que tenga sentido. Los desarrollos a medida no suelen haberlos tenido en cuenta y muchos CMS que los desarrollan mediante plugins (al hacerlo de forma genérica) no acaban de ser lo que necesitamos. Solo tras una planificación y definición estratégica adecuadas empezamos a hacer auténticas virguerías con estos archivos.

Hay muchos tipos de SEO y muchos estadios de evolución en una estrategia SEO, no creo que esto sea de lo primero a atacar (por complejo) pero sí tengo clara una cosa: al hacer un sitemap debemos tomarnos nuestro tiempo y hacerlo bien. Si no vas a mimarlos, mejor no los uses.