it-swarm.dev

pushState i SEO

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

Czego nie rozumiem, jak byłbyś przyjazny dla wyszukiwarki bez używania hashbang?

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

Scenariusz jest zatem następujący:

Jestem na 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ę wpisów na blogu w obszarze zawartości.

W hashbangach Google wie, że należy przejść do adresu URL escaped_fragment, aby uzyskać ich statyczną zawartość.

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

Jedynym sposobem, aby to zrobić, jest renderowanie szablonu po stronie serwera, ale to całkowicie neguje korzyści z przeniesienia warstwy aplikacji do klienta.

Czy mam to w porządku, pushState nie jest przyjazny SEO dla aplikacji po stronie klienta?

76
Harry

Co z użyciem metatagu, który Google sugeruje tym, którzy nie chcą haszować w swoich adresach URL: <meta name="fragment" content="!">

Więcej informacji można znaleźć tutaj: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Niestety nie sądzę, aby NickC wyjaśnił problem, który według mnie miał OP. Problem polega po prostu na tym, że nie wiemy, komu służymy treściom, jeśli nie użyjemy hash-bang. Pushstate nie rozwiązuje tego dla nas. Nie chcemy, aby wyszukiwarki informowały użytkowników końcowych, aby przechodzili do jakiegoś adresu URL, który wypluwa niesformatowany JSON. Zamiast tego tworzymy adresy URL (które wywołują inne połączenia do większej liczby adresów URL), które pobierają dane za pośrednictwem AJAX i prezentują je użytkownikowi w sposób, który preferujemy. Jeśli użytkownik nie jest człowiekiem, alternatywnie możemy udostępnić obraz html-snapshot, aby wyszukiwarki mogły odpowiednio skierować użytkowników ludzkich na adres URL, pod którym oczekiwaliby znaleźć żądane dane (i w sposób reprezentacyjny). Ale największym wyzwaniem jest to, w jaki sposób określamy typ użytkownika? Tak, możemy użyć .htaccess lub coś, aby przepisać URL dla wykrytych przez nas botów wyszukiwarek, ale nie jestem pewien, czy jest to w pełni odporne i przyszłościowe. Możliwe też, że Google może ukarać ludzi za robienie tego rodzaju rzeczy, ale nie zbadałem ich w pełni. Kombi (metatag pushstate + google) wydaje się być prawdopodobnym rozwiązaniem.

16
prograhammer

Czy pushState jest zły, jeśli potrzebujesz wyszukiwarek, aby przeczytać treść?

Nie, rozmowa o pushState jest ukierunkowana na wykonanie tego samego ogólnego procesu do hashbangów, ale z lepiej wyglądającymi adresami URL. Pomyśl o tym, co naprawdę się dzieje, gdy używasz haszyszów ...

Mówisz:

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

Innymi słowy,

  1. Google widzi link do example.com/#!/blog
  2. Żądania Google example.com/?_escaped_fragment_=/blog
  3. Ty zwraca migawkę treści, które użytkownik powinien zobaczyć

Jak widać, już opiera się na serwerze. Jeśli nie wyświetlasz migawki zawartości z serwera, Twoja witryna nie jest poprawnie indeksowana.

Jak więc Google zobaczy wszystko z pushState?

Z pushState, google po prostu nie widzi nic, ponieważ nie może użyć javascript, aby załadować json, a następnie utworzyć szablon.

Właściwie Google zobaczy wszystko, czego może zażądać w 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 strona, ale umowy są takie same.

Tak więc zamierzona elegancja zmiennej pushState polega na tym, że służy ona tej samej treści wszystkim użytkownikom, starym i nowym, zdolnym do obsługi JS, a nie nowym, ale nowym użytkownikom uzyskuje lepsze wrażenia .

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

  1. Podejście na Facebooku - podawaj tę samą treść w adresie URL site.com/blog, w który twoja aplikacja kliencka przekształciłaby się po naciśnięciu /blog na stan. (Facebook nie używa jeszcze pushState, który znam, ale robią to z hashbangami)

  2. Podejście na Twitterze - przekieruj wszystkie przychodzące adresy URL do odpowiednika hashbang. Innymi słowy, link do „/ blog” wypycha /blog na stan. Ale jeśli jest to wymagane bezpośrednio, przeglądarka kończy się na #!/blog. (W przypadku Googlebota będzie to następnie skierowane do _escaped_fragment_, jak chcesz. Dla innych klientów możesz pushState wrócić do ładnego adresu URL).

Czy tracisz zdolność _escaped_fragment_ za pomocą pushState?

W kilku różnych komentarzach powiedziałeś

fragment ucieczki jest zupełnie inny. Możesz obsługiwać czystą zawartość niezaszyfrowaną, zawartość w pamięci podręcznej i nie być umieszczana pod obciążeniem, które są normalne.

Idealnym rozwiązaniem dla Google jest albo wykonanie stron JavaScript, albo implementacja jakiegoś sposobu uświadomienia sobie, że istnieje URL fragmentu, który uciekł nawet w przypadku witryn pushstate (robots.txt?).

Wspomniane korzyści nie są odosobnione do _escaped_fragment_. To, że przepisuje dla ciebie i używa specjalnie nazwanego parametru GET, jest tak naprawdę szczegółem implementacji. Nie ma w tym nic szczególnego, czego nie można by zrobić ze standardowymi adresami URL - innymi słowy, własnoręcznie przepisuj /blog na /?content=/blog używając mod_rewrite lub odpowiednika twojego 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 obsługiwać jakiś rodzaj zawartości w /blog (lub w jakimkolwiek innym stanie w przeglądarce), twój serwer naprawdę nie przestrzega już umowy HTTP.

Jest to ważne, ponieważ przeładowanie strony (z jakiegokolwiek powodu) spowoduje pobranie zawartości pod tym adresem URL. (Zobacz https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source i reload będą pobierać zawartość nowego URI, jeśli został naciśnięty.")

To nie jest tak, że rysowanie interfejsów użytkownika po stronie klienta i ładowanie treści za pomocą interfejsów API JS jest złym celem, po prostu nie jest tak naprawdę rozliczane za pomocą HTTP i adresów URL i zasadniczo nie jest kompatybilne wstecz.

W tej chwili jest to dokładnie to, do czego przeznaczone są hashbangy - reprezentujące odmienne stany stron, które są nawigowane na kliencie, a nie na serwerze. Przeładowanie, na przykład, załaduje zasób sam, który może następnie odczytać, przeanalizować i przetworzyć wartość mieszania.

Zdarza się, że mają również zostały użyte (zwłaszcza przez Facebooka i Twittera), aby zmienić historię na lokalizację po stronie serwera bez odświeżania strony. To w tych przypadkach użycia ludzie zalecają porzucanie hashbangów dla pushState.

Jeśli renderujesz całą zawartość kliencką, powinieneś myśleć o pushState jako część wygodniejszego interfejsu API historii, a nie o wyjście z używania hashbangów.

97
Nicole

Wszystkie interesujące rozmowy na temat pushState i #!, a ja wciąż nie widzę, jak pushState zastępuje cel #!, Jak pyta oryginalny plakat.

Nasze rozwiązanie, dzięki któremu nasza 99-procentowa strona Ajax/aplikacja SEOable może korzystać z #! oczywiście. Ponieważ renderowanie klienta odbywa się za pomocą HTML, JavaScript i PHP, używamy następującej logiki w ładowarce kontrolowanej przez nasze lądowanie strony. Pliki HTML są całkowicie oddzielone od JavaScript i PHP, ponieważ chcemy tego samego HTML w obu (w większości). JavaScript i PHP robią to samo, ale kod PHP jest mniej skomplikowany, ponieważ JavaScript jest znacznie bogatszym doświadczeniem użytkownika.

JavaScript używa jQuery do wstrzykiwania do HTML treści, których chce. PHP używa PHPQuery do wstrzykiwania zawartości HTML, której chce - używając „prawie” tej samej logiki, ale znacznie prostszej, ponieważ wersja PHP będzie używana tylko do wyświetlania wersji SEOable z linkami SEOable, a nie być w interakcji z podobną wersją JavaScript.

Wszystkie trzy komponenty tworzą stronę, page.htm, page.js i page.php istnieją dla wszystkiego, co używa ucieczkowego fragmentu, aby wiedzieć, czy załadować wersję PHP zamiast wersji JavaScript. Wersja PHP nie musi istnieć w przypadku treści innych niż SEO (takich jak strony widoczne tylko po zalogowaniu użytkownika). Wszystko jest proste.

Nadal jestem zdziwiony, jak niektórzy programiści odsuwają się od tworzenia wspaniałych witryn (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, to nasze 99% rozwiązanie JavaScript oczywiście nic nie zrobi bez PHP na miejscu.

Możliwe jest, aby ładny adres URL wylądował na stronie PHP i przekierował do wersji JavaScript, jeśli włączona jest obsługa JavaScript, ale nie jest to Nicea z perspektywy użytkownika, ponieważ użytkownicy są ważniejszą publicznością.

Na marginesie. Jeśli tworzysz tylko prostą stronę internetową, która może działać bez JavaScript, wtedy widzę, że pushState jest przydatny, jeśli chcesz stopniowo zwiększać komfort użytkownika z prostej, statycznie renderowanej treści na coś lepszego, ale jeśli chcesz dać swojemu użytkownikowi najlepsze wrażenia z podróży uzyskaj ... powiedzmy, że twoja najnowsza gra napisana w JavaScript lub coś takiego jak Google Docs, to jej zastosowanie w tym rozwiązaniu jest nieco ograniczające, ponieważ wdzięczne upadki mogą pójść tak daleko, zanim wrażenia użytkownika będą bolesne w porównaniu z wizją strony.

0
Julian