JavaScript jest istotną częścią wielu nowoczesnych stron internetowych, w zasadzie jest to obecnie najpopularniejszy język programowania. Jeśli chodzi jednak o SEO, JavaScript stanowić może pewne wyzwane. Przy niewłaściwej implementacji, JS może utrudnić wyszukiwarkom crawlowanie i indeksowanie witryny, co z kolei może negatywnie wpłynąć na jej pozycje w SERPach.
W dzisiejszym artykule przeprowadzimy Was krok po kroku przez proces audytu JS pod kątem SEO. Mamy nadzieję, że dowiecie się wszystkiego, czego potrzebujecie! Zapraszamy do czytania!
TL;DR
Zanim przytłoczy Was długość artykułu… Mamy dla Was coś specjalnego! Oto szablon, który podsumowuje wszystko, co zawarte w tym poście:
Pobierz szablon audytu JS dla SEO
JavaScript a SEO
JavaScript może wpływać na witrynę na jeden z następujących sposobów:
- Może w znaczący sposób spowolnić działanie Twojej witryny (core web vitals/wskaźniki prędkości ładowania się strony);
- Może uniemożliwić Google odkrywanie i crawlowanie adresów URL;
- Może uniemożliwić Google zobaczenie treści na Twojej witrynie (content i obrazy).
- Inne wyszukiwarki są mniej wydajne w renderowaniu JavaScript niż Google.
Badanie przeprowadzone przez Onely.com wskazało, że Google potrzebuje 9x więcej czasu na crawl stron opartych na JS w porównaniu do zwykłych stron HTML.
Także John Muller z Google w swoim tweecie z 2018 roku wspomina, że JavaScript może spowolnić indeksowanie witryny.
Podsumowując zatem, wykorzystanie JavaScriptu może mieć poważny wpływ na indeksowanie witryny i jej wydajność.
Narzędzia do przeprowadzenia audytu JavaScript dla SEO
Zacznijmy od listy narzędzi, które pomogą Ci kontrolować problemy z JS na Twojej witrynie:
- Google Search Console URL Inspection Tool: po sprawdzeniu danego adresu URL możesz kliknąć „Wyświetl przetestowaną stronę” lub „Test wersji opublikowanej ” i zobaczyć, jak Google renderuje stronę. Możesz także skorzystać z narzędzi Rich Results Test lub Mobile-Friendly Test.
- Rozszerzenie Chrome Web Developer: po zainstalowaniu rozszerzenia, przejdź do strony internetowej, którą chcesz przetestować, kliknij ikonkę rozszerzenia, a następnie “Disable JS”, po czym odśwież stronę i zobacz, jak prezentuje się ona bez JS. Jeśli brakuje treści, masz problemy z JS na swojej witrynie.
- Rozszerzenie Chrome View Rendered Source: narzędzie pokazuje surowy HTML, kod po renderowaniu JS i różnicę pomiędzy nimi.
- Screaming Frog: jeśli masz do czynienia z witryną z dużą liczbą adresów URL, możesz rozważyć wersję narzędzia w chmurze zamiast klasycznej wersji desktop. W obu przypadkach możesz porównać surowy i renderowany kod HTML i sprawdzić różnice. Potrzebna będzie płatna wersjia tego narzędzia. Przejdź do Configuration → Spider → Crawl i upewnij się, że element JavaScript jest zaznaczony:
Następnie przejdź do zakładki Rendering, wybierz JavaScript i upewnij się, że poszczególne elementy są ustawione w następujący sposób:
Teraz wykonaj crawl witryny. Screaming Froga możesz także wykorzystać do namierzenia blokowanych zasobów (więcej szczegółów na ten temat poniżej).
Jak przeprowadzić audyt SEO dla stron wykorzystujących JavaScript?
Kiedy przeprowadzamy audyt techniczny lub też audyt po migracji/przeprojektowaniu witryny, aby sprawdzić, czy JavaScript nie wpływa negatywnie na SEO, niezbędnych jest kilka kroków. Pozwólcie, że Was przez nie przeprowadzimy.
Wyłącz JavaScript
To najprostszy sposób, aby zobaczyć, co dzieje się na stronie. Istnieją różne opcje, aby to zrobić. My rekomendujemy skorzystanie z rozszerzenia Chrome Web Developer. Wystarczy zainstalować rozszerzenie, wybrać jego ikonkę na pasku Chrome, a następnie kliknąć “Disable JavaScript” i odświeżyć stronę.
Kiedy już to zrobisz, spójrz na stronę. Czasami sytuacja będzie oczywista – ujrzysz pustą stronę. Czasem natomiast trzeba będzie sprawdzić poszczególne elementy, takie jak:
- Czy linki wewnętrzne oraz linki w menu górnym i stopce działają poprawnie?
- Czy treść na stronie jest widoczna? Sprawdź zawartość body oraz accordion Dobrym sposobem na wdrożenie modułów akordeonowych jest umożliwienie widoczności całego tekstu na stronie, jeśli JS jest wyłączony. Oto przykład z tej strony.
Moduł akordeonowy z włączonym JS – należy kliknąć, aby zobaczyć tekst:
Moduł akordeonowy z wyłączonym JS. Tekst staje się automatycznie widoczny w całości na stronie, co oznacza, że Google może go zobaczyć bez konieczności przetwarzania JS (idealna sytuacja!):
Jak wyjaśnić ten problem deweloperowi?
Chcemy mieć pewność, że cała zawartość strony jest bezpośrednio dostępna w surowym kodzie HTML. Jeśli linki wewnętrzne lub w nawigacji nie są widoczne z wyłączonym JS, oznacza to, że Google nie będzie w stanie ich zobaczyć i zaindeksować. Podobnie będzie z treścią.
Chcemy również upewnić się, że wszystkie linki wewnętrzne są tworzone przy użyciu atrybutu ahref, zgodnie z zaleceniami Google. Przykład:
<a href= “link”>tekst kotwicy</a>
Uważaj na Lazy Loading obrazów
Lazy loading to bardzo popularna technika, w której zawartość zidentyfikowana jako mniej istotna nie jest ładowana, dopóki nie jest potrzebna. Ma to powszechne zastosowanie w przypadku obrazów, między innymi w celu skrócenia rzeczywistego i postrzeganego czasu ładowania.
Uwaga: Lazy load należy ustawiać jedynie dla obrazów znajdujących się poniżej “pierwszego ekranu”. W innym wypadku może mieć to negatywny wpływ na wskaźniki Core Web Vital.
Niektóre popularne biblioteki oparte na Lazy Loading JS używają atrybutu „data-src” zamiast atrybutu „src” dla źródła obrazu w HTML. Nie wchodząc w szczegóły na ten temat, po prostu otwórz kod źródłowy strony i poszukaj atrybutów „data-src”. Jeśli je znajdziesz, oznacza to, że Twoje obrazy mogą nie zostać zindeksowane przez Google.
Atrybuty obrazu powinny wyglądać mniej więcej tak:
<img src=”przyklad.pl/seo.jpg” alt=”SEO” style=”width:100%”>
Mogą również korzystać z leniwego ładowania w następujący sposób:
<img src=”przyklad.pl/seo.jpg” alt=”SEO” style=”width:100%” loading=”lazy”>
Jak wyjaśnić ten problem deweloperowi?
Chcemy mieć pewność, że wszystkie obrazy w witrynie są indeksowane, ponieważ mogą one generować wartościowy ruch z wyszukiwarki grafik. Bez atrybutu „src” Google może nie mieć do tych obrazów dostępu. Dlatego zalecamy wykorzystywanie Native Lazy Loading.
Nie traktuj przycisków jako linków wewnętrznych
Pamiętaj: Google nie może klikać przycisków. Google nie wchodzi w interakcje ze stroną w taki sam sposób, w jaki robią to użytkownicy. Tak więc, analizując wewnętrzne linkowanie swojej strony, nie uznawaj przycisków jako linków wewnętrznych.
Infinite scroll, czyli nieskończone przewijanie
Infinite scroll to funkcja używana do dynamicznego ładowania większej ilości treści dopiero w momencie, gdy użytkownik przewinie stronę do końca. Stosuje się ją powszechnie na stronach kategorii e-commerce lub blogów.
Jeśli Twoja witryna korzysta z Infinite Scroll, musisz mieć na uwadze, że, jak już wspomnieliśmy, Google nie zachowuje się tak samo jak użytkownicy i nie przechodzi do kolejnych treści ładując zawartość strony. Używanie nieskończonego przewijania może zatem powodować problemy z indeksacją, gdyż część adresów URL nie zostanie w ogóle przez Google odkrytych.
Aby sprawdzić, co Google może zobaczyć na stronie, możesz użyć narzędzia Rich Result Test.
Kliknij „Zrzut ekranu”, aby sprawdzić, co Google może zobaczyć na stronie, a czego nie. Jak poradzić sobie z ograniczeniami infinite scrolla? Jedną z opcji jest wykorzystanie paginated infinite scroll.
Jak wyjaśnić ten problem deweloperowi?
Naszym celem jest upewnienie się, że gdy użytkownicy przewijają stronę i zaczyna ładować się jej nowa zawartość, adres URL strony również zostaje zaktualizowany (na przykład w formie ?page=2). Dzięki temu rozwiązaniu Google uzyska dostęp do wszystkich stron w naszej witrynie i będzie mogło je zaindeksować. Wszystkie niezbędne informacje potrzebne programiście na temat paginated infinite scroll można znaleźć tutaj.
Pamiętaj zatem: Google nie wchodzi w interakcje z Twoimi treściami, nie klika przycisków i nie przewija treści!
# w adresach URL
Używanie adresów URL z # jest jak najbardziej w porządku, jeśli stosujemy je na przykład w spisie treści, jako kotwice do poszczególnych części tekstu, które zostały już załadowane na stronie. Adresy te mogą pojawiać się w raporcie GSC i w tym również nie ma nic złego.
Nie należy jednak wykorzystywać linków z hashem (#) w elementach, które dynamicznie doładowują treści. Frameworki JS, takie jak Angular czy Vue, generują adresy URL z #, a Google te URLe ignoruje i ich nie indeksuje. Zostało to podkreślone w oficjalnym stanowisku Google.
Jak wyjaśnić ten problem deweloperowi?
W tym przypadku chcemy mieć pewność, że każda strona ma unikalny adres URL. Używanie JavaScript i URL z hashem w dynamicznie ładujących się elementach nie jest dobrą praktyką i powoduje problemy z widocznością witryny w SERP.
Robots.txt
Upewnij się, że Twój plik robots.txt nie blokuje plików JavaScript. Jeśli Google nie uzyska dostępu do plików JavaScript, nie będzie w stanie poprawnie wyświetlić zawartości witryny. Należy zatem sprawdzić, czy wszystkie foldery oznaczone jako disallow nie są plikami JS.
Przykład pliku robots.txt blokującego folder plików JS:
Aby znaleźć blokowane zasoby możesz także użyć Screaming Froga:
Jak wyjaśnić ten problem deweloperowi?
Chcemy mieć pewność, że Google może poprawnie renderować witrynę. Aby to zrobić, musimy upewnić się, że żadne istotne pliki JS nie są blokowane przed indeksacją w pliku robots.txt.
Raport Statystyki indeksowania w GSC
Dobrym miejscem do sprawdzenia, ile plików JavaScript jest indeksowanych w Twojej witrynie, jest raport Statystyki indeksowania w GSC. Można go znaleźć w ustawieniach:
Po otworzeniu raportu możesz zobaczyć statystyki indeksowania według typów pliku. Warto więc zaglądać do niego regularnie.
Renderowanie po stronie serwera
Prawdopodobnie zetknąłeś się już z terminem takim jak renderowanie po stronie serwera i po stronie klienta. Krótko przypomnijmy:
- Renderowanie po stronie klienta – oznacza, że zawartość strony generowana jest w przeglądarce, a nie na serwerze. Jeśli używasz frameworka JavaScript, domyślnym ustawieniem będzie właśnie renderowanie po stronie klienta.
- Renderowanie po stronie serwera – renderowanie kodu JavaScript jest wykonywane już na serwerze, a przeglądarka pokazuje jedynie wynik końcowy.
Dlaczego renderowanie po stronie klienta nie jest korzystne dla SEO?
Wykorzystanie JavaScript przy renderowaniu po stronie klienta oznacza w praktyce dodatkowe sekundy ładowania strony, co zdecydowanie nie jest dobre dla user experience. Korzystanie z tego typu renderownia to także gorsze wyniki w SERPach – problemy z JavaScript mogą blokować wyświetlanie Twojej strony lub niektórych jej treści w wyszukiwarce.
Polecamy do czytania: SXO – jak skuteczne połączenie SEO i UX może pomóc Twojemu biznesowi?
Czy korzystanie z renderowania po stronie klienta zawsze stanowi problem?
Niektóre witryny renderują po stronie klienta jedynie określone elementy. Może być to na przykład osadzony widżet recenzji, który pobiera dane z innej strony.
Do tego typu sytuacji warto podejść indywidualnie. Czasami, gdy element ten nie jest uważany za kluczową część zawartości strony, zmiana na całkowite renderowanie po stronie serwera może nie być konieczna.
Jak sprawdzić czy moja strona renderuje się po stronie serwera, czy po stronie klienta?
Najprostszy sposób to sprawdzenie kodu źródłowego strony. Kliknij prawym przyciskiem myszy, wybierz „Wyświetl źródło strony”. Jeśli kod źródłowy zawiera bardzo mało linijek kodu, oznacza to, że witryna korzysta z renderowania po stronie klienta.
Szukasz agencji SEO?
Zostaw kontakt i zamów bezpłatną konsultację SEO z naszym doradcą.
Renderowanie dynamiczne
W idealnym świecie chcielibyśmy, aby wszystkie nasze witryny były renderowane po stronie serwera, tak, aby zawartość stron była dostarczana do Google gotowa do indeksowania. Wróćmy jednak do rzeczywistości!
Jeszcze do niedawna, alternatywnym rozwiązaniem było renderowanie dynamiczne, w którym serwer dostarcza różne treści w zależności od user-agent. Jeśli zatem dostępu do strony zażądał użytkownik, serwer udostępniał jej wersję JavaScript, a jeśli był to robot Google, serwer udostępnial wersję HTML.
Google ogłosiło jednak niedawno, że renderowanie dynamiczne nie stanowi zalecanego długoterminowego rozwiązania dla witryn korzystających z renderowania po stronie klienta.
Jak wyjaśnić ten problem deweloperowi?
Nasza witryna korzysta obecnie z renderowania po stronie klienta, co stanowi pewne wyzwanie dla robota Google i innych wyszukiwarek. Musimy przełączyć się na jedną z opcji polecanych przez Google:
Polecane przez Google sposoby rozwiązania polecamy omówić bezpośrednio z programistą.
Przekierowania JavaScript
Choć JavaScript może być używany do tworzenia przekierowań, Google nie zaleca takiego rozwiązania, ponieważ inne wyszukiwarki mogą tego typu przekierowań nie wykryć. Mówi o tym Gary Illyes z Google w swoim wpisie na Twitterze.
Optymalny sposób tworzenia przekierowań to przekierowania 301. Istnieją jednak sytuacje, w których ich implementacja jest niemożliwa i musimy wybrać przekierowania JavaScript. Należy mieć jednak na uwadze, że niepoprawnie zaimplementowane przekierowania JS mogą tworzyć tzw. miękkie błędy 404.
Oto przykładowy kod implementujący przekierowania JS [Źródło]:
fetch(`/api/products/${productId}`)
.then(response => response.json())
.then(product => {
if(product.exists) {
showProductDetails(product); // shows the product information on the page
} else {
// this product does not exist, so this is an error page.
window.location.href = ‘/not-found’; // redirect to 404 page on the server.
}
})
Najprostszy sposób na znalezienie przekierowań JS to skorzystanie z Screaming Froga. Wykonaj crawl strony, przejdź do zakładki Response codes i wybierz z rozwijanego menu Redirection (JavaScript).
Jak wyjaśnić ten problem deweloperowi?
Przekierowania JavaScript wiążą się z pewnymi problemami: nie są dobrze wykrywane przez inne wyszukiwarki, a niepoprawnie zaimplementowane mogą powodować miękkie błędy 404. Zalecamy zatem korzystanie z przekierowań 301. Jeżeli nie jest to możliwe, możemy utworzyć przekierowanie JS, korzystając z zamieszczonego powyżej przykładowego kodu.
Czy niewidoczne na stronie treści są uznawane przez Google za mniej wartościowe?
Nie! Choć istotnie było tak w przeszłości, obecnie treści niewidoczne na stronie, np. ukryte w modułach akordeonowych, nie są uznawane za mniej wartościowe. Tak długo, jak treść jest widoczna w kodzie HTML lub bezpośrednim kodzie JavaScript i żaden XHR (JS API do wysyłania żądań sieciowych pomiędzy przeglądarką a serwerem) nie jest używany do jej wprowadzania, treść ukryta jest równie istotna co treść widoczna na stronie i jest traktowana przez Google w taki sam sposób.
Chociaż tego typu rozwiązanie nie jest zalecane przez samo Google, możesz użyć JS do implementacji tagów kanonicznych. Google odczyta je już po wyrenderowaniu stron. Oto przykład, jak to zrobić [Źródło]:
fetch(‘/api/cats/’ + id)
.then(function (response) { return response.json(); })
.then(function (cat) {
// creates a canonical link tag and dynamically builds the URL
// e.g. https://example.com/cats/simba
const linkTag = document.createElement(‘link’);
linkTag.setAttribute(‘rel’, ‘canonical’);
linkTag.href = ‘https://example.com/cats/’ + cat.urlFriendlyName;
document.head.appendChild(linkTag);
});
Podsumowując
Nie ma co ukrywać, że audyt JavaScript pod kątem SEO nie jest tematem, który można omówić w jednym poście na blogu. Zrobiliśmy jednak wszystko, co w naszej mocy, aby zebrać wszystkie kluczowe informacje, niezbędne, żeby rozpocząć audyt JS. Mamy nadzieję, że okażą się dla Ciebie, czytelniku, użyteczne! A jeżeli potrzebujesz pomocy z SEO (nie tylko pod kątem JS!), skontaktuj się z nami.
