Jak renderować stronę www?

Renderowanie przez bota wyszukiwarki brzmi nieco niczym skrzyżowanie tytułu science fiction z zaawansowanym procesem technologicznym w parku maszynowym. Tymczasem dla SEO renderowanie strony internetowej to fundament – technologia, bez której trudno myśleć o kluczowym celu, jakim są wysokie pozycje słów kluczowych.

Proces renderowania można bowiem sprowadzić do sytuacji, w której bot Google dokonuje kilku kroków kluczowych dla końcowego postrzegania serwisu internetowego. Pierwszy to pobranie strony, kolejny – uruchomienie kodu. Następnie – na jego podstawie – dokonuje własnej analizy układu strony i całej struktury witryny. Komplet informacji pobieranych do swoistej oceny zbierany jest przez tę – zwykle nie odczuwalną chwilę – jaka towarzyszy renderowaniu strony. W efekcie jakościowy content, skuteczny linkbuilding czy drobiazgowo dopilnowane Google Search Console stają się drugoplanowymi czynnikami jeśli renderowanie strony www generuje błędy, opóźnienia, odejścia od norm przyjętych przez magów z Alphabet Inc.

Można bowiem – z technicznego punktu widzenia – przyjąć, że każda witryna internetowa to dwie twarze HTML: przed renderingiem i już po wyrenderowaniu zasobów. Pierwszy to wygenerowany zestaw podstawowych informacji – od treści przez obrazy po kody JS i CSS. Drugie oblicze stanowi ten sam podstawowy kod, ale wzbogacony już o zmiany, które wywołał HTML. I w tej wąskiej przestrzeni między dwoma trybami kryje się jedna z dróg do skuteczności SEO. To, jak założone pierwotnie komendy realizowane są już w przeglądarce użytkownika stanowi jeden z fundamentów prawidłowego działania.

Jak wygląda to w praktyce? Uruchomienie strony internetowej w przeglądarce sprawia, że serwer wysyła określone dane na komputer lub inne urządzenie. Dane zebrane w formacie HTML – jak i np. XML – analizowane są przez system pod kątem uzyskania zaplanowanego efektu graficznego. To, co zostaje zaprezentowane na ekranie użytkownika to efekt renderowania – niezależnie od tego jaki jest jego typ. A rodzajów technologia zapewnia sporo: od ciągłego po progresywne.

Dlaczego renderowanie jest tak istotne?

Powód jest prosty, prozaiczny i bezwzględny: serwis, którego zrenderować nie można, nie podlega indeksacji przez Google. Nie istnieje. Jest gdzieś w cyberprzestrzeni, ale bez większego znaczenia i bez szans na to, by pokazać się światu. Indeksacja to renderowanie, renderowanie to indeksacja – w tym przypadku Google nie pozostawia furtki i okoliczności łagodzących.

Stąd tak istotne jest sprawdzenie zarówno strony głównej jak i pozostałych witryn wewnętrznych pod kątem tego, czy np. serwis zawiera zasoby, które są zablokowane lub w inny sposób nie zostały udostępnione dla botów Google. To zarówno CSS jak i pliki JS czy obrazy.

W jaki sposób skutecznie zrenderować stronę internetową?

Google rządzi się swoimi prawami, boty spacerują własnymi ścieżkami, a wszystko to skryte jest w gąszczu kodu, do którego zwykli śmiertelnicy spoza Doliny Krzemowej mają dostęp co najwyżej ograniczony. Jak w takim razie zweryfikować, czy strona internetowa spełnia wymagania bezlitosnej w tym kontekście wyszukiwarki?

Podstawową opcją długo był test dla urządzeń mobilnych. Wbrew temu co mogłoby się wydawać, nie musi być używane wyłącznie do smartfonów czy tabletów. Sprawdzenie działania, jak bot Google pobiera i renderuje stronę mobilną daje odpowiedź również na to, jaki jest jej jakość renderowania. W sytuacji, gdy strona jest responsywna, problemy – i zły wynik – renderowania mobilnego oznacza również nieprawidłowe dostosowanie do komputerów.

W połowie roku 2019 Google ogłosił, że bot będzie regularnie aktualizować silnik renderowania – wyznacznikiem stała się więc Chrome 41 i jej funkcja wykrywania funkcji, wypełniania i błędów dziennika. Zablokowanych zasobów nie widać – ostatecznie przeglądarka i tak je wyrenderuje – ale i tak można tę drogę uznać za szczególnie cenną.

Nie wymaga dużego zaangażowania: wystarcza pobranie i instalacja Chrome 41. Wcześniej warto odinstalować czasowo inne – nowsze – wersje oraz wykonać kopię zapasową zakładek i plików. Dysponując już Chrome 41 wystarcza wprowadzenie dowolnego adresu URL, a następnie – w typowy sposób – zbadanie strony po przyciśnięciu prawego klawisza myszy. W ten sposób otwarte będą narzędzia dla programistów. W zakładce konsoli można zobaczyć wykryte błędy – wystarczy skopiowanie danych do programistów, by uruchomić proces naprawy mankamentów.

Skomplikowane? Alternatywą – jakże banalną! – jest wtyczka do renderowania. View Rendered Source to doskonałe rozwiązanie, które urzeka prostotą działania.

Link do wtyczki: https://chrome.google.com/webstore/detail/view-rendered-source/ejgngohbdedoabanmclafpkoogegdpob

Jako rozszerzenie dodawane do Chrome pokazuje, jak przeglądarka zbudowała – a więc wyrenderowała – oryginalny HTML do DOM włączając w to wszystkie modyfikacje realizowane przez Javascript. Jeśli więc programista używa ram JS – Angular, React JS, Vue.js – pozwala zrozumieć, jak wyszukiwarki widzą stronę. Przejrzyście zaprezentować tego się nie da: różnice pomiędzy wersją “surową” a już wyrenderowaną są zaznaczane podświetlaną linią.

Programy do sprawdzenia renderowania www

Gdyby jednak sięgnąć głębiej – nie po narzędzia Google, a inne rozwiązania wdrażane już w branży SEO? I tu nie brak rozwiązań, które odpowiedzą, jak boty postrzegają serwis od strony technicznej.

Screaming Frog SEO Spider

Jedno z naturalnych narzędzi do SEO – po aktualizacji oprogramowania – zapewnia ciekawą funkcję idealną pod kątem renderowania kątowego. W panelu konfiguracyjnym znajduje się zakładka “Rendering”, w której z kolei można zmienić opcję domyślną – schemat indeksowania AJAX – na JavaScript.

Configuration -> Spider -> Rendering

W kolejnym etapie, po włączeniu zrzutów ekranu renderowania strony wystarcza wybrać opcję między botem Google a komputerami stacjonarnymi. Następnie, przechodząc do konfiguracji należy upewnić się, że obrazy, linki, JS i CSS są zaznaczone. W ten sposób Screaming Frog uruchomi renderowanie zasobów – należy pamiętać, że jeśli analizowana strona jest pusta lub brakuje w niej niektórych elementów, margines czasowy na reakcję powinien być poszerzony ze standardowych 5 do 7-10 sekund.

Wynik renderowania strony można obejrzeć w „żabie”:

Iframe

Inny sposób to użycie iFrame do renderingu. Wystarczy do tego możliwość dostępu do jej FTP – np. poprzez Google Search Console. Dodając plik PHP z github wystarczy zmienić adres url w jego 11 wierszu. To przykładowy Example.com – tu należy wstawić własną domenę. Następnie należy otworzyć folder na własnym FTP i przesłać na niego wspomniany plik PHP.

Można również iść w innym kierunku: pobrania i zrenderowania strony w środowisku testowym. Ponieważ Google używa – jak się spekuluje, nie zostało to potwierdzone – adresu IP rozpoczynającego się od 66, wystarcza dodać go do białej listy. W sytuacji, gdy witryna jest hostingowana z serwerem Apache, należy uzupełnić plik HTACCESS o następujący wiersz:

• ErrorDocument 403 /error.php
• Order Allow,Deny
• Allow from 66.

W ten sposób można pobrać i wyrenderować witrynę. Warunkiem jest jednak brak uwierzytelnienia. Jeśli jest inaczej, bot Google nie będzie miał dostępu do zasobów. Po ukończeniu wszystkich prac należy usunąć wspomnianą linię z HTACCESS.

Link: https://www.screamingfrog.co.uk/how-to-fetch-render-any-site/

Technical SEO

Dobrą alternatywą do rozgrzebywania kodu (iframe) oraz płatnych narzędzi (screaming frog) jest wykorzystanie darmowego narzędzia znajdującego się pod adresem: https://technicalseo.com/tools/fetch-render/

Podobnie jak w „żabie” mamy do wyboru szereg opcji, dzięki którym możemy zweryfikować jak nasz serwis jest widziany przez Google:

Test wersji mobilnej w Google

Google posiada narzędzie (darmowe), dzięki któremu możemy sprawdzić, jak nasza strona jest widziana przez jego roboty: https://search.google.com/test/mobile-friendly?url=https%3A%2F%2Fwww.zgred.pl%2F

Na ekranie oznaczyłem informację, w której Google pokazuje problemy z wczytywaniem strony. Pomimo tego, że badana podstrona poprawnie wygląda w testerze warto tam zajrzeć i przejrzeć problematyczne zasoby.

Warto przejrzeć to z czym Googlebot ma problemy przy renderowaniu i wczytywaniu serwisu – możliwe, że jakieś pojedyncze pliki zostały zablokowane a warto je jednak odblokować. Należy przy tym pamiętać, że nie wszystkie pliki Googlebot pobierze, jak również mogą nastąpić jakieś przekłamania w transmisji danych i w trakcie testu Googlebot nie mógł pobrać wszystkiego. Dlatego warto ten test powtórzyć 2-3 razy z rzędu.

Dlaczego warto weryfikować wygląd serwisu?

• pod kątem Mobile First Index
• ze względu na blokowane zasoby, które mogą utrudniać rankowanie
• weryfikacja wielkości zdjęć, które mogą przesłaniać tekst
• prosty test czy firewall działa poprawnie 🙂
• analiza crawl budżet
• Google Search Console nie pokazuje wszystkiego (niestety)

Artykuł powstał na podstawie https://www.tldrseo.com/fetch-and-render-alternatives/ i za zgodą jego autora.