Jeszcze kilka lat temu, używanie JavaScript pod kątem SEO nie było dobrym rozwiązaniem. Wyszukiwarki internetowe, takie jak Google nie widziały tego. Na szczęście technologia poszła mocno do przodu i samo Google nauczyło się czytać oraz analizować kod JavaScript. Dlatego postał nowy termin: JavaScript SEO. W tym wpisie rozwinę problem JavaScript SEO – czyli jak tworzyć nowoczesne strony by były przyjazne wyszukiwarkom internetowym.
W tym wpisie nie będę skupiał się mocno na aspektach technicznych. Gdybym to zrobił, to mógłbym napisać książkę o tym zagadnieniu – czyli jak pożenić JavaScript z SEO. Skupiam się na problemie i sposobach jego rozwiązania. W planach mam, by tekst aktualizować na bieżąco gdy pojawią się nowe, ciekawe rozwiązania.
Faktem jest, że wielu programistów tworzących aplikacji z wykorzystaniem JavaScript nie ma dużej wiedzy na temat bycia przyjaznym wyszukiwarkom internetowym. To samo dotyczy samego biznesu. Często bywa tak, że gdy mamy już aplikację zrobioną, to często okazuje się, że trzeba bardzo dużo zmieniać, bo strona nie jest przyjazna SEO. Na szczęście są sposoby by to zmienić – nawet w istniejących projektach.
Google rozumie już JavaScript, ale…
Odkąd Google zaczęło przeglądać strony za pomocą silnika renderującego Chromium, indeksowanie treści renderowanych przez Javascript stało się osiągalne. Oczywiście nie oznacza to, że nagle wszystkie strony w tworzone w JS będą pojawiać się wysoko w wynikach wyszukiwania. Trzeba mieć na uwadze, że analizowanie takich stron jest zasobożerne.
I jest to kluczowym problem gdy mówimy o SEO i JavaScript.
Długi czas analizy i indeksowania strony w JavaScript (CSR)
Dla tradycyjnej strony, która serwuje content – nazwijmy to – w tradycyjny sposób, czyli treść jest dostępna od razu dla wszystkich, bycie SEO friendly nie jest problemem.
Dla strony, która treść zostaje wygenerowana po pewnym czasie (krótkim, ale wciąż) w JavaScript, bo trzeba odpytać kilka zasobów, jest to problem. Aby wyświetlić zawartość takiej strony, to przeglądarka musi wykonać trzy zadania:
- Pobrać wszystkie zasoby (pliki JS, CSS, obrazki itp) (ang. download).
- Przeanalizować pobrane zasoby (ang. parse).
- Wykonać (ang. execute).
Do tego trzeba to wszystko przeskanować i zaindeksować.
W przeglądarce te trzy punkty wykonują się w mgnieniu oka. W przypadku robotów wyszukiwarek jest to czasochłonne. Bowiem to wszystko należy uruchomić na serwerach wyszukiwarki. Wykonywanie tego dla milionów stron musi trwać. W praktyce oznacza to, że treści generowane po stronie klienckiej (CSR) będą się indeksowały i pozycjonowały znaczniej dłużej niż w przypadku stron, których content jest dostępny od razu.
Co zrobić jeżeli mam stronę tylko w JavaScript aby była przyjazna SEO?
Można skupić się jedynie na pomocy wyszukiwarkom, czyli:
- Stworzyć plik
robots.txtw którym zawrzemy reguły na temat stron jakie może i nie może indeksować crawler. Wskażemy linki do mapy strony (sitemap). - Utworzyć mapy strony, które wskażą wyszukiwarce jakie strony mają być zaindeksowane.
- Zadbać o poprawne meta tagi, czyli
titleorazmeta="description". - Upewnić się, że link do innych stron są linkami
a(anchor HTML) a nie elementami HTML z podpiętymonClick. - Stworzyć znaczniki uporządkowanych danych.
Powyższe punkty, to absolutne minimum, które można osiągnąć niskim nakładem pracy oraz kosztem. Oczywiście nie rozwiąże to głównego problemu.
Aby rozwiązać ten problem należy zainteresować się tematem SSR.
JavaScript i SEO – czyli SSR (server side rendering)
Skoro już wiemy gdzie leży problem, to możemy próbować rozwiązać go lepiej i optymalniej.
A tak na marginesie, to Google zachęca wszystkich developerów by tworzyli dedykowane rozwiązania pod kątem wyszukiwarek użytkowników, które zapewnią błyskawiczny dostęp do treści.
Skoro jesteśmy już przy SSR, to możemy mówić tutaj o trzech rozwiązaniach.
Klasyczny SSR
Zanim wszystko zostanie wyświetlone w przeglądarce, to najpierw po stronie serwera zbierane są niezbędne dane do obsłużenia danego zapytania HTTP. Każde odświeżenie strony, czy zmiana parametrów w URL spowoduje wyświetlenie innej odpowiedzi przez serwer.
W takim rozwiązaniu JavaScript jest dodatkiem, który usprawnia niektóre części strony.
Dzięki temu rozwiązaniu mamy niskie wskaźniki FCP oraz TBT (główny wątek nie jest blokowany) z Core Web Vitals.
Statyczny SSR (Static SSR)
Dzięki tej technice strona ładuje się w ułamku sekundy za sprawą wcześniej przygotowanego dokumentu HTML. Te pliki HTML tworzą się w momencie „budowania” aplikacji.
Tego typu rozwiązanie sprawdzi się dla serwisów/stron, które mają mało stron. Każda strona to zajęcie miejsca na serwerze. Więc trzeba mieć sporo miejsca w planie hostingowym. Z drugiej strony takie strony można wrzucić na CDN.
W tym rozwiązaniu nie używa się JavaScript, dzięki czemu strona jest w pełni funkcjonalna.
W przypadku CWV, mamy tutaj „zielone” wskaźniki FCP, TBT i INP.
Sam korzystam z tego rozwiązania w kilku mniejszych projektach. Bardzo fajnie to sprawdza i działa. Dodam tylko, że mówimy tutaj w dalszym ciągu o serwisach do 20 stron.
SSR i hydrate
Ta technika łączy ze sobą dwa rozwiązania. Czyli z jednej strony dostajemy gotowy HTML oraz pliki JavaScript, które „podpinają” (hydrate) się pod to zdarzenia takie jak onClick czy sprawiają, że inputy reagują na to co użytkownik wpisuje. Można by powiedzieć, że jest złoty środek. Z drugiej jednak strony, musimy defacto stworzyć dwie aplikacje – jedna po stronie serwera, druga po stronie klienta (musimy czasami zdublować dane).
Minusem tego rozwiązania jest to, że strona nie jest w pełni interaktywna. Użytkownik musi chwilę poczekać, aż wszystkie pliki JS zostanie wykonane w przeglądarce.
W przypadku CWV, mówimy o negatywnym wpływie na TBT i INP ale FCP może być szybki.
Dynamic rendering jako alternatywa dla SSR
W przypadku tego rozwiązania mówimy o kilku wersjach serwisu. Jedna wersja jest dla użytkowników (laptop, smartfon, tablet), zaś inna jest specjalnie pod wyszukiwarki. W praktyce wygląda to tak, że wyszukiwarka dostaje treści bez zbędnego JavaScriptu. Oczywiście Google tutaj uspokaja tutaj, że w takim przypadku nie ma mowy o cloackingu.
Dynamic renderening nie jest rozwiązaniem na dłuższą metę (wg Google) by rozwiązać wszystkie problemy z treścią generowaną po stronie klienckiej. W oficjalnych dokumentach firma sugeruje, że rekomendowanym rozwiązaniem jest jedna z wersji SSR.
Podsumowanie
Jak widzimy, sposobów na rozwiązanie problemu jest całkiem sporo. Bez względu czy tworzymy nasze strony i aplikacje w React, Angular, Vue czy innych frameworkach to nie zapominajmy, że mamy też rozwiązania po stronie serwera jak np. expressJS czy Next.js. Szczególnie ten ostatni wspiera większość z rozwiązań SSR, które sprawią, że nasze rozwiązanie będzie przyjazne SEO.
To na jakie rozwiązanie zdecydujemy się, będzie zależało przede wszystkim od wymagań biznesowych, zasobów i pieniędzy.
Ciekawe zestawienie każdego z rozwiązań w postaci tabelki znajdziecie na web.dev.
