Google-ის განმარტება Search Console-ში არსებულ „მოჩვენებით“ noindex შეცდომებზე

Google-ის წარმომადგენელმა, ჯონ მიულერმა, Search Console-ში დაფიქსირებულ „მოჩვენებით“ noindex შეცდომებთან დაკავშირებით მნიშვნელოვანი განმარტება გააკეთა. მისი თქმით, ინდექსირების ბლოკირება, რომელსაც Google ხედავს, ხშირად რეალურია, მიუხედავად იმისა, რომ საიტის მფლობელებისთვის ის შეიძლება შეუმჩნეველი დარჩეს.

Search Console-ის ანგარიშებში ხშირად გვხვდება შეტყობინება, რომ გვერდის ინდექსირება ვერ მოხერხდა noindex დირექტივის გამო, მაშინაც კი, როდესაც HTML კოდში მსგავსი არაფერი ფიქსირდება. ეს სიტუაცია დამაბნეველია როგორც გამომცემლებისთვის, ისე SEO სპეციალისტებისთვის, რადგან კოდის დონეზე პრობლემა არ ჩანს.

როდესაც Google Search Console (GSC) აჩვენებს შეტყობინებას „Submitted URL marked ‘noindex’“, ეს მიუთითებს ურთიერთგამომრიცხავ სიტუაციაზე:

• საიტმა სთხოვა Google-ს გვერდის ინდექსირება Sitemap-ის საშუალებით.
• გვერდმა გაუგზავნა Google-ს სიგნალი (noindex დირექტივა), რომ არ მოხდეს მისი ინდექსირება.

Noindex, რომელიც მხოლოდ Google-ისთვის ჩანს

ჯონ მიულერმა Bluesky-ზე დასმულ კითხვას უპასუხა, სადაც მომხმარებელი ჩიოდა, რომ 4 თვის განმავლობაში Search Console-დან არ ქრებოდა noindex შეცდომა, მიუხედავად იმისა, რომ საიტზე ან robots.txt ფაილში მსგავსი დირექტივა არ არსებობდა. მიულერმა აღნიშნა, რომ მის მიერ შესწავლილ შემთხვევებში noindex ყოველთვის არსებობდა, თუმცა ის ხშირად მხოლოდ Google-ისთვის იყო ხილული.

„შემთხვევები, რომლებიც წარსულში მინახავს, აჩვენებდა, რომ noindex რეალურად არსებობდა, თუმცა ზოგჯერ ის მხოლოდ Google-ს მიეწოდებოდა (რისი დიაგნოსტიკაც საკმაოდ რთულია)“, — განაცხადა მიულერმა.

როგორ აღმოვაჩინოთ და გამოვასწოროთ „მოჩვენებითი“ noindex შეცდომები

შესაძლოა, სერვერის კოდში არსებობდეს ჩანაწერი, რომელიც noindex-ს მხოლოდ Google-ისთვის აჩვენებს. მაგალითად, თუ გვერდს წარსულში ჰქონდა noindex დირექტივა, სერვერის ქეშირებამ (მაგალითად, ქეშირების პლაგინმა) ან CDN-მა (მაგალითად, Cloudflare) შესაძლოა შეინახა იმ დროინდელი HTTP Header-ები. შედეგად, Googlebot-ს (რომელიც ხშირად სტუმრობს საიტს) მიეწოდება ძველი noindex ჰედერი, ხოლო საიტის მფლობელი ხედავს გვერდის ახალ ვერსიას.

HTTP Header-ების შემოწმება მარტივია ისეთი ხელსაწყოებით, როგორიცაა KeyCDN ან SecurityHeaders.com. მნიშვნელოვანია ყურადღება მიექცეს 520 სერვერის პასუხის კოდს, რომელსაც Cloudflare აგზავნის მომხმარებლის აგენტის (User Agent) ბლოკირებისას.

Rich Results Test-ის გამოყენება დიაგნოსტიკისთვის

იმ სიტუაციაში, როდესაც ვებგვერდი Google-ს აწვდის ინფორმაციას, რომელიც კოდში არ ჩანს, საჭიროა გვერდის ნახვა უშუალოდ Google-ის მცოცავის (crawler) პოზიციიდან. ამისათვის საუკეთესო გზაა URL-ის შემოწმება Google-ის Rich Results Test ხელსაწყოში. ეს მეთოდი ეფექტურია რამდენიმე მიზეზის გამო:

• მოთხოვნა მოდის Google-ის მონაცემთა ცენტრებიდან: ბოტი იყენებს Google-ის რეალურ IP მისამართს.
• გადის Reverse DNS შემოწმებას: თუ სერვერი ან უსაფრთხოების პლაგინი ამოწმებს IP-ს, ის დაადასტურებს, რომ ეს ნამდვილად googlebot.com-ია.

თუ გვერდი დაბლოკილია noindex-ით, ხელსაწყო ვერ აჩვენებს სტრუქტურირებული მონაცემების შედეგებს და გამოიტანს სტატუსს „Page not eligible“ ან „Crawl failed“. ასეთ შემთხვევაში, დეტალების ნახვისას (View Details) გამოჩნდება შეტყობინება: „Robots meta tag: noindex“ ან „‘noindex’ detected in ‘robots’ meta tag“.

ეს მიდგომა იყენებს Google-InspectionTool/1.0 მომხმარებლის აგენტს. თუ სერვერი ბლოკავს IP მისამართს, ეს მეთოდი ამას აუცილებლად დააფიქსირებს.

User Agent-ის შეცვლა და სკანირება

კიდევ ერთი გზაა Googlebot-ის მომხმარებლის აგენტის სიმულაცია (spoofing). ამისათვის შესაძლებელია Chrome-ის გაფართოების, User Agent Switcher-ის გამოყენება, ან ისეთი აპლიკაციის კონფიგურაცია, როგორიცაა Screaming Frog, სადაც იდენტიფიკატორად მიეთითება Googlebot. ეს დაგეხმარებათ იმის გარკვევაში, არის თუ არა noindex ტეგი სპეციალურად Google-ის ბოტისთვის გამიზნული.

Search Console-ში მსგავსი შეცდომების დიაგნოსტიკა შეიძლება რთული ჩანდეს, თუმცა ზემოთ ჩამოთვლილი ნაბიჯების თანმიმდევრული შესრულება დაგეხმარებათ იმ ფარული მიზეზების პოვნაში, რომლებიც ხელს უშლის თქვენი გვერდების ინდექსირებას.