Skąd biorą się problemy

W architekturze rozdzielonej treść jest przechowywana bez informacji o tym, jak ma zostać wyświetlona. Aplikacja frontendowa pobiera ją i buduje z niej stronę. Zaletą jest swoboda: ta sama treść zasila serwis, aplikację mobilną i inne kanały.

Problem dla wyszukiwarki jest prostszy, niż się zwykle opisuje. Robot potrzebuje adresu, który zwraca poprawny status i kompletną treść wraz z metadanymi oraz linkami prowadzącymi dalej. W klasycznym systemie ten kontrakt był spełniony przez sam silnik. Tutaj każdy jego element realizuje kod napisany przez zespół, który — i mówię to bez złośliwości — bardzo często nie miał w wymaganiach ani słowa o wyszukiwarce.

Stąd charakterystyczna cecha takich wdrożeń: strona działa bez zarzutu dla człowieka i jednocześnie jest w połowie niewidoczna dla robota. Nie ma tu żadnej kary ani uprzedzenia algorytmu wobec nowoczesnych technologii. Jest brak kilku elementów, które nikomu nie przyszły do głowy, bo w poprzednim świecie były darmowe.

Sposób renderowania to decyzja SEO

Najważniejsza decyzja techniczna w takim projekcie dotyczy tego, gdzie powstaje kod strony. Warianty są cztery i różnią się konsekwencjami.

• Generowanie statyczne przy budowaniu — najbezpieczniejsze dla wyszukiwarki, bo robot dostaje gotowy dokument. Ograniczenie jest praktyczne: przy dużej liczbie podstron budowanie trwa długo, a każda zmiana treści wymaga przebudowy.

• Renderowanie po stronie serwera przy każdym żądaniu — również daje robotowi kompletny dokument i radzi sobie z treścią zmienną. Wymaga za to sprawnej infrastruktury i przemyślanego buforowania, bo inaczej czas odpowiedzi serwera potrafi urosnąć.

• Podejście mieszane z odświeżaniem stron w tle — w praktyce najczęstszy kompromis w dużych serwisach i zwykle mój wybór, gdy trzeba pogodzić skalę z aktualnością.

• Renderowanie wyłącznie po stronie przeglądarki — najbardziej ryzykowne. Robot potrafi wykonać JavaScript, ale robi to w osobnym, opóźnionym przebiegu i nie ma gwarancji, że wykona wszystko. Przy serwisie, który żyje z ruchu z wyszukiwarki, nie polecam tego rozwiązania dla treści mających się pozycjonować.

Praktyczna zasada, którą powtarzam na spotkaniach technicznych: wszystko, co ma się pozycjonować, powinno być w dokumencie przychodzącym z serwera. Elementy interaktywne mogą doładowywać się później, ale treść, nagłówki, metadane i linki nie należą do tej kategorii.

Co psuje się najczęściej

Lista z audytów, w kolejności częstotliwości.

Linki, które nie są linkami. Nawigacja zbudowana na elementach reagujących na kliknięcie, bez klasycznego odnośnika z adresem, jest dla robota ścianą. To pojedynczy najczęstszy i najkosztowniejszy błąd w tej architekturze.

Statusy odpowiedzi. Nieistniejąca podstrona zwraca poprawną odpowiedź i wyświetla komunikat o błędzie w treści. Wyszukiwarka widzi tysiące poprawnych, pustych adresów. To samo dotyczy przekierowań realizowanych po stronie przeglądarki zamiast po stronie serwera.

Metadane wstawiane dopiero po wczytaniu skryptu. Tytuł i opis podmieniane w przeglądarce działają zwykle, ale w praktyce widuję wersje, gdzie każda podstrona ma w źródle ten sam tytuł domyślny.

Adresy kanoniczne. Albo nie ma ich wcale, albo wszystkie wskazują na stronę główną, albo są generowane z bieżącego adresu razem z parametrami sortowania.

Paginacja i filtry. Nieskończone przewijanie bez alternatywnych adresów oznacza, że dalsze pozycje z listy nie istnieją dla robota. Filtry przepisane do adresu bez ograniczeń tworzą z kolei nieskończoną liczbę kombinacji do odwiedzenia.

Środowiska testowe. Kopia serwisu dostępna publicznie, bez blokady indeksowania, konkurująca z produkcją. Zdarza się w tej architekturze częściej niż w klasycznej, bo takich środowisk jest więcej.

Redakcja musi mieć gdzie wpisać

Ten punkt jest organizacyjny, ale odpowiada za bardzo dużą część efektu.

W klasycznym systemie osoba redagująca ma pod treścią pola na tytuł w wyszukiwarce, opis, adres podstrony i obrazek do udostępniania. W systemie bezgłowym te pola trzeba świadomie zdefiniować w modelu treści. Jeśli tego nie zrobiono, redakcja nie ma jak wpłynąć na to, co widać w wynikach — i po wdrożeniu okazuje się, że tytuł jest generowany automatycznie z nazwy wpisu.

Minimalny zestaw, o który proszę na etapie projektowania modelu: tytuł dla wyszukiwarki, opis, uchwyt adresu z historią zmian, obrazek do udostępniania, przełącznik indeksowania oraz pole na adres kanoniczny w przypadkach szczególnych. Do tego pole na dane strukturalne albo mechanizm ich generowania z pól treści.

Historia zmian uchwytu adresu jest tu elementem, o którym najczęściej się zapomina. Bez niej zmiana tytułu wpisu przez redaktora zmienia adres i tworzy błąd w miejscu, gdzie wcześniej była działająca podstrona z linkami.

Wydajność, mapa witryny i indeksowanie

Serwis rozdzielony bywa bardzo szybki i bywa bardzo wolny, w zależności od tego, ile pracy zostawiono przeglądarce. Dwie rzeczy pilnuję szczególnie.

Pierwsza to rozmiar paczki JavaScriptu i to, czy jest dzielona według widoków. Aplikacja ładująca kod całego serwisu przy wejściu na jeden artykuł obciąża każde urządzenie, a najmocniej te słabsze.

Druga to czas odpowiedzi serwera przy renderowaniu na żądanie. Bez buforowania i bez sieci dostarczania treści łatwo tu wyjść gorzej niż w krytykowanym klasycznym systemie z porządną wtyczką cache.

Mapa witryny musi być generowana automatycznie z zawartości systemu treści i aktualizowana przy publikacji, nie przy budowaniu raz na tydzień. Przy dużych serwisach dzielę ją na części i pilnuję, żeby zawierała wyłącznie adresy indeksowalne — mapa z połową adresów zablokowanych to sygnał, który sam sobie zaprzecza.

Osobno sprawdzam plik z regułami dla robotów. W tej architekturze bywa on generowany dynamicznie i widziałem przypadki, w których środowisko produkcyjne odziedziczyło regułę blokującą wszystko z wersji testowej.

Jak to testować

Trzy narzędzia i jedna zasada.

Zasada: nie oceniam tego, co widzę w przeglądarce z włączonym JavaScriptem, bo to najbardziej optymistyczny możliwy scenariusz. Sprawdzam surowy kod odpowiedzi serwera — najprościej narzędziem wiersza poleceń pobierającym dokument bez wykonywania skryptów. Jeśli treści tam nie ma, dalsze testy są tylko potwierdzaniem nadziei.

Potem test pobrania i wyrenderowania w Search Console, na kilku typach podstron, z obejrzeniem zrzutu ekranu i kodu po renderowaniu. Następnie przejście robotem indeksującym po całym serwisie, żeby wyłapać statusy odpowiedzi, łańcuchy przekierowań, powtarzające się tytuły i adresy bez linków wewnętrznych.

Na koniec rzecz, którą polecam wpisać do procesu wdrożeń: krótka lista kontrolna uruchamiana przed każdym wydaniem. Cztery pozycje wystarczą — czy treść jest w źródle, czy metadane są unikalne, czy nieistniejący adres zwraca właściwy status, czy blokada indeksowania nie została włączona przypadkiem. Zajmuje kwadrans i oszczędza tygodnie tłumaczenia spadków ruchu.

Migracja bez utraty widoczności

Przy przejściu na taką architekturę najwięcej ruchu traci się nie na technologii, a na zaniedbaniu dwóch rzeczy.

Pierwsza to mapa przekierowań. Kompletna lista starych adresów zestawiona z nowymi, przygotowana przed wdrożeniem, wdrożona jako przekierowania stałe po stronie serwera, bez łańcuchów. Jeśli struktura adresów się nie zmienia — a przy tego typu migracji często nie musi — to jest to najlepsza możliwa decyzja i warto o nią walczyć.

Druga to porównanie treści przed i po. W praktyce nowy szablon prawie zawsze coś gubi: fragment opisu kategorii, sekcję z pytaniami, dane strukturalne, wewnętrzne linkowanie w treści. Robię więc pełny zrzut kluczowych podstron przed migracją i po niej, i porównuję je pozycja po pozycji.

Do tego dwa nawyki na okres po wdrożeniu: obserwacja raportu indeksowania częściej niż zwykle przez pierwszy miesiąc oraz zachowanie starych logów serwera do porównania zachowania robota. To ostatnie kosztuje jedną prośbę do administratora, a bywa jedynym sposobem ustalenia, co się faktycznie zmieniło.