Nie pytaj tylko, czy wyszukiwarka uruchamia skrypty
Google opisuje przetwarzanie stron JavaScript jako pobieranie, renderowanie i indeksowanie. Sam fakt obsługi skryptów nie oznacza jednak, że każda aplikacja zostanie poprawnie odczytana w każdej sytuacji. Dla właściciela serwisu ważniejsze jest pytanie, czy kluczowa treść i nawigacja są dostępne w sposób niezawodny. Nie trzeba traktować całego JavaScriptu jako zagrożenia, aby sprawdzić tę zależność.
W typowym blogu lub witrynie usługowej tekst, tytuł i odnośniki można dostarczyć bez oczekiwania na zewnętrzne API. Skrypty mogą wtedy wspierać menu, zgodę cookies lub powiększenie QR. To propozycja architektoniczna dopasowana do rodzaju strony, a nie zakaz budowania aplikacji. Im bardziej podstawowa informacja zależy od wielu kolejnych operacji, tym więcej punktów trzeba uwzględnić w testach awarii.
Porównaj trzy obrazy tej samej podstrony
Sprawdź odpowiedź HTML serwera, strukturę dokumentu po wykonaniu skryptów i widok dostępny użytkownikowi. Zanotuj, gdzie występują różnice. Jeśli pierwsza odpowiedź zawiera tylko pusty kontener, właściwa treść pojawi się dopiero po kolejnych działaniach. Google wskazuje, że w takim modelu potrzebne jest renderowanie, aby zobaczyć materiał generowany przez JavaScript.
Przygotuj listę elementów kontrolnych: nagłówek H1, główne akapity, cena lub zakres usługi, ważne linki i metadane. Nie porównuj wyłącznie liczby znaków HTML, bo duży dokument może składać się przede wszystkim ze skryptów. Celem jest ustalenie, czy odbiorca i system pobierający stronę otrzymują tę samą istotną informację. Wyniki zapisuj dla konkretnych URL-i, nie tylko dla strony głównej aplikacji.
Sprawdź zależności od kliknięcia i stanu użytkownika
Otwórz stronę w nowej sesji, bez wcześniejszej zgody i bez danych zapisanych przez poprzednią wizytę. Sprawdź, czy treść nie zależy od zalogowania, lokalnego ustawienia lub kliknięcia przycisku. Nie zakładaj, że robot odtworzy pełny scenariusz interakcji człowieka. Materiał, który ma być publicznie odnajdywany, powinien mieć stabilny adres i być dostępny bez nieprzewidywalnego ciągu czynności.
Szczególnie uważaj na listy wpisów doładowywane dopiero po przewinięciu. Zapewnij zwykłą drogę do kolejnych stron archiwum i poszczególnych artykułów. Użytkownik powinien móc skopiować adres oraz wrócić do tej samej treści. To także ułatwia wsparcie techniczne: zgłoszenie problemu z konkretną podstroną jest czytelniejsze niż opis stanu aplikacji osiągniętego po kilku niewidocznych w URL krokach.
Zachowaj prawdziwe odnośniki
Google zaleca odnośniki oparte na elemencie a z atrybutem href wskazującym adres. Sam przycisk uruchamiający zmianę widoku nie jest równoważny zwykłemu linkowi w nawigacji. Sprawdź menu, karty artykułów i paginację. Odnośnik powinien pozwalać otworzyć stronę w nowej karcie i działać jako adres, nie wyłącznie jako wyzwalacz skryptu.
Nie przenoś całej nawigacji do zdarzeń JavaScript, jeśli nie ma takiej potrzeby. Dla bloga liczącego kilkadziesiąt wpisów klasyczna paginacja może być prostsza i bardziej przewidywalna. Skrypt może poprawiać wygodę, ale podstawowa ścieżka powinna pozostać czytelna. Przy testach wyłącz JavaScript i zanotuj, co przestaje działać. To diagnostyka zależności, nie symulacja wszystkich zachowań robota Google.
Pilnuj statusów i metadanych przed renderowaniem
Sprawdź, jak aplikacja odpowiada na nieistniejący URL. Pusta powłoka z kodem 200 i komunikatem dodanym dopiero po uruchomieniu skryptu może utrudniać poprawne rozpoznanie braku strony. Dokumentacja JavaScript SEO opisuje znaczenie prawidłowych odpowiedzi i metadanych. Testuj również canonical, tytuł i robots dla poszczególnych adresów, nie tylko dla pierwszego załadowania aplikacji.
Nie dodawaj w początkowej odpowiedzi blokady indeksowania z założeniem, że skrypt zawsze później ją usunie. Ustal jedną odpowiedzialną warstwę generowania metadanych i kontroluj jej wynik. Gdy zmieniasz routing, sprawdź wejście bezpośrednie na artykuł oraz przejście do niego z listy. Obie ścieżki powinny dawać zgodną treść i adres kanoniczny, bez pozostawienia tytułu poprzednio odwiedzanej zakładki.
Zbadaj awarie, nie tylko idealne ładowanie
Sprawdź zachowanie przy niedostępnym API, błędzie skryptu i wolniejszym połączeniu. Czy użytkownik nadal widzi podstawową ofertę, czy wyłącznie animację oczekiwania? Czy błąd jednego widgetu zatrzymuje menu albo formularz? Takie testy pomagają ocenić odporność aplikacji, nawet jeśli codziennie działa ona poprawnie na szybkim komputerze autora.
Google zaznacza, że zablokowane zasoby mogą uniemożliwić oczekiwane renderowanie. Przejrzyj więc nie tylko reguły dla HTML, ale również dostęp do plików potrzebnych do odczytu treści. Nie udostępniaj przy tym prywatnej konfiguracji czy sekretów. Rozdziel publiczne zasoby strony od elementów administracyjnych i sprawdź, czy optymalizacja bezpieczeństwa nie odcięła przypadkiem podstawowego arkusza stylów lub skryptu aplikacji.
Wybierz najmniejszą zmianę rozwiązującą problem
Nie przepisuj całego serwisu tylko dlatego, że używa JavaScriptu. Jeśli problem dotyczy paginacji, zacznij od zwykłych linków do kolejnych stron. Jeśli treść znika przy awarii API, rozważ dostarczanie jej po stronie serwera. Jeżeli błędne są metadane, popraw odpowiedzialny moduł i dodaj test dla kilku typów podstron. Zakres naprawy powinien wynikać z diagnozy, a nie z ogólnej opinii o technologii.
Po wdrożeniu porównaj HTML, widok publiczny i kontrolę adresu w narzędziach wyszukiwarki. Zapisz wyniki oraz ograniczenia testu. Dla strony wspierającej usługi DR ważniejsza jest przewidywalna dostępność materiałów niż efektowna liczba bibliotek. Skrypty mają ułatwiać korzystanie z wiedzy i kontaktu, nie tworzyć dodatkowej przeszkody między linkiem zewnętrznym a odpowiedzią, której potrzebuje odbiorca.