12 cosas que debes saber sobre los sitemaps.xml

Hoy nos toca el tercer post especializado en sistemas de indexación posicionamiento SEO. Ya hemos abordadoy lapara supervisar la indexación. Ahora nos toca trabajar con otro de los archivos más conocidos del SEO: los archivos sitemaps.xml. Como en precedentes ocasiones vamos desgranar todo el contenido en distintos puntos, en este caso vamos a hablar sobre doce cosas que es esencial que sepas sobre estos archivos. Algunas serán sabidas, otras espero que te sorprendan y como es natural algunas serán validas para unos proyectos u otros.

Los Sitemap no son más que una vía que nos ofrecen los buscadores para que nosotros mismos les afirmemos que páginas deberían rastrear. Como casi todo en herramientas de indexación son solo 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 (más por defecto de la página web que de las arañas de Google) las arañas van un poco perdidas han probado ser de enorme utilidad para guiarlas y ayudarlas a encontrar el contenido.

Los sitemaps.xml son uno de los primeros ficheros que Google se preocupó por que conociésemos y eso ha logrado que exista muchísima documentación sobre como crearlos. A día de hoy la mejor referencia oficial que tenemos la encontramos en "en muchísimos idiomas. El protocolo es muy simple pero tiene algunas peculariedades.

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

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

La codificación de caracteres también es fundamental, solo se acepta UTF-8 así que hay que repasarla. Además el sistema nos prohíbe de forma explicita el uso de ciertos caracteres. Si deseamos emplearlos tenemos que "escapearlos" en código HTML, es decir, debemos emplear un código HTML para identificar el carácter preciso que realmente queremos incorporar.

Por suerte estos no son muchos:

Todo muy lógico, y no es nada que aun site con un tanto de posicionamiento en buscadores onpage bien hecho le vaya a afectar. Mas tengámonos en cuenta. Por ejemplo, ¿qué pasa con esta url: "?categoria=2&producto=25"? pues que en realidad en nuestro sitemap deberíamos incluirla como "?categoria=2&producto=25".

Por último hay una restricción de tamaño:

• Máximo se nos permiten cincuenta URLs por archivo sitemap.xml
• Y el peso del fichero no podrá ser superior a los 50MB (así que cuidado con ajustar a 50.000 urls como hacen muchos que la podéis liar)

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

Esto no es solo verdad, sino que si hacemos mal el fichero sitemap.xml podemos hacer más mal a la indexación que bien. Este es otro de los puntos clásicos de los SEOs que están empezando: en clase les afirman 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 donde acceder. Pero ¿que pasa si no se pierden? Les estoy aportando algo con este archivo. Puede que si, si tienes alguna estrategia de trabajo con ellos (vamos a ver múltiples ejemplos más adelante) pero solo por subirlo con URLs y nada más no ganarás nada con ello.

Así que por poner un ejemplo para sites pequeños (normalmetne con escasos recursos de desarrollo) y donde no vemos un problema de estructura evidente nosotros desde IKAUE no acostumbramos a solicitar archivos sitemaps.xml. El SEO siembre debe jugar en la línea de la rentabilidad y sin duda gastar tiempo de desarrollo en algo que no aporta nada no tiene sentido. Y no, la solución no es subir un archivo sitemap.xml estático que creas tu con cualquier programa... ¿qué sentido tiene? ¿Vas a utilizar un crawler menor para ayudar a uno que es mucho más potente que el que tu empleas? ¿Que esperas encontrar que google no pueda encontrar por si acaso mismo?

Como contra además tenemos a toda esta gente que sube un sitemap sin tener mucha idea de SEO y encima provoca inconvenientes de indexación que ya antes no tenía. Esto pasa más de lo que podría parecer (hay demasiados "primos de" o "amigos de" haciendo posicionamiento en buscadores para webs pequeñas). Os pongo algunos ejemplos de problemas que podemos provocar con sitemaps.xml mal realizados.

• Para iniciar si no lo haces bien puedes darle muchas URLs que en posicionamiento en buscadores te importan más bien poco su indexación. Esto pasa cuando los produces automáticamente. Le dices que te indexe paginas corporativas que ya antes no tenía indexadas cosas así. También en el momento en que te los producen desde desarrollo sin que pase nadie las indicaciones de qué deben contener te puedes localizar con cosas URLs del ambiente privado de usuario o páginas de gracias en el sitemap... ¿En serio deseamos enseñarle eso a Google?
• Otro clásico similar al primero es cuando nos fiamos de nuestro CMS o bien de algún complemento de esos que lo genera todo. Ahí WordPress, drupals y cosas así son unos expertos en conseguir indexar contenido basura. Taxonomias a las que no habías ofrecido URLs en tu página, Páginas de autor, de Ficheros Mensuales (o peor aun diarios). No todo suma, todo esto resta
• Finalmente otro problema sucede con sites donde el rastreo de Google no llega a todas y cada una de las páginas (con inconvenientes de). Nos hallamos 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 tu les dabas en tu estructura. Por poner un ejemplo, en una estructura web has apartado el posicionamiento de artículos viejísimos que no estaban bien enfocados hacia el objetivo real de tu página 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 percatas de que el crawl budget prosigue 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 cierto tiempo la desindexación de otros que tampoco estaban en primera línea de indexación pero que tenias más priorizados que estos que ahora estás comenzando a recoger. Cuidado con ese tipo de cosas que cuando pasan puedes no percatarte de que el problema lo has provocado tu mismo con tus ansias de 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 ponemos a disposición de cualquiera que sea capaz de encontrar este fichero todas nuestras URLs y todos y cada uno de los datos que pongamos sobre ellas a su alcance. La competencia en posicionamiento web en buscadores se audita también y ponérselo un poco difícil no está de más. A mi me da la sensación de que salvo salvedades no es problemático que la competencia vea nuestros sitemaps, pero todo depende. Si esto te preocupa, es fácil de evitar: pongámonos a los archivos un nombre que no sea obvio y declaremoslos en Google Search Console y no en Robots.txt.

En terminante dos cosas a destacar: a) en muchas webs no notaras ninguna por añadir un sitemap y b) si no te lo tomas en serio puedes empeorar tu indexación en vez de mejorarla. Como norma general, si no hay una estrategia clara detrás no hagas un sitemap.

Si es que en realidad es muy obvio que no asisten pero sigue sucediendo. La gente lee sitemap y hace asociaciones raras. No es exactamente lo mismo un fichero XML de Sitemaps que un Mapa del sitio montado en una o múltiples páginas de la página web.

Un sitemap.xml:

Es un archivo muy concreto que tus usuarios no ven y que solo le ofreces a los rastreadores. diseñador web barcelona funciones posicionamiento SEO, no afecta a la usabilidad del site

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

Son páginas web que se empleaban hace muchos años para sustituir faltas de estructura en la web. Lo que hacían estas páginas era, ante sites que no permitían a las arañas lograr el contenido saltando de enlace en link ofrecer una vía secundaria de indexación. Vamos, que se solucionaban faltas 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 aun se usaron para casos específicos: Por servirnos de un ejemplo era algo muy utilizado 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 cara el contenido así que se colocaba un link abajo de "mapa del sitio" donde link a link el contenido terminaba siendo accedido por las arañas. Eran otros tiempos y las arañas eran mucho más tontas y nosotros sabíamos menos sobre como gestionarlas.

A día de el día de hoy los mapas del sitio carecen de sentido. Existen métodos mucho mejores para lograr que las arañas encuentren el contenido. Lo primero es una arquitectura bien planeada y aprovechar los propios menús y bloques de enlaces del site. Si esto no es suficiente es probable que precisemos dar vías de acceso secundarias (las aerolíneas prosiguen haciéndolo) pero con una estructura muy próxima 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 cierto... Lo dicho: Muerte a los mapas del lugar. No los relaciones jamás con los sitemaps.xml. Estos últimos son una herramienta estupenda para hacer posicionamiento web mientras que los desfasados mapas de sitio son solo un vestigio del pasado tenebroso del posicionamiento SEO.

Uno de los puntos básicos mas vitales a fin de que Google lea nuestro sitemap. El sitemap no es como el fichero robots que siempre y en toda circunstancia queda alojado en la misma URL sino que practicamente podemos ponerle cualquier nombre. Así que hay que decirle a Google (o bien a bing) donde buscar. Esto se hace mediante Google Search Console, donde encontraremos una sección llamada sitemap donde 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 esta es la mejor vía posible pues nos da ciertas estadísticas sobre fallos y su lectura, pero no es la única, realmente podemos emplear 2 vías más para apuntarle a Google estos ficheros.

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 con 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 web menores. Por ejemplo, si vamos a trabajar sobretodo Google pero deseamos que ya de paso Bing lea nuestros sitemaps (si bien no vayamos a trabajarlos en bing) podemos añadirlo al Robots.txt y además darlos de alta en Google Search Console.

Es tan fácil como declarar todos y cada uno de los archivos sitemaps que deseemos con la declaración "siteamap:" al principio de la línea.

Los buscadores los rastrearán pero no nos darán la información de indexación y fallos que si 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 petición a esta URL sin más complejidades. Se carga la URL y el sistema se da por enterado. Esta solución también es valida para múltiples buscadores web. Mandamos un ping a una URL con el siguiente formato "dominio buscador/ping?sitemap=URL del Sitemap". Por servirnos de un ejemplo para enviar a Google el ping de mi dominio llamaríamos a la siguiente URL.

Esta es la manera más desmandada 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 reastreos: frente a un update lanzamos pings de sitemaps que poseen las URLs con update procurando que la araña las visite. Aunque es cierto que subir sitemaps de URLs a efectuar updates parece que algo si que afecta yo por lo menos no he tenido mucha diferencia en hacer ping o no a sus sitemaps la verdad.

Es decir "midominio.com/carpeta1/carpeta2/sitemaps.xml" no debe contener enlaces a ficheros de "midominio.com/carpeta1" o bien "midominio.com/" solo a los de "midominio.com/carpeta1/carpeta2/..."

Asi que por poner un ejemplo crear la típica carpetita de /sitemaps/ y por poner un ejemplo alojar uno en "midominio.com/sitemaps/posts.xml" no es una gran idea puesto que en teoría estos links no se seguirían.

Lo mejor que podemos hacer es que es que todos nuestros sitemaps queden en la raiz de nuestro dominio (así garantizamos que no tendremos esta clase de limitaciones). También existe la posibilidad de tener las cosas bien organizadas, y por poner un ejemplo tener "/blog/sitemaps.xml" que solo tenga links a "/blog/..." pero es más fácil confundirse con estas URLs que obligando a que los archivos se queden en la raiz del dominio (sin emplear carpetas).

Lo que solemos hacer nosotros para ordenarlos es (si realmente tenemos esta necesidad) jugar con el nombre de los ficheros. Por poner un 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 carpetita "dominio.com/madrid/blog/sitemap.xml" pues ciertas URLs podrían no estar en esta estructura lo que si podemos es imitar algo parecido con en el nombre poniéndole por nombre por ejemplo: "/sitemap-dominio-com--madrid--blog.xml"

Y es que el sitemap.xml es solo uno de los formatos aceptados (y el más completo y estándar, claro) pero hay otros que nos pueden ser realmente muy útiles en otros casos. Puedes.

Podemos subir archivos sitemap.txt, formados por un fichero muy simple que solo 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 eludir complejidades técnicas si tenemos prisa o bien trabajamos con el típico proyecto con recursos técnicos limitados... (ejem). Como sitemap básico funcionará igual, mas este sistema por supuesto no es el más recomendado por la sencilla razón de que perdemos muchas de las funcionalidades que vamos a ver más adelante (dado precisamente a que solo señalamos URLs y nada más con ellos).

Otra opción incluso menos conocida es que podemos

Subir un RSS o bien Feed del site. Estos son ficheros que se utilizan para sindicar el contenido, o sea, a fin de que ciertas herramientas puedan ver las ultimas publicaciones de una plataforma y leerlas. Son archivos XML que solo tienen contenido y no diseño. Si jamás has visto ninguno puedes ver el de cualqueir blog en wordpress añadiendo "/rss" al final de su URL. POr ejemplo,. Subir este género de archivos acostumbra a suponer una mejora en la velocidad de indexación nuevamente contenido. Son sitemaps bastante consultados que por norma general solo poseen diez o veinte elementos y por lo tanto Google puede leerlso muy rápidamente.

Estamos habituados a que los Sitemaps.xml se refieran a páginas HTML concretas mas realmente pueden contener otros tipos de información. Google tiene detallados cuatro géneros de sitemap entre los que resalta el estandar (URLs):

• Estandar:/index.html

• Video:/webmasters/answer/80471

• Imagen:/webmasters/answer/178636

• Noticias:/news/publisher/answer/74288

Por supuesto, cuando lo que queremos es indexar contenido multimedia (algo que no siempre os recomendaría) los sitemaps expertos en vídeos y también imágenes pueden ser muy útiles. Los de noticias también son utiles aunque con la desparición de Google News (que vuelve a estar visible, todos lo hemos visto) puede parecer que no tienen sentido lo cierto es que no se trabajan igual y deberían aprovecharse en sitios de noticias.

POr último mencionar que incluso podemos entremezclar estas tipologías de sitemaps creando archivos que contengan sitemap de URLs, imagenes, vídeos, lo-que-quieras al unísono... Yo no lo haría porque no ayuda a entender las cosas mejor pero existe esa posibilidad.

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 ultimo cambio en la página
• changeFreq: Cada cuanto tiempo aprox cambia el contenido de esta página.
• Priority: de 0.1 a diez y solo en relación a las páginas del propio sitemap, cuan esenciales son unas y otras.

Sobre su interpretación tenemos históricamente mensajes muy contradictorios por parte de Google mas que a la que los lees te das cuenta de que todos tienen un hilo común. No voy a contestarlos por el hecho de que son bastantes, pero os los resumo: por una parte nos dicen que se ignora la fecha de modificacion y la frecuencia porque absolutamente nadie lo hacia bien, por otro que se ignora la prioridad por el hecho de que no aportaba la información esperada... pero siempre y en todo momento, en cada comentario que nos hacen hay una coletilla: "en la mayor parte de los casos".

Al final todo esto significa que estas etiquetas bien gestionadas no se ignoran, mas que acostumbramos a administrarlas mal y cuando eso sucede Google no les hace caso omiso. Esto cuadra, casi en todos los aspectos es así: si Google no lo ve claro ignora tus etiquetados. Así que partamos de que si que podemos usarlas, pero solo para utilizarlas bien, no para hacer el bárbaro.

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

Sobre lastmod

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

¿Que hacer con esta indicación?

Pensemos en su utilidad de cara al posicionamiento web. Realmente incorporarlo tan solo nos sirve para señalar a Google que se está perdiendo una actualización en uno de nuestros contenidos. Aguardamos con ello que al ver que su data de modificación es más reciente que la que el tiene en caché venga a ver el contenido ya antes. Por ese motivo os recomendaría lo siguiente:

• Ni lo marquéis en páginas o sitemaps que no podéis garantizar que su data implique si o si la ultima revisión del contenido único de la página
• Marquémoslo solo en páginas de contenido (un last mod en un listado es muy difícil de trabajar seguramente)
• Usémoslo solo si verdaderamente hacemos reediciones en el contenido y nuestra reindexación es tan lenta que tenemos que asistir a Google a percatarse de que lo hemos cambiado

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

ChangeFreq

Otra vez acostumbra a emplearse muy mal esta etiqueta:

• Muchos sitemaps emplean el daily para todo esperando que así su contenido se revise más a menudo
• Otros escriben aun mal el texto, solo se deja detallado por la documentación
• Y otros sencillamente la lían mucho haciendo un etiquetado arbitrario que nada tiene que ver con la realidad del cambio del contenido

¿Cómo deberíamos utilizarlo?

• Lo primero. Ni lo indiquemos si no estamos prestos 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 favor nuestro ignorará la etiqueta.
• Aún así, en muchos casos esta indicación ni siquiera tendrá sentido. ¿Cada cuanto cambia un contenido? Lo adecuado sería apuntar "never" pero, ¿queremos decirle a Google eso? ¿y si nos hiciese caso y nunca la revisitara? Mas lo cierto es que un contenido puede no cambiar jamás y todo lo que no sea un "never" es engañar al buscador.
• En listados muy dinámicos un "dialy" en contraposición a los "never" o "yearly" de las fichas haciendo más que evidente que deseamos más indexación en estos listados dinámicos

En la práctica nosotros en IKAUE prácticamente jamás la señalamos pues son matices muy particulares y creemos poco en que las arañas vayan a cambiar su cola de indexación por esta indicación. Mas puesto a usarlo yo solo lo usaría en listados, para marcar diferencias entre los que añaden nuevos elementos continuamente (daily) y los que solo reciben nuevos elementos cada pocos días (weekly), aguardando así optimar mejor nuestro crawl budget advirtiendo mejor nuevos items en la página web.

Priority

Como en las demás esta también acostumbra a emplearse 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 servirnos de un ejemplo, tengo todo mi sitemap todo a 0.5 y cuando deseo 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 acostumbra a marchar (aunque si lo que hacemos es subir otro sitemap nuevo a veces si)

¿como usar la indicación de priority?

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

Lo que procuramos es que Google vea que nuestras prioridades si tienen sentido para que nos haga caso y asi asistirle a matizar lo más esencial. Así hallar que la home y secciones primordiales tienen prioridad diez y vamos bajando hasta hallar los productos estrella en prioridad 0.7 o 0.6 puede tener sentido. Haciéndolo así no se nos deja poner estos productos en máxima prioridad (mintiendo a Google) mas si cuando menos distinguir los esenciales de los que no lo son (por ejemplo marcando los esenciales a 0.7 y los menos esenciales a 0.5).

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

Y aqui viene otra utilidad secundaria de los sitemaps. Todos sabemos que el proyecto web perfecto no existe... Todos tienen uno, dos o aun muchos inconvenientes. Hay cosas que sencillamente resulta un problema etiquetar en ciertas web. Abordamos ya como solventar inconvenientes de indexación desde cabeceras o indexación desde el robots mas veamos 2 posibilidades que si que nos aportan los sitemaps para sustituir a etiquetas específicas.

Marcar los hreflang desde el sitemap

Los hreflang son una especie de implementación en sites con orientación a múltiples regiones geográficas o bien sencillamente idiomas. Su definición es realmente sencilla: Desde cada página web debo indicar en su cabecera y a través de 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 comienzo) o bien si las maquetas son singularmente rígidas puede ser un infierno para los programadores.

En estos casos debemos saber que contamos con otra posibilidad: indicar estas relaciones en los ficheros sitemap en lugar de (o además de) en la web. Su empleo es igualmente simple: en cada <url/< del sitempa indicamos además del nodo <loc> varios nodos <xhtml:link/> con las equivalencias de esa URL con otros idiomas. El inconveniente sigue siendo el mismo: debemos identificar en cada URL sus posibles traducciones mas cuando menos disponemos de otro sitio (en muchas ocasiones más programado a medida del posicionamiento en buscadores) donde hacer este trabajo.

Puedes ver, o bien simplemente guiarte por el ejemplo que te copio a continuación:

Evitar canibalizaciones del contenido

Y este es un método que desde luego no es equivalente a una buena etiqueta canonical (de las que vamos a hablar en otro blog post) pero si que puede asistirnos en ciertos momentos en los que tenemos canibalizaciones de contenido (entiéndase canibalizado como contenido duplicado interno en el que uno posiciona por encima de otro haciendo a la segunda URL completamente inútil).

En estos casos lo que solemos hacer es decidir como de los dos contenidos queremos que sea el que se posicione y añadir una etiqueta canónica (si no un trescientos uno de forma directa) desde las URLs secundarias a la primordial. Mas sabemos que esto no es siembre fácil...

Sin embargo: ¿Sabías que ante duplicados internos Google elige casi siempre la URL que esté en el sitemap.xml? Lo indican mismos en su documentación, mencionando que es un posible sustituto de etiquetas canonicas. Para esto solo tenemos qu etner un sitemap bien hecho, en el que evitemos incluir ninguna etiqueta que tenga riesgo de ser canibalizada. Esto es, en estos casos en los que múltiples URLs tienen exactamente el mismo contenido o bien apuestan por exactamente la misma Keywrod nos es suficiente con solo incluir la URL primordial en el sitemap a fin de que esta sea la que muestre Google en sus resultados. A menos que por enlaces recibidos nuestra elección de URL primordial no tenga ningún sentido (por ejemplo: le señalamos una URL sin links internos dejando fuera a la URL que se enlaza desde todos y cada uno de 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 y en todo momento (bueno, con los canonicals tampoco) mas es una vía secundaria que tomar en consideración cuando tenemos esta clase de limitaciones.

Dado que los Sitemaps.xml son finitos (tienen peso y URLs máximas) debieron idear una forma por las que despiezarlos en diferentes ficheros. Para poder hacer eso existe un tipo de archivo sitemap de índice. Son ficheros en los que podemos señalar otros archivos sitemap. Los beneficios son claras: subimos un único archivo y desde este controlamos todos y cada uno de los que ofrecemos verdaderamente a Google automatizando su fragmentación.

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

• Corremos el peligro de pasarnos del tamaño máximo.
• Nos cuesta mucho hallar en el todas las URls
• Nos cuesta auditar sus prioridades.

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

Crear un índice es sencillo y, 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 exactamente los mismos comentarios que al lastmod de las 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 de ellos cuantas URLs contenía y de ellas cuantas ha indizado. Solo tendremos que dividir una cifra sobre la otra para saber el porcentaje de indexación de dicho sitemap.

Pensando un tanto sobre esto no es difícil llegar a la conclusión de que no deseamos subir sitemaps enormes a nuestro site: lo suyo es que subamos siempre y en todo momento un índice que apunte a una colección más o bien menos grande de sitemaps.xml parciales del site. ¿Cuantos? depende de cuanta información quieras verdaderamente recoger.

Por cada sitemap.xml fragmentado que creemos, tendremos un nuevo conjunto de URLs del que conocer el estado de su indexación. Así que a mayor cantidad de información que deseemos saber sobre la indexación del site más deberíamos fragmentar los sitemaps para conocerla. Esta es una técnica medianamente conocida mas que incluso sabiendola se usa poco y se aplica sin meditar demasiado en ella:

Os pongo dos ejemplos a fin de que queden claro.

Imaginad que tenemos un blog del que vamos a subir los sitemaps.xml fragmentados en diferentes 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 que porcentaje de cada género de página tenemos indizado. Probablemente 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 género de cosas no vamos a poder accionarlo, no sabemos que hacer para mejorar estas situación y no tenemos nada que hacer con esta información. Este acostumbra a ser el problema.

Ahora pensemos en aplicar a nuestra fragmentación del sitemap una lógica posicionamiento web. Pensamos en todos y cada tipología de página, cual puede ser su problemática de indexación. Por servirnos de un ejemplo, escogemos los posts, donde estamos viendo el mayor porcentaje de contenido no indizado, los analizamos y vemos que probablemente se trata de un problema de anigüedad: a mayor antigüedad del post más pensamos que se habrá desindexado... Así que hacemos nuestra fragmentación del sitemap buscando conseguir información justo por este criterio y en vez de subir un único sitemap de artículo subimos la próxima colección:

- posts-novedad.xml -->Indexación noventa por ciento

- artículo-ultimo-mes.xml -->Indexación cien por cien

- posts-dos-meses.xml -->Indexación noventa y ocho por cien

- post-3-6meses.xml -->Indexación ochenta y nueve por cien

- posts-7-12-meses.xml -->Indexación 50 por ciento

- post-1-dos-anos.xml -->Indexación cincuenta y cinco por ciento

- posts-dos-3-anos.xml -->Indexación 57 por ciento

Etc...

La cantidad de indexación de cada uno de estos sitemaps si que es un dato accionable. Puedo hallarme con que desde los seis meses comienzan a perder la indexación y descubrir que tengo inconvenientes de rastreo profundos. O que los posts de hace más de 5 años siguen indizados 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. Aun 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 poder ver desde cuantos saltos empieza a sufrir la indexación. Sacamos el dato, lo activamos y después volvemos a emplear los sitemaps de siempre y en toda circunstancia...

Otra opción es simplemente hacer seguimiento, apuntar estos datos cada seemana y asi observar como mejora o empeora la indexación por zonas de la web.

Alguno habrá arqueado la ceja al leer este título... Y es que esto es raro mas tiene grandisimas ventajas sobre todo si llevas el posicionamiento web en buscadores 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 diferente al del propio site pero para determinadas acciones y pruebas viene realmente bien tener la posibilidad de poder ir haciendo subidas sin incordiar a los desarrolladores de la web. Pensad solo en muchas de las posibilidades que hemos comentado en este artículo y veréis que tener un espacio donde no depender de IT para subir ciertos sitemaps bajo tu control te va a permitir efectuar más acciones (o bien al menos de forma más rápida) de este género.

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

Para esto hay múltiples opciones:

A. Usar los sitemaps para sites multiples

Esto estáy basicamente nos permite subir el sitemap de un dominio de la forma normal, solo que indicándole en el sitemap URLs de otros dominios.

Para esto básicamente tenemos que hacer que el usuario que suba el sitemap.xml sea

ADMINdel Google Search Console de los 2 dominios. Así que realmente nada impide que creemos un dominio estúpido (sitemaps-seo.midominio.com) lo demos de alta en GSC y en el subamos nuestros propios sitemaps.xml para nuestros clientes del servicio, siempre y cuando nos hayan dado privilegios sobre sus GSCs.

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

Este es otro recurso documentado aun en la propia documenación documentación de los sitemaps.org. Ahi nos dicen que podemos incluir en la indicación "sitemap: " del archivo robots un sitemap sin que importe que se encuentre o bien no en el dominio indicado.

Es decir que si en midominio.com dispongo de un robots.txt que acaba con las próximas lineas:

Leerá ambos. Si sumamos esto a que estos sitemaps pueden ser indices que controlan donde leer cada fichero ya tenemos un mecanismo afín al de Google Search Console.

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

Por ultimo y con una utilidad muy práctica si lo ligamos al punto precedente (de subir sitemaps por tu cuenta) tenemos una vieja técnica que se fundamenta 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 bien temprando siendo visitadas, pero esto es por norma general aún más rápido (aunque tampoco será inmediato) si lo que hacemos es subir sitemaps nuevos.

Así que tenemos una herramienta (la subida de nuevos sitemaps) que nos deja crearle a Google listas de URLs pendientes de rastrear y que nos puede venir realmente 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 ciertos de estos casos:

• En una migración dejar el sitemap viejo o incluso, mejor aun, subir un nuevo el sitemap de URLs con trescientos uno ayuda a que estas se lean ya antes y asegura que todas terminen siendo leidas
• Lo mismo para 301. Después de arreglos masivos de fallos 404 que han sido reemplazados por trescientos uno una subida de sitemap con estas URLs ayuda a que las arañas las recojan y asimilen./li>
• 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 ciertos casos donde la indexación de páginas AMP se atasca nos ha resultado de gran 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 fallos al tener estas bloqueadas.

Y bueno, en definitiva, nos ayuda a revisar o bien procurar agilizar la indexación tras nuestras actualizaciones en la página web. Toda vez 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, jamás será algo exageradamente rápido mas 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 determinados momentos el extra que necesitamos.

Los sitemaps son unos archivos muy poco mimados por gran cantidad de SEOs. Como son fáciles de definir y no lanzan grandes dificultades más allá de lograr el propio listado de URLs para muchos el trabajo queda ahí. Aun como decíamos al comienzo es una zona que mucha gente termina 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 progresar nuestra indexación, para hacer un análisis de la indexación o para reemplazar distintas carencias técnicas del SEO de nuestro site.

El inconveniente con estos archivos sigue siendo siempre y en toda circunstancia el mismo: la base hay que programarla a fin de que tenga sentido. Los desarrollos a la medida no acostumbran a haberlos tenido en cuenta y muchos Content Management System que los desarrollan a través de complementos al hacerlo de forma generica no terminan de ser lo que precisamos. Solo tras una planificación y definición estratégica adecuadas comenzamos a hacer autenticas virguerías con estos archivos. Hay muchos géneros de posicionamiento web en buscadores y muchos estadios de evolución en una estrategia posicionamiento web en buscadores, no creo que esto sea de lo primero a atacar (por complejo) mas si tengo clara una cosa: al hacer un sitemap debemos tomarnos nuestro tiempo y hacerlo bien. SI no vas a mimarlos, mejor no los emplees.

¿Te gustó este blog post? Puedes continuar sus comentarios a través de, o realizardesde tu blog.