Pumili ng kontrol na tumutugma sa hangarin
Ang crawling ay awtomatikong pagkuha (retrieval) ng isang URL. Ang indexing ay ang pagpapasya ng search engine kung i-susulat at ipapakita ang impormasyon tungkol dito. Ang access control ay tumutukoy kung sino ang maaaring makuha ang nilalaman. Ang robots.txt ay tungkol sa crawling, at ang mga sumusunod na crawler ang nagdedesisyon kung susundin nila ito. Ayon sa IETF Robots Exclusion Protocol, hindi ito authorization.
Gumamit ng Disallow rule para pamahalaan ang access ng crawler sa isang publikong path na mababa ang halaga, gaya ng isang kontroladong internal-search route. Gumamit ng noindex para sa publikong nilalaman na hindi dapat lumabas sa suportadong resulta ng search. Gumamit ng totoong kontrol sa access para sa mga preview, account area, export, o sensitibong data. Para sa customer, empleyado, pagbabayad, o reguladong impormasyon, kumuha ng kwalipikadong security at platform review; hindi kailanman isang compensating control ang robots.txt.
Maaaring hilingin ng robots.txt na iwasan ng mga sumusunod na crawler ang isang tinukoy na publikong path; hindi nito ginagarantiya ang pagtanggal mula sa mga resulta.
Gumamit ng noindex sa HTML o sa X-Robots-Tag header, at iwanang crawlable ang tugon para mabasa ang instruksyon.
Kailangan ng authentication o angkop na kontrol ng application o server, at pagkatapos alisin ang URL mula sa pampublikong discovery paths.
Gamitin ang core syntax at saklaw nang eksakto
Maglathala ng UTF-8 plain-text na robots.txt sa /robots.txt para sa bawat scheme, host, at port na nangangailangan ng mga tuntunin. Ang file sa https://www.example.com/robots.txt ay hindi awtomatikong kumokontrol sa https://example.com, isang subdomain, o isang HTTP origin. Beripikahin ang mga origin na hinihain ng canonical URLs, redirects, CDN, at application bago ipalagay na naaangkop ang isang tuntunin.
Nagsisimula ang isang group sa User-agent at gumagamit ng Allow o Disallow paths. Ang User-agent: * ay ang pangkalahatang grupo. Case-sensitive ang matching at nagsisimula sa simula ng path. Ang pinaka-specific na matching rule ang nananalo; dapat manalo ang isang pantay na specific na Allow laban sa Disallow. Ang Disallow: ay hindi nagba-block ng anuman, samantalang ang Disallow: / ay nagba-block ng buong origin. Tinukoy ng standard ang # para sa comments, * para sa wildcard, at $ para sa dulo ng pattern.
Kung walang dokumentadong pangangailangan sa crawl-management, huwag magdagdag ng exclusions; huwag gumawa ng speculative blocks.
Mas piliin ang isang matatag, makitid na prefix gaya ng /search/ kaysa sa maluwag na wildcard o hindi ipinaliwang filename rule.
Itala ang layunin ng tuntunin, may-ari, at reference ng pagbabago, ngunit huwag ituring ang comments bilang pamalit sa review.
I-block lamang ang mga pattern na suportado ng ebidensya ng URL
Bago magsulat ng tuntunin, imbentaryo ang mga importanteng pahina, hindi gustong crawl paths, query variants, on-site search, preview routes, assets, at sitemap URLs. Para sa bawat sample URL, itala ang inaasahang resulta at katugmang rule. Ihambing ang listahan sa canonical URLs at live navigation para hindi maitago ng block ang isang kapaki-pakinabang na ruta.
Panatilihing available ang mga browser-critical na resources maliban na lang kung nasubukan nang iba. Binibigyang-diin ng Google na ang pag-block ng CSS, JavaScript, images, o ibang resources ay maaaring magpahirap sa pagsusuri ng pahina. Hindi nilulutas ng robots.txt ang duplicate-content selection, authorization, o page quality; gumamit ng canonicalization, redirects, access controls, o content work kung nararapat.
Gumamit ng totoong URL samples at server o crawl evidence, hindi isang generic na listahang kinopya mula sa ibang site.
Panatilihin ang bawat sample URL, inaasahang resulta, matched rule, at may pananagutang may-ari sa release record.
Panatilihing magkakaugnay ang sitemap discovery, noindex, at mga desisyon sa privacy
Ang sitemap ay nagsasabi sa search engines kung aling mga URL at file ang itinuturing mong mahalaga; makakatulong ito sa discovery ngunit hindi ginagarantiyahan ang crawling o indexing. Mahalaga pa rin ang malalakas na internal links. Maaari kang magdagdag ng fully qualified na Sitemap URL sa robots.txt, ngunit huwag ilista ang pribado, redirected, robots-blocked, o intentional na noindex na URL. I-reconcile ang output ng sitemap sa robots rules sa release.
Ang noindex ay hindi isang directive ng Google robots.txt. Sinusuportahan ito ng Google sa isang HTML meta tag o X-Robots-Tag HTTP response header, at kailangan nilang i-crawl ang tugon para makita ito. Kung ang isang publikong pahina ay kailangang lumabas sa Google results, alisin ang anumang robots block na nagtatago ng noindex. Kung ang nilalaman ay nonpublic, huwag i-advertise ang path nito sa robots.txt; ipatupad ang access control. Ang mga hangganan ng sensitibong data ay nangangailangan ng kwalipikadong review.
Gumamit ng full URL, halimbawa Sitemap: https://www.example.com/sitemap.xml; hindi nito nire-override ang crawl block.
Gumamit ng meta noindex para sa HTML o ng X-Robots-Tag: noindex response header kung angkop, at pagkatapos subukan ang live na tugon.
Limitahan muna ang access kapag sensitibo ang nilalaman, at pagkatapos gamitin ang removal process ng search engine kung nararapat.
Subukan at i-release ito tulad ng isang kritikal na configuration file
I-validate ang aprubadong teksto nang lokal, pagkatapos subukan ang pinapayagan at hindi pinapayagang mga halimbawa para sa inaasahang crawler group. Pagkatapos i-deploy, i-retrieve ang pampublikong /robots.txt nang pribado o sa pamamagitan ng direktang HTTP request para tiyakin ang nilalaman, origin, at response status. Nag-aalok ang Google ng Search Console robots.txt report para sa accessible na mga file at isang open-source parser library para sa lokal na testing.
Maaaring mag-cache ang mga crawler ng robots file, kaya huwag mag-asang agarang pagbabago sa discovery o indexing. Ang mga error sa server o network ay nag-uudyok sa mga crawler na ipalagay ang kumpletong disallow, habang ang 4xx ay maaaring magpayag ng access. Ilagay ang file sa source-controlled configuration, mangailangan ng dagdag na review para sa whole-site o wildcard changes, at panatilihin ang naunang bersyon. Nakakatulong ang SIU preflights at rollback planning upang mahuli ang isang maling release bago ito lumaki bilang availability o discoverability problem.
Mangailangan ng pangalawang reviewer para sa origin migrations, whole-site blocks, wildcards, at mga pagbabago na nakakaapekto sa sign-in, checkout, o support routes.
I-restore ang naunang bersyon kapag isang mahalagang sample URL ay bagong na-block, isang kailangang asset ay hindi maa-access, o ang endpoint ay hindi available.
Isang crawler test lamang ay hindi nagpapatunay na bawat automated client ay i-interpret ang bawat rule sa parehong paraan.