JavaScript SEO: unikanie pułapek renderowania po stronie serwera

JavaScript SEO jest obecnie jednym z gorących tematów w branży SEO, ponieważ współczesna sieć ewoluuje i coraz więcej stron internetowych uruchamia się ponownie lub jest tworzonych na podstawie aplikacji internetowych opartych na JavaScript, głównie na React lub AngularJS. Dzięki temu do SEO dodaje się więcej złożoności, ponieważ musimy upewnić się, że Google jest w stanie skutecznie renderować JavaScript, aby strony mogły być poprawnie indeksowane i pozycjonowane. Można to osiągnąć za pomocą renderowania po stronie serwera. Nie jest to jednak pozbawione ryzyka. W tym artykule omawiam pięć błędów renderowania po stronie serwera i wyjaśniam, jak można ich uniknąć.

Jeśli szukasz wsparcia w technicznej optymalizacji swojej strony internetowej, umów się na niezobowiązujące spotkanie z naszymi konsultantami Digital Strategies Group i dowiedz się, w czym mogą Ci pomóc?

Umów się na spotkanie!

Jakie są różne rodzaje renderowania po stronie serwera?

Wstępne renderowanie witryny dla Google na serwerze (renderowanie po stronie serwera, SSR) to jedna z opcji zapewniających, że witryna JavaScript jest przyjazna dla Googlbota. W ten sposób możesz dostarczyć wstępnie wyrenderowaną wersję HTML swojej witryny do Google, podczas gdy użytkownik otrzyma normalną (jeszcze nie wyrenderowaną) wersję przeglądarki.

Jednak jeśli chodzi o renderowanie po stronie serwera, istnieją również różne sposoby renderowania, jak widać na następnym wykresie, który został pomocny przez Google, z kilkoma przydatnymi dodatkami od Jana-Willema Bobbinka.

Istnieją trzy główne sposoby konfigurowania i wykonywania renderowania po stronie serwera:

1. Renderowanie po stronie serwera z dynamicznym HTML

Renderowanie po stronie serwera tworzy wyrenderowaną wersję HTML każdego adresu URL na żądanie.

2. Renderowanie statyczne za pomocą statycznego HTML

Zasadniczo tworzy to wstępnie wyrenderowaną (statyczną) wersję adresu URL w formacie HTML i przechowuje ją w pamięci podręcznej.

3. Renderowanie po stronie serwera z (re)hydratacją za pomocą dynamicznego HTML i JS/DOM

Serwer udostępnia statyczną wersję HTML adresu URL i klienta (przeglądarki itp.), która zawiera już znaczniki strukturalnego modelu obiektów dokumentu (DOM). Klient bierze to i przekształca w dynamiczny DOM, który może reagować na zmiany po stronie klienta i czyni go bardziej interaktywnym.

Google opublikował świetny przegląd renderowania sieci, ze wszystkimi zaletami i wadami, a także głębsze wyjaśnienie, jeśli jesteś zainteresowany. Ale przede wszystkim, jeśli szukasz pomocy w temacie JavaScript SEO lub renderowania po stronie serwera, skontaktuj się z nami tutaj w Searchmetrics Digital Strategies Group.

Skontaktuj się!

Pułapki podczas renderowania stron JavaScript przez serwer

Niedawno natknęliśmy się na pewne problemy z SSR u jednego z naszych klientów. Prowadzą swoją stronę internetową na Angular JS i renderują ją za pomocą Rendertron za pośrednictwem Headless Chrome.

Używają statycznego podejścia do renderowania SSR, co oznacza, że ​​renderują stronę i buforują renderowany kod HTML na serwerze (z wyprzedzeniem). Zbuforowany kod HTML nie zostanie automatycznie zastąpiony, ale oparty na logice renderowania. Poniżej znajduje się pięć problemów, które napotkaliśmy podczas pracy na tej stronie. Dzielę się nimi z Tobą tutaj, aby przy podobnych wyzwaniach miałeś pomysł, jak sobie z nimi poradzić. Można to jednak uznać za niedokończoną/rozszerzalną listę.

1. Kiedy nic nie robisz

Jeśli nie obchodzi Cię to i nie zwracasz uwagi na to, jak Google renderuje Twoją stronę, pozwól, że pokażę Ci, jak Google renderuje (faktycznie widzi) Twoją stronę. Jest to oparte na witrynie internetowej zbudowanej na aplikacji jednostronicowej (SPA) przy użyciu struktury JavaScript, bez renderowania po stronie serwera.

Nie wygląda to szczególnie obiecująco, prawda? Właśnie dlatego ważne jest, aby używać SSR, ponieważ wtedy wygląda to tak:

2 . Paginacja

Jak radzić sobie ze stronami z podziałem na strony, jeśli chodzi o renderowanie? Cóż, zwłaszcza w przypadku publikowania, strony z podziałem na strony mogą nadal dobrze służyć Google z (najnowszymi) artykułami, podczas gdy Google je indeksuje. Jeśli spojrzysz na swoje pliki dziennika, zobaczysz, w jaki sposób Google uzyskuje dostęp do Twojej paginacji, abyś wiedział, gdzie ma sens dostarczenie wstępnie wyrenderowanej wersji (Spoiler: nie musisz podawać 399 adresów URL z wyrenderowaną wersją )

Gdy nasz klient renderuje przy użyciu statycznego podejścia SSR, wyrenderował po prostu pierwszą stronę i odzwierciedlił wersję strony 1 w pamięci podręcznej aż do strony 10. Bez żadnej renderowanej wersji od strony 11 i dalej. Oto dwa zrzuty ekranu, które dość dobrze pokazują problem, z dokładnie taką samą treścią ze strony 1, jak również na stronach 2-10.

Oznacza to, że udostępniasz strony Google 10 z tą samą treścią i artykułami. Idealnie byłoby, gdyby Google renderował wszystkie strony jako unikalne z poprawnie ponumerowanymi artykułami.

3 . Odnów renderowaną wersję stron kategorii po opublikowaniu nowego artykułu/produktu

Nasz klient znacznie poprawił swoją pozycję w prawie każdej usłudze Google News, takiej jak AMP Carousels, Google News Boxes i Mobile News Boxes, z wyjątkiem Publisher Carousels. Zaczęliśmy to badać i okazało się, że nasz klient nie aktualizował swojej wersji w pamięci podręcznej, gdy pojawił się nowy artykuł. Tydzień później dowiedzieliśmy się, że odnowili swoją wersję głównych kategorii w pamięci podręcznej:

a na podkategoriach nawet miesiąc później.

Doprowadziło to do tego, że nadal mieli stary artykuł na temat Brexitu w swojej wstępnie wyrenderowanej wersji, ale nie opublikowali wszystkich nowych artykułów na ten temat. Zakładamy, że z powodu tego problemu nie było wystarczającej liczby świeżych artykułów, aby Google mógł zapełnić karuzelę, co miało duży negatywny wpływ na ich wydajność. Wciąż badamy wpływ zmiany.

4 . Renderowanie może spowodować zduplikowanie treści i nieprawidłową kanonizację

Dostarczenie wstępnie wyrenderowanej wersji adresu URL może spowodować problemy systemowe. Ponieważ nasz klient dostarczał wstępnie wyrenderowane strony, każda z własnym adresem URL utworzonym przez silnik renderujący, te adresy URL miały parametry „p=1; render=1” i były w pełni indeksowalne:

Silnik SSR ustawił nawet nowy kanoniczny adres dla tego adresu URL. Dość upiorne, co?

Najlepiej byłoby wykluczyć te parametry z indeksowania Google.

5 . Zmiana tytułu strony podczas renderowania

Odkryliśmy również, że aktualne tytuły stron były renderowane przez JavaScript. Zostało to zrobione w sposób, który oznaczał, że tytuł meta HTML zawsze pokazywał nazwę marki, gdy JavaScript był wyłączony. A gdy klientem użytkownika nie jest Googlebot, renderuje tylko tytuł strony HTML. Zobacz dwa poniższe przykłady. Pierwsza pokazuje adres URL z wyłączoną obsługą JavaScript. Drugi to ten sam adres URL, ale z włączoną obsługą JavaScript.

Aby upewnić się, że metadane są zawsze poprawnie renderowane, należy uwzględnić je w nierenderowanej (JavaScript) wersji adresu URL.

Wniosek

Renderowania po stronie serwera nie można używać jako metody obcinania plików cookie do renderowania aplikacji jednostronicowych. Szczególna uwaga jest wymagana w przypadku podejść statycznych, w których po prostu podajesz migawkę. Jak widać na przykładzie naszego klienta, musisz upewnić się, że silnik SSR zawsze udostępnia aktualną wersję adresu URL, w przeciwnym razie Google nie będzie widzieć ani przechwytywać Twoich najnowszych artykułów, a Ty będziesz tracisz cenny ruch.

Przed ponownym uruchomieniem ze strony internetowej opartej na HTML do frameworka opartego na JavaScript, upewnij się, że włączone jest renderowanie po stronie serwera, które zawsze jest wyświetlane dynamicznie!

Jeśli masz problemy z JavaScriptem lub szukasz wsparcia w technicznej optymalizacji swojej witryny, umów się na niewiążące spotkanie z naszymi konsultantami Digital Strategies Group i dowiedz się, gdzie mogą Ci pomóc?

Umów się na spotkanie!