க்ராலருக்கு HTTP ப்ராக்ஸி வழங்குவது அதன் கோரிக்கைகள் வலைத்தளத்தை அடையும் விதத்தை மாற்றுகிறது. ஆனால் அது ப்ராக்ஸி robots.txt ஐப் பெறச் செய்யாது, க்ராலரின் விதிக் குழுவைத் தேர்ந்தெடுக்காது, அல்லது அதன் கோரிக்கைகளைப் பணிவுடன் திட்டமிடாது.

Robots Exclusion Protocol க்ராலர்களுக்கான விதிகளை விவரிக்கிறது. பொருத்தம், பெறுதலில் ஏற்படும் தோல்விகள், திருப்பிவிடல்கள் மற்றும் தற்காலிகச் சேமிப்பின் நடத்தை ஆகியவை இதில் அடங்கும். கோரப்பட்ட ஆவணத்தை மட்டும் அனுப்பும் ப்ராக்ஸி அந்தக் கொள்கையை க்ராலரின் சார்பாகச் செயல்படுத்தவில்லை.

விதிகளின் முடிவை க்ராலரின் கோரிக்கை வரிசைக்கு அருகில் வைத்திருங்கள். வேலை அனுப்பப்படும் முன், கருதப்படும் அடையாளம், இலக்கு URI மற்றும் திட்டமிடல் நிலை ஆகியவை அங்கேயே கிடைக்கும்.

ப்ராக்ஸி பக்கத்தில் வடிகட்டுவது கேட்பதை விட ஏன் கடினம்

சாதாரண HTTP இல், சிறப்பாக உருவாக்கப்பட்ட வடிகட்டி இலக்குப் பாதையையும் User-Agent ஐயும் பார்க்கலாம். இருப்பினும் அதற்கு உண்மையான விதிச் செயலாக்கமும், பொருந்தும் robots கோப்பைப் பெறுவது, சேமிப்பது, புதுப்பிப்பது ஆகியவற்றுக்கான திட்டவட்டமான கொள்கையும் தேவை. சில Disallow வரிகளை நிலையான முகவரித் தடைகளாக மாற்றுவது முழு நெறிமுறை அல்ல.

சாதாரண CONNECT வழியே HTTPS செல்லும்போது, முன்னனுப்பு ப்ராக்ஸி சுரங்கப்பாதையின் இலக்கைப் பார்க்கிறது, ஒவ்வொரு மறையாக்கப்பட்ட பக்கத்தின் பாதையையும் உள் User-Agent ஐயும் அல்ல. வேறு ஒரு வேண்டுமென்ற ஏற்பாடு வழங்காதவரை, பாதை அளவிலான robots முடிவுகளுக்குத் தேவையான தகவல் அதற்கு இல்லை.

வெளியேறும் முகவரியை மாற்றுவதும் தடைசெய்யப்பட்ட பாதையை அனுமதிக்கப்பட்டதாக மாற்றாது. க்ராலரின் செயல்பாட்டைப் பங்கிடும் பணியாளர்களிடையே வேகத்தை ஒருங்கிணைக்கவும்; பாதைகளைச் சுழற்றுவது அந்தக் கொள்கைக்கு மாற்று அல்ல.

இறுதியாக, robots விதிகள் அணுகல் அனுமதி அல்ல. அனுமதிக்கப்பட்ட பாதை அங்கீகாரத்தையோ தளத்தின் பிற அணுகல் தேவைகளையோ மீறாது, பொது robots கோப்பு தனிப்பட்ட உள்ளடக்கத்தைப் பாதுகாக்காது.

தொடர்புடைய கட்டுரைகள்