Niespodzianka SEO SEO! Google używa tagów kanonicznych z wtryskiem JS.

1. Przegląd naszych „znaczników kanonicznych za pomocą GTM” z ubiegłego roku
2. Konfigurowanie naszego nowego testu po I / O
3. Czekam na wyniki
4. Google zaczyna kanonizować nasze testowe adresy URL
5. „Pobieranie i renderowanie> indeksowanie żądań” w GSC nie przyspiesza
6. Nowy raport pokrycia indeksu Search Console nie mówi całej prawdy
7. TL; DR

Podczas I / O 2018 John Mueller i Tom Greenaway z Google przedstawili doskonałą prezentację na temat SEO dla stron JavaScript. Podczas rozmowy Tom Greenaway wspomniał, że Google nie szuka tagów kanonicznych w renderowanym HTML strony. John Mueller później potwierdził to stwierdzenie kilka razy na Twitterze. Ogłoszenie zapoczątkowało naszą ciekawość, ponieważ wcześniej przeprowadziliśmy testy, które sprawiły, że uwierzyliśmy, że tagi kanoniczne wstrzyknięto za pomocą JavaScript za pomocą Google Tag Manager DID. Zdecydowaliśmy się skonfigurować nowy test po ogłoszeniu we / wy. Oto wyniki.

Pamiętaj, że ten eksperyment nie dotyczy tego, czy powinieneś używać GTM lub JavaScript do wstrzykiwania elementów krytycznych na stronę. Problem ten dotyczy sposobu, w jaki Google radzi sobie ze stronami internetowymi, które zależą od JavaScript po stronie klienta, co jest niezwykle ważne w czasach i czasach popularnych struktur JavaScript.

W pośpiechu? Przejdź prosto do TL; sekcja DR !

Przegląd naszych „znaczników kanonicznych za pomocą GTM” z ubiegłego roku

Ogłoszenie Google zaskoczyło nas nasze poprzednie testy zasugerował, że znaczniki kanoniczne i inne elementy istotne dla SEO były zawsze wyciągane z renderowanego HTML, gdy tylko były dostępne, a nie z dokumentu źródłowego HTML. Czy Google zmienił sposób, w jaki radził sobie ze wstrzykiwanymi przez JS tagami kanonicznymi? Czy nasza interpretacja wyników poprzednich testów była błędna?

Nasz kanoniczny wynik testu tagów z ubiegłego roku był oparty na jednym adresie URL, więc mieliśmy dość słabe dowody na poparcie twierdzenia, że ​​Google używa tagów kanonicznych, które są wstrzykiwane JS. Wynik naszego testu mógł być po prostu dużym zbiegiem okoliczności: Google mógł zdecydować się na kanonizację naszego testowego adresu URL do celu naszego kanonicznego znacznika wstrzykniętego JS z innych powodów.

Jest to ogólny problem podczas testowania, czy tagi kanoniczne działają, czy nie: naprawdę można używać znaczników kanonicznych między bardzo podobnymi stronami, które i tak mogą być kanonizowane. W przeciwnym razie ryzykujesz, że twoje tagi kanoniczne zostaną całkowicie zignorowane. Z drugiej strony, gdy twoje strony ze znacznikami kanonicznymi są kanonizowane, nie możesz być w 100% pewien, że tak naprawdę jest to spowodowane znacznikami kanonicznymi.

Uwaga: Jeśli myślisz „Dlaczego po prostu nie sprawdzają nowych raportów pokrycia indeksu GSC?”, Prosimy o cierpliwość i czytanie. Dotrzemy tam.

W zeszłorocznym teście wstrzyknęliśmy kanoniczny znacznik na moją stronę autora w angielskiej wersji tego bloga, wskazując na główną stronę bloga. Od tamtej pory strona autora została kanonizowana do głównej strony bloga, którą można zweryfikować za pomocą informacji: operator wyszukiwania adresu URL w Google (zrzut ekranu z 11 maja 2018 r.):

Kanonizacja nastąpiła po tym, jak wstrzyknęliśmy kanoniczny tag JS za pomocą Google Tag Managera, a żadna inna strona autora lub kategorii na naszej stronie nigdy nie została kanonizowana w podobny sposób (z lub bez wstrzykniętych JS znaczników kanonicznych). Czy to był tylko przypadek?

Konfigurowanie naszego nowego testu po I / O

Po ogłoszeniu Google w I / O, chcieliśmy powtórzyć ten dokładny wynik dla większej liczby adresów URL, więc użyliśmy JS i GTM, aby wprowadzić znaczniki kanoniczne wskazujące na główną stronę bloga na cztery kolejne strony kategorii i autora na naszym blogu. Zadbaliśmy również o to, aby dwie nietknięte dwie podobne strony (moja niemiecka strona autora i strona autorska Michaela) miały grupę kontrolną adresów URL, które nie otrzymują żadnych tagów kanonicznych wskazujących na inne strony, a zatem nie powinny być kanonizowane przez Google. Jeśli jeden z naszych kontrolnych adresów URL został kanoniczny do głównej strony bloga bez wstrzyknięcia nam kanonicznego znacznika, może to oznaczać, że testowe adresy URL zostały kanonizowane z powodów innych niż wstrzyknięte kanoniczne znaczniki JS.

Oto cztery nowe testowe adresy URL, dla których ustawiliśmy wstrzyknięte przez JS tagi kanoniczne 11 maja, dzień po ogłoszeniu we / wy Google (wszystkie zrzuty ekranu wykonane 11 maja) .

Strona kategorii „Eksperymenty SEO”:

Strona kategorii „SEO dla ponownego uruchomienia witryny”:

Strona kategorii „SEO für Website Relaunches”:

Niemiecka strona autora Michaela:

Zauważ, że ostatni testowy adres URL powyżej, niemiecka strona autora Michaela, został kanonizowany na jego angielskiej stronie autora w momencie tworzenia tagu kanonicznego, co często widzimy w różnych wersjach językowych stron, które nie mają poprawnych adnotacji hreflang. W momencie zrzutu ekranu brakowało adnotacji hreflang, które można teraz znaleźć na stronie. Żadna z pozostałych trzech stron nie została kanonizowana w momencie tworzenia zrzutów ekranu i, według naszej wiedzy, nigdy nie została kanonizowana w żadnym momencie w przeszłości.

Czekam na wyniki

Po wstrzyknięciu znaczników kanonicznych czekaliśmy niecierpliwie. Z naszych doświadczeń z poprzednimi testami wiedzieliśmy, że to wymaga czasu, ponieważ takie zmiany mogą potrwać kilka miesięcy, zanim zaczną obowiązywać. Wynika to z faktu, że Google nie renderuje stron tak często, jak ponownie je indeksuje bez renderowania, a im mniej ważna jest strona, tym rzadziej jest ponownie indeksowana, a nawet rzadziej renderowana. Jeśli wstrzykniesz element związany z SEO, taki jak znacznik kanoniczny, adnotacja hreflang lub „noindex” do renderowanego HTML, ale nie umieścisz go w dokumencie źródłowym HTML, musisz być przygotowany na dłuższe oczekiwanie widzisz wyniki.

Google zaczyna kanonizować nasze testowe adresy URL

Pierwszą z naszych stron testowych, które zostaną kanonizowane do celu naszego kanonicznego znacznika wstrzykniętego w JS, była nasza strona kategorii „SEO dla relaunches”. Zauważyliśmy zmianę 21 maja, 10 dni po wstrzyknięciu znacznika kanonicznego. Oto ostatni zrzut ekranu z odpowiednią informacją: wynik operatora wyszukiwania:

Następnie strona kategorii „Eksperymenty SEO” została kanonizowana. Trwało to znacznie dłużej i zauważyliśmy zmianę 3 czerwca, 23 dni po wstrzyknięciu znacznika kanonicznego:

4 czerwca, 24 dni po wstrzyknięciu kanonicznego tagu JavaScript, niemiecka strona „SEO für Website-Relaunches” została kanonizowana do głównej strony bloga naszej niemieckiej wersji strony:

Nasz czwarty testowy adres URL, niemiecka strona autora Michaela, nie został jeszcze kanonizowany w momencie pisania tego (25 dni po wstrzyknięciu znacznika kanonicznego), ale jesteśmy przekonani, że ta strona będzie również kanonizowana do celu JS -wstrzykiwany kanoniczny znacznik w ciągu najbliższego miesiąca:

Aktualizacja (13 czerwca 2018 r.): Ten adres URL został kanonizowany, 34 dni po wstrzyknięciu znacznika kanonicznego.

Co myślisz o tych danych? Czy to zbieg okoliczności, że trzy z naszych czterech testowych adresów URL zostały kanonizowane do celów znaczników kanonicznych, do których wstrzyknęliśmy JavaScript? Czy Google nadal używa tagów kanonicznych z wtryskiem JS, chociaż oficjalnie oświadczył, że tak nie jest? A jeśli tak, dlaczego powiedzieli, że nie?

Zanim przejdziemy do wniosków, porozmawiajmy o innych rzeczach, które powinieneś wiedzieć o tym teście.

„Pobieranie i renderowanie> indeksowanie żądań” w GSC nie przyspiesza

Po wstrzyknięciu znaczników kanonicznych 11 maja wykonaliśmy indeksowanie „Pobierz i renderuj> Żądanie” dla wszystkich naszych testowych adresów URL:

22 maja poprosiliśmy o zaindeksowanie i indeksowanie naszych głównych blogów i wszystkich powiązanych stron, ponieważ wszystkie nasze testowe adresy URL są bezpośrednio powiązane z głównymi stronami bloga. 1 czerwca wykonaliśmy kolejne indeksowanie „Fetch and render> Request” dla trzech pozostałych testowych adresów URL, które nie zostały kanonizowane na tym etapie.

Wiemy, że „Pobierz i renderuj> Indeksowanie żądań” ma zwykle niemal natychmiastowy efekt, gdy używasz go do przesłania nowego adresu URL. Wydaje się jednak, że nie ma to wpływu na renderowanie strony, a przynajmniej nie zawsze. Nasza prośba 1 czerwca mogła spowodować kanonizację dwóch naszych testowych adresów URL 3 i 4 czerwca, ale ta 11 maja z pewnością nie miała natychmiastowego efektu. Innym czynnikiem może być to, że Google musi renderować stronę więcej niż jeden raz, zanim zdecyduje się pobrać wstrzyknięty kanoniczny tag.

Nowy raport pokrycia indeksu Search Console nie mówi całej prawdy

W momencie pisania tego tekstu nasz testowy adres URL z ubiegłego roku i nasz nowy testowy adres URL, który został kanonizowany 21 maja, pojawia się jako „Przesłany adres URL nie wybrany jako kanoniczny” w nowym raporcie pokrycia indeksu Konsoli wyszukiwania Google:

Dwa testowe adresy URL, które zostały kanonizowane 3 i 4 czerwca, nadal są wyświetlane jako „Przesłane i zindeksowane”, ponieważ dane GSC są nieaktualne, ale oczekuję, że pojawią się jako „Nie wybrano adresu URL przesłanego tak kanoniczny ”w ciągu najbliższych kilku dni.

Gdy Google znajdzie kanoniczny znacznik na stronie i szanuje go, spodziewamy się, że status adresu URL w nowym raporcie indeksu będzie „Alternatywna strona z odpowiednim znacznikiem kanonicznym”. Co tu się dzieje?

Mam prostą teorię, która może to wyjaśnić: raport pokrycia indeksu Google Search Console zachowuje się dokładnie tak, jak ogłosił Tom Greenaway i John Mueller na i po I / O - ignoruje znaczniki kanoniczne, których nie ma w źródłowym dokumencie HTML. Odzwierciedla to zachowanie, które Google oficjalnie przekazuje, zamiast tego, które ujawniają wyniki tego testu.

Więc Google Search Console ma informacje o tym, które adresy URL są indeksowane i ma zestaw reguł, które zakłada, że Google używa do indeksowania. Następnie używa tego zestawu reguł do generowania raportów. Gdy zestaw reguł używanych przez GSC do generowania raportów różni się od reguł, których Google używa do indeksowania, raporty zawierają fałszywe informacje.

Wydaje się, że tak jest w przypadku znaczników kanonicznych z wtryskiem JS: Google używa ich do kanonizacji stron, ale GSC uważa, że ​​nie. Dlatego te adresy URL kończą się jako „Przesłany URL nie wybrany jako kanoniczny” zamiast „Alternatywna strona z odpowiednim znacznikiem kanonicznym”. Może to również wyjaśniać, dlaczego John Mueller jest w 100% przekonany, że Google nie używa wstrzykniętych JS tagów kanonicznych:

hundo-p.

- John o .o (≧ ▽ ≦) o. ☆ (@JohnMu) 11 maja 2018 r

Jestem pewien, że John Mueller wie dokładnie, jak działa GSC, a także jestem pewien, że zespół GSC chce dostarczyć dokładnych informacji. Ale jeśli w Google pojawi się nieporozumienie lub po prostu błąd (nie należy używać wstrzyknięć kanonicznych z JS, ale są), to nawet oficjalne oświadczenia i raporty Google mogą być błędne.

TL; DR

• Google ogłosił niedawno, że tagi kanoniczne nie są przetwarzane, jeśli znajdują się tylko w renderowanym HTML, a nie w źródłowym dokumencie HTML.
• Przetestowaliśmy to, wstrzykując tagi kanoniczne w cztery adresy URL za pomocą GTM, a nasze wyniki testów sugerują, że Google używa tych znaczników kanonicznych.
• Kanonizacja niektórych przetestowanych adresów URL zajęła ponad trzy tygodnie do celów wstrzykniętych przez JS znaczników kanonicznych.
• Funkcja „Pobierz i renderuj> Indeksowanie żądań” w Google Search Console nie pomaga przyspieszyć renderowania stron.
• Nowy raport pokrycia indeksu w Google Search Console ignoruje w raportach tagi kanoniczne wstrzykiwane przez JS, a zatem jest zgodny z oficjalnymi oświadczeniami Google.
• Powodem, dla którego Google opublikowało komunikat, który wydaje się błędny, może być wewnętrzne nieporozumienie lub błąd.

Dyskusja

Z przyjemnością wysłucham twojej opinii na ten temat! Co mnie ominęło? Gdzie się mylę? Niestety nasze komentarze na blogu są obecnie wyłączone, dopóki nie uda nam się wdrożyć rozwiązania zgodnego z GDPR (przepraszam za to!). Porozmawiajmy dalej Świergot lub gdziekolwiek chcesz!