Od dawna zalecenia SEO koncentrują się na zwykłej wersji tekstowej treści, gdy tylko jest to możliwe, i unikaniu dynamicznie generowanych treści, Ajax i JavaScript. To nie powinno być już w przypadku głównych wyszukiwarek, zwłaszcza Google. Czy powinien?
Tradycyjnie roboty wyszukiwarek patrzyły tylko na surową treść tekstową zawartą w treści odpowiedzi HTTP i tak naprawdę nie interpretowały interpretacji typowej przeglądarki obsługującej JavaScript. Gdy zaczęły się pojawiać strony z dużą ilością treści renderowanej przez JavaScript, Google zaczął go indeksować i indeksować już w 2008 r., ale w dość ograniczony sposób. Schemat indeksowania Ajax do tej pory było to standardowe, choć niezgrabne rozwiązanie tego problemu. Google wkładał wiele pracy w bardziej eleganckie podejście lepiej zrozumieć strony internetowe i wreszcie 14 października 2015 r. oficjalnie ogłosili, że Schemat przeszukiwania AJAX jest obecnie przestarzały . Własnymi słowami:
Nie zalecamy już propozycji indeksowania AJAX, którą stworzyliśmy w 2009 roku.
Nigdy więcej nieprzewidzianych, minimalnych prób indeksowania. To oficjalne, powinni teraz wspierać całą sprawę. W końcu [niektóre szczegółowe i wyczerpujące testy przeprowadzone prawie rok temu] (( http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 ) pokazało, że Google może teraz obsługiwać JavaScript jak nigdy dotąd, w tym przekierowania, linki, dynamicznie wstawiane treści, metadane i elementy strony. Więc [czy możemy ufać Google] (( http://searchengineland.com/can-now-trust-google-crawl-ajax-sites-235267 ) do pełnego przeszukiwania witryn opartych na Ajax? Niestety odpowiedź brzmi - nie, przynajmniej jeszcze nie.
Zgodnie z naszym doświadczeniem, podczas gdy większość funkcji opartych na JavaScript jest teraz rozumiana przez Googlebota, konsekwentnie nie przeszukuje treści pobranych przez Interfejs API XMLHttpRequest z zewnętrznego źródła - lub czegokolwiek zbudowanego na bazie tego API lub z nim związanego. To zachowanie występuje w czystym JavaScript, jQuery, AngularJS lub innych nowoczesnych strukturach JavaScript. Zawsze, gdy trzeba pobrać zawartość z „zewnętrznego” adresu URL lub wywołać punkt końcowy interfejsu API REST w celu pobrania danych, istnieje duże prawdopodobieństwo, że nie zostanie on poprawnie przeszukany i zaindeksowany. Wprowadza to ogromne implikacje dla aplikacji pracujących z dowolną infrastrukturą Backend-as-a-Service (BaaS) lub podobną. Aby rozwiązać ten problem, wymagane byłoby renderowanie po stronie serwera, i chociaż jest ono obsługiwane w niektórych strukturach JavaScript (np Reagować ), potrzebujemy uniwersalnego rozwiązania, dopóki nie będzie szeroko dostępne.
Oto przykład. Spójrz na jedną z najprostszych Zestawy startowe na blogu Baasic . Jest zbudowany przy użyciu AngularJS i pobiera listę wpisów na blogu z naszego interfejsu API, wyświetlając go w prostym układzie. Wszystko wydaje się być w porządku, prawda?
Tak się jednak dzieje, gdy próbujemy znaleźć słowo z pojedynczego postu w wynikach wyszukiwania Google:
Statyczna zawartość samej strony jest indeksowana, ale brakuje dynamicznie generowanych rzeczy - oto dowód na to:
Tak więc, chociaż Google jest w stanie generować i rozumieć Twoje strony internetowe, takie jak nowoczesne przeglądarki, obecnie nie obejmuje wszystkich możliwych scenariuszy. Jest to oczywiście niedopuszczalne w środowiskach produkcyjnych, więc cofnijmy się o krok i powróćmy do istniejącego standardu.
Schemat indeksowania Ajax
Google i inne zaawansowane wyszukiwarki obsługują format adresu URL hashbang (! #), Który był oryginalną metodą tworzenia permalinków dla aplikacji JS. Za każdym razem, gdy robot indeksujący widzi adres URL zawierający hashbang -
http://www.site.com/#!/some/page
przekształci adres URL w
http://www.site/?_escaped_fragment_=/some/page
informując Cię, że powinieneś obsługiwać odpowiedź inaczej w swojej aplikacji JS. W większości przypadków przekażesz przeszukiwaczowi wstępnie wyrenderowaną migawkę HTML, oszczędzając ją przed wysiłkiem samodzielnego analizowania i wykonywania JavaScript.
Nowszy HTML5 pushState nie działa w ten sam sposób, ponieważ modyfikuje adres URL i historię przeglądarki. Jeśli używasz pushState, powinieneś użyć następującego tagu w nagłówku swoich stron:
<meta name = "fragment" content = "!">
To mówi Googlebotowi, aby ponownie odwiedził witrynę, używając fragmentu ? _Escaped = w adresie URL.
Nie należy się mylić, jeśli przeczytałeś, że Google nie obsługuje już schematu indeksowania Ajax. Nie polecają go, ale nadal jest wspierany i pozostanie taki w najbliższej przyszłości.
Korzystanie z jednej z istniejących usług komercyjnych jest najłatwiejszym sposobem rozpoczęcia korzystania z tego podejścia w aplikacjach JavaScript. Oto tylko kilka:
Zdecydowaliśmy się uruchomić dedykowaną usługę prerenderingu na naszych własnych serwerach, korzystając z Prerender.io.
Prerender.io
Ogólnym pomysłem jest zainstalowanie oprogramowania pośredniego Prerender.io na serwerach renderujących aplikacje. Oprogramowanie pośredniczące to tylko wymyślna nazwa pakietu lub zestawu reguł przepisywania adresów URL, które sprawdzają każde żądanie, aby sprawdzić, czy pochodzi ono od robota. Jeśli jest to żądanie przeszukiwacza, oprogramowanie pośredniczące wyśle żądanie do usługi prerenderingu dla statycznego kodu HTML tej strony.
Jeśli obsługujesz aplikacje z ASP.NET, middleware może być prostym modułem HTTP . Zazwyczaj jednak wybieramy podejście, które wykorzystuje reguły przepisywania adresów URL. Może być używany z Apache, Nginx lub dowolnym innym serwerem - rzeczywiste pakiety i instrukcje można pobrać z tutaj .
Teraz musimy zainstalować usługę Prerender.io na naszych serwerach. Jego kod źródłowy jest swobodnie dostępny, ale dokumentacja instalacyjna jest nieco zwięzła. Poprowadzimy Cię przez proces w następnym poście. W międzyczasie podziel się swoimi doświadczeniami ze strategiami SEO dla aplikacji JavaScript.
Czy powinien?Wszystko wydaje się być w porządku, prawda?
Site/?