robots.txt: რა დავბლოკოთ, რა დავუშვათ
ერთ-ერთი კლიენტი გასულ ზამთარს უჩიოდა: „საიტი Google-ში საერთოდ ვერ მოიძებნება. საკუთარი ბრენდის სახელით — შედეგებში არ ვართ. რა ჩაიდინე?“ საიტი თვის წინ ახალ სერვერზე გადავიდა, ყველაფერი მუშაობდა, დიზაინი ახალი, კონტენტი ადგილზე. მაგრამ ინდექსში — ნული გვერდი. სრულიად ნული.
გავხსენი https://site.com/robots.txt. იქ ოთხი ხაზი ეწერა:
User-agent: *
Disallow: /
სულ ეს იყო. საიტი მთლიანად დახურულია ყველა საძიებო სისტემისგან. ეს კონფიგურაცია staging-გარემოდან დარჩა — როცა საიტი ჯერ კიდევ მუშავდებოდა და არ უნდოდათ მისი ინდექსირება. პროდაქშენზე დეპლოის დროს ფაილი უბრალოდ ისე გადააკოპირეს, როგორც იყო. ვერავინ შეამოწმა.
გასასწორებლად ათი წამი დასჭირდა: Disallow-ის შემდეგ / მოვაშორე. იმისთვის, რომ Google-ს კვლავ მოეხდინა საიტის ინდექსირება — სამი კვირა. ორგანული ტრაფიკის დასაბრუნებლად — ნახევარი წელი. თვე ინდექსაციის გარეშე = დაკარგული სიგნალები, დაკარგული პოზიციები, დაკარგული მომხმარებლები.
robots.txt — საიტზე ერთ-ერთი ყველაზე საშიში ფაილია. არა იმიტომ, რომ რთულია. პირიქით — იმიტომ, რომ ძალიან მარტივია. ეს plain text-ია, ოთხი დირექტივა, არ აქვს ვალიდატორი IDE-ში, არ აქვს ავტოტესტები. სლეში არასწორ ადგილას დააყენე, wildcard ცუდად ჩასვი — და საიტის ნახევარი გაქრა ძიების შედეგებიდან. ვერავინ გაგაფრთხილებს. ვერავინ წითლად მონიშნავს შეცდომას. Google ჩუმად შეწყვეტს იქ შესვლას, სადაც აუკრძალე, და ამის შესახებ შენ ორი კვირის შემდეგ შეიტყობ, როცა პოზიციები უკვე ჩამოიქცა.
ამ პოსტში — რა გავაკეთო, რომ ჩემი ისტორია არ გაიმეორო.
რა არის robots.txt
ტექსტური ფაილი, რომელიც დევს დომენის ფესვში: https://example.com/robots.txt. არა ქვესაქაღალდეში, არა ქვედირექტორიაში — სწორედ ფესვში, თორემ ბოტები მას ვერ იპოვიან. ერთი ფაილი ერთ ჰოსტზე. თუ გაქვს ქვედომენები — თითოეულს თავისი robots.txt აქვს.
ეს არის REP — Robots Exclusion Protocol-ის სტანდარტის ნაწილი. სტანდარტი ძველია, 1994 წლის, დაიბადა მანამდე, სანამ საძიებო სისტემები ისეთებად იქცეოდნენ, როგორებიც გახდნენ. 2022 წელს IETF-მა საბოლოოდ შექმნა მისგან RFC 9309 — ფორმალურად დოკუმენტირებული სტანდარტი. მანამდე თითოეული ბოტი robots.txt-ს ისე იგებდა, როგორც სურდა.
არსში ეს არის ინსტრუქცია კრაულერებისთვის: საიტზე რომელი გზები არ უნდა დაასკანერონ. Google, Bing, Yandex, DuckDuckGo და ნორმალური ბოტების უმეტესობა იცავს მას. ChatGPT-იც ახლა უყურებს robots.txt-ს — GPTBot-ისა და ClaudeBot-ისთვის განკუთვნილი დირექტივების მეშვეობით. სკამ-კრაულერები და პარსერები ჩვეულებრივ უგულებელყოფენ მას, რადგან ეს არ არის აკრძალვა, ეს არის თხოვნა.
ორი რამ, რასაც robots.txt არ აკეთებს:
robots.txt — ეს არ არის უსაფრთხოება. ნებისმიერს შეუძლია გახსნას site.com/robots.txt და წაიკითხოს იმის სია, რაც დახურე. თუ იქ წერ Disallow: /secret-admin-panel/ — ახლახან მთელ ინტერნეტს მიუთითე საიდუმლო ადმინპანელის მისამართი. პირადი გზების robots.txt-ით დახურვა იგივეა, რომ უსაკეტო სახლზე ჩამოკიდო ფირფიტა „აქ სეიფია“.
robots.txt — ეს არ არის noindex. Disallow კრძალავს გვერდზე შესვლას. მაგრამ თუ ამ გვერდზე სხვა საიტებიდან ბმულები მიდის, Google მაინც შეიძლება აჩვენოს იგი ძიების შედეგებში — ცარიელი სნიპეტითა და მინიშნებით „No information is available for this page“. გინდა, რომ გვერდი სამუდამოდ ამოშალო ინდექსიდან — გჭირდება noindex, არა robots.txt.
ბაზისური სინტაქსი
ფაილი ბლოკებისგან შედგება. თითოეული ბლოკი იწყება User-agent-ით, შემდეგ მოდის დირექტივები.
User-agent: *
Disallow: /admin/
Allow: /admin/public/
Sitemap: https://example.com/sitemap.xml
User-agent: * — წესები ერთდროულად ყველა ბოტისთვის. ვარსკვლავი ნიშნავს „ნებისმიერ კრაულერს“.
User-agent: Googlebot — წესები მხოლოდ Google-ისთვის. თუ გინდა სხვადასხვა წესი სხვადასხვა ბოტისთვის, ცალკე ბლოკებს აკეთებ. Googlebot კითხულობს თავის ბლოკს და უგულებელყოფს ვარსკვლავიან ბლოკს. თუ კონკრეტული ბოტისთვის ბლოკი არ არსებობს — ის კითხულობს ვარსკვლავიან ზოგად ბლოკს.
Disallow: /admin/ — კრძალავს ყველაფერს, რაც იწყება /admin/-ით. ანუ ერთდროულად /admin/, /admin/users და /admin/settings/permissions. სლეში ბოლოში მნიშვნელოვანია: Disallow: /admin სლეშის გარეშე დახურავს ერთდროულად /admin/users-ს და /admin-panel-secret-ს. ყოველთვის ის არ არის, რაც გინდოდა.
Allow: /public/ — უშვებს გზას. აზრი აქვს მხოლოდ მაშინ, როცა ზემოთ ფართო Disallow გაქვს და გინდა გამონაკლისის გაკეთება. Disallow-ის გარეშე დირექტივა Allow უაზროა — ყველაფერი ისედაც დაშვებულია ნაგულისხმევად.
Sitemap: https://example.com/sitemap.xml — გზა sitemap-მდე. შეიძლება რამდენიმე ხაზი, თუ sitemap-ები რამდენიმეა. მითითებულია სრული URL, არა შედარებითი.
Wildcards: * — სიმბოლოების ნებისმიერი თანმიმდევრობა, $ — სტრიქონის დასასრული.
Disallow: /*.pdf$
Disallow: /*?session=
პირველი ხაზი დახურავს ყველა PDF-ფაილს. მეორე — ყველა URL-ს session პარამეტრით query string-ში.
URL path-ები რეგისტრდამოკიდებულია. /Admin/ და /admin/ — ეს ორი სხვადასხვა გზაა. თუ საიტზე ასეთი დანაწევრება გაქვს, ორივე უნდა დახურო.
კომენტარები — #-ის მეშვეობით. გამოიყენე ისინი უხვად, რომ ნახევარი წლის შემდეგ გესმოდეს, რა და რისთვის დაწერე აქ.
რას ვბლოკავთ ჩვეულებრივ
არა ყველაფერს ზედიზედ. მხოლოდ იმას, რაც არ უნდა აბინძურებდეს ინდექსს ან ფუჭად ხარჯავდეს crawl budget-ს.
/admin/, /wp-admin/, /login/, /dashboard/ — შიდა გვერდები ადმინისტრატორებისა და რეგისტრირებული მომხმარებლებისთვის. Google-ს იქ ნაკეთები არაფერი აქვს, ეს გვერდები ან ავტორიზაციას მოითხოვს, ან საერთოდ მხოლოდ შენთვისაა.
/cart/, /checkout/, /account/, /order/ — e-commerce-ის პირადი გვერდები. კალათა თითოეულ მომხმარებელს თავისი აქვს, პირადი კაბინეტიც. მათი ინდექსირება ნიშნავს დუბლების გამრავლებას და crawl budget-ის ფლანგვას.
/search/ — საიტის შიდა ძიების გვერდები. მომხმარებლის თითოეული საძიებო მოთხოვნა — ეს არის ახალი URL /search?q=... სახით. თუ მათ არ დახურავ, Google იპოვის მილიონ ასეთ URL-ს ბმულების მეშვეობით და შეეცდება ყველას ინდექსირებას. შედეგად — ათასობით thin-content გვერდი, რომელიც მთელ საიტს ქვემოთ ჩათრევს.
/api/ — JSON-endpoint-ები, REST API. ეს არ არის გვერდები, ეს არის მონაცემები. კრაულერმა ისინი არ უნდა დაინახოს როგორც კონტენტი.
?session=, ?utm_source=, ?ref= — URL-ები tracking-პარამეტრებით. ქმნიან ერთი და იმავე გვერდის დუბლებს. საუკეთესო გადაწყვეტა — canonical, მაგრამ თუ canonical-ის დაყენება რთულია, შეგიძლია ნაწილობრივ დახურო robots.txt-ის მეშვეობით. მხოლოდ ფრთხილად: თუ ?utm_* დახურე, დაბლოკავ ნამდვილი კონტენტის მქონე გვერდებსაც ამ URL-ებზე.
/staging/, /preview/, /test/, /dev/ — ცალკე გარემოები. ხშირად ეს ქვედომენებია (staging.site.com), და მაშინ მათ თავიანთი robots.txt აქვთ, და ეს უფრო სწორია. მაგრამ თუ staging ძირითად დომენზე ქვესაქაღალდეშია — დახურე.
ძველი დროებითი landing-ები. დაიწყე სარეკლამო კამპანია, გააკეთე /black-friday-2024/, მან თავისი ფუნქცია შეასრულა — დაბლოკე, სანამ წაშლი.
ფაილები გადაკეცილი კონტენტით. გვერდის PDF-ვერსია, RSS-ფიდი სრული ტექსტებით, print-ვერსიები — თუ ისინი ძირითად კონტენტს იმეორებენ, ინდექსის გარეთ დაიჭირე.
რა არ უნდა დავბლოკოთ
ეს ის ნაწილია, სადაც ხალხი ყველაზე ხშირად ფეხში ისვრის.
CSS და JavaScript. 2014 წლიდან Google გვერდს ბრაუზერივით ახდენს რენდერინგს — ის ტვირთავს HTML-ს, შემდეგ ამატებს CSS-ს და JS-ს, ასრულებს სკრიპტებს და უყურებს საბოლოო შედეგს. თუ დაბლოკავ /wp-content/themes/-ს ან /static/js/-ს — Google იხილავს საიტს სტილების გარეშე და JS-ლოგიკის გარეშე. Mobile-friendly ტესტი ვერ გაივლის. Layout დაიშლება. კონტენტი, რომელიც JS-ის მეშვეობით რენდერდება, ინდექსში არ მოხვდება. არასოდეს დახურო სტატიკა.
/sitemap.xml თავად. მინახავს შემთხვევა, როცა კაცმა დაამატა Disallow: /sitemap.xml, რადგან „არ მინდა, კონკურენტებმა დაინახონ ჩემი სტრუქტურა“. Sitemap — ეს არის ის, რასაც Google სპეციალურად კითხულობს, რომ იცოდეს, რა გაქვს. sitemap-ის დახურვით, თვითონ მოიჭერი ინდექსაცია.
სურათები, თუ გინდა, რომ ისინი Google Images-ში ინდექსირდებოდეს. /images/-ისა და /uploads/-ის დახურვა — გავრცელებული შეცდომაა კონსტრუქტორიდან გადასვლის შემდეგ. სურათებზე ცალკე ტრაფიკი მოდის Google Images-ის გავლით, და დაბლოკვა კლავს ამ არხს.
PDF და უნიკალური კონტენტის მქონე ფაილები. თუ გაქვს PDF-დოკუმენტაცია, ანგარიშები, ტექნიკური whitepapers — ისინი შეიძლება დამოუკიდებლად რანჟირდნენ და ტრაფიკი მოიყვანონ. მათი robots.txt-ში დახურვა — ხილვადობის დაკარგვაა.
გვერდები noindex-ით meta-ში. ეს კონტრინტუიციური რამეა. თუ გინდა გვერდის ინდექსიდან ამოშლა noindex meta-ტეგის მეშვეობით, Google-მა უნდა შევიდეს გვერდზე, წაიკითხოს HTML და დაინახოს ეს ტეგი. თუ დამატებით robots.txt-ში დახურავ — Googlebot იქ არ შევა, noindex-ს ვერ დაინახავს, და გვერდი შეიძლება ინდექსში დარჩეს გარე ბმულების მიხედვით. ლოგიკა საპირისპიროა: noindex-ის მეშვეობით გვერდის წასაშლელად ის robots.txt-ში გახსნილი უნდა იყოს.
JSON-LD და structured data, რომლებიც ცალკე ფაილებში დევს. თუ schema.org მარკაპი /schema/-ში გადატანილია, ეს საქაღალდე ღია დატოვე.
robots.txt vs noindex vs canonical
სამი სხვადასხვა ინსტრუმენტი. მათ ხშირად ურევენ ერთმანეთში, და აქედან იბადება SEO-ში ყველაზე ლამაზი ბაგები.
robots.txt Disallow — ეს არის „არ შეხვიდე“. კრაულერი გვერდზე არ შევა. ეს არ ნიშნავს, რომ გვერდი ინდექსში არ არის: თუ მასზე გარე ბმულები მიდის, Google-მა იცის მისი არსებობის შესახებ და შეუძლია მისი ჩვენება ძიების შედეგებში. მინიშნებით „No information is available for this page“ ან საერთოდ გარე ბმულების anchor-ტექსტიდან მიღებული სათაურით. Disallow ზოგავს crawl budget-ს, მაგრამ deindex-ს არ გარანტიას.
<meta name="robots" content="noindex"> — ეს არის „შედი, წაიკითხე, არ მოახდინო ინდექსირება“. Googlebot შედის გვერდზე, ხედავს meta-ტეგს, და გვერდი გადის ინდექსიდან. ეს არის ერთადერთი საიმედო ხერხი გვერდის ძიების შედეგებიდან ამოსაშლელად. მთავარი პირობა: გვერდი კრაულერისთვის ხელმისაწვდომი უნდა იყოს. თუ ის robots.txt-ში დახურულია, Google ვერ შევა, ვერ დაინახავს noindex-ს, და გვერდი გარე ბმულების მიხედვით კვლავ ეკიდება ძიების შედეგებში.
<link rel="canonical" href="..."> — ეს არის „იმ ვერსიის ინდექსირება მოახდინე ჩემს მაგივრად“. გამოიყენება, როცა გაქვს რამდენიმე URL ერთი და იმავე კონტენტით და გინდა Google-ს უთხრა, რომელი ჩათვალოს ძირითადად. დუბლები პარამეტრების მეშვეობით, ბეჭდვის ვერსიები, AMP-გვერდები — ეს ყველაფერი canonical-ით წყდება, არა robots.txt-ით. იხ. როდის გჭირდება canonical URL.
ტიპიური ამოცანების ბმული:
— გინდა გვერდის სამუდამოდ ამოშლა ინდექსიდან: გახსენი ის robots.txt-ში + დააყენე noindex meta + დაელოდე ორ-ოთხ კვირას, სანამ Google ხელახლა დაასკანერებს და გადააგდებს.
— გინდა crawl budget-ის დაზოგვა არასაჭირო გვერდებზე: დახურე robots.txt-ში. ისინი შეიძლება ინდექსში დარჩნენ, მაგრამ Google შეწყვეტს მათ შემოწმებას.
— გინდა დუბლების შეერთება: canonical. არა robots.txt.
— გინდა გვერდის სრულად წაშლა: 410 Gone HTTP-სტატუსში + sitemap-იდან ამოშლა. robots.txt აქ მხოლოდ ხელს უშლის.
ყველაზე გავრცელებული შეცდომა: „საიმედოობისთვის გვერდი robots.txt-ში დავხურე და noindex-იც დავაყენე“. ეს არ არის „საიმედოობისთვის“, ეს არის კონფლიქტი. Google ვერ შეძლებს noindex-ის წაკითხვას და გვერდი ინდექსში გაიჭედება.
როგორ შევამოწმოთ
ყველაზე მარტივი — გახსენი ბრაუზერში ან curl-ით:
curl https://site.com/robots.txt
მაშინვე ჩანს, რას აბრუნებს სერვერი. თუ 404 — robots.txt არ გაქვს, რაც თავისთავად კატასტროფა არ არის, მაგრამ უმჯობესია მისი შექმნა.
Google Search Console-ში არსებობს robots.txt Tester (ის გადავიდა, ახლა Settings → Crawling-ის ნაწილშია). იქ შეგიძლია URL ჩასვა და იკითხო: არის თუ არა ის დაშვებული Googlebot-ისთვის. სასარგებლოა, როცა წესები wildcard-ებით რთულია.
URL Inspection tool GSC-ში კონკრეტული URL-ის მიხედვით აჩვენებს, არის თუ არა ის დაბლოკილი და რომელი წესით. იდეალური დიაგნოსტიკისთვის „რატომ არ ხდება ამ გვერდის ინდექსირება“.
screaming-frog ან ანალოგები საიტის კრაულის დროს მაშინვე გამოყოფს, რა არის დაბლოკილი robots.txt-ში. თუ დეპლოის წინ ატარებ Frog-ს — დაინახავ პრობლემას მანამდე, სანამ ის პროდაქშენში მოხვდება.
robots.txt-ის თითოეული ცვლილების შემდეგ აუცილებლად ხელით ხელახლა შეამოწმე საკვანძო გვერდების URL-ები. და GSC-ის გავლით გააგზავნე განახლებული robots.txt — Google მაშინვე არ წაიკითხავს მას, ჩვეულებრივ დღე-ღამეში.
შეჯამება
robots.txt — ხუთი ხაზი ტექსტი, რომელიც შეიძლება დაგიჯდეს მთელი წლის ორგანული ტრაფიკი. ეს არ არის ექსპერიმენტების ადგილი და არც ადგილი „გავაკეთო როგორც მეზობელმა“-სთვის.
ბაზისური წესი: დახურე მხოლოდ ის, რაც ნამდვილად არ უნდა იყოს ინდექსში. არა პარანოიდან, არც „ყოველი შემთხვევისთვის“. თითოეულ დირექტივას უნდა ჰქონდეს მიზეზი, და ეს მიზეზი კომენტარში უნდა იყოს ჩაწერილი.
თითოეული დეპლოის წინ — გახსენი robots.txt და თვალით წაიკითხე. ეს ხუთი ხაზია. ეს იღებს ათ წამს. ეს გადაგარჩენს თვეების მანძილზე პოზიციების აღდგენისგან.
და გახსოვდეს: robots.txt ბლოკავს შემოვლას, არა ინდექსაციას. ინდექსაციისთვის არსებობს noindex. დუბლებისთვის — canonical. ნუ აურევ ინსტრუმენტებს. იხ. ასევე SEO-ის 30+ ფაქტორი და hreflang: subdomain vs subdirectory — იქაც ბევრი ადგილია, სადაც ერთი ხაზით შეიძლება ნახევარი წლის სამუშაოს დაკარგვა.