Vue.js i SEO: jak zoptymalizować strony reaktywne pod kątem wyszukiwarek i botów

Reaktywne frameworki JavaScript (takie jak React, Vue.js i Angular) są ostatnio modne i nic dziwnego, że są używane w coraz większej liczbie stron internetowych i aplikacji ze względu na ich elastyczność, modułowość i łatwość automatycznego testowania.

Te frameworki pozwalają osiągnąć nowe, wcześniej nie do pomyślenia rzeczy na stronie internetowej lub w aplikacji, ale jak radzą sobie pod względem SEO? Czy strony utworzone za pomocą tych frameworków są indeksowane przez Google? Ponieważ w przypadku tych frameworków całość — lub większość — renderowania strony jest wykonywana w JavaScript (a HTML pobierany przez boty jest w większości pusty), wydaje się, że nie można tego zrobić, jeśli chcesz, aby Twoje witryny były indeksowane w wyszukiwarek, a nawet ogólnie analizowanych przez boty.

W tym artykule opowiem głównie o Vue.js, ponieważ jest to framework, z którego korzystałem najczęściej i z którym mam bezpośrednie doświadczenie w indeksowaniu przez wyszukiwarki w dużych projektach, ale mogę założyć, że większość to, co omówię, dotyczy również innych frameworków.

Trochę tła problemu

Jak działa indeksowanie

Aby Twoja witryna została zaindeksowana przez Google, musi zostać zindeksowana przez Googlebota (automatyczne oprogramowanie indeksujące, które odwiedza Twoją witrynę i zapisuje zawartość stron w swoim indeksie) za pomocą linków na każdej stronie. Googlebot szuka również specjalnych plików XML mapy witryny w witrynach internetowych, aby znaleźć strony, do których mogą nie być prawidłowo połączone linki z Twojej witryny publicznej, oraz uzyskać dodatkowe informacje o tym, jak często zmieniają się strony w witrynie i kiedy były ostatnio zmieniane.

Trochę historii

Jeszcze kilka lat temu (przed 2009 r.) Google indeksowało zawartość HTML strony — wyłączając całą zawartość stworzoną przez JavaScript. Powszechnie wiadomo było, że ważne linki i treści nie powinny być pisane przez JavaScript, ponieważ nie będą indeksowane przez Google, a to może spowodować karę dla witryny, ponieważ Google może uznać ją za „fałszywą treść”, tak jakby właściciel witryny próbował aby pokazać użytkownikom coś innego niż to, co pokazano wyszukiwarkom i próbować oszukać te drugie.

Bardzo powszechną praktyką oszustów było umieszczanie wielu przyjaznych SEO treści w kodzie HTML i ukrywanie ich na przykład w JavaScript. Google zawsze ostrzegał przed taką praktyką:

„Udostępnianie Googlebotowi innych treści niż zwykły użytkownik jest uważane za maskowanie i byłoby niezgodne z naszymi wskazówkami dla webmasterów”.

Możesz zostać za to ukarany. W niektórych przypadkach możesz zostać ukarany za udostępnianie różnych treści różnym agentom użytkownika po stronie serwera, ale także za przełączanie treści za pomocą JavaScript po załadowaniu strony. Myślę, że to pokazuje nam, że Google od dłuższego czasu indeksuje witryny wykonujące JavaScript — przynajmniej w celu porównania końcowego kodu HTML witryny (po wykonaniu JavaScript) z surowym kodem HTML, który analizował pod kątem swoich indeksów. Jednak Googlebot nie wykonywał JavaScript przez cały czas, a Google nie używał treści generowanych przez JavaScript do celów indeksowania.

Następnie, biorąc pod uwagę zwiększone wykorzystanie AJAX do dostarczania dynamicznych treści na stronach internetowych, Google zaproponował „schemat indeksowania AJAX”, aby pomóc użytkownikom w indeksowaniu witryn opartych na AJAX. To było bardzo skomplikowane; w zasadzie wymagało to od witryny renderowania stron z dołączoną treścią AJAX. Na żądanie Google serwer dostarczał wersję strony z całą (lub większością) zawartością, która byłaby generowana dynamicznie przez JavaScript zawarty na stronie HTML — wstępnie renderowana jako migawka HTML zawartości. Ten proces polegający na tym, że rozwiązanie po stronie serwera dostarcza treści, które (do wszystkich innych celów) miały być generowane po stronie klienta, sugerował, że ci, którzy chcą mieć witrynę, która w dużym stopniu opiera się na JavaScript indeksowanym w Google, musieli przejść przez wiele kłopotów technicznych.

Na przykład, jeśli treść odczytywana przez AJAX pochodziła z zewnętrznej usługi sieciowej, konieczne było zduplikowanie tych samych wywołań usługi sieciowej po stronie serwera i wytworzenie po stronie serwera tego samego kodu HTML, który zostałby utworzony po stronie klienta przez JavaScript — a przynajmniej bardzo podobny. Było to bardzo skomplikowane, ponieważ przed pojawieniem się Node.js wymagało przynajmniej częściowego zduplikowania tej samej logiki renderowania w dwóch różnych językach programowania: JavaScript dla frontendu oraz PHP, Java, Python, Ruby i tak dalej. backend. Nazywa się to „ renderowaniem po stronie serwera ” i może prowadzić do piekła konserwacyjnego: jeśli dokonałeś ważnych zmian w sposobie renderowania treści w interfejsie użytkownika, musiałeś zduplikować te zmiany w zapleczu.

Jedyną alternatywą, aby uniknąć duplikowania logiki, było przeanalizowanie własnej witryny za pomocą przeglądarki wykonującej JavaScript, zapisanie wyników końcowych na serwerze i przekazanie ich Googlebotowi. Jest to podobne do tego, co obecnie nazywa się „ wstępnym renderowaniem ”.

Google (ze swoim schematem indeksowania AJAX) gwarantował również, że unikniesz kar ze względu na to, że w tym przypadku wyświetlałeś różne treści Googlebotowi i użytkownikowi. Jednak od 2015 r. Google odrzucił tę praktykę, publikując oficjalny wpis na blogu, w którym zarządcy witryn mówili:

„Dzisiaj, o ile nie blokujesz Googlebotowi indeksowania Twoich plików JavaScript lub CSS, generalnie jesteśmy w stanie renderować i rozumieć Twoje strony internetowe jak nowoczesne przeglądarki”.

To, co nam to powiedziało, nie było takie, że Googlebot nagle nabył zdolność wykonywania JavaScriptu podczas indeksowania stron internetowych, ponieważ wiemy, że robił to od bardzo dawna (przynajmniej po to, by sprawdzać fałszywe treści i oszustwa). Zamiast tego powiedział nam, że wynik wykonania JavaScript zostanie zindeksowany i wykorzystany w SERP.

Wydaje się to sugerować, że nie musimy się już martwić o udostępnianie Google renderowanego kodu HTML po stronie serwera. Jednak widzimy wszelkiego rodzaju narzędzia do renderowania po stronie serwera i renderowania wstępnego dostępne dla frameworków JavaScript, wydaje się, że tak nie jest. Ponadto w przypadku agencji SEO przy dużych projektach wstępne renderowanie wydaje się być uważane za obowiązkowe. Dlaczego?

W jaki sposób Google faktycznie indeksuje strony utworzone za pomocą Front-End Frameworks?

Eksperyment

Aby zobaczyć, co Google faktycznie indeksuje w witrynach, które zostały stworzone we front-endowym frameworku, zbudowałem mały eksperyment. Nie obejmuje wszystkich przypadków użycia, ale jest przynajmniej sposobem, aby dowiedzieć się więcej o zachowaniu Google. Zbudowałem małą witrynę internetową za pomocą Vue.js i różnie renderowałem różne części tekstu.

Zawartość strony została zaczerpnięta z opisu książki Infinite Jest autorstwa Davida Fostera Wallace'a w Infinite Jest Wiki ( dzięki wam! ). Do całej książki jest kilka tekstów wprowadzających oraz lista postaci z ich indywidualną biografią:

• Jakiś tekst w statycznym kodzie HTML, poza głównym kontenerem Vue.js;
• Część tekstu jest renderowana natychmiast przez Vue.js, ponieważ jest zawarta w zmiennych, które są już obecne w kodzie aplikacji: są one zdefiniowane w obiekcie data komponentu;
• #Niektóre teksty są renderowane przez Vue.js z obiektu data , ale z opóźnieniem 300 ms;
• Bios postaci pochodzą z zestawu pozostałych interfejsów API, które specjalnie zbudowałem przy użyciu Sandbox. Ponieważ zakładałem, że Google wykona kod strony i zatrzyma się po pewnym czasie, aby zrobić migawkę aktualnego stanu strony, ustawiłem każdą usługę sieciową tak, aby odpowiadała z przyrostowym opóźnieniem, pierwsza na 0ms, druga na 300ms, trzeci z 600ms i tak dalej do 2700ms.

Biografia każdego znaku jest skrócona i zawiera link do podstrony, która jest dostępna tylko przez Vue.js (adresy URL są generowane przez Vue.js za pomocą history API), ale nie po stronie serwera (jeśli wywołasz adres URL strony bezpośrednio, nie otrzymujesz odpowiedzi z serwera), aby sprawdzić, czy te również zostały zaindeksowane. Założyłem, że nie zostaną one zindeksowane, ponieważ nie są to prawidłowe linki renderujące po stronie serwera i nie ma możliwości, aby Google mógł bezpośrednio skierować użytkowników do tych linków. Ale chciałem tylko sprawdzić.

Opublikowałem tę małą witrynę testową na moich stronach Github i poprosiłem o indeksowanie — spójrz.

Wyniki

Wyniki eksperymentu (dotyczące strony głównej) są następujące:

• Treści, które już znajdują się w statycznej treści HTML, są indeksowane przez Google (co jest dość oczywiste);
• Treści generowane przez Vue w czasie rzeczywistym zawsze są indeksowane przez Google;
• Zawartość, która jest generowana przez Vue, ale renderowana po 300 ms, również jest indeksowana;
• Treści pochodzące z serwisu internetowego mogą z pewnym opóźnieniem zostać zindeksowane, ale nie zawsze. Sprawdziłem indeksowanie strony przez Google w różnych momentach i ostatnio wstawiona treść (po kilku sekundach) czasami była indeksowana, czasami nie. Treść, która jest renderowana dość szybko, przez większość czasu jest indeksowana, nawet jeśli pochodzi z asynchronicznego wywołania zewnętrznej usługi sieci Web. Zależy to od tego, czy Google ma budżet renderowania dla każdej strony i witryny, który zależy od wewnętrznych algorytmów i może się znacznie różnić w zależności od rankingu witryny i bieżącego stanu kolejki renderowania Googlebota. Nie możesz więc polegać na zawartości pochodzącej z zewnętrznych usług internetowych w celu zindeksowania;
• Podstrony (ponieważ nie są dostępne jako bezpośredni link) nie są indeksowane zgodnie z oczekiwaniami.

Co mówi nam ten eksperyment? Zasadniczo Google indeksuje treść generowaną dynamicznie, nawet jeśli pochodzi z zewnętrznej usługi internetowej, ale nie ma gwarancji, że treść zostanie zaindeksowana, jeśli „dotrze za późno”. Oprócz tego eksperymentu miałem podobne doświadczenia z innymi prawdziwymi, produkcyjnymi stronami internetowymi.

Pozycjonowanie konkurencyjne

Dobra, więc treść zostaje zindeksowana , ale ten eksperyment nie mówi nam: czy treść będzie miała konkurencyjny ranking? Czy Google woli witrynę ze statyczną treścią od witryny generowanej dynamicznie? Nie jest łatwo odpowiedzieć na to pytanie.

Z mojego doświadczenia mogę powiedzieć, że treści generowane dynamicznie mogą plasować się na najwyższych pozycjach SERPS-ów. Pracowałem nad stroną internetową dla nowego modelu dużej firmy samochodowej, uruchamiając nową stronę internetową z nową domeną trzeciego poziomu. Witryna została w pełni wygenerowana za pomocą Vue.js — z bardzo małą zawartością w statycznym HTML, poza tagami <title> i meta .

Witryna zaczęła pozycjonować się pod kątem drobnych wyszukiwań w ciągu pierwszych kilku dni po publikacji, a fragmenty tekstu w SERPach wskazywały słowa pochodzące bezpośrednio z treści dynamicznych.

W ciągu trzech miesięcy zajęła pierwsze miejsce w większości wyszukiwań związanych z tym modelem samochodu — co było stosunkowo łatwe, ponieważ była hostowana na oficjalnej domenie należącej do producenta samochodu, a domena była mocno powiązana z renomowanymi witrynami.

Ale biorąc pod uwagę fakt, że musieliśmy stawić czoła silnej opozycji ze strony firmy SEO, która kierowała projektem, uważam, że wynik był nadal znakomity.

Ze względu na napięte terminy i brak czasu na projekt zamierzaliśmy opublikować stronę bez wstępnego renderowania.

Animowany tekst

To, czego Google nie indeksuje, to mocno animowany tekst. Witryna jednej z firm, z którą współpracuję, Rabbit Hole Consulting, zawiera wiele animacji tekstu, które są wykonywane podczas przewijania przez użytkownika i wymagają podzielenia tekstu na kilka kawałków w różnych tagach.

Główne teksty na stronie głównej serwisu nie są przeznaczone do indeksowania w wyszukiwarkach, ponieważ nie są zoptymalizowane pod kątem SEO. Nie są zrobione z tech-mowy i nie używają słów kluczowych: mają jedynie towarzyszyć użytkownikowi w koncepcyjnej podróży po firmie. Tekst jest wstawiany dynamicznie, gdy użytkownik wchodzi do różnych sekcji strony głównej.

Żaden z tekstów w tych sekcjach witryny nie jest indeksowany przez Google. Aby Google pokazał coś znaczącego w SERPach, dodaliśmy trochę statycznego tekstu w stopce pod formularzem kontaktowym, a ta treść jest wyświetlana jako część zawartości strony w SERPach.

Tekst w stopce zostaje zindeksowany i wyświetlony w SERP-ach, mimo że nie jest od razu widoczny dla użytkowników, chyba że przewiną na dół strony i nie klikną przycisku „Pytania”, aby otworzyć formularz kontaktowy. Potwierdza to moją opinię, że treść jest indeksowana, nawet jeśli nie jest wyświetlana od razu użytkownikowi, o ile jest renderowana wkrótce do kodu HTML — w przeciwieństwie do renderowania na żądanie lub z dużym opóźnieniem.

A co z renderowaniem wstępnym?

Po co więc całe zamieszanie związane z prerenderowaniem — czy to po stronie serwera, czy w czasie kompilacji projektu? Czy to naprawdę konieczne? Chociaż niektóre frameworki, takie jak Nuxt, znacznie ułatwiają wykonanie, nadal nie jest to piknik, więc wybór, czy go skonfigurować, czy nie, nie jest łatwy.

Myślę, że nie jest to obowiązkowe . Jest to z pewnością wymagane, jeśli wiele treści, które chcesz zindeksować przez Google, pochodzi z zewnętrznej usługi sieciowej i nie jest od razu dostępna w czasie renderowania, a w niektórych niefortunnych przypadkach może w ogóle nie być dostępna z powodu np. , przestój usługi sieciowej. Jeśli podczas odwiedzin Googlebota część Twoich treści pojawia się zbyt wolno, może nie zostać zindeksowana . Jeśli Googlebot zindeksuje Twoją stronę dokładnie w momencie, w którym przeprowadzasz konserwację usług internetowych, może w ogóle nie zindeksować żadnej zawartości dynamicznej.

Ponadto nie mam dowodu na różnice w rankingu między treścią statyczną a treścią generowaną dynamicznie. To może wymagać kolejnego eksperymentu. Myślę, że jest bardzo prawdopodobne, że jeśli treść pochodzi z zewnętrznego serwisu internetowego i nie ładuje się od razu, może to mieć wpływ na postrzeganie przez Google wydajności Twojej witryny, co jest bardzo ważnym czynnikiem w rankingu.

Zalecana literatura : Jak projektowanie stron mobilnych wpływa na wyszukiwanie lokalne (i co z tym zrobić)

Inne rozważania

Zgodność

Do niedawna Googlebot używał dość starej wersji Chromium (projektu open-source, na którym oparty jest Google Chrome), a mianowicie wersji 41. Oznaczało to, że niektóre najnowsze funkcje JavaScript lub CSS nie mogły być poprawnie renderowane przez Google (np. IntersectionObserver, Składnia ES6 itd.).

Google ogłosił niedawno, że obecnie korzysta z najnowszej wersji Chromium (74, w momencie pisania tego tekstu) w Googlebot i że wersja będzie regularnie aktualizowana. Fakt, że Google używał Chromium 41, mógł mieć duże implikacje dla stron, które zdecydowały się zlekceważyć kompatybilność z IE11 i innymi starymi przeglądarkami.

Tutaj możesz zobaczyć porównanie obsługi funkcji Chromium 41 i Chromium 74, jednak jeśli Twoja witryna już uzupełniała brakujące funkcje, aby zachować zgodność ze starszymi przeglądarkami, nie powinno być problemu.

Zawsze używaj wypełniaczy , ponieważ nigdy nie wiesz, która przeglądarka nie obsługuje funkcji, które Twoim zdaniem są powszechne. Na przykład Safari nie obsługiwała nowej, ważnej i bardzo przydatnej nowej funkcji, takiej jak IntersectionObserver, aż do wersji 12.1, która ukazała się w marcu 2019 roku.

Błędy JavaScript

Jeśli polegasz na tym, że Googlebot wykonuje kod JavaScript w celu renderowania istotnych treści, za wszelką cenę należy unikać poważnych błędów JavaScript, które mogą uniemożliwić renderowanie treści. Chociaż boty mogą analizować i indeksować kod HTML, który nie jest całkowicie poprawny (chociaż zawsze lepiej jest mieć poprawny kod HTML w dowolnej witrynie!), jeśli wystąpi błąd JavaScript, który uniemożliwia załadowanie niektórych treści , Google nie ma możliwości zindeksowania tę treść.

W każdym razie, jeśli polegasz na JavaScript, aby renderować istotne treści użytkownikom końcowym, prawdopodobnie masz już rozbudowane testy jednostkowe, które sprawdzają, czy nie występują jakiekolwiek błędy blokujące. Należy jednak pamiętać, że błędy Javascript mogą wynikać z nieprzewidywalnych scenariuszy, na przykład w przypadku niewłaściwej obsługi błędów w odpowiedziach API.

Lepiej jest mieć jakieś oprogramowanie do sprawdzania błędów w czasie rzeczywistym (takie jak Sentry lub LogRocket), które będzie ostrzegać o wszelkich błędach skrajnych, których możesz nie wychwycić podczas testowania jednostkowego lub ręcznego. Zwiększa to złożoność polegania na JavaScript w treści SEO.

Inne wyszukiwarki

Inne wyszukiwarki nie działają tak dobrze jak Google z dynamiczną zawartością. Wydaje się, że Bing w ogóle nie indeksuje zawartości dynamicznej, podobnie jak DuckDuckGo czy Baidu. Prawdopodobnie tym wyszukiwarkom brakuje zasobów i mocy obliczeniowej, które Google ma do zaoferowania.

Parsowanie strony za pomocą przeglądarki bezgłowej i wykonywanie przez kilka sekund kodu JavaScript w celu przeanalizowania wyrenderowanej treści jest z pewnością bardziej zasobożerne niż samo czytanie zwykłego kodu HTML. A może te wyszukiwarki z innych powodów zdecydowały się nie skanować zawartości dynamicznej. Niezależnie od przyczyny, jeśli Twój projekt musi obsługiwać którąkolwiek z tych wyszukiwarek, musisz skonfigurować wstępne renderowanie.

Uwaga : aby uzyskać więcej informacji na temat możliwości renderowania innych wyszukiwarek, zapoznaj się z tym artykułem autorstwa Bartosza Góralewicza. Jest trochę stary, ale z mojego doświadczenia wynika, że ​​nadal jest aktualny.

Inne boty

Pamiętaj, że Twoja witryna będzie odwiedzana również przez inne boty. Najważniejszymi przykładami są Twitter, Facebook i inne boty mediów społecznościowych, które muszą pobrać metainformacje o Twoich stronach , aby wyświetlić podgląd Twojej strony, gdy jest ona podlinkowana przez swoich użytkowników. Te boty nie będą indeksować zawartości dynamicznej i pokażą tylko metainformacje, które znajdą w statycznym kodzie HTML. To prowadzi nas do kolejnego rozważania.

Podstrony

Jeśli Twoja witryna jest tak zwaną „witryną One Page”, a cała odpowiednia treść znajduje się w jednym głównym kodzie HTML, nie będziesz miał problemu z zaindeksowaniem tej treści przez Google. Jeśli jednak chcesz, aby Google zaindeksował i wyświetlił dowolną podrzędną stronę w witrynie, nadal będziesz musiał utworzyć statyczny kod HTML dla każdej z nich — nawet jeśli polegasz na swoim frameworku JavaScript, aby sprawdzić bieżący adres URL i dostarczyć odpowiednią treść do umieszczenia na tej stronie. W tym przypadku radzę utworzyć strony po stronie serwera (lub statyczne), które zawierają przynajmniej poprawny tag title i meta opis/informacje.

Wnioski

Wnioski, do których doszedłem podczas badania tego artykułu, są następujące:

1. Jeśli kierujesz reklamy tylko na Google, użycie wstępnego renderowania w celu pełnego zindeksowania witryny nie jest obowiązkowe , jednak:
2. Nie należy polegać na usługach internetowych innych firm w przypadku treści, które muszą być indeksowane, zwłaszcza jeśli nie odpowiadają one szybko.
3. Treść, którą wstawiasz do kodu HTML natychmiast za pomocą renderowania Vue.js, jest indeksowana, ale nie powinieneś używać animowanego tekstu ani tekstu, który jest wstawiany do DOM po czynnościach użytkownika, takich jak przewijanie itp.
4. Upewnij się, że testujesz pod kątem błędów JavaScript, ponieważ mogą one spowodować, że całe strony/sekcje nie będą indeksowane lub Twoja witryna w ogóle nie zostanie zindeksowana.
5. Jeśli Twoja witryna ma wiele stron , nadal musisz mieć pewną logikę, aby tworzyć strony, które, korzystając z tego samego systemu renderowania frontonu, co strona główna, mogą być indeksowane przez Google jako indywidualne adresy URL.
6. Jeśli potrzebujesz różnych opisów i obrazów podglądu dla mediów społecznościowych na różnych stronach, musisz to również rozwiązać, po stronie serwera lub kompilując strony statyczne dla każdego adresu URL.
7. Jeśli chcesz, aby Twoja witryna działała w wyszukiwarkach innych niż Google , na pewno będziesz potrzebować jakiegoś wstępnego renderowania.