Rastreo e indexación: TODO lo que necesitas saber para aparecer en Google

641

Te aviso ya de entrada, hoy se viene artículo largo. No sé cuánto, pero va a ser muy largo.

Con esto quiero decir que te recomendaría que prepares un buen café o una infusión, te sientes tranquilamente y te tomes tu tiempo. Si no lo tienes, siempre puedes ponerte el post en marcadores y ya me lees otro rato con más calma.

Dicho esto, al lío.

El camino hacia la aparición en los resultados de búsqueda de Google

Vale, vamos a empezar por el principio ¿Cuáles son los pasos que sigue Google a la hora de posicionar una página web? En concreto, son cuatro.

1. Descubrimiento de la URL
2. Rastreo de su código/contenido
3. Indexación de la página en su base de datos
4. Aparición de la misma en los resultados de búsqueda

Dentro de cada uno de esos pasos entran en juego diferentes factores que harán que podamos optimizarlos. Unos más técnicos, otros más de calidad…

Pues bien, por centrar un poco el tiro, hoy vamos a hablar de dos de ellos: el rastreo y la indexación. Más adelante, en nuevos artículos, ya podremos mirar el resto.

Y como va primero, obviamente vamos a empezar por el…

Rastreo

Cuando hablamos del rastreo lo primero que tenemos que conocer y tener clarísimo es el concepto de ‘Crawl Budget’ o, dicho en nuestro idioma, ‘Presupuesto de rastreo’.

¿Qué es el Crawl Budget? El TIEMPO que nos dedica Google a diario para rastrear nuestra web.

Pongo ‘tiempo’ en mayúsculas porque mucha gente cree erróneamente que lo que decide es el número de URL’s que rastreará cada día. No es así. Eso dependerá, como veremos más adelante.

Qué tipo de sitios web deben preocuparse especialmente por mejorar su presupuesto de rastreo

En realidad todos, y en breve te cuento por qué, pero sobre todo las webs grandes. Y cuando digo grandes no hablo de un sitio con 2.000 URL’s. Estamos hablando, según especifica el buscador en su propia documentación, de sitios web con a partir de 10.000 páginas y especialmente 1 millón o más.

¿Por qué estos tamaños? Porque es que si son más pequeñas, los robots de Google no van a tener problema en encontrar y ‘tragarse’ todas las URL’s sin mayor complicación.

Sin embargo, cuidado de todas formas aún así, ya que por mucho que pueda rastrear sin dificultad el 100% de tus URL’s, si el 40% de ellas son una basura inservible el buscador puede decidir que no vale la pena tirar su tiempo y dinero en rastrear una web con tanta página de baja calidad. Algo que claramente perjudicaría a las URL’s buenas.

Y parafraseo lo que dice al respecto para que no haya dudas:

Gestiona tus URLs. Usa las herramientas adecuadas para indicar a Google qué páginas debe rastrear y cuáles no. Si Google pasa demasiado tiempo rastreando URLs que no son apropiadas para incluirlas en el índice, es posible que el robot de Google decida que no vale la pena rastrear el resto del sitio (o aumentar el presupuesto para ello).

Así pues, seas una web grande o pequeña, lo primero es intentar evitar el efecto ‘aguja en el pajar’. Que Google pierda el tiempo rastreando continuamente páginas que no aportan y te bajan la calidad media de la web en lugar de dedicarlo a encontrar y actualizar nuevas páginas de servicios, productos o posts es pegarte un tiro en el pie antes de empezar.

Dicho esto, hay dos grandes cosas que tiene en cuenta el buscador a la hora de estimar cuánto presupuesto de rastreo va a destinar por el momento a un sitio web: el Crawl Rate y el Crawl Demand.

Crawl Rate

Podríamos resumir este punto en ‘¿Cuánto rastreo puedo ofrecerte y cuánto puede soportar tu sitio web?‘, algo que determina en base a dos factores.

Tu servidor

Si Google ve que a pesar de querer rastrearte más, tu servidor no lo soporta (ralentizaciones a la hora de responder, errores del servidor…) bajará el ritmo de peticiones aún y si tuviera la intención de rastrear más.

Ante todo, quiere evitar tumbarte el servidor por pasarse de intensito y dejarte sin web.

En la siguiente captura te dejo un ejemplo donde se puede apreciar perfectamente como, al empezar el servidor a dar errores y tardar más en responder, las solicitudes del rastreador bajan inmediatamente.

Los propios servidores de Google

La propia infraestructura de Google también podría ser un limitante. Tiene miles de servidores, pero no infinitos. Podría darse el caso puntual en que simplemente el buscador no tuviera suficiente capacidad por lo que sea para rastrear tu sitio todo lo que le gustaría.

Yo estaría bastante tranquilo por este punto. Entre otras cosas porque. además de poco probable, es algo en lo que tenemos cero capacidad de acción y mejora por nuestra parte.

Aprovecho este momento para dejar claro un tema relacionado con todo esto.

La directiva ‘Crawl-Delay’

Imagino que si has llegado hasta aquí, o todo te está sonando a chino o seguramente te es familiar el archivo robots.txt.

Por si acaso, lo vamos a resumir muy brevemente.

El archivo robots.txt es un fichero que subes a la raíz de tu dominio (ejemplo.com/robots.txt) y desde el que, con ciertas órdenes/directivas, puedes determinar qué pueden y qué no pueden rastrear los diferentes bots. No sólo los de Google, cualquiera: Bing, Yandex, DuckDuckGo, ChatGPT… hay muchísimos.

Ok. Pues si te pones a cotillear los ‘robots’ de otras webs, en muchas verás algo como esto:

Crawl-delay: 10

El ‘crawl-delay’, en teoría, le dice al rastreador cada cuánto puede hacer peticiones. Y de esta manera frenas o aceleras el presupuesto de rastreo a placer.

Vale. Pues esto no sirve de nada ¿Pero no de ahora, eh? No ha servido al menos en 10 años. No con Google.

No hay manera alguna de forzar el aumento de rastreo por parte del buscador. Sí la hubo de frenarlo, con una herramienta que había (bastante escondida) desde hacía años en Search Console, pero que eliminaron el 8 de enero de 2024.

Así que eso ya tampoco.

Y hasta aquí lo relativo a qué afectaría al Crawl Rate. Pasemos al Crawl Demand.

Crawl Demand

Si el anterior apartado trataba sobre cuánto rastreo podías soportar, el Crawl Demand se resumiría en ‘¿Cuánto rastreo necesita tu sitio web?‘.

Nuevamente, esto va a depender de diferentes cosas, en realidad de bastantes más que el Crawl Rate. Y la primera y más importante es el inventario percibido.

Inventario percibido

Es el total de URL’s que Google encuentra y entiende que tiene que rastrear. Esto quiere decir que si tu web tiene, pongamos, las 500 páginas que creaste en su momento… el inventario será de 500.

Pero ojo, porque puede que tú crearas 500 páginas pero por diferentes motivos tengas en realidad 100.000. En este caso el inventario percibido sería de 100.000 ¿Cómo narices va a ser eso posible? Vamos a verlo en el primero de los puntos a cuidar a la hora de optimizar el Crawl Demand.

URL’s innecesarias

Es muy muy fácil como te decía que tu web se descontrole y genere una cantidad brutal de URL’s que tú ni tan siquiera sepas que existen pero ahí están, ocupando tiempo de rastreo que sería más útil dedicar a otras páginas.

¿Casuísticas en las que es fácil que esto pase? Pues por ejemplo y de las más frecuentes…

• Navegaciones facetadas: En los listados de cualquier e-commerce, si cualquier combinatoria de filtros genera su propia URL… échate a temblar.
• Identificadores de sesión: Hay veces en las que cada inicio de sesión, envío de formulario o similares generan también una URL rastreable, ojo también ya que esto tiende a infinito.
• Búsquedas internas: Mucho cuidado nuevamente si en tu web cualquier búsqueda interna deriva en una página de resultados con su propia URL.

Otro caso de ejemplo sería ese enlace que pone muchas veces WordPress en todas las URL’s a su feed. Una maravillosa manera de multiplicar x2 el inventario percibido de tu web sin aportar prácticamente nada.

Intenta evitar por todos los medios que ninguna de esas situaciones te genere URL’s rastreables si es posible. Hay diferentes soluciones para ello: Carga de contenido mediante JavaScript, ofuscación, parametrización… encuentra la que más se adapte a tu sitio web, pero hazlo.

Si directamente consigues que no se generen, ya no hará falta buscar soluciones ya que no existirá ningún problema. Si puedes eliminarlas, lo mismo.

Robots.txt

Antes hemos hablado de él ¿recuerdas? Servía para decirle a Google qué URL’s podía rastrear y cuáles no.

Pues en caso que sea tarde para evitar que ciertas páginas se generen y no puedas eliminarlas, será nuestro mejor amigo.

Con la directiva ‘Disallow:’ podremos indicarle patrones de URL’s que no tendrá permitido rastrear aunque las encuentre, evitando así que pierda presupuesto de rastreo en ellas.

Por ejemplo, con la directiva:

Disallow: /feed/

Estaríamos indicándole que no puede rastrear ninguna URL que contenga ‘/feed/’ en ella, bloqueando de golpe todas esas páginas que genera WordPress automáticamente y comentábamos en el ejemplo anterior. Un problema menos.

Canonicals

Unifica el contenido altamente similar que puedas tener mediante etiquetas ‘canonical’ para indicar a Google cuál es la URL principal. Por ejemplo, si tienes diferentes URL’s para distintas variantes de un mismo producto o servicio. También aplica para versiones AMP y otros casos similares.

El canonical es una etiqueta HTML que puedes definir fácilmente en muchos de los CMS actuales. En WordPress por ejemplo a través de plugins como Yoast.

Simplemente, si crees o sabes que el contenido de varias páginas es muy similar y necesitas que todas sigan existiendo y siendo rastreables por lo que sea, apunta todas las versiones a una sola en plan ‘Oye Google, todo esto es un poco lo mismo, céntrate sólo en ESTA página’. Puedes leer más sobre esta etiqueta y cómo la gestiona el buscador aquí.

Eso no sólo hará que con el tiempo Google muy probablemente (el canonical es una ‘sugerencia’ no algo a lo que haga caso siempre) rastree menos esas páginas, mejorando el crawl budget, si no que a nivel SEO también te irá bien al unificar contenido y evitar posibles canibalizaciones y otros temas.

No lo digo yo, lo dice Google:

Ahorrar tiempo de rastreo en páginas duplicadas. Te interesa que el robot de Google aproveche al máximo el tiempo que pasa en tu sitio, por lo que es mejor que rastree las páginas nuevas o actualizadas que las versiones para móviles y para ordenadores de una misma página.

Más claro, agua.

Enlaces internos y sitemaps

La forma en que Google encuentra nuevas URL’s que rastrear en realidad es muy sencilla: Sigue enlaces. Llega a una página, la ‘lee’, detecta que hay un par de enlaces a otras páginas y dice ‘Anda, las voy a rastrear también’.

Estos enlaces a tus URL’s los puede encontrar en tres sitios. En webs de terceros que te enlazan, en tus propios enlaces internos o en los sitemaps que puedas haberle enviado. En el primer caso no tienes demasiado a hacer, así que centrémonos en los otros dos.

Te interesa que todos tus enlaces internos y URL’s que puedas estarle enviando a Google en los sitemaps sean páginas rastreables, indexables y que se pueden cargar correctamente (vamos, que respondan con un Status Code 200).

Así pues, de vez en cuando, recuerda hacer un análisis de tus inlinks y sitemaps para modificar o eliminar todo enlace que incluya redirecciones (3XX) o páginas no existentes (4xx). Son pequeñas piedras en el camino del bot rastreador de Google que perderá un tiempo que intentamos rentabilizar al máximo.

No sólo eso, si no que como hemos dicho ya varias veces, si el número de URL’s ‘malas’ supone un alto porcentaje de las solicitudes de rastreo de tu sitio web, pueden terminar perjudicándolo en su conjunto.

Intentemos evitar situaciones como las de la siguiente captura, donde el 40% de las solicitudes de rastreo se tiran a la basura en redirecciones y páginas inexistentes.

Y hasta aquí todo lo referente al inventario percibido, que no es poco. Lo podríamos resumir en lo que decía al principio: Intenta evitar el fenómeno ‘Aguja en un pajar’.

Esta parte del Crawl Demand nos ayudará a enfocar bien a Google sobre qué SÍ tiene que rastrear ¿Miramos ahora las partes que además harán que las rastree más frecuentemente?

Popularidad

Sí. La popularidad afecta al rastreo.

Si Google ve que por lo que sea el tráfico de tu web aumenta de manera anormal, entrará a chafardear qué está pasando.

Un clásico en situaciones de alta temporalidad estacional o viralidad ¿Quieres un par de ejemplos?

Mira esta web, es una competición deportiva. Tras meses de parón, retomó sus partidos, consiguiendo que obviamente la gente les buscará y entrara mucho más a la web. Puedes ver cómo suben las impresiones y clics en su Search console en la primera gráfica de abajo.

Fíjate qué pasa automáticamente a partir de ese día con las solicitudes de rastreo: PUM. El doble.

Ese era el ejemplo de estacionalidad fuerte en el sector. Vamos a ver ahora otro pero de viralidad.

Un e-commerce. Lanza un nuevo producto exclusivo, muy limitado, y lo publica en Twitter. La gente se vuelve loca y entra en tropel a la web para comprarlo, pico de de impresiones, clics y visitas ¿Qué hace Google? Efectivamente.

Frecuencia de publicación y obsolescencia

El otro gran punto que hará que Google decida rastrear más o menos frecuentemente tu sitio web es cada cuánto publiques.

¿Verdad que si tú supieras que cada vez que vas a ver a alguien te regala algo irías cada día a verle? ¿Y si sólo te diera algo una de cada diez veces? Seguramente irías, pero no tan a menudo. Nah, no es que seas una persona interesada, es que tu tiempo vale oro ¿Verdad? Google no es tan diferente a ti en ese aspecto.

Pero no sólo la frecuencia de publicación de nuevo contenido afecta, si no también si el que ya tenía controlado cambia sustancial y/o regularmente. Eso es lo que el buscador llama ‘obsolescencia’, y califica según la frecuencia de cambios a los contenidos entre ‘fresh’ (los que cambian a menudo) y ‘stale’ (los que no). Visitando más a las primeras, claro.

Y no, con cambiar la fecha de publicación de un artículo no basta para pasar de ‘stale’ a ‘fresh’. Sé legal.

Lo bueno de haber trabajado ya en tantos proyectos es que tengo muchos ejemplos. Mira, éste es buenísimo.

Dos medios de noticias. Casi exactos en cuanto al total de URL’s rastreadas, porcentaje de indexadas y hasta tamaño de descarga. Casi páginas siamesas. Una publica una media de 15-20 artículos al día, la otra sólo 1-3.

Mira el presupuesto de rastreo. La que publica más, siendo igual en todo lo demás, tiene 4 veces más.

Migraciones y grandes cambios en el sitio web

Quiero hacer un aparte y mencionar un caso extra que afecta de manera crítica en el Crawl Demand, y son las migraciones.

En general, cualquier gran cambio en un sitio web a nivel estructural, URL’s, contenido, enlazado interno… va a hacer levantar las orejas a Googlebot. Las migraciones no dejan de ser más que un caso paradigmático de ello.

Y tiene todo el sentido del mundo. Google está acostumbrado a venir cada poco a tu web, rastrear lo de siempre y alguna cosita nueva y nos vamos para c… ‘Un momento ¡¡¿Por qué está toda la web totalmente cambiada? ¡Necesito enterarme de qué ha pasado aquí y cuánto es ahora diferente!’.

Durante unos días, el pico de solicitudes de rastreo es brutal, ya que apreta el acelerador para enterarse de cómo están las cosas ahora. A partir de ahí, baja y ya vuelve a su ritmo habitual.

Ojo aquí, aunque sea un poco otro tema. Google dice claramente que si una web crece o cambia lo suficiente, va a reevaluar el sitio por completo para decidir si lo sigue posicionando igual o si mejor a partir de entonces lo hace diferente. Porque ha cambiado tanto que ahora, en realidad, es otra web.

Si un sitio web crece de manera significativa, en este caso, por un factor de 10, el sitio web será muy diferente en general. Por definición, el sitio web antiguo solo sería un 10 % del nuevo. Por ello, lo lógico es esperar que los buscadores vuelvan a evaluar cómo muestra el sitio web. Básicamente, es un sitio web nuevo. Es importante realizar cambios de este tipo de forma estratégica.

Tenlo en cuenta e intenta fasear los grandes cambios para evitarlo.

WPO: La velocidad de carga como factor de rastreo

Ajeno a todo lo comentado arriba referente a cuánto rastreo soporta y necesita tu web, o el número de URL’s que Google encuentre y pueda rastrear, hay un último aspecto a tener muy en cuenta. El WPO.

¿Recuerdas que antes te he dicho que el presupuesto de rastreo no va de cuántas URL’s rastrea si no de cuánto tiempo te dedica para rastrear URL’s? Pues en ese matiz es donde importa el WPO, o dicho de otra manera, la velocidad de carga de tus páginas.

Muy sencillo. Pongamos que el crawl budget de tu sitio web es 1 minuto de rastreo al día. Por simplificar.

Si tus páginas cargan en 0’5 segundos, Google cada día rastrearía 120 URL’s.

Si en cambio fueran muy lentas y cargaran en 5 segundos cada una… sólo rastrearía 12.

Mismo presupuesto de rastreo, dos mundos en cuanto a su eficiencia. Obviamente no voy a hablar de cómo optimizar la velocidad de carga de una web porque daría para otro tocho-post, pero tenlo muy en cuenta.

Herramientas para controlar el rastreo de tu página web

Te voy a decir tres, brevemente, para que puedas tener controlado todo lo que afecte al rastreo a nivel de cantidad, calidad y demás.

• La sección ‘Páginas’ en Search Console: Para ver cuántas páginas se indexan o dejan de hacerlo aún rastreadas y por qué.
• La sección ‘Estadísticas de rastreo’ también en Search Console: La encontrarás en ‘Ajustes’. Para ver qué tipos de URL’s y status codes rastrea Google, y con qué bots. Porque tiene varios.
• La sección ‘Core Web Vitals’ adivina dónde, en Search Console: Para detectar si tienes demasiadas URL’s muy lentas. Profundiza después si quieres en PageSpeed para encontrar las causas y buscar soluciones.

Hay más, claro. Pero estas tres seguro que las tienes a mano, son gratis y te van a dar información más que de sobra.

Bueno… pues oye, que llevamos unas 3.000 palabras hablando de rastreo. Yo creo que ya estaría.

¿Hablamos ahora de la indexación?

Indexación

No sé si no tendría que haber hecho un post sólo de rastreo y otro de indexación… pero bueno, tiramos ahora ya hasta el final.

Hasta ahora hemos leído en qué se basa Google para rastrear y ‘leer’ nuestras páginas pero ¿En qué se basa para decidir si las añade o no a su base de datos para así poder aparecer en los resultados de búsqueda?

Eso es la indexación, y gira en torno a 4 aspectos fundamentales que vamos a ver a partir deeeeeeeee… YA.

Meta robots o X-Robots-Tag

A través de la meta etiqueta HTML ‘robots’ puedes indicar a Google si quieres que esa página se indexe (index) o no lo haga pese a que la encuentre y rastree (noindex).

Esta etiqueta imagino que la tenemos todxs ya bastante por la mano, así que poco a profundizar aquí. Si manejas un WordPress, con cualquier plugin como Yoast o Rank Math puedes con un par de clics definir si una URL quieres que sea indexable o no.

En este ejemplo puedes ver cómo mi página de política de privacidad la tengo como ‘no indexable’ con dicha etiqueta y por tanto no aparece en los resultados de búsqueda. Easy.

X-Robots-Tag es lo mismo, pero enviando dicha directiva desde los encabezados HTTP.

Ojo porque con este tema me he encontrado ya varias veces con auténticos dramas. Principalmente porque las cabeceras no se ven en el código, has de hacerlo por ejemplo con alguna extensión de navegador como ésta.

Y aunque con la otra etiqueta le estés diciendo que indexe, si aquí dice que no… ante la duda, hará caso a la orden más restrictiva.

¿Qué pasa entonces? Cosas como por ejemplo que pasen a producción un nuevo diseño en la web sin recordar quitar el ‘noindex’ de las cabeceras, con dramáticos resultados como éste que analicé hace unos años al llamarme la atención su brutal pérdida de visibilidad online:

Page Quality

La madre del cordero. Aquí no hablamos de etiquetas HTML ni historias técnicas de ‘está bien o no’, entramos en el maravilloso mundo de la subjetividad.

Puro SEO. DEPENDE.

Si Google considera que por lo que sea (spam, thin content, contenido duplicado, black hat…) el contenido de tu URL no aportaría nada a los resultados de búsqueda… no la va a indexar. No importa que sea rastreable, indexable y todo lo que quieras. Su casa, sus reglas.

Voy a ser muy claro. Si tu contenido es una mierda, no lo va a indexar.

Y cuidado, puede serlo queriendo (contenido copiado, casi inexistente o de pésima calidad) o sin querer (hackeo). Y para muestra, un botón.

Mira esta web que estuve analizando hace un par de meses. E-commerce de libros italiano hackeado, donde el usuario ve la web normal, pero Googlebot veía en todas las páginas el mismo contenido pirata promocionando casinos.

El resultado NO te sorprenderá. Mira cómo se empezaron a desindexar sus URL’s en cuestión de pocos días. Al hoyo.

Canonicals

‘¡¿Otra vez?!’ En efecto.

Puede que tengas un buen contenido, rastreable e indexable, pero que Google tenga claro (o entienda) que ese contenido ya existe igual o muy similar en otra de tus URL’s o incluso en una externa a tu web. En dicho caso, pasa a canonicalizar hacia ella y a no indexarla.

Digo que ‘tenga claro o entienda’ porque puede tenerlo claro en base a que tú le hayas indicado con la etiqueta HTML que comentábamos antes en la sección de rastreo que tal URL es canónica de tal otra. Ok.

Pero Google va a hacerte caso sólo si quiere.

Es decir, como te comentaba, la etiqueta canonical no es más que una sugerencia (o como dicen en inglés: hint), no algo que vaya a verse obligado a seguir.

Si Google decide que la URL es canónica de otra, da igual lo que tú hayas puesto o si no has puesto nada. Hará lo que quiera.

Y esa URL canónica no tiene porque ser tuya, por cierto. Puede que estime que tu contenido es exactamente igual que el de otra web y que mejor indexa esa que ya estaba antes y no la tuya que no aporta nada nuevo.

Mira aquí como dice que no indexa una página que ha rastreado porque le pusimos un canonical a otra URL:

Aprecia ahora aquí como sin poner ningún canonical Google decide no indexar esta otra porque considera que ya tenemos ese mismo contenido en otra URL:

Por último, me he dejado un buen melonazo que puede afectar de lleno a la indexación de tus páginas.

JavaScript

Esto da para otro tocho-post también. Qué bonito es el SEO. A lo mejor debería escribir un libro.

No importa nada de todo lo anterior si el robot rastreador no puede ver el contenido de la página. Y en el caso de usar JavaScript para ‘pintar’ nuestra web, es imprescindible asegurarse que Google puede verlo todo correctamente. Porque puede haber dramas.

Antes de nada, has de tener claro dónde está el riesgo en todo esto.

Por defecto, el código que se carga de primeras en una URL es el HTML. De hecho antes las webs se hacían con HTML y punto. Bueno, y CSS después para ponerlas más bonitas con estilos. Con JavaScript, cada vez más utilizado, esto cambió.

¿Por qué? Porque tras cargar el HTML, Google renderiza (imagina que es como si lo desenvolviera o cocinara) el contenido que se entrega mediante JavaScript y lo junta todo. Ese resultado final es lo que se conoce como el DOM (Document Object Model), y es lo que tenemos que asegurarnos que vea Googlebot correctamente.

Entonces aquí técnicamente tenemos diferentes formas de plantear cómo hacer esto. O bien para aligerar trabajo a nuestro servidor le damos el HTML y el JS sin renderizar tanto al usuario como a Google y que trabajen ellos para pintarlo todo, o bien ese renderizado lo hacemos previamente nosotros y así ya les entregamos la página totalmente ‘pintada’ de contenido.

Básicamente es como si el usuario comprara el mueble en IKEA y se lo tuviera que montar él o vinieran a montárselo.

Eso son los métodos CSR (Client Side Rendering) y SSR (Server Side Rendering). Hay opciones híbridas, pero no toca hablar de eso.

Ojo, Google es capaz de entender bien el contenido de una web en CSR ¿eh? Es sólo que puede tardar más y que sólo lo hará si se ha implementado todo correctamente. Cosa que a veces no pasa. Con el SSR te dejas de sustos.

Pero si te interesa cómo lo hace, te dejo este gráfico. Y un enlace a un documento donde lo explican más en detalle.

Ah, un detalle con esto último. Google espera 5 segundos para cargar el JavaScript de una URL. Si tarda más… eso no lo carga. Así que otro punto donde el WPO es pieza clave.

Resumiendo, lo que puede pasar si Googlebot no renderiza correctamente el contenido por Js, es algo como lo que te muestro a continuación.

A la izquierda, una web en la que ve lo mismo el usuario (arriba) que Google (abajo). A la derecha, una donde eso no pasa. El usuario bien, pero el buscador no ve nada del contenido ya que se debería mostrar mediante un JavaScript que no puede renderizar.

Esa web además era un rediseño que estaban haciendo para darle un look más actual y renovado. Fue hacer el cambio y mira qué pasó con su índice de visibilidad online…

Con esto quiero decir que siempre que puedas con el Js… Server Side Rendering. Y si optas por otras soluciones, asegúrate que todo está funcionando como debe.

Herramientas para controlar la indexación de tu página web

Pues vamos a ser breves otra vez en esta sección pero tremendamente efectivos:

• La sección ‘Páginas’ en Search Console: Nuevamente, una maravillosa gráfica con detalles del número de URL’s indexadas y el por qué de las que no lo están.
• El comando ‘site:’ + la URL que quieras en Google: No hay manera más sencilla de saber si una URL está indexada en la base de datos del buscador. Un clásico.
• La herramienta ‘Inspeccionar URL’, adivina otra vez dónde: Realmente Search Console es una maravilla. Pon la URL que quieras en el buscador superior y te dirá si la página está indexada o no. No sólo eso, si le das a ‘Probar URL’ podrás ver si renderiza correctamente todo el contenido.

Apunte final: Terminemos con esto

Como detalle final, y así de paso llegamos a las 5000 palabras, vamos a terminar con una broma que dura ya más que la del crawl-delay.

UN ‘NOINDEX’ NO IMPIDE EL RASTREO DE UNA URL.

Mira este mensaje de una URL que ha sido rastreada y por eso, al poder detectar la etiqueta ‘noindex’ en el HTML, sabe que no la puede indexar .

UN ‘DISALLOW:’ EN ROBOTS.TXT NO IMPIDE LA INDEXACIÓN DE UNA URL.

Mira ahora en cambio cómo el bloquear el rastreo de esta otra página no ha impedido que se indexara. Simplemente, al no poder rastrearla, no puede leer atributos como el title o la meta description, por lo que no es capaz de mostrar su contenido en los resultados de búsqueda pese a listar la URL.

Si alguna vez alguien te vuelve a repetir una de las dos cosas, sonríe con superioridad y dile ‘No lo creo, lo leí en un blog SEO con imágenes de videojuegos, películas y dibujos animados’.

Conclusiones

Como conclusión final. De nada sirve lo mucho que trabajemos nuestro contenido, como este artículo por ejemplo, si Google no es capaz de rastrearlo e indexarlo correctamente.

Sencillamente será como si no existiera.

Esa es la grandeza y la importancia del SEO técnico. Son los cimientos con los que construir después un edificio con la tranquilidad de saber que no se va a caer.

Si tienes una web (o la idea de tener una) y crees que te puedo echar una mano, puedes contactarme por aquí y lo hablamos. Y si quieres una imagen-resumen de todo lo que has leído hasta ahora, te diría que esta imagen que he hecho podría servir:

Si el post te ha parecido útil, o crees que puede serle útil a otras personas, te agradeceré cualquier compartido que le des en redes sociales o enlaces que le puedas poner, porque me ha llevado más de 5 horas redactarlo. Sin presión.

Y gracias, gracias y mil gracias de nuevo si has llegado hasta aquí por haberme dedicado este tiempo de tu vida. Cualquier cosa la comentamos por Twitter, LinkedIn o los comentarios.

Un abrazo y nos vemos en el próximo artículo 🙂