Czy możesz teraz zaufać Google, aby indeksować witryny Ajax?

Streszczenie:

14 października Google ogłosił, że nie zalecają już programu Crawling Ajax, który opublikowali w 2009 roku. Rodzi to pytanie, czy możesz zaufać Google, aby pomyślnie się czołgać i indeksować witrynę Ajax.

Kluczowe punkty:

1. Projektanci stron internetowych i inżynierowie wolą korzystać z AJAX do budowania aplikacji jednokierunkowych (SPA) z ramami takimi jak Angular i React.
2. Ajax pozwala na płynne, interaktywne aplikacje internetowe, które działają jak aplikacje komputerowe.
3. W SPA zawartość HTML nie jest początkowo ładowana do przeglądarki. Zamiast tego Ajax używa JavaScript do dynamicznej komunikacji z serwerem WWW i renderowania HTML.
4. Google był w stanie zawołać niektóre treści JavaScript, ale SEO dla Pure Spa Ajax Sites stanowi wyzwania.
5. W 2009 r. Google wprowadził rozwiązanie AJAX Crawleble, które polegało na użyciu adresów URL „Uciekanych fragmentów” lub meta tagów, aby poinformować Google, aby pobrała wcześniej renderowaną wersję strony z pełnym HTML.
6. Pomimo zdolności Google do czołgania się JavaScript, wiele witryn, które pozwoliły Google czołgać się na witrynach spa Ajax, doświadczyło ograniczonego sukcesu.
7. Niektóre strony odnotowały nawet znaczny spadek ruchu organicznego po przejściu na wdrożenie Ajax.
8. 14 października Google ogłosił, że nie zalecają już swojej starej propozycji Crawling Ajax, ale nadal ją popierają.
9. Istnieje nieporozumienie, że Google może teraz bez problemu pełzać witryny Ajax, ale ważne jest, aby zauważyć, że stwierdzają, że są one „ogólnie zdolne” do renderowania i rozumienia stron internetowych, takich jak współczesne przeglądarki.
10. Ważne jest, aby wziąć pod uwagę język używany przez Google i nie tylko polegać na założeniu, że mogą w pełni zrozumieć strony Ajax.

Pytania:

1. Czy Google z powodzeniem indeksuje witryny AJAX?
2. Jaki jest cel używania Ajax w projektowaniu stron internetowych?
3. Co się stanie, gdy spa jest początkowo ładowana?
4. Jakie wyzwania mają miejsca Ajax w historycznie w odniesieniu do SEO?
5. Jakie były metody zaproponowane przez Google w 2009 roku, aby zawołać Ajax?
6. Umożliwiło Google na czołganie witryn AJAX spowodował pomyślne indeksowanie wielu stron internetowych?
7. Jaki negatywny wpływ doświadczył niektórych stron po wdrożeniu AJAX?
8. Co Google ogłosił 14 października w sprawie rekomendacji Crawling Ajax?
9. Czy jest dokładne przekonanie, że Google może teraz skutecznie czołgać się witrynami Ajax?
10. Dlaczego ważne jest rozważenie języka Google w ich ogłoszeniu?
11. Czy możesz zaufać Google, aby w pełni zrozumieć i pełnić swoją witrynę Ajax?
12. Jak projektanci stron internetowych i inżynierowie wykorzystują AJAX w budowaniu aplikacji internetowych?
13. Jaka jest rola JavaScript w procesie renderowania witryny AJAX?
14. Dlaczego niektóre strony internetowe uciekły się do wcześniej renderowanych migawek HTML jako rozwiązania?
15. Jakie nieporozumienie istnieje na temat zdolności Google do czołgania się witryn Ajax?

Odpowiedzi:

1. Google może indeksować witryny Ajax, ale sukces indeksowania jest różny i nie jest gwarantowany.
2. Ajax jest używany w projektowaniu stron internetowych do tworzenia aplikacji jednokierunkowej (SPA), które zapewniają płynną i interaktywną wrażenia użytkownika podobne do dedykowanych aplikacji komputerowych.
3. Gdy spa jest początkowo ładowana, zawartość HTML nie jest pobierana i renderowana. Zamiast tego przeglądarka opiera się na JavaScript w celu komunikacji z serwerem i dynamicznie renderowanie HTML.
4. Historycznie witryny Ajax stały przed wyzwaniami SEO, ponieważ zdolność Google do czołgania się treści JavaScript była ograniczona. Doprowadziło to do trudności w skutecznym indeksowaniu i rankingu.
5. W 2009. Jeden wiązał się z użyciem adresów URL „Ucieknie fragmentu”, co spowodowało brzydkie adresy URL. Druga metoda zastosowana a Meta = „Fragment” Tag na stronie, aby poinstruować Google, aby pobrać wersję wstępnie renderowaną z pełnym HTML.
6. Umożliwienie Google na czołowanie witryn AJAX nie zawsze zaowocowało pomyślnym indeksowaniem wielu stron internetowych. Niektóre witryny widziały tylko część ich stron w pełni renderowanych i indeksowanych, podczas gdy inne doświadczyły znacznego spadku ruchu organicznego.
7. Po wdrożeniu AJAX niektóre strony internetowe odnotowały negatywny wpływ na ich ruch organiczny i musiały odzyskać się po spadku odwiedzających.
8. 14 października Google ogłosił, że nie zalecają już swojej starej propozycji Crawling Ajax, ale nadal ją wspierają. Oznacza to, że nie sugerują aktywnie jego użycia, ale nadal uznają jego funkcjonalność.
9. Nie jest dokładne założenie, że Google może teraz skutecznie indeksować witryny AJAX. Chociaż stwierdzają, że są „ogólnie zdolne” do renderowania i rozumienia stron internetowych, takich jak współczesne przeglądarki, konieczne jest rozważenie używanego języka, a nie wyłącznie na tym stwierdzeniu.
10. Ważne jest, aby rozważyć język Google w ich ogłoszeniu, ponieważ nie zapewniają one gwarancji bezproblemowej indeksowania witryn Ajax. Wyrażenie „ogólnie zdolne” implikuje potencjał ograniczeń i wyzwań w pełnym zrozumieniu i czołganiu stron Ajax.
11. Ufanie Google do pełnego zrozumienia i czołgania się witryny AJAX nie jest wskazane bez dalszych testów i monitorowania. Sukces indeksowania może się różnić i kluczowe jest rozważenie alternatywnych rozwiązań, takich jak wstępne migawki HTML.
12. Projektanci stron internetowych i inżynierowie używają AJAX do budowania spa z ramami takimi jak Angular i React, umożliwiając opracowanie aplikacji internetowych, które oferują interaktywne i płynne wrażenia użytkownika podobne do dedykowanych aplikacji stacjonarnych.
13. JavaScript odgrywa znaczącą rolę w procesie renderowania witryny AJAX. Dynamicznie komunikuje się z serwerem WWW w celu tworzenia i renderowania zawartości HTML dla użytkownika do interakcji.
14. Strony internetowe uciekały się do przedstawienia migawek HTML jako rozwiązania, ponieważ niektóre frameworki Ajax, takie jak Angular, nie obsługują jeszcze renderowania po stronie serwera. Wstępne renderowanie pozwala na tworzenie migawek HTML, które są obsługiwane w wyszukiwarkach, zapewniając pełne indeksowanie i widoczność.
15. Istnieje nieporozumienie, że zdolność Google do czołgania się witryn Ajax jest teraz bezbłędna. Należy jednak zauważyć, że ich zdolność do zrozumienia i pełzania treści JavaScript uległa poprawie, ale nadal mogą istnieć wyzwania i ograniczenia.

Czy możesz teraz zaufać Google, aby indeksować witryny Ajax

A potem, 14 października, Google powiedział:

Czy Google Crawl Ajax treść? [Zamknięte]

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby koncentrowało się na jednym problemu tylko edytując ten post.

Zamknięte 7 lat temu .

Na stronie głównej mojej witryny używam funkcji AJAX JQuery, aby wyciągnąć listę najnowszych czynności użytkowników. Ostatnie działanie jest wyświetlane na stronie, a każda wiersz ostatniego działania zawiera link do profilu użytkownika użytkownika, który wykonał czynność. Czy Google faktycznie wywoła wywołanie AJAX, aby wyciągnąć te informacje i użyć ich do obliczania trafności / przepływu soku z linkiem? Mam nadzieję, że to nie Ponieważ strony profilu użytkownika nie są bardzo warte indeksu Google i nie chcę wszystkich tych linków do stron profilu użytkownika rozcieńczającego sok z linków mojej strony głównej od innych ważniejszych linków.

Czy możesz teraz zaufać Google, aby indeksować witryny Ajax?

14 października Google ogłosił, że nie zaleca już programu Crawling Ajax, który opublikowali w 2009 roku. Felietonista Mark Munroe zanurza się w pytaniu, czy oznacza to, że możesz teraz liczyć na Google, aby pomyślnie się czołgać i indeksować witrynę AJAX.

Mark Munroe 13 listopada 2015 o 9:18 | Czas czytania: 7 minut

Projektanci stron internetowych i inżynierowie uwielbiają ajax do budowania aplikacji jedno stronicowych (SPA) z popularnymi ramami, takimi jak Angular i React. Implementacje czystej AJAX mogą zapewnić płynną, interaktywną aplikację internetową, która działa bardziej jak dedykowana aplikacja komputerowa.

Z ogólnie spa zawartość HTML nie jest ładowana do przeglądarki na początkowym pobraniu strony internetowej. Ajax używa JavaScript do dynamicznej komunikacji z serwerem WWW, aby utworzyć HTML do renderowania strony i interakcji z użytkownikiem. (Istnieje technika o nazwie “Renderowanie po stronie serwera” gdzie JavaScript jest faktycznie wykonywany na serwerze, a żądanie strony jest zwracane z renderowanym HTML. Jednak takie podejście nie jest jeszcze obsługiwane we wszystkich ramach Spa i zwiększa złożoność rozwoju.)

Jednym z problemów z witrynami Spa Ajax był SEO. Google od jakiegoś czasu czołga się trochę treści JavaScript. W rzeczywistości ta ostatnia seria testów potwierdziła Google’S zdolność do czołgania się linków, metadanych i treści wstawionych za pośrednictwem JavaScript. Jednak strony internetowe wykorzystujące Pure Spa Ajax Frameworks historycznie doświadczyły wyzwań z SEO.

W 2009 roku Google wymyśliło rozwiązanie, aby Ajax będzie się czołgać. Ta metoda albo tworzy “Uniknął fragment” URL (brzydkie adresy URL) lub niedawno, czyści adresy URL z Meta =”fragment” tag na stronie.

Udnikowy URL fragmentu lub meta Fragment Tag instruuje Google, aby wyjdzie i otrzymał wstępnie renderowaną wersję strony, która wykonała całą JavaScript i ma pełny HTML, który Google może analizować i indeksować. W tej metodzie pająk obsługuje zupełnie inny kod źródłowy (HTML vs. JavaScript).

Z głowie, że Google Crawls JavaScript, wiele witryn postanowiło pozwolić Google indeksować witryny spa Ajax. Ogólnie rzecz biorąc, nie odniosło to sukcesu. W ubiegłym roku skonsultowałem się z kilkoma stronami internetowymi z wdrożeniem kątowym Ajax. Google odniósł pewien sukces i około 30 procent stron w Google’S Cache zostały w pełni renderowane. Pozostałe 70 procent było puste.

Popularna strona z jedzeniem przełączona na Angular, wierząc, że Google może go czołgać. Stracili około 70 procent swojego ruchu organicznego i wciąż wracają do zdrowia po tej klęsce. Ostatecznie obie strony przeszły do ​​przedwczesnych migawek HTML, zalecanego rozwiązania Crawling Ajax w tym czasie.

A potem, 14 października, Google powiedział:

Nie zalecamy już propozycji Crawling Ajax, którą złożyliśmy w 2009 roku.

Zauważ, że nadal są wspierający ich stara propozycja. (Pojawiły się artykuły ogłaszające, że już go nie wspierają, ale to nieprawda – po prostu nie zalecają już tego podejścia.)

Rozpuszczając starą zalecenie, wydawali się mówić, że mogą teraz czołgać się Ajax.

Potem, zaledwie tydzień po ogłoszeniu, klient z nowo uruchomioną witryną poprosił mnie o sprawdzenie. To była strona kątowa, ponownie wdrożenie spa Ajax.

Po zbadaniu Google’S INDEKS i pamięć podręczna, widzieliśmy niektóre częściowo indeksowane strony bez czołgania się wszystkich treści. Powtórzyłem moją wcześniejszą zalecenie używania migawek HTML lub progresywnego ulepszenia.

Ta strona została zbudowana z Angular, która nie obsługuje jeszcze renderowania po stronie serwera (ponownie w tym przypadku serwer początkowo renderuje stronę do obsługi dokumentu HTML), więc progresywne ulepszenie byłoby trudne do obsługi, a migawki HTML są dla nich najlepszym rozwiązaniem dla nich.

Odpowiedziała, “Ale dlaczego? Wszystko, co czytam, mówi mi, Google może czołgać się Ajax.”

Czy mogą? Pozwalać’S przyjrzyj się głębiej na nową zalecenie w odniesieniu do AJAX.

Google’S nowe zalecenia Ajax

Wyjaśniając, dlaczego deprecjonują stare rekomendację, mówią (podkreślenie kopalni):

Jesteśmy ogólnie zdolne renderować i zrozumieć swoje strony internetowe, takie jak współczesne przeglądarki.

Wiele osób może szybko stwierdzić, że mogą teraz bez problemu czołgać się Ajax. Ale spójrz na język: “ogólnie zdolne”? Czy postawiłbyś przychody z działalności, jaka jest Google “ogólnie zdolne” Aby zrozumieć twoją stronę?

Czy to możliwe, że po prostu wybieram semantykę? Pozwalać’s zbadaj dalej ogłoszenie. Później po ich ogłoszeniu stwierdzają w odniesieniu do Ajax:

Ponieważ założenia dla naszej propozycji w 2009 r. Nie są już ważne, zalecamy przestrzeganie zasad progresywnego ulepszenia.

Nie mają’Nie przeliteruj tego w ogłoszeniu, ale polecając progresywne ulepszenie (które ładuje trochę HTML dla przeglądarków’T wspierają JavaScript), wydaje się, że są domyślnie mówienie, “Przywdziewać’T licz na nas, czołgając twoje JavaScript.” Po co polecić tę metodę, jeśli rzeczywiście Google może konsekwentnie czołgać się witrynami Ajax?

Martwiłem się, że być może przeanalizuję Google’słowa, ale potem…

John Mueller potwierdza, że ​​Google nadal ma problemy z Ajax

27 października (niecałe dwa tygodnie po ogłoszeniu Google) John Mueller, w swoim hangoutie Webmaster Central, potwierdził, że Google rzeczywiście ma problemy z Ajax.

Możesz obejrzeć wymianę około 1:08:00 na wideo, gdzie było pytanie dotyczące konkretnej implementacji kątowej:

Nadal mają problemy z renderowaniem i z czasem spodziewają się poprawy. John zaleca niektóre działania, aby pomóc w debugowaniu problemów.

Ostatecznie zalecił użycie migawek HTML, dopóki Google nie poprawi się w AJAX (tak, metoda, która została oficjalnie przestarzała).

Więc co robić?

• Progresywne ulepszanie. Renderowanie po stronie serwera byłoby wymagane do progresywnego ulepszenia i nie jest jeszcze obsługiwane przez Angular. Jednak nadchodzące Angular 2.0 będzie obsługiwać renderowanie po stronie serwera. React w rzeczywistości obsługuje renderowanie po stronie serwera. Jest to jednak więcej pracy niż tylko tworzenie migawek HTML. Musisz upewnić się, że renderujesz wszelkie wymagane linki, aby Google mógł się czołgać i indeksować dodatkowe treści, które są ładowane na stronę. Niemniej jednak w przypadku witryn korzystających z frameworka Ajax, byłoby to moje zalecane podejście. (I oczywiście to Google’s Zalecane podejście.)
• Wcześniejsze migawki HTML. Znowu Don’nie zdezorientuj, jeśli słyszałeś lub czytałeś, że Google nie obsługuje już tej metody. Będą nadal wspierać go w dającej się przewidzieć przyszłości. Po prostu już tego nie polecają. Ta metoda działa; Jednak pisanie kodu do przedmuchu i obsługi migawek nie jest trywialne. Dobra wiadomość jest taka, że ​​istnieje kilku sprzedawców, takich jak Prerender.IO, kto wykonuje dla ciebie pracę po stosunkowo niskim koszcie. To prawdopodobnie najprostsze podejście. Ta metoda nie jest idealna. Obsługując inny kod źródłowy do pełzania vs. przeglądarki (HTML vs. JavaScript) może być problematyczne. Można to uznać za technikę maskowania i niekoniecznie jest oczywiste, jakie boty są podawane. To’jest ważne dla monitorowania Google’S pamięć podręczna, aby upewnić się, że nie otrzymują niewłaściwej strony. Niemniej jednak, jeśli używasz platformy, która nie obsługuje renderowania po stronie serwera, może to być twoje jedyne rozwiązanie.

Lepiej dmuchać na zimne

Nawet gdybym widział dowody, że Google konsekwentnie pełzał witryny Ajax, nadal byłbym ostrożny. Pełne renderowanie strony zajmuje znacznie więcej zasobów i znacznie więcej czasu.

Co stanie się z stronami z setkami tysięcy lub milionów stron? Jak wpłynie to na budżet pełzania? Czy wskaźnik pełzania pozostanie spójny?

Przed poleceniem tego podejścia i’D raczej poczekaj i zobacz mocne dowody na to, że Google może i konsekwentnie czołgają się duże, czyste aplikacje jedno stronicowe Ajax bez negatywnego wpływu na szybkość pełzania, indeksowanie i rankingi. Podziel się własnymi doświadczeniami.

Opinie wyrażone w tym artykule to opinie autora gościa i niekoniecznie w wyszukiwarkach. Autorzy pracowników są wymienione tutaj.

Jak JavaScript i Ajax wpływają na indeksowanie w Google?

Z czasem Google znacznie poprawił swoje Indeksowanie JavaScript i Ajax. Na początku to nie’t indeksuj wszystko lub podążał za dowolnymi linkami pojawiającymi się w zawartości załadowanej przez te frameworki. Ale stopniowo zaczął indeksować niektóre implementacje i poprawić swoje możliwości. W dzisiejszych czasach może indeksować wiele różnych implementacji, i podążaj za załadowanymi linkami Ajax Lub API Fetch. Niemniej jednak, Nadal będą przypadki, w których może tego nie zrobić.

Aby przeanalizować przypadki, w których Google może nie indeksować naszej witryny, najpierw musimy zrozumieć koncepcję Renderowanie po stronie klienta (CSR). To implikuje HTML jest pomalowany po stronie klienta JavaScript, Zwykle używa Ajax w nadmiarze. Pierwotnie strony internetowe zawsze malowały po stronie serwera HTML (Renderowanie po stronie serwera lub SSR), ale od jakiegoś czasu, CSR stał się popularny, wraz z pojawieniem się ram JavaScript, takich jak Angular, React i Vue. Jednakże, CSR negatywnie wpływa na indeksowanie, Wydajność na stronie internetowej, a zatem SEO.

Jak my’ve już wyjaśniono wcześniej, Aby zapewnić indeksowanie we wszystkich wyszukiwarkach i sytuacjach, Oprócz osiągnięcia dobrej wydajności, Najlepszym rozwiązaniem jest użycie uniwersalnej struktury, Podobnie jak w przypadku tych środków, kończy się czymś, co nazywa się Renderowanie hybrydowe. Składa się z Malowanie strony internetowej na serwerze przy pierwszym ładowaniu, a następnie na kliencie przez JavaScript i Ajax, gdy nawigacja przechodzi do następujących linków. Chociaż w rzeczywistości istnieje więcej sytuacji, w których stosowanie terminu renderowania hybrydowego jest również prawidłowe.

Czasami firma deweloperska korzysta z CSR i nie’T zaoferuj nam opcję korzystania z uniwersalnej struktury. Ten Rozwój stron internetowych oparty na CSR wpędzi nas w kłopoty, w większym lub mniejszym stopniu, w zależności od Crawlera i jego algorytmów rankingowych. W tym poście analizujemy Jakie problemy z Google’S Crawler są i jak je rozwiązać.

Problemy CSR podczas początkowego obciążenia strony

Najpierw przeanalizujemy problemy z indeksowaniem Jak tylko wejdziemy do adresu URL poza witryną, a gdy HTML jest renderowany po stronie klienta z JavaScript.

Problemy w wyniku powolnego renderowania

Google’S Proces indeksowania przechodzi następujące kroki:

1. Pełzanie: GoogleBot żąda adresu URL na serwerze.
2. Pierwsza fala indeksowania: Natychmiast indeksuje zawartość pomalowana na serwerze i otrzymuje nowe linki do czołgania się.
3. Generuje pomalowaną przez HTML stronę klienta, uruchamiając JavaScript. Proces ten jest kosztowny obliczeniowo (można to zrobić w danym momencie lub trwać nawet kilka dni, a nawet czekać na uzyskanie niezbędnych zasobów).
4. Druga fala indeksowania: W przypadku pomalowanej przez HTML po stronie klienta pozostała treść jest indeksowana i uzyskuje się nowe linki do czołgowania się.

Oprócz tego Strony mogą potrwać dłużej, aby w pełni indeksować, opóźniając indeksowanie kolejnych stron powiązanych z nich, jeśli renderowanie strony jest powolne, GoogleBot’S Renderer może pozostawić niepomalowane części. My’VE testowało to za pomocą opcji “Pobierz jako Google” dostarczone przez Google Search Console, i generowany przez niego zrzut ekranu’T pomaluj wszystko, co trwa dłużej niż 5 sekund. Jednak generuje HTML, który trwa dłużej niż te 5 sekund. Aby zrozumieć, dlaczego tak się dzieje, musimy o tym pamiętać Konsola wyszukiwania Google’S Renderer najpierw buduje HTML z JavaScript z GoogleBot’renderer, a następnie maluje stronę’Pikselki. Pierwszym zadaniem jest to, które należy wziąć pod uwagę do indeksowania, do którego odnosimy się do terminu CSR. W konsoli wyszukiwania Google możemy zobaczyć HTML wygenerowane podczas pierwszej fali indeksowania, a nie ta wygenerowana przez GoogleBot’renderer.

W konsoli wyszukiwania Google nie widzimy HTML namalowanego przez JavaScript, uruchomiony przez GoogleBot �� i używany w ostatniej fazie indeksowania. Aby to zrobić, musimy użyć tego narzędzia: https: // wyszukiwanie.Google.com/test/przyjazny dla urządzeń mobilnych �� kliknij, aby tweetować

W testach my’VE przeprowadziło się, gdy renderowanie HTML trwało ponad 19 sekund’Nie indeksuj wszystkiego. Chociaż jest to długi czas, w niektórych przypadkach można go przekroczyć, zwłaszcza jeśli intensywnie używamy Ajax, aw takich przypadkach Google’Sndener, podobnie jak każdy renderer, naprawdę musi czekać na następujące kroki:

1. Html jest pobierany i przetwarzany Aby żądać połączonych plików i utworzenie DOM.
2. CSS jest pobierany i przetwarzany, Aby żądać połączonych plików i utworzyć CSSOM.
3. JavaScript jest pobrany, skompilowane i uruchom, aby uruchomić żądania AJAX (y).
4. Żądanie Ajax jest przenoszone na kolejkę żądania, Czekam na odpowiedź, wraz z innymi żądanymi plikami.
5. Żądanie Ajax jest uruchamiany i musi podróżować przez sieć na serwer.
6. Serwer odpowiada na żądania za pośrednictwem sieci, a wreszcie, Musimy poczekać, aż JavaScript uruchomi się, aby pomalować treść strony’S szablon html.

W tym czasie żądanie i czas pobierania procesu zależą od sieci i serwera. Ponadto, GoogleBot używa tylko HTTP/1.1, który jest wolniejszy niż HTTP/2, ponieważ żądania są rozpatrywane jeden po drugim i nie wszystkie jednocześnie. To’s konieczne, aby zarówno klient, jak i serwer zezwolili na użycie HTTP/2, dlatego GoogleBot będzie używał tylko HTTP/1.1, nawet jeśli nasz serwer pozwala HTTP/2. Podsumowując, oznacza to, że GoogleBot czeka na każde żądanie zakończenia, aby uruchomić następne i to’możliwe, że wygrał’T spróbuj równolegle wymyślać niektóre żądania, otwierając różne połączenia, tak jak robią to przeglądarki’Nie wiem dokładnie, jak to robi). Dlatego jesteśmy w sytuacji, w której Możemy przekroczyć te 19 sekund, które oszacowaliśmy wcześniej.

Wyobraź sobie na przykład, że z obrazami, żądaniami CSS, JavaScript i Ajax, uruchamiano ponad 200 żądań, z których każde zajmuje 100 ms. Jeśli prośby Ajax zostaną wysłane na odwrót kolejki, my’Prawdopodobnie przekraczać wymagany czas, aby ich treść była indeksowana.

Z drugiej strony, ze względu na te problemy z wydajnością CSR, Otrzymamy gorszy znak dla wskaźnika FCP (First Contentful Paint) w Pagespeed pod względem renderowania i jego WPO, w wyniku czego gorsze rankingi.

Problemy z indeksowaniem:

Podczas indeksowania treści pomalowanej po stronie klienta, GoogleBot może napotykać następujące problemy, które zapobiegną indeksowaniu html generowanego przez JavaScript:

• Używają Wersja JavaScript Crawler nie’t rozpoznaj.
• Używają API JavaScript Nie rozpoznane przez GoogleBot (obecnie wiemy, że gniazda internetowe, WebGL, WebVR, indexedDB i WebSQL nie są obsługiwane – więcej informacji na stronie https: // programistów.Google.com/Search/Docs/przewodniki/rendering).
• Pliki JavaScript są blokowane przez roboty.tekst.
• Pliki JavaScript są obsługiwane za pośrednictwem HTTP, podczas gdy strona internetowa używa HTTPS.
• Istnieje JavaScript błędy.
• Jeśli wniosek o wniosek zgoda użytkownika zrobić coś, a od tego zależy od renderowania głównej treści, wygrał’nie jest pomalowany, ponieważ Googlebot zaprzecza jakiejkolwiek pozwoleniu’s domyślnie żądany.

Aby dowiedzieć się, czy cierpimy na którykolwiek z tych problemów, powinniśmy korzystać z Google’S Test przyjazny mobilnej. Pokaże nam zrzut ekranu, w jaki sposób strona jest malowana na ekranie, podobnie jak Google Search Console, ale także pokazuje nam Kod HTML generowany przez renderer (jak wcześniej wspomniano), Rejestry dziennika błędów w kodzie JavaScript, I JavaScript Funkcje Renderer nie może jeszcze interpretować. Powinniśmy użyć tego narzędzia do testowania wszystkich adresów URL, które są reprezentatywne dla każdego szablonu strony na naszej stronie internetowej, aby upewnić się, że witryna jest indeksowana.

Musimy pamiętać o tym w Html Generowany przez poprzednie narzędzie, wszystko metadane (w tym kanoniczny adres URL) zostanie zignorowany przez GoogleBot, ponieważ bierze pod uwagę informacje tylko wtedy’s namalowany na serwerze.

Problemy CSR w odniesieniu do nawigacji na następnej stronie

Teraz pozwól’S zobacz, co się stanie, gdy używamy linku do nawigacji, kiedy’ponownie na stronie internetowej, a HTML jest pomalowany po stronie klienta.

Problemy z indeksowaniem

W przeciwieństwie do CSR podczas początkowego obciążenia, Nawigacja na następną stronę Przełączając główną zawartość za pośrednictwem JavaScript jest szybszy niż SSR. Ale my’LL mają problemy z indeksowaniem, jeśli:

• Linki Don’t mają ważny adres URL, który zwraca 200 OK w swoim atrybut HREF.
• Serwer zwraca błąd podczas bezpośredniego dostępu do adresu URL, bez JavaScript lub z włączonym JavaScript i usuwaniem wszystkich buforów. Uważaj na to: jeśli przejdziemy do strony, klikając link, może się wydawać’działa, ponieważ jest ładowany przez JavaScript. Nawet przy dostępie bezpośrednio, jeśli strona internetowa korzysta z pracownika usług, witryna może symulować prawidłową odpowiedź, ładując pamięć podręczną. Ale GoogleBot jest bezstanowym szczupłączem, powód, dla którego tak się nie dzieje’T Weź pod uwagę dowolną pamięć podręczną pracownika serwera lub inną technologię JavaScript, taką jak lokalna pamięć lub pamięć sesji, więc otrzyma błąd.

Ponadto, aby strona internetowa była dostępna, adres URL musi się zmienić za pomocą JavaScript z Historia API.

Co dzieje się z fragmentami teraz, gdy Google może indeksować Ajax?

Fragmenty są częścią adresu URL, który może pojawić się na końcu, poprzedzony hash #. Na przykład:

http: // www.HumanLevel.com/blog.HTML#Przykład

Ten rodzaj adresów URL nigdy nie dociera do serwera, są zarządzane tylko po stronie klienta. Oznacza to, że żądając powyższego adresu URL na serwerze, otrzymałby żądanie “http: // www.HumanLevel.com/blog.html”, aw kliencie przeglądarka będzie przewijać do fragmentu określanego dokumentu. Jest to powszechne i pierwotnie zamierzone zastosowanie tych adresów URL, powszechnie znany jako Kotwice HTML. A kotwica w rzeczywistości jest dowolnym linkiem ( “A” Tag w HTML pochodzi z kotwica). Jednak w dawnych czasach, Fragmenty zastosowano również do modyfikowania adresów URL przez JavaScript na stronach załadowanych Ajax, Zamierzanie pozwolić użytkownikowi poruszać się po swojej historii przeglądania. Został wdrożony w ten sposób, ponieważ wtedy fragment był jedyną częścią adresu URL, który moglibyśmy zmodyfikować za pomocą JavaScript, dlatego programiści skorzystali z tego, aby ich użyć w sposób, w jaki nie byli’nie zamierzałem. Zmieniło się to wraz z pojawieniem się interfejsu API historii, ponieważ pozwoliło to na modyfikację całego adresu URL za pośrednictwem JavaScript.

Kiedy Google mógł’indeks t AJAX, jeśli adres URL zmienił swoją zawartość za pośrednictwem AJAX, w oparciu o część fragmentu, wiedzieliśmy, że indeksuje adres URL i treści bez uwzględnienia fragmentu. Więc… co dzieje się ze stronami z fragmentami teraz, gdy Google może indeksować Ajax? Zachowanie jest dokładnie takie samo. Jeśli połączymy stronę z fragmentem i zmieni jej zawartość po dostępie przez fragment, indeksuje treść ignorując fragment, a popularność trafi do tego adresu URL, Ponieważ Google ufa, że ​​fragment będzie używany jako kotwica, a nie zmieniać treści, tak jak powinna.

Jednak Google indeksuje obecnie adresy URL z hashbang (#!). Można to zaimplementować poprzez proste dodanie znaku wykwalifikowania lub huk, A Google sprawi, że zadziała, aby zachować zgodność wsteczną z przestarzałą specyfikacją, aby AJAX był możliwy do indeksowania. Ta praktyka nie jest jednak zalecana, ponieważ teraz powinna być wdrażana z interfejsem API historii, a poza tym, Google może nagle zatrzymać indeksowanie adresów URL Hashbang w dowolnym momencie.

Blokowanie indeksowania częściowych odpowiedzi za pośrednictwem AJAX

Kiedy Ajax prośba jest wysyłana do URL API odpoczynku lub GraphQL, My’ponownie zwrócił a JSON lub kawałek strony, którą nie’T chcę indeksować. Dlatego powinniśmy zablokować indeksowanie adresów URL, do których skierowane są te żądania.

Back in the day we could block them using robots.tekst, Ale od GoogleBot’Stał się Renderer, nie możemy zablokować żadnego zasobu używanego do malowania HTML.

Obecnie Google jest trochę mądrzejsze i to nie’t zwykle próbuj indeksować odpowiedzi z JSONS, ale jeśli chcemy się upewnić’T, Uniwersalne rozwiązanie obowiązujące we wszystkich wyszukiwarkach jest uczynienie wszystkich adresów URL z AJAX do akceptowania tylko żądań złożonych przez metodę postu, Ponieważ to nie’t Używane przez pełzanie. Gdy żądanie GET dotrze do serwera, powinno zwrócić błąd 404. Jeśli chodzi o programowanie, nie’zmusza nas do usunięcia parametrów z adresu URL’S QueryString.

Istnieje również możliwość dodania HTTP “X-Robots-Tag: Noindex” Nagłówek (wynaleziony przez Google) do odpowiedzi Ajax lub w celu zwrotu tych odpowiedzi z 404 lub 410. Jeśli używamy tych technik zawartości załadowanych bezpośrednio z HTML, wygrał’nie indeksować, tak jakbyśmy go zablokowali przez roboty.plik txt. Jednakże, Biorąc pod uwagę to’S Malowanie JavaScript Odpowiedź na stronie, Google’T ustanowić związek między tą odpowiedzią a malowaniem JavaScript treści, Więc robi dokładnie to, czego się od tego oczekujemy. I to znaczy: nie indeksuj częściowej odpowiedzi i w pełni indeksowanie wygenerowanego HTML. Ostrożnie, ponieważ takie zachowanie może kiedyś się zmienić, podobnie jak cała nasza treść załadowana przez Ajax, jeśli zastosujemy tę technikę.

Wniosek

Google może teraz indeksować JavaScript i Ajax, ale nieuchronnie implikuje wyższy koszt indeksowania już przetworzonego HTML na serwerze. Oznacza to, że SSR jest i będzie nadal najlepszą opcją przez dłuższy czas. Jeśli nie masz innej alternatywy, jak tylko poradzić sobie ze stroną internetową CSR, w pełni lub częściowo, teraz wiesz, jak to zrobić.