Google განმარტავს, თუ რატომ უგულებელყოფს მისი საძიებო რობოტი Resource Hint-ებს

Google-ის წარმომადგენლებმა, გარი ილიეშმა და მარტინ სპლიტმა, პოდკასტის „Search Off the Record“ ერთ-ერთ ეპიზოდში დეტალურად განიხილეს, თუ როგორ ამუშავებს Google-ის საძიებო რობოტი (Googlebot) HTML კოდს. საუბრისას გამოიკვეთა მნიშვნელოვანი განსხვავებები იმას შორის, თუ როგორ აღიქვამენ ერთსა და იმავე გვერდს ბრაუზერები და Googlebot-ი.

დისკუსია შეეხო ისეთ საკითხებს, როგორიცაა რესურსების მინიშნებები (resource hints), მეტამონაცემების განთავსება და HTML ვალიდაცია. ილიეშის განმარტებებმა ეჭვქვეშ დააყენა მრავალი გავრცელებული მოსაზრება იმის შესახებ, თუ რომელი ტექნიკური ცვლილებები ეხმარება საიტს ძიების შედეგებში დაწინაურებაში.

მთავარი მიგნებები აჩვენებს, რომ ისეთი ელემენტები, როგორიცაა prefetch, preload და preconnect, სრულიად უმნიშვნელოა Google-ის სკანირების ინფრასტრუქტურისთვის. გარდა ამისა, ხაზგასმით აღინიშნა, რომ HTML კოდის ვალიდურობა არ წარმოადგენს რანჟირების სიგნალს.

რატომ არ ეხმარება Resource Hint-ები Googlebot-ს

ბრაუზერის წარმადობის გასაუმჯობესებელი ფუნქციები, როგორიცაა dns-prefetch, preload, prefetch და preconnect, წყვეტს დაყოვნების (latency) პრობლემებს, რომლებიც Google-ის ინფრასტრუქტურას უბრალოდ არ გააჩნია. ილიეშის თქმით, Google-ის DNS რეზოლუციას არ სჭირდება ის დახმარება, რომლის გაწევასაც საიტების უმეტესობა ცდილობს.

„მაგალითად, DNS Prefetching ძალიან სასარგებლოა, თუ სუსტი ინტერნეტ კავშირი გაქვთ. ჩვენს შემთხვევაში ეს საჭირო არ არის, რადგან შეგვიძლია ძალიან სწრაფად დავუკავშირდეთ ყველა კასკადურ DNS სერვერს“, — აღნიშნა ილიეშმა.

მან ასევე დაამატა, რომ Google გვერდის რესურსებს ცალკე ინახავს ქეშში და მათ რეალურ დროში არ ტვირთავს ისე, როგორც ამას ბრაუზერი აკეთებს. Google ამას აკეთებს იმისთვის, რომ შეამციროს გამტარუნარიანობა და სერვერის დატვირთვა იმ საიტებზე, რომლებსაც ის სკანირებს. „იგივე ეხება preload-ს. თუ ჩვენ არ ვმუშაობთ სინქრონულად, მაშინ განსაკუთრებით არ გვჭირდება preload-ის გათვალისწინება“.

Google იყენებს Speculation Rules API-ს Chrome-ის მომხმარებლებისთვის ძიების შედეგებზე დაწკაპუნების დასაჩქარებლად. ეს სისტემა მუშაობს, რადგან ის ფუნქციონირებს ბრაუზერის დონეზე, სადაც მომხმარებელსა და სერვერს შორის დაყოვნებას მნიშვნელობა აქვს. Googlebot კი მუშაობს Google-ის საკუთარი ინფრასტრუქტურის შიგნით, სადაც მსგავსი შეფერხებები არ არსებობს.

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

მეტამონაცემების ადგილი Head სექციაშია

მარტინ სპლიტმა გააზიარა შემთხვევა, როდესაც Head სექციაში განთავსებულმა სკრიპტმა ჩატვირთა iframe, რამაც ბრაუზერს ნაადრევად დაახურინა Head სექცია. ამის გამო hreflang ტეგები Body სექციაში აღმოჩნდა, სადაც Google-ის სისტემებმა ისინი უბრალოდ დააიგნორეს.

ილიეშმა განმარტა, თუ რატომ არის Google ამ საკითხში მკაცრი. HTML სტანდარტის მიხედვით, meta name="robots" ტეგი მხოლოდ Head-ში შეიძლება გამოჩნდეს. იგივე ეხება rel=canonical ელემენტებს.

„მე ვიტყოდი, რომ საკმაოდ სახიფათოა Body-ში ისეთი ბმულების ქონა, რომლებსაც მეტამონაცემები გადააქვთ“, — განაცხადა ილიეშმა.

მისი ლოგიკით, Google-ს Body-ში არსებული კანონიკური ტეგები რომ მიეღო, შესაძლებელი გახდებოდა გვერდის კანონიკური მისამართის „მოტაცება“ და მისი ძიების შედეგებიდან ამოშლა უბრალო მარკაპის ინექციით. ილიეშმა მანამდეც გასცა რეკომენდაცია HTML პარსინგისა და rel-canonical-ის იმპლემენტაციის შესახებ, სადაც ურჩევდა სრული URL მისამართის მითითებას პარსერის მხრიდან გაურკვევლობის თავიდან ასაცილებლად.

HTML ვალიდურობა არ ნიშნავს უპირატესობას რანჟირებაში

ილიეშმა პირდაპირ განაცხადა, რომ ვალიდური HTML არ შეიძლება იყოს რანჟირების სიგნალი. ვალიდურობა ბინარული ცნებაა — კოდი ან ვალიდურია, ან არა, და მათ შორის შუალედი არ არსებობს. მისი თქმით, რთულია რაიმე მნიშვნელოვანის გაკეთება „გაიარა/ვერ გაიარა“ მეტრიკით.

მან მოიყვანა მაგალითი, რომ გამოტოვებული დამხურავი <span> ტეგი გვერდის HTML-ს ტექნიკურად არავალიდურს ხდის, მაგრამ მომხმარებლისთვის ეს არაფერს ცვლის. სპლიტი დაეთანხმა ამ აზრს და აღნიშნა, რომ სემანტიკური მარკაპი, როგორიცაა სათაურების სწორი იერარქია და HTML5 სტრუქტურული ელემენტები, ასევე არ ატარებს გადამწყვეტ წონას საძიებო სისტემებისთვის, თუმცა ისინი სასარგებლოა ხელმისაწვდომობისა (accessibility) და მომხმარებლის გამოცდილებისთვის.

რატომ არის ეს მნიშვნელოვანი

ტექნიკურმა აუდიტმა შესაძლოა გამოავლინოს Resource Hint-ების გამოყენების შესაძლებლობები ან HTML ვალიდაციის შეცდომები. იმის ცოდნა, თუ რომელი მათგანი ახდენს გავლენას Google-ის რობოტზე და რომელი — ბრაუზერზე, დაგეხმარებათ პრიორიტეტების სწორად განსაზღვრაში.

როდესაც hreflang ტეგები, კანონიკური ბმულები ან meta robots დირექტივები არ მუშაობს ისე, როგორც მოსალოდნელია, პირველ რიგში უნდა შემოწმდეს, ხომ არ ხვდება ისინი Body სექციაში ბრაუზერის მიერ გვერდის დამუშავების შემდეგ. ტეგი, რომელიც საწყის HTML კოდში სწორად ჩანს, შესაძლოა არასწორ ადგილას აღმოჩნდეს, თუ სკრიპტი ან iframe გამოიწვევს Head სექციის ნაადრევ დახურვას.

აღსანიშნავია, რომ Google-ის განახლებული რეკომენდაციები სკანირების ქეშირების შესახებ გვირჩევს ETag ჰედერების გამოყენებას არასაჭირო სკანირების შესამცირებლად, რაც სრულ თანხვედრაშია ილიეშის მიერ მოწოდებულ ინფორმაციასთან.

მომავლის გეგმები

მარტინ სპლიტმა აღნიშნა, რომ თავდაპირველად მას Client Hints-ის თემის დაფარვა სურდა და HTML პარსინგზე მსჯელობა მხოლოდ საფუძველი იყო მომავალი ეპიზოდისთვის. თუ ეს ეპიზოდი შედგება, ის სავარაუდოდ შეეხება იმას, თუ როგორ ამუშავებს Googlebot ახალ Accept-CH და Sec-CH-UA ჰედერებს, რომლებიც ტრადიციულ User Agent სტრიქონებს ანაცვლებს.