تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
نظرة عامة على برامج الزحف وبرامج الجلب من Google (برامج وكيل المستخدم)
تستخدم Google برامج الزحف والجلب لتنفيذ الإجراءات الخاصة بمنتجاتها، سواءً بشكل تلقائي أو استنادًا إلى طلب المستخدم. "برنامج الزحف" أو "الزاحف" (يُسمّى أيضًا "الروبوت" أو "العنكبوت") هو مصطلح عام لأي برنامج يتم استخدامه لاكتشاف المواقع الإلكترونية وفحصها تلقائيًا.
تعمل برامج الجلب كبرامج مثل
wget التي تنشئ طلبًا واحدًا بالنيابة عن أحد المستخدمين. تندرج برامج الزحف من Google ضمن ثلاث فئات:
تشبه برامج الزحف في الحالات الخاصة برامج الزحف الشائعة، ولكنّها مستخدَمة في منتجات معيّنة
إذا كانت هناك اتفاقية بشأن عملية الزحف بين الموقع الإلكتروني الذي يتم الزحف إليه ومنتج Google. على سبيل المثال، يتجاهل AdsBot وكيل المستخدم العام robots.txt (*) الحاصل على إذن ناشر الإعلان.
برامج الجلب التي يشغّلها المستخدم هي جزء من الأدوات ووظائف المنتجات التي يشغّل فيها المستخدم النهائي عمليات جلب. على سبيل المثال، تعالج أداة إثبات ملكية الموقع على Google طلب المستخدم.
السمات الفنية لبرامج الزحف وبرامج الجلب من Google
تم تصميم برامج الزحف وبرامج الجلب من Google لتشغيلها على الآلاف من الأجهزة في الوقت نفسه بهدف تحسين أدائها وإمكاناتها مع تطوّر شبكة الويب. لتحسين استهلاك معدل نقل البيانات، يتم توزيع العملاء على عدّة مراكز بيانات حول العالم ليكونوا بالقرب من المواقع الإلكترونية التي قد تم الوصول إليها. بالتالي، قد تعرض سجلاتك الزيارات من عناوين IP متعدّدة.
تصدر معظم زيارات الإنترنت على Google من عناوين IP تقع في الولايات المتحدة بشكل أساسي. وفي حال اكتشف محرك بحث Google أنّ موقعًا إلكترونيًا يحظر الطلبات من الولايات المتحدة، قد يحاول الزحف من عناوين IP تقع في بلدان أخرى.
بروتوكولات النقل المتوافقة
تتوافق برامج الزحف وبرامج الجلب من Google مع بروتوكولَي HTTP/1.1 وHTTP/2. ستستخدم برامج الزحف إصدار البروتوكول الذي يوفّر أفضل أداء للزحف، وقد تبدّل البروتوكول بين جلسات الزحف بناءً على إحصاءات الزحف السابقة. إنّ إصدار البروتوكول التلقائي الذي تستخدمه برامج الزحف من Google هو HTTP/1.1. ويمكن أن يساهم الزحف عبر HTTP/2 في توفير موارد الحوسبة (على سبيل المثال، وحدة المعالجة المركزية CPU وذاكرة الوصول العشوائي RAM) الخاصة بكل من الموقع الإلكتروني وGooglebot، ولكن بخلاف ذلك، لن يستفيد الموقع الإلكتروني من أي مزايا خاصة بالمنتجات (مثل تحسين ترتيبه في "بحث Google").
لإيقاف الزحف عبر HTTP/2، يمكنك أن تطلب من الخادم الذي يستضيف موقعك الإلكتروني الاستجابة
برمز 421 لحالة HTTP عندما يحاول Google الوصول إلى موقعك الإلكتروني عبر HTTP/2. إذا لم يكن ذلك ممكنًا، يمكنك
إرسال رسالة إلى فريق برامج الزحف
(إلا أنّ هذا الحل مؤقت).
تتيح البنية الأساسية لبرامج الزحف من Google أيضًا الزحف عبر "بروتوكول نقل الملفات" (كما هو محدّد وفق المعيار RFC959 وتحديثاته) و"بروتوكول نقل الملفات الآمن" (كما هو محدّد وفق المعيار RFC4217 وتحديثاته)، إلا أنّ الزحف نادرًا ما يتم عبر هذين البروتوكولين.
ترميزات المحتوى المتوافقة
تتوافق برامج الزحف وبرامج الجلب من Google مع ترميزات المحتوى التالية (عمليات الضغط):
gzip
وdeflate
وBrotli (br). تظهر ترميزات المحتوى المتوافقة مع كل وكيل مستخدم من Google
في عنوان Accept-Encoding لكل طلب يتم إجراؤه. على سبيل المثال:
Accept-Encoding: gzip, deflate, br.
معدل الزحف وحِمل المضيف
هدفنا هو الزحف إلى أكبر عدد ممكن من صفحات موقعك الإلكتروني عند كل زيارة بدون تحميل الخادم عبئًا زائدًا. وإذا كان موقعك الإلكتروني يواجه صعوبة في الاستجابة لطلبات الزحف من Google، يمكنك خفض معدّل الزحف. يُرجى العِلم أنّ إرسال
رمز استجابة HTTP
غير ملائم إلى برامج الزحف من Google قد يؤثّر على طريقة ظهور موقعك الإلكتروني في منتجات Google.
التخزين المؤقت عبر HTTP
تتيح البنية الأساسية للزحف في Google التخزين المؤقت الإرشادي عبر HTTP كما هو محدّد وفق معيار التخزين المؤقت عبر HTTP، وتحديدًا من خلال عنوان الاستجابة الذي يتضمّن ETag وعنوان الطلب الذي يتضمّن If-None-Match، ومن خلال عنوان الاستجابة الذي يتضمّن Last-Modified وعنوان الطلب الذي يتضمّن If-Modified-Since.
إذا كان الحقلان ETag وLast-Modified لعنوان الاستجابة متوفّرَين في استجابة HTTP، ستستخدم برامج الزحف من Google القيمة ETagوفقًا لما يتطلّبه معيار HTTP.
بالنسبة إلى برامج الزحف من Google تحديدًا، ننصح بتضمين السمة
ETag
في العنوان بدلاً من Last-Modified لتحديد الخيار المفضّل للتخزين المؤقت،
لأنّ السمة ETag لا تؤدي إلى مشاكل مرتبطة بتنسيق التاريخ.
لا يمكن استخدام توجيهات HTTP الأخرى الخاصة بالتخزين المؤقت.
يمكن أن تستعين برامج الزحف والجلب الفردية من Google بالتخزين المؤقت، ويعتمد ذلك على الاحتياجات المحددة للمنتج المرتبط بها. على سبيل المثال، يتيح Googlebot التخزين المؤقت عند إعادة الزحف إلى عناوين URL لمحرّك بحث Google، ويتيح Storebot-Google التخزين المؤقت في حالات محددة فقط.
لتنفيذ التخزين المؤقت عبر HTTP لموقعك الإلكتروني، عليك التواصل مع المستضيف أو مزوّد نظام إدارة المحتوى.
ETag وIf-None-Match
تتيح البنية الأساسية لبرامج الزحف من Google استخدام ETag وIf-None-Match، كما هو محدّد وفق معيار التخزين المؤقت عبر HTTP.
يمكن الاطّلاع على المزيد حول
عنوان الاستجابة الذي يتضمّن ETag،
ونظيره،
عنوان الطلب الذي يتضمّن If-None-Match.
Last-Modified وIf-Modified-Since
تتيح البنية الأساسية لبرامج الزحف من Google استخدام Last-Modified وIf-Modified-Since، كما هو محدّد وفق معيار التخزين المؤقت عبر HTTP، شرط الالتفات إلى النقاط التالية:
يجب أن يكون تنسيق التاريخ في العنوان الذي يتضمّن Last-Modified متوافقًا مع معيار HTTP.
لتجنُّب حدوث أي مشاكل متعلّقة بالتحليل، ننصح باستخدام التنسيق التالي للتاريخ:
"اليوم من الأسبوع، DD Mon YYYY HH:MM:SS المنطقة الزمنية". مثال:
"Fri, 4 Sep 1998 19:15:56 GMT".
مع أنّ ضبط الحقل max-age في عنوان الاستجابة الذي يتضمّن Cache-Control ليس شرطًا، ننصح بضبطه لمساعدة برامج الزحف على معرفة الوقت المناسب لإعادة الزحف إلى عنوان URL المحدّد. يجب ضبط قيمة الحقل
max-age على عدد الثواني المتوقّع ألّا يتغيّر المحتوى خلالها. مثلاً: Cache-Control: max-age=94043.
يمكن الاطّلاع على المزيد حول
عنوان الاستجابة الذي يتضمّن Last-Modified،
ونظيره، عنوان الطلب الذي يتضمّن If-Modified-Since.
التحقّق من برامج الزحف وبرامج الجلب من Google
يتم تحديد برامج الزحف من Google من خلال ثلاث طرق وهي:
عنوان طلب HTTP الخاص بـuser-agent
عنوان IP المصدر للطلب
نظام أسماء النطاقات العكسي لاسم المضيف الخاص بعنوان IP المصدر
تاريخ التعديل الأخير: 2025-08-04 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-04 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eGoogle uses crawlers and fetchers, categorized as common, special-case, and user-triggered, to automatically discover and scan websites or make single requests on behalf of users.\u003c/p\u003e\n"],["\u003cp\u003eGoogle's crawlers and fetchers, distributed globally for optimized performance, primarily egress from US IP addresses and support HTTP/1.1, HTTP/2, FTP, and FTPS protocols for content access.\u003c/p\u003e\n"],["\u003cp\u003eGoogle aims for efficient crawling without overloading servers and supports content encodings like gzip, deflate, and Brotli, while also respecting robots.txt rules for automatic crawls.\u003c/p\u003e\n"],["\u003cp\u003eGoogle utilizes HTTP caching mechanisms, primarily ETag and Last-Modified headers, to minimize redundant data transfer and improve crawling efficiency.\u003c/p\u003e\n"],["\u003cp\u003eGoogle's crawlers can be verified through their user-agent, source IP address, and reverse DNS hostname, ensuring authenticity and security.\u003c/p\u003e\n"]]],["Google's crawlers, which automatically discover and scan websites, and fetchers, which make single requests, serve Google products. Clients are categorized as common crawlers, special-case crawlers (with site-specific agreements), and user-triggered fetchers. They operate from global datacenters, use HTTP/1.1 or HTTP/2, and support gzip, deflate, and Brotli compression. Crawl rates can be adjusted to prevent server overload. Caching, via ETag and Last-Modified headers, is supported to optimize crawling efficiency. To identify a google crawler, use HTTP user-agent, source IP address, and the reverse DNS hostname.\n"],null,["# Google Crawler (User Agent) Overview | Google Search Central\n\nOverview of Google crawlers and fetchers (user agents)\n======================================================\n\n\nGoogle uses crawlers and fetchers to perform actions for its products, either automatically or\ntriggered by user request. Crawler (sometimes also called a \"robot\" or \"spider\") is a generic term\nfor any program that is used to\n[automatically discover and scan websites](/search/docs/fundamentals/how-search-works#crawling).\nFetchers act as a program like\n[wget](https://www.gnu.org/software/wget/) that typically make a\nsingle request on behalf of a user. Google's clients fall into three categories:\n\n|------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| [Common crawlers](/search/docs/crawling-indexing/google-common-crawlers) | The common crawlers used for Google's products (such as [Googlebot](/search/docs/crawling-indexing/googlebot)). They always respect robots.txt rules for automatic crawls. |\n| [Special-case crawlers](/search/docs/crawling-indexing/google-special-case-crawlers) | Special-case crawlers are similar to common crawlers, however are used by specific products where there's an agreement between the crawled site and the Google product about the crawl process. For example, `AdsBot` ignores the global robots.txt user agent (`*`) with the ad publisher's permission. |\n| [User-triggered fetchers](/search/docs/crawling-indexing/google-user-triggered-fetchers) | User-triggered fetchers are part of tools and product functions where the end user triggers a fetch. For example, [Google Site Verifier](https://support.google.com/webmasters/answer/9008080) acts on the request of a user. |\n\nTechnical properties of Google's crawlers and fetchers\n------------------------------------------------------\n\n\nGoogle's crawlers and fetchers are designed to be run simultaneously by thousands of machines to\nimprove performance and scale as the web grows. To optimize bandwidth usage, these clients are\ndistributed across many datacenters across the world so they're located near the sites that they\nmight access. Therefore, your logs may show visits from several IP addresses.\nGoogle egresses primarily from IP addresses in the United States. In case Google detects that a\nsite is blocking requests from the United States, it may attempt to crawl from IP addresses\nlocated in other countries.\n\n### Supported transfer protocols\n\n\nGoogle's crawlers and fetchers support HTTP/1.1 and\n[HTTP/2](https://en.wikipedia.org/wiki/HTTP/2). The crawlers will\nuse the protocol version that provides the best crawling performance and may switch protocols\nbetween crawling sessions depending on previous crawling statistics. The default protocol\nversion used by Google's crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources\n(for example, CPU, RAM) for your site and Googlebot, but otherwise\nthere's no Google-product specific benefit to the site (for example, no ranking boost in Google Search).\nTo opt out from crawling over HTTP/2, instruct the server that's hosting your site to respond\nwith a `421` HTTP status code when Google attempts to access your site over\nHTTP/2. If that's not feasible, you\n[can send a message to the Crawling team](https://www.google.com/webmasters/tools/googlebot-report)\n(however this solution is temporary).\n\n\nGoogle's crawler infrastructure also supports crawling through FTP (as defined by\n[RFC959](https://datatracker.ietf.org/doc/html/rfc959) and its\nupdates) and FTPS (as defined by\n[RFC4217](https://datatracker.ietf.org/doc/html/rfc4217) and its\nupdates), however crawling through these protocols is rare.\n\n### Supported content encodings\n\n\nGoogle's crawlers and fetchers support the following content encodings (compressions):\n[gzip](https://en.wikipedia.org/wiki/Gzip),\n[deflate](https://en.wikipedia.org/wiki/Deflate), and\n[Brotli (br)](https://en.wikipedia.org/wiki/Brotli). The\ncontent encodings supported by each Google user agent is advertised in the\n`Accept-Encoding` header of each request they make. For example,\n`Accept-Encoding: gzip, deflate, br`.\n\n### Crawl rate and host load\n\n\nOur goal\nis to crawl as many pages from your site as we can on each visit without overwhelming your\nserver. If your site is having trouble keeping up with Google's crawling requests, you can\n[reduce the crawl rate](/search/docs/crawling-indexing/reduce-crawl-rate). Note that\nsending the inappropriate\n[HTTP response code](/search/docs/crawling-indexing/http-network-errors)\nto Google's crawlers may affect how your site appears in Google products.\n\n### HTTP Caching\n\n\nGoogle's crawling infrastructure supports heuristic HTTP caching as defined by the\n[HTTP caching standard](https://httpwg.org/specs/rfc9111.html),\nspecifically through the `ETag` response- and `If-None-Match` request\nheader, and the `Last-Modified` response- and `If-Modified-Since` request\nheader.\n| Note: Consider setting both the `Etag` and `Last-Modified` values regardless of the preference of Google's crawlers. These headers are also used by other applications such as CMSes.\n\n\nIf both `ETag` and `Last-Modified` response header fields are present in the\nHTTP response, Google's crawlers use the `ETag` value as\n[required by the HTTP standard](https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.3).\nFor Google's crawlers specifically, we recommend using\n[`ETag`](https://www.rfc-editor.org/rfc/rfc9110#name-etag)\ninstead of the `Last-Modified` header to indicate caching preference as\n`ETag` doesn't have date formatting issues.\n\n\nOther HTTP caching directives aren't supported.\n\n\nIndividual Google crawlers and fetchers may or may not make use of caching, depending on the needs\nof the product they're associated with. For example, `Googlebot` supports caching when\nre-crawling URLs for Google Search, and `Storebot-Google` only supports caching in\ncertain conditions.\n\n\nTo implement HTTP caching for your site, get in touch with your hosting or content management\nsystem provider.\n\n#### `ETag` and `If-None-Match`\n\n\nGoogle's crawling infrastructure supports `ETag` and `If-None-Match` as\ndefined by the\n[HTTP Caching standard](https://httpwg.org/specs/rfc9111.html).\nLearn more about the\n[`ETag`](https://www.rfc-editor.org/rfc/rfc9110#name-etag)\nresponse header and its request header counterpart,\n[`If-None-Match`](https://www.rfc-editor.org/rfc/rfc9110#name-if-none-match).\n\n#### Last-Modified and If-Modified-Since\n\n\nGoogle's crawling infrastructure supports `Last-Modified` and\n`If-Modified-Since` as defined by the\n[HTTP Caching standard](https://httpwg.org/specs/rfc9111.html)\nwith the following caveats:\n\n- The date in the `Last-Modified` header must be formatted according to the [HTTP standard](https://www.rfc-editor.org/rfc/rfc9110.html). To avoid parsing issues, we recommend using the following date format: \"Weekday, DD Mon YYYY HH:MM:SS Timezone\". For example, \"Fri, 4 Sep 1998 19:15:56 GMT\".\n- While not required, consider also setting the [`max-age` field of the `Cache-Control` response header](https://www.rfc-editor.org/rfc/rfc9111.html#name-max-age-2) to help crawlers determine when to recrawl the specific URL. Set the value of the `max-age` field to the expected number of seconds the content will be unchanged. For example, `Cache-Control: max-age=94043`.\n\n\nLearn more about the\n[`Last-Modified`](https://www.rfc-editor.org/rfc/rfc9110#name-last-modified)\nresponse header and its request header counterpart, [`If-Modified-Since`](https://www.rfc-editor.org/rfc/rfc9110#name-if-modified-since).\n\nVerifying Google's crawlers and fetchers\n----------------------------------------\n\n\nGoogle's crawlers identify themselves in three ways:\n\n1. The HTTP `user-agent` request header.\n2. The source IP address of the request.\n3. The reverse DNS hostname of the source IP.\n\n\nLearn how to use these details to\n[verify Google's crawlers and fetchers](/search/docs/crawling-indexing/verifying-googlebot)."]]