pushState i SEO

Wiele osób mówi, że używaj pushState zamiast hashbang.

Nie rozumiem, jak byłbyś przyjazny dla wyszukiwarek bez użycia hashbang?

Przypuszczalnie zawartość pushState jest generowana przez kod JavaScript po stronie klienta.

Scenariusz jest zatem:

Jestem włączony example.com. Mój użytkownik klika link:href="example.com/blog"

pushState przechwytuje kliknięcie, aktualizuje adres URL, pobiera skądś plik JSON i tworzy listę postów na blogu w obszarze zawartości.

Dzięki hashbangom Google wie, że musi przejść do adresu URL escaped_fragment, aby pobrać zawartość statyczną.

Dzięki pushState Google po prostu nic nie widzi, ponieważ nie może użyć kodu JavaScript do załadowania JSON, a następnie utworzenia szablonu.

Jedyny sposób, aby to zrobić, to renderowanie szablonu po stronie serwera, ale to całkowicie neguje korzyści płynące z wypychania warstwy aplikacji do klienta.

Czy dobrze rozumiem, pushState nie jest w ogóle przyjazny dla SEO dla aplikacji po stronie klienta?

A co z użyciem metatagu, który sugeruje Google dla tych, którzy nie chcą haszów w swoich adresach URL: <meta name="fragment" content="!">

Zobacz tutaj, aby uzyskać więcej informacji: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Niestety nie sądzę, aby Nicole wyjaśniła problem, który myślałem, że ma OP. Problem polega po prostu na tym, że nie wiemy, komu udostępniamy treści, jeśli nie używamy hash-bang. Pushstate nie rozwiązuje tego za nas. Nie chcemy, aby wyszukiwarki mówiły użytkownikom końcowym, aby przechodzili do adresu URL, który wypluwa niesformatowany kod JSON. Zamiast tego tworzymy adresy URL (które wyzwalają inne wywołania do większej liczby adresów URL), które pobierają dane za pośrednictwem AJAX i przedstawiają je użytkownikowi w preferowany przez nas sposób. Jeśli użytkownik nie jest człowiekiem, alternatywnie możemy podać migawkę html, aby wyszukiwarki mogły prawidłowo kierować użytkowników do adresu URL, pod którym spodziewaliby się znaleźć żądane dane (i w sposób reprezentacyjny). Ale największym wyzwaniem jest to, jak określimy typ użytkownika? Tak, możemy użyć. htaccess lub coś do przepisania adresu URL wykrywanych przez nas robotów wyszukiwarek, ale nie jestem pewien, jak to jest w pełni zabezpieczone i przyszłościowe. Możliwe też, że Google może karać ludzi za robienie tego typu rzeczy, ale nie zbadałem tego w pełni. Zatem kombinacja (pushstate + metatag google) wydaje się być prawdopodobnym rozwiązaniem.

Czy jest pushStateźle, jeśli potrzebujesz wyszukiwarek do czytania treści?

Nie, rozmowa dotyczy pushStatewykonania tego samego ogólnego procesu z hashbangami, ale z lepiej wyglądającymi adresami URL. Pomyśl o tym, co naprawdę się dzieje, gdy używasz haszowania ...

Mówisz:

Dzięki hashbangom Google wie, jak przejść do adresu URL escaped_fragment, aby pobrać ich statyczną zawartość.

Innymi słowy,

1. Google widzi link do example.com/#!/blog
2. Prośby Google example.com/?_escaped_fragment_=/blog
3. Ci powrócić zrzut zawartości użytkownik powinien zobaczyć

Jak widać, już polega na serwerze. Jeśli nie udostępniasz migawki zawartości z serwera, oznacza to, że witryna nie jest poprawnie indeksowana.

Jak więc Google zobaczy cokolwiek z pushState?

Dzięki pushState Google po prostu nic nie widzi, ponieważ nie może użyć javascript do załadowania json, a następnie utworzenia szablonu.

Właściwie Google zobaczy wszystko, o co poprosi, pod adresem site.com/blog. Adres URL nadal wskazuje na zasób na serwerze, a klienci nadal przestrzegają tej umowy. Oczywiście dla współczesnych klientów Javascript otworzył nowe możliwości pobierania i interakcji z treścią bez odświeżania strony , ale umowy są takie same.

Tak więc zamierzona elegancja pushStatepolega na tym, że udostępnia te same treści wszystkim użytkownikom, starym i nowym, obsługującym JS i nie, ale nowi użytkownicy uzyskują lepsze wrażenia .

Jak sprawić, by Google zobaczyło Twoje treści?

1. Podejście Facebooka - serwuj te same treści pod adresem URL, w site.com/blogktóry Twoja aplikacja kliencka przekształci się, gdy przejdziesz /blogdo stanu. (Facebook pushStatejeszcze nie używa , o których wiem, ale robią to z haszami)

2. Podejście Twittera - przekierowuj wszystkie przychodzące adresy URL do odpowiednika hashbang. Innymi słowy, odsyłacz do „/ blog” jest przekazywany /blogdo stanu. Ale jeśli zażądano bezpośrednio, przeglądarka kończy się na #!/blog. (W przypadku Googlebota przekierowanie to będzie _escaped_fragment_zgodne z oczekiwaniami. W przypadku innych klientów możesz pushStatewrócić do ładnego adresu URL).

Więc czy tracisz _escaped_fragment_zdolność pushState?

Powiedziałeś w kilku różnych komentarzach

uciekający fragment jest zupełnie inny. Możesz wyświetlać czystą zawartość bez motywu, zawartość z pamięci podręcznej i nie dać się obciążać, jak zwykłe strony.

Idealnym rozwiązaniem dla Google jest wykonanie witryn JavaScript lub zaimplementowanie w pewien sposób informacji o adresie URL fragmentu ze zmianą znaczenia nawet w przypadku witryn pushstate (robots.txt?).

Korzyści, o których wspomniałeś, nie są odosobnione _escaped_fragment_. To, że robi to za Ciebie i używa specjalnie nazwanego GETparametru, jest naprawdę szczegółem implementacji. Nie ma nic szczególnego o tym, że nie można zrobić ze standardowych adresów URL - innymi słowy, przepisać /blogdo /?content=/blogna własnym wykorzystaniem mod_rewrite lub odpowiednik serwera.

A jeśli w ogóle nie udostępniasz treści po stronie serwera?

Jeśli nie możesz przepisać adresów URL i udostępniać jakiejś treści w /blog(lub w jakimkolwiek stanie, w którym umieściłeś w przeglądarce), oznacza to, że twój serwer naprawdę nie przestrzega już kontraktu HTTP.

Jest to ważne, ponieważ ponowne załadowanie strony (z dowolnego powodu) spowoduje pobranie zawartości z tego adresu URL. (Zobacz https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - „view-source i reload pobiorą zawartość pod nowym identyfikatorem URI, jeśli został on przekazany”).

Nie chodzi o to, że rysowanie interfejsów użytkownika raz po stronie klienta i ładowanie treści za pośrednictwem interfejsów API JS jest złym celem, po prostu nie jest to tak naprawdę uwzględniane przez HTTP i adresy URL i w zasadzie nie jest kompatybilne wstecz.

W tej chwili jest to dokładnie to, do czego służą hashbangi - do reprezentowania odrębnych stanów strony, po których nawiguje się po kliencie, a nie na serwerze. Na przykład przeładowanie spowoduje załadowanie tego samego zasobu, który może następnie odczytać, przeanalizować i przetworzyć zaszyfrowaną wartość.

Tak się składa, że ​​były one również wykorzystywane (zwłaszcza przez Facebooka i Twittera) do zmiany historii na lokalizację po stronie serwera bez odświeżania strony. To właśnie w tych przypadkach użycia ludzie zalecają rezygnację z haszowania dla pushState.

Jeśli renderujesz całą zawartość po stronie klienta, powinieneś pomyśleć o tym pushStatejako o części wygodniejszego interfejsu API historii, a nie o sposobie rezygnacji z używania skrótów.

Cała interesująca rozmowa o pushState i #!, a nadal nie widzę, jak pushState zastępuje cel #!, O co pyta oryginalny plakat.

Nasze rozwiązanie, dzięki któremu nasza witryna / aplikacja Ajax oparta na języku JavaScript w 99% jest obsługiwana przez SEO, jest #!oczywiście używana . Ponieważ renderowanie klienta odbywa się za pomocą HTML, JavaScript i PHP, używamy następującej logiki w module ładującym kontrolowanym przez nasz landing page. Pliki HTML są całkowicie oddzielone od JavaScript i PHP, ponieważ chcemy mieć ten sam HTML w obu (w większości). JavaScript i PHP robią w większości to samo, ale kod PHP jest mniej skomplikowany, ponieważ JavaScript zapewnia znacznie bogatsze wrażenia użytkownika.

JavaScript używa jQuery do wstrzyknięcia do HTML żądanej zawartości. PHP używa PHPQuery do wstawiania do HTML żądanej zawartości - używając „prawie” tej samej logiki, ale znacznie prostszej, ponieważ wersja PHP będzie używana tylko do wyświetlania wersji z możliwością pozycjonowania z linkami do pozycjonowania, a nie do interakcji z wersją JavaScript.

Wszystkie trzy komponenty tworzą stronę: page.htm, page.js i page.php istnieją dla wszystkiego, co używa fragmentu ucieczki, aby wiedzieć, czy wczytać wersję PHP zamiast wersji JavaScript. Wersja PHP nie musi istnieć dla treści nie podlegających pozycjonowaniu SEO (takich jak strony, które można zobaczyć tylko po zalogowaniu się użytkownika). Wszystko jest proste.

Nadal zastanawiam się, jak niektórym programistom front-endowym udaje się tworzyć świetne witryny (z bogactwem Dokumentów Google) bez korzystania z technologii po stronie serwera w połączeniu z przeglądarkami ... Jeśli JavaScript nie jest nawet włączony, nasze rozwiązanie w 99% JavaScript oczywiście nic nie zrobi bez PHP.

Możliwe jest posiadanie ładnego adresu URL, który wyląduje na stronie obsługiwanej przez PHP i przekierowuje do wersji JavaScript, jeśli JavaScript jest włączony, ale nie jest to przyjemne z punktu widzenia użytkownika, ponieważ użytkownicy są ważniejszymi odbiorcami.

Na marginesie. Jeśli tworzysz prostą witrynę internetową, która może działać bez JavaScript, to funkcja pushState może być przydatna, jeśli chcesz stopniowo zwiększać wygodę użytkownika z prostej statycznie renderowanej treści w coś lepszego, ale jeśli chcesz dać użytkownikowi najlepsze wrażenia z podróży ... powiedzmy, że twoja najnowsza gra napisana w JavaScript lub czymś w rodzaju Dokumentów Google, wtedy jej użycie w tym rozwiązaniu jest nieco ograniczone, ponieważ z wdziękiem cofanie się może zajść tylko tak daleko, zanim wrażenia użytkownika będą bolesne w porównaniu z wizją witryny.