ახორციელებს თუ არა წინა პროქსი robots.txt-ს მცოცავისთვის?

მცოცავისთვის HTTP პროქსის მიცემა ცვლის იმას, თუ როგორ აღწევს მისი მოთხოვნები საიტამდე. თუმცა ეს არ აიძულებს პროქსის ჩამოტვირთოს robots.txt, აირჩიოს მცოცავის წესების ჯგუფი ან თავაზიანად დაგეგმოს მისი მოთხოვნები.

რობოტების გამორიცხვის პროტოკოლი აღწერს წესებს მცოცავებისთვის. ის მოიცავს შედარებას, ჩამოტვირთვის წარუმატებლობებს, გადამისამართებებსა და ქეშის ქცევას. პროქსი, რომელიც უბრალოდ გადასცემს მოთხოვნილ დოკუმენტს, ამ პოლიტიკას მცოცავის სახელით არ განუხორციელებია.

წესების გადაწყვეტილება მცოცავის მოთხოვნების რიგთან ახლოს შეინახეთ. სწორედ იქ არის სამუშაოს გაგზავნამდე ხელმისაწვდომი განზრახული იდენტობა, სამიზნე URI და დაგეგმვის მდგომარეობა.

რატომ არის პროქსის მხარეს ფილტრი უფრო რთული, ვიდრე ჟღერს

ჩვეულებრივი HTTP-სთვის სპეციალურად აშენებულ ფილტრს შეუძლია დაინახოს სამიზნე გზა და User-Agent. მას მაინც სჭირდება წესების ნამდვილი დანერგვა და განსაზღვრული პოლიტიკა შესაბამისი robots ფაილის ჩამოტვირთვის, ქეშირებისა და განახლებისთვის. რამდენიმე Disallow ხაზის სტატიკურ მისამართთა ბლოკებად გადაქცევა სრული პროტოკოლი არ არის.

ჩვეულებრივი CONNECT-ით HTTPS-ის დროს წინა პროქსი ხედავს გვირაბის დანიშნულებას და არა ყოველი დაშიფრული გვერდის გზასა და შიდა User-Agent-ს. მას აკლია გზის დონეზე robots გადაწყვეტილებებისთვის საჭირო ინფორმაცია, თუ სხვა განზრახ მოწყობა არ მოგვაწვდის.

გამავალი მისამართის შეცვლაც არ აქცევს აკრძალულ გზას ნებადართულად. შეათანხმეთ ტემპი მცოცავის აქტივობის გამზიარებელ მუშაკებს შორის; მარშრუტების ტრიალი ამ პოლიტიკას არ ცვლის.

და ბოლოს, robots წესები წვდომის ნებართვა არ არის. ნებადართული გზა არ აუქმებს ავთენტიფიკაციას ან საიტის სხვა წვდომის მოთხოვნებს, ხოლო საჯარო robots ფაილი კერძო შიგთავსს არ იცავს.