{"id":25334,"date":"2024-12-03T00:00:00","date_gmt":"2024-12-03T00:00:00","guid":{"rendered":"https:\/\/alienroad.com\/google-bilgi-bankasi\/crawling-december-the-how-and-why-of-googlebot-crawling\/"},"modified":"2024-12-03T00:00:00","modified_gmt":"2024-12-03T00:00:00","slug":"crawling-december-the-how-and-why-of-googlebot-crawling","status":"publish","type":"ar_kb","link":"https:\/\/alienroad.com\/google-bilgi-bankasi\/crawling-december-the-how-and-why-of-googlebot-crawling\/","title":{"rendered":"Diciembre de rastreo: El c\u00f3mo y el porqu\u00e9 del rastreo de Googlebot"},"content":{"rendered":"

Martes, 3 de diciembre de 2024<\/p>\n

\n Es posible que hayas o\u00eddo que la B\u00fasqueda de Google necesita realizar cierto trabajo antes de que una p\u00e1gina web pueda aparecer en los resultados de la B\u00fasqueda de Google. Uno de estos pasos se denomina rastreo. El rastreo para la B\u00fasqueda de Google lo realiza Googlebot, un programa que se ejecuta en los servidores de Google, el cual recupera una URL y gestiona aspectos como errores de red, redirecciones y otras peque\u00f1as complicaciones que pueda encontrar mientras recorre la web. Sin embargo, hay algunos detalles de los que no se suele hablar. Cada semana de este mes exploraremos algunos de esos detalles, ya que pueden tener un efecto significativo en c\u00f3mo se rastrean tus sitios.\n<\/p>\n

Retrocedamos un poco: \u00bfQu\u00e9 es el rastreo?<\/h2>\n

\n El rastreo<\/a> es el proceso de descubrir p\u00e1ginas web nuevas, volver a visitar las actualizadas y descargarlas. En resumen, Googlebot obtiene una URL, realiza una solicitud HTTP al servidor que la aloja y luego gestiona la respuesta de dicho servidor, posiblemente siguiendo redirecciones, manejando errores y enviando el contenido de la p\u00e1gina al sistema de indexaci\u00f3n de Google.\n<\/p>\n

\n Pero las p\u00e1ginas web modernas no son solo HTML puro, as\u00ed que \u00bfqu\u00e9 pasa con los otros recursos que componen una p\u00e1gina? \u00bfC\u00f3mo afecta el rastreo de estos recursos al “presupuesto de rastreo”? \u00bfSon estos recursos almacenables en cach\u00e9 por parte de Google? \u00bfY existe alguna diferencia entre las URLs que no se han rastreado antes y las que ya est\u00e1n indexadas? \u00a1En este art\u00edculo vamos a responder a estas preguntas y m\u00e1s!\n<\/p>\n

Googlebot y el rastreo de recursos de p\u00e1gina<\/h2>\n

\n M\u00e1s all\u00e1 del HTML, los sitios web modernos utilizan una combinaci\u00f3n de diferentes tecnolog\u00edas, como JavaScript y CSS, para ofrecer a los usuarios experiencias din\u00e1micas y funcionalidades \u00fatiles. Al acceder a dichas p\u00e1ginas con un navegador, este primero descarga la URL principal que aloja los datos necesarios para empezar a construir la p\u00e1gina para el usuario: el HTML de la p\u00e1gina. Estos datos iniciales pueden contener referencias a recursos como JavaScript y CSS, pero tambi\u00e9n im\u00e1genes y v\u00eddeos que el navegador descargar\u00e1 posteriormente para construir finalmente la p\u00e1gina que se presenta al usuario.\n<\/p>\n

\n Google hace exactamente lo mismo<\/a>, aunque de forma ligeramente diferente:\n<\/p>\n

    \n
  1. Googlebot descarga los datos iniciales de la URL principal: el HTML de la p\u00e1gina.<\/li>\n
  2. Googlebot env\u00eda los datos obtenidos al Servicio de Renderizado Web (WRS).<\/li>\n
  3. Utilizando Googlebot, el WRS descarga los recursos referenciados en los datos originales.<\/li>\n
  4. El WRS construye la p\u00e1gina utilizando todos los recursos descargados, tal como lo har\u00eda el navegador de un usuario.<\/li>\n<\/ol>\n

    \n En comparaci\u00f3n con un navegador, el tiempo entre cada paso puede ser significativamente mayor debido a restricciones de programaci\u00f3n, como la carga percibida del servidor que aloja los recursos necesarios para renderizar una p\u00e1gina. Y aqu\u00ed es donde el presupuesto de rastreo<\/a> entra en la conversaci\u00f3n.\n<\/p>\n

    \n Rastrear los recursos necesarios para renderizar una p\u00e1gina consumir\u00e1 parte del presupuesto de rastreo del nombre de host que aloja el recurso. Para mejorar esto, el WRS intenta almacenar en cach\u00e9 cada recurso (JavaScript y CSS) referenciado en las p\u00e1ginas que renderiza. El tiempo de vida (TTL) de la cach\u00e9 del WRS no se ve afectado por las directivas de cach\u00e9 HTTP; en su lugar, el WRS almacena todo durante un m\u00e1ximo de 30 d\u00edas, lo que ayuda a preservar el presupuesto de rastreo del sitio para otras tareas de rastreo.\n<\/p>\n

    \n Desde la perspectiva de los propietarios de sitios, gestionar c\u00f3mo y qu\u00e9 recursos se rastrean puede influir en el presupuesto de rastreo del sitio; recomendamos:\n<\/p>\n

      \n
    1. \n Utilizar la menor cantidad de recursos posible<\/strong> para ofrecer a los usuarios una gran experiencia; cuantos menos recursos se necesiten para renderizar una p\u00e1gina, menos presupuesto de rastreo se gastar\u00e1 durante el renderizado.\n <\/li>\n
    2. \n Utilizar par\u00e1metros de control de cach\u00e9 con precauci\u00f3n<\/strong>: si las URLs de los recursos cambian, es posible que Google necesite rastrear los recursos de nuevo, incluso si su contenido no ha cambiado. Esto, por supuesto, consumir\u00e1 presupuesto de rastreo.\n <\/li>\n
    3. \n Alojar los recursos en un nombre de host diferente<\/strong> al del sitio principal, por ejemplo, empleando una CDN o simplemente alojando los recursos en un subdominio distinto. Esto trasladar\u00e1 las preocupaciones sobre el presupuesto de rastreo al host que sirve los recursos.<\/p>\n