Godziny pracy SEO, 1 lipca 2022

Oto podsumowanie najciekawszych pytań i odpowiedzi z godzin pracy Google SEO z Johnem Muellerem w dniu 1 lipca 2022 r.

PageSpeed ​​Insights czy Google Search Console – który z nich jest dokładniejszy?

0:44 „Kiedy sprawdzam swój wynik PageSpeed ​​Insights w swojej witrynie, widzę prostą liczbę. Dlaczego to nie pasuje do tego, co widzę w Search Console i raporcie Podstawowe wskaźniki internetowe? Która z tych liczb jest poprawna?

Według Johna: „[…] Nie ma poprawnej liczby, jeśli chodzi o szybkość ‒ , jeśli chodzi o zrozumienie, jak Twoja witryna działa dla użytkowników. Uważam, że w PageSpeed ​​Insights domyślnie pokazujemy jedną liczbę, która jest wynikiem od 0 do 100, która opiera się na wielu założeniach, w których zakładamy, że różne rzeczy są nieco szybsze lub wolniejsze dla użytkowników. I na tej podstawie obliczamy wynik.

W Search Console mamy podstawowe informacje o kluczowych wskaźnikach sieciowych , które opierają się na trzech liczbach dotyczących szybkości, responsywności i interaktywności. I te liczby są oczywiście nieco inne, bo to trzy liczby, a nie tylko jedna. Ale jest też duża różnica w sposobie określania tych liczb. Mianowicie istnieje różnica między tak zwanymi danymi terenowymi a danymi laboratoryjnymi.

Dane pola to dane, które widzieli użytkownicy, którzy przechodzą do Twojej witryny. I tego właśnie używamy w Search Console. Tego używamy również w wyszukiwarce. Podczas gdy dane laboratoryjne są teoretycznym spojrzeniem na twoją stronę internetową, gdzie nasze systemy mają pewne założenia, w których myślą, cóż, przeciętny użytkownik jest prawdopodobnie taki, korzystający z tego rodzaju urządzenia i być może z takim połączeniem. Na podstawie tych założeń oszacujemy, jakie mogą być te liczby dla przeciętnego użytkownika. Możesz sobie wyobrazić, że te szacunki nigdy nie będą w 100% poprawne.

Podobnie dane, które widzieli użytkownicy – ​​zmieniają się z czasem, gdy niektórzy użytkownicy mogą mieć naprawdę szybkie połączenie lub szybkie urządzenie, a wszystko dzieje się szybko w ich witrynie lub podczas odwiedzania witryny, a inni mogą nie mieć to. Z tego powodu ta zmienność może zawsze skutkować różnymi liczbami.

Naszą rekomendacją jest wykorzystanie danych terenowych, które zobaczysz w Search Console, jako sposobu na zrozumienie, jaka jest aktualna sytuacja na naszej stronie, a następnie skorzystanie z danych laboratoryjnych, czyli poszczególnych testów, które możesz przeprowadzić bezpośrednio siebie, aby zoptymalizować swoją witrynę i spróbować ją ulepszyć. A kiedy jesteś całkiem zadowolony z danych laboratoryjnych, które otrzymujesz z nową wersją swojej witryny, z czasem możesz zbierać dane terenowe, co dzieje się automatycznie, i dwukrotnie sprawdzać, czy użytkownicy widzą je jako szybsze lub bardziej responsywny.

Krótko mówiąc, znowu nie ma poprawnej liczby, jeśli chodzi o którykolwiek z tych wskaźników. […] Ale raczej są różne założenia i różne sposoby zbierania danych, a każdy z nich jest nieco inny”.

Dlaczego Googlebot ma problemy z indeksowaniem stron opartych na JavaScript?

4:19 „Mamy kilka stron klientów używających Next.js bez pliku robots.txt lub pliku mapy witryny. Teoretycznie Googlebot może dotrzeć do wszystkich tych stron, ale dlaczego indeksowana jest tylko strona główna? W Search Console nie ma błędów ani ostrzeżeń. Dlaczego Googlebot nie znajduje innych stron?”

John powiedział: „[…] Next.js to framework JavaScript, co oznacza, że ​​cała strona jest generowana za pomocą JavaScript. Ale ogólna odpowiedź na wszystkie te pytania, takie jak: dlaczego Google nie indeksuje wszystkiego ‒ ważne jest, aby najpierw powiedzieć, że Googlebot nigdy nie zindeksuje wszystkiego w witrynie. Nie sądzę, aby z jakąkolwiek witryną o nietrywialnych rozmiarach zdarzało się, że Google wyłączyłby i zindeksowałby wszystko. Z praktycznego punktu widzenia nie jest możliwe zindeksowanie wszystkiego w całej sieci. Tak więc założenie, że idealna sytuacja to wszystko jest indeksowane ‒ Zostawiłbym to na boku i powiedziałbym, że chcesz, aby Googlebot skupił się na ważnych stronach.

Inną rzeczą, która stała się nieco jaśniejsza, kiedy, jak sądzę, osoba ta skontaktowała się ze mną na Twitterze i udzieliła mi trochę więcej informacji o swojej witrynie, było to, że sposób, w jaki witryna generowała linki do innych stron, był w sposób, którego Google nie był w stanie odebrać. Tak więc, w szczególności za pomocą JavaScript, możesz wziąć dowolny element na stronie HTML i powiedzieć, że jeśli ktoś na niego kliknie, to uruchom ten fragment JavaScript. I tym fragmentem JavaScriptu może być na przykład przejście do innej strony. A Googlebot nie klika wszystkich elementów, aby zobaczyć, co się dzieje, ale zamiast tego szukamy normalnych linków HTML, co jest tradycyjnym, normalnym sposobem łączenia się z poszczególnymi stronami w witrynie.

Dzięki temu frameworkowi nie generował normalnych linków HTML. Nie mogliśmy więc rozpoznać, że jest więcej do zindeksowania, więcej stron do obejrzenia. I to jest coś, co możesz naprawić w sposób, w jaki zaimplementujesz swoją witrynę JavaScript. W witrynie Search Developer Documentation mamy mnóstwo informacji na temat JavaScript i SEO, w szczególności na temat linków, ponieważ pojawia się to od czasu do czasu. Istnieje wiele kreatywnych sposobów tworzenia linków, a Googlebot musi je znaleźć, aby działały. […]”

Poza oficjalną dokumentacją Google, sprawdź Ultimate Guide to JavaScript SEO na naszym blogu. “

Czy linkowanie do stron HTTP wpływa na SEO Twojej witryny?

7:35 „Czy ma to negatywny wpływ na mój wynik SEO, jeśli moja strona zawiera link do zewnętrznej niezabezpieczonej witryny? Więc na HTTP, a nie HTTPS.”

John powiedział: „Po pierwsze, nie mamy pojęcia o wyniku SEO, więc nie musisz się martwić o wynik SEO.

Ale niezależnie od tego, rozumiem, że pytanie brzmi: czy to źle, jeśli linkuję do strony HTTP zamiast do strony HTTPS. I z naszego punktu widzenia wszystko jest w porządku. Jeśli te strony są za pośrednictwem protokołu HTTP, to do nich należy link. Właśnie tego oczekiwaliby użytkownicy. Nie ma nic przeciwko linkowaniu do takich stron. Twoja witryna nie ma żadnych wad, jeśli chodzi o unikanie linków do stron HTTP, ponieważ są one stare lub chrupiące i nie są tak fajne, jak w przypadku HTTPS. O to bym się nie martwił.

Czy powinieneś usunąć swój plik zrzeczenia się?

10:16 „W ciągu ostatnich 15 lat zrzekłem się łącznie ponad 11 000 linków. […] Linki, których się wyrzekłem, mogły pochodzić ze zhakowanych witryn lub z bezsensownych, automatycznie generowanych treści. Ponieważ Google twierdzi teraz, że ma lepsze narzędzia, aby nie uwzględniać tego rodzaju zhakowanych lub spamerskich linków w swoich algorytmach, czy powinienem usunąć mój plik disavow? Czy samo usunięcie go wiąże się z ryzykiem lub wadą?”

John odpowiedział: „[…] Wyrzekanie się linków jest zawsze jednym z tych trudnych tematów, ponieważ wydaje się, że Google prawdopodobnie nie podaje pełnych informacji.

Ale z naszego punktu widzenia […] ciężko pracujemy, aby nie brać tych powiązań pod uwagę. Robimy to, ponieważ wiemy, że narzędzie Disavow links jest narzędziem niszowym i SEO o tym wie, ale przeciętna osoba prowadząca witrynę internetową nie ma o tym pojęcia. A wszystkie te linki, o których wspomniałeś, są rodzajami linków, które każda strona internetowa otrzymuje przez lata. A nasze systemy rozumieją, że to nie są rzeczy, które próbujesz zrobić, aby oszukać nasze algorytmy.

Więc z tego punktu widzenia, jeśli masz pewność, że nie ma nic związanego z ręcznym działaniem, które musiałeś rozwiązać w odniesieniu do tych linków, usunę plik disavow i […] odłóż to wszystko na bok. Jedną rzeczą, którą osobiście bym zrobił, jest pobranie go i wykonanie kopii, aby mieć zapis tego, co usunąłeś. Ale w przeciwnym razie, jeśli jesteś pewien, że to tylko normalne, chrupiące rzeczy z Internetu, usunę je i przejdę dalej. Jeśli chodzi o strony internetowe, możesz poświęcić znacznie więcej czasu, niż tylko wyrzec się tych przypadkowych rzeczy, które zdarzają się w dowolnej witrynie w sieci.”

Czy lepiej zablokować indeksowanie za pomocą pliku robots.txt czy metatagu robots?

14:19 „Co jest lepsze: blokowanie za pomocą pliku robots.txt czy używanie metatagu robots na stronie? Jak najlepiej zapobiegać raczkowaniu?”

John: „[…] Ostatnio zrobiliśmy odcinek podcastu o tym również. Więc sprawdziłbym to. […]

W praktyce jest tu subtelna różnica, jeśli zajmujesz się SEO i pracowałeś z wyszukiwarkami, to prawdopodobnie już to rozumiesz. Ale dla osób, które są nowe w okolicy, czasami nie jest jasne, gdzie dokładnie znajdują się wszystkie te linie.

Za pomocą pliku robots.txt, który jest pierwszym wymienionym w pytaniu, możesz zablokować indeksowanie. Dzięki temu możesz uniemożliwić Googlebotowi nawet przeglądanie Twoich stron. Dzięki metatagowi robots, gdy Googlebot przegląda Twoje strony i widzi ten metatag robots, możesz na przykład blokować indeksowanie. W praktyce obie te opcje powodują, że Twoje strony nie pojawiają się w wynikach wyszukiwania, ale nieznacznie się różnią.

Więc jeśli nie możemy się czołgać, to nie wiemy, czego nam brakuje. I może być tak, że powiemy, no cóż, właściwie jest wiele odniesień do tej strony. Może do czegoś się przyda. Nie wiemy. A potem ten adres URL może pojawić się w wynikach wyszukiwania bez żadnej treści, ponieważ nie możemy na niego spojrzeć. Podczas gdy w przypadku metatagu robots, jeśli możemy spojrzeć na stronę, możemy spojrzeć na metatag i na przykład zobaczyć, czy nie ma tam indeksu noindex. Następnie przestajemy indeksować tę stronę, a następnie usuwamy ją całkowicie z wyników wyszukiwania.

Jeśli więc próbujesz zablokować indeksowanie, zdecydowanie najlepszym rozwiązaniem jest plik robots.txt. Jeśli nie chcesz, aby strona pojawiała się w wynikach wyszukiwania, wybrałbym tę, która jest dla Ciebie łatwiejsza do zaimplementowania. W niektórych witrynach łatwiej jest ustawić pole wyboru z informacją, że nie chcę, aby ta strona znalazła się w wyszukiwarce, a następnie dodać metatag noindex. W innych może łatwiej jest edytować plik robots.txt. [To] zależy od tego, co tam masz”.

Czy możesz umieścić ten sam adres URL w wielu plikach map witryn?

16:40 „ Czy istnieją jakieś negatywne konsekwencje posiadania zduplikowanych adresów URL z różnymi atrybutami w mapach witryn XML? Na przykład jeden adres URL w jednej mapie witryny z adnotacją hreflang i ten sam adres URL w innej mapie witryny bez tej adnotacji”.

John powiedział: „[…] Z naszego punktu widzenia jest to całkowicie w porządku. […] To się zdarza od czasu do czasu. Niektóre osoby mają adnotacje hreflang w plikach map witryn specjalnie oddzielonych, a także mają normalny plik mapy witryny do wszystkiego. I jest tam pewne nakładanie się.

Z naszego punktu widzenia przetwarzamy te pliki map witryn, jak tylko możemy, i bierzemy wszystkie te informacje pod uwagę. Nie ma wady posiadania tego samego adresu URL w wielu plikach map witryn.  

Jedyne, na co chciałbym zwrócić uwagę, to brak sprzecznych informacji w tych plikach map witryn. Na przykład, jeśli z adnotacjami hreflang mówisz, że ta strona jest dla Niemiec, a następnie w innym pliku mapy witryny mówisz, że właściwie ta strona jest również dla Francji, […] to nasza systemy mogą być jak, cóż, co się tutaj dzieje? Nie wiemy, co zrobić z tą mieszanką adnotacji. A potem może się zdarzyć, że wybierzemy jedno lub drugie.

Podobnie, jeśli mówisz, że ta strona została ostatnio zmieniona 20 lat temu […], a w innym pliku mapy witryny mówisz, no cóż, właściwie to było pięć minut temu. Wtedy nasze systemy mogą na to spojrzeć i powiedzieć, że jeden z was się myli. Nie wiemy, który. Może pójdziemy jednym lub drugim. Może całkowicie zignorujemy datę ostatniej modyfikacji. Więc na to należy uważać.

Ale w przeciwnym razie, jeśli wspomniano o wielu plikach mapy witryny, a informacje są spójne lub działają razem, w tym, że może jeden ma datę ostatniej modyfikacji, a drugi ma adnotacje hreflang, to jest w porządku.”

Jak zapobiec indeksowaniu osadzonych stron wideo?

19:00 „Zajmuję się platformą do odtwarzania wideo, a nasze embedy są czasami indeksowane indywidualnie. Jak możemy temu zapobiec?”

John odpowiedział: „[…] Spojrzałem na stronę internetową, a to są ramki iframe zawierające uproszczoną stronę HTML z osadzonym odtwarzaczem wideo.

Z technicznego punktu widzenia, jeśli strona zawiera treść iframe, widzimy te dwie strony HTML. Możliwe, że nasze systemy zaindeksowały obie te strony HTML, ponieważ są to osobne strony HTML. Zazwyczaj jedno jest włączone w drugie, ale teoretycznie mogą też stać samodzielnie.

Jest jeden sposób, aby temu zapobiec, co jest dość nową kombinacją z metatagami robots, którą możesz zrobić, czyli za pomocą metatagu indexifembedded robots wraz z metatagiem robots noindex .

A w wersji osadzonej, czyli pliku HTML bezpośrednio w nim wideo, dodałbyś kombinację metatagów noindex plus indexifembedded robots. A to oznaczałoby, że jeśli znajdziemy tę stronę pojedynczo, zobaczymy, że jest tam noindex [tag]. Nie musimy tego indeksować.

Ale z indexifembedded mówi nam, że […] jeśli znajdziemy tę stronę z filmem osadzonym w ogólnej witrynie, możemy zaindeksować tę treść wideo, co oznacza, że ​​​​poszczególna strona HTML nie zostanie zindeksowana. Ale strona HTML z osadzeniem, z informacjami wideo, byłaby normalnie indeksowana. Więc to jest konfiguracja, której bym tam użył. A to całkiem nowy metatag robotów, więc nie każdy go potrzebuje. Ponieważ taka kombinacja treści iframe lub treści osadzonych jest rzadka. Ale w przypadku niektórych witryn po prostu ma to sens”.