JavaScript i widok mobilny w audycie SEO — co sprawdzić i jak poprawić

1. Co porównujemy: odpowiedź serwera i stronę po JavaScript

HTML to dokument otrzymany z serwera. DOM to struktura strony, którą przeglądarka może zmieniać podczas wykonywania skryptów. Jeżeli aplikacja dopiero pobiera produkty, opis albo linki z API, oba odczyty mogą się różnić. Różnica nie jest automatycznie błędem: trzeba ustalić, co dodano, czy dodanie się powiodło i czy treść jest potrzebna do zrozumienia podstrony.

Google wykonuje JavaScript w procesie obejmującym pobieranie, renderowanie i indeksowanie. Nie wynika z tego, że każda aplikacja zostanie odczytana identycznie jak w Twojej przeglądarce. Dostęp do zasobów, błędy skryptów oraz sposób dostarczania treści wymagają sprawdzenia. Szczegóły opisuje dokumentacja JavaScript SEO Google.

Przykładowo krótki HTML z kontenerem aplikacji nie dowodzi braku treści w indeksie. To powód, aby sprawdzić render, a następnie — jeśli masz uprawnienia do witryny — odczyt w Inspekcji adresu URL w Search Console.

2. Uruchom dodatkowy test w raporcie

1. Otwórz zapisany wynik audytu SEO dla konkretnego publicznego adresu.
2. Przejdź do sekcji JavaScript i widok mobilny i wybierz Sprawdź JavaScript i widok mobilny.
3. Poczekaj na zakończenie zadania. Test ma własną kolejkę i limity; oczekiwanie nie oznacza usterki badanej strony.
4. Przeczytaj stan wyniku, odczytane wartości oraz ograniczenia. Brak danych pozostaw jako nieustalony, zamiast uznawać go za wynik negatywny.

To osobne uzupełnienie zapisanego raportu: nie przelicza jego pierwotnej punktacji. Automat nie loguje się do panelu, nie zatwierdza zgód ani nie wykonuje ścieżki zakupu. Dlatego element zależny od takich działań może nie pojawić się w odczycie, choć działa u zalogowanego użytkownika.

3. Które różnice wymagają wyjaśnienia

Najpierw sprawdź, czy renderowany adres końcowy jest tym, który zamierzasz badać. Następnie porównaj tytuł, canonical, dyrektywy robots i H1. Konfliktujące wartości wymagają ustalenia, która warstwa je generuje: szablon HTML, wtyczka, router aplikacji czy skrypt. Nie usuwaj canonical lub robots tylko po to, aby wyrównać tabelę.

Przy tekście i linkach interesuje nas przede wszystkim treść główna. Większa liczba znaków po renderze nie musi oznaczać lepszej strony: mogło dojść menu, okno zgody albo komunikat. Licznik nie jest precyzyjnym porównaniem redakcyjnym, a próbka tekstu może być ograniczona. Widoczność elementów zależy również od CSS i badanego rozmiaru.

Praktyczny przykład: opis usługi jest w edytorze, lecz po publikacji znika z odczytanego HTML i renderu. Sprawdź najpierw, czy w przeglądarce niezalogowanej faktycznie się pojawia, a potem błędy ładowania komponentu. Samo dopisanie opisu do meta description nie zastąpi widocznej treści.

4. Jak poprawiać dostarczanie treści

W CMS ustal, czy treść generuje edytor, kreator strony czy dodatkowa wtyczka. W aplikacji przekaż programiście konkretny adres, datę próby, brakujący element i różnice z raportu. Sprawdź w narzędziach przeglądarki, czy potrzebne zasoby odpowiadają poprawnie i czy wykonanie skryptu nie kończy się błędem.

Kluczowa treść nie powinna wymagać przypadkowej interakcji użytkownika, aby stać się dostępna dla wyszukiwarki. Przy doładowywaniu kolejnych wyników potrzebne są również odkrywalne adresy i linki. Google opisuje zasady oraz weryfikację w poradniku o odroczonym ładowaniu treści. Nie wyłączaj całego JavaScriptu ani zabezpieczeń jako domyślnej naprawy. Wybór renderowania po stronie serwera lub przeglądarki powinien wynikać z potrzeb aplikacji i ustalonej przyczyny problemu.

5. Co zrobić, gdy strona wychodzi poza ekran

Sprawdź też znacznik viewport w szablonie strony. Typowa konfiguracja dopasowuje szerokość do urządzenia; sam znacznik nie naprawi sztywnego układu CSS. Nie blokuj użytkownikowi powiększania, np. przez user-scalable=no. Zasady opisuje poradnik projektowania responsywnego web.dev.

<meta name="viewport" content="width=device-width, initial-scale=1">

W dodatkowym teście odczytaj szerokość badanego widoku oraz dokumentu. Jeżeli zaobserwowano przewijanie poziome, zobacz wskazane elementy i otwórz ten sam adres przy podobnej szerokości. Częste miejsca do sprawdzenia to szeroka tabela, obraz, osadzony film, długa nazwa, sztywny układ kolumn albo element ustawiony poza ekranem.

Popraw źródło szerokości w odpowiednim komponencie. Obraz powinien mieścić się w kontenerze; tabela może potrzebować własnego przewijanego obszaru, aby zachować czytelność danych. Długie ciągi tekstu wymagają dopasowanego zawijania. Ukrycie przewijania całej strony nie zastępuje diagnozy: może tylko obciąć treść i przyciski.

Po poprawce sprawdź także otwarte menu, komunikaty błędów, rozwinięte szczegóły i formularz z dłuższą treścią. Wąski test bez interakcji nie obejmuje automatycznie tych stanów.

6. Potwierdź efekt poza jednym automatycznym testem

Po wdrożeniu zmian użyj ponownego audytu i upewnij się, że powstał nowy raport z aktualną datą. Następnie uruchom dodatkowy test renderowania w tym raporcie. Przycisk „Odśwież wynik” na starym raporcie może odczytać zapisany rezultat; nie traktuj go jako potwierdzenia nowej próby. Jeżeli cache lub cooldown nadal zwraca poprzedni raport, zaczekaj na możliwość wykonania nowego badania. Ręcznie sprawdź również stronę na telefonie. Zwróć uwagę na czytelność tekstu, możliwość powiększenia, widoczność aktywnego pola, obsługę klawiaturą oraz działanie przycisków. Brak przewijania w widoku 375 px oznacza tylko, że w tej próbie go nie zaobserwowano. Nie potwierdza wszystkich urządzeń, dostępności ani zgodności WCAG.

Google wykorzystuje mobilną wersję treści do indeksowania i rankingu; ważna jest dostępność istotnej zawartości i metadanych na telefonie. Zobacz zalecenia dotyczące indeksowania mobilnego. Nasz Chrome nie jest Googlebotem. Jeżeli pytanie dotyczy obecności adresu w Google, potrzebne będą osobne dane z Search Console, a nie sam poprawny wynik renderowania.

Sprawdź dostępność w naszym audytorze WCAG – Cyfrowo Dostępni →