Dwing 'n voorstuur-proksie robots.txt af vir 'n kruiper?
Hou die robots-beleid in die kruiper en verstaan die grense van die afdwing daarvan by 'n voorstuur-proksie.
'n HTTP-proksie aan 'n kruiper gee verander die manier waarop sy versoeke die webwerf bereik. Dit maak nie dat die proksie robots.txt gaan haal, die kruiper se reëlgroep kies of sy versoeke hoflik beplan nie.
Die Robots Exclusion Protocol beskryf reëls vir kruipers. Dit sluit passing, mislukkings by die ophaal, herleidings en kasgedrag in. 'n Proksie wat net die gevraagde dokument deurstuur, het daardie beleid nie namens die kruiper geïmplementeer nie.
Hou die reëlbesluit naby die kruiper se versoekwagtou. Dit is waar die beoogde identiteit, die teiken-URI en die beplanningstatus beskikbaar is voordat werk gestuur word.
Waarom 'n filter aan die proksiekant moeiliker is as wat dit klink
Vir gewone HTTP kan 'n spesiaal geboude filter die teikenpad en die User-Agent sien. Dit het steeds 'n werklike reëlimplementering nodig, plus 'n bepaalde beleid vir die ophaal, kas en bywerking van die betrokke robots-lêer. Om 'n paar Disallow-reëls in statiese URL-blokke te omskep, is nie die volledige protokol nie.
Vir HTTPS deur gewone CONNECT sien die voorstuur-proksie die tonnelbestemming, nie elke geënkripteerde bladsypad en die binneste User-Agent nie. Dit kort inligting vir robots-besluite op pad-vlak, tensy 'n ander doelbewuste reëling dit verskaf.
Om die uitgangs-IP te verander maak ook nie 'n verbode pad na 'n toegelate pad nie. Koördineer die tempo oor werkers wat dieselfde kruiperaktiwiteit deel; die rotering van roetes is nie 'n plaasvervanger vir daardie beleid nie.
Laastens is robots-reëls nie toegangsgesag nie. 'n Toegelate pad hef nie verifikasie of die werf se ander toegangsvereistes op nie, en 'n openbare robots-lêer beveilig nie private inhoud nie.