Godziny pracy SEO, 3 czerwca 2022

Opublikowany: 2022-07-04

Oto podsumowanie najciekawszych pytań i odpowiedzi z godzin pracy Google SEO z Johnem Muellerem 3 czerwca 2022 r.

Ukryj zawartość
1 Czy mogę użyć dwóch kodów wynikowych HTTP na stronie?
2 Czy korzystanie z CDN poprawia rankingi, jeśli moja witryna jest już szybka w moim głównym kraju?
3 Czy powinienem zabronić żądań API, aby ograniczyć indeksowanie?
4 Czy powinienem używać rel="nofollow" na wewnętrznych linkach?
5 Czy można wymusić wyświetlanie linków do podstron?
6 Nasza strona osadza pliki PDF z ramkami iframe, czy powinniśmy OCR tekstu?
7 Czy Google indeksuje adresy URL w znacznikach danych strukturalnych?

Czy mogę użyć dwóch kodów wynikowych HTTP na stronie?

1:22 „[…] Teoretycznie możliwe jest posiadanie na stronie dwóch różnych kodów wynikowych HTTP, ale co Google zrobi z tymi dwoma kodami? Czy Google w ogóle je zobaczy? A jeśli tak, co zrobi Google? Na przykład 503 plus 302”.

Odpowiedź Johna brzmiała: „[…] Dzięki kodom wyników HTTP możesz dołączyć wiele różnych rzeczy. Google przyjrzy się pierwszemu kodowi wynikowemu HTTP i zasadniczo go przetworzy.

I teoretycznie możesz nadal mieć dwa lub więcej kodów wynikowych HTTP, jeśli są to przekierowania prowadzące do jakiejś końcowej strony. Na przykład możesz mieć przekierowanie z jednej strony na inną. To jeden kod wynikowy. A potem na tej drugiej stronie możesz podać inny kod wyniku. To może być przekierowanie 301 na stronę 404 […]. Z naszego punktu widzenia, w tych sytuacjach łańcuchowych, w których możemy podążać za przekierowaniem, aby uzyskać końcowy wynik, zasadniczo skupimy się na tym końcowym wyniku.

A jeśli ten końcowy wynik ma treść, to jest to coś, co możemy wykorzystać do kanonizacji. Jeśli końcowy wynik jest stroną błędu, to jest to strona błędu. Dla nas to też jest w porządku”.

Czy korzystanie z CDN poprawia rankingi, jeśli moja witryna jest już szybka w moim głównym kraju?

2:50 „[…] Większość ruchu dociera do nas z określonego kraju. Naszą witrynę hostowaliśmy na serwerze znajdującym się w tym kraju. Czy sugerujesz umieszczenie całej naszej witryny za CDN, aby poprawić szybkość strony dla użytkowników na całym świecie, czy nie jest to wymagane w naszym przypadku?”

John odpowiedział: „ Nie sądzę, aby miało to jakikolwiek duży wpływ na Google, jeśli chodzi o SEO.

Jedynym efektem, w którym mogłem sobie wyobrazić, że coś może się wydarzyć, jest to, co widzą użytkownicy. […] Jeśli większość Twoich użytkowników widzi już bardzo szybką witrynę, ponieważ znajduje się tam Twój serwer, to […] robisz dobrze. Ale oczywiście, jeśli użytkownicy w innych lokalizacjach widzą bardzo powolny wynik, ponieważ być może połączenie z Twoim krajem nie jest tak dobre, to jest coś, co możesz poprawić.

[…] Jeśli jest coś, co możesz zrobić, aby poprawić globalnie swoją stronę internetową, myślę, że to dobry pomysł. Nie sądzę, żeby to było krytyczne […]. Ale jest to coś, co możesz zrobić, aby […] rozwinąć swoją witrynę poza obecny kraj.

Może jedna rzecz, którą powinienem wyjaśnić, jeśli indeksowanie Google jest naprawdę, naprawdę powolne, to oczywiście może to wpłynąć na to, ile możemy zindeksować i zaindeksować ze strony […]. Tak naprawdę nie widziałem tego jako problemu w odniesieniu do jakiejkolwiek witryny, która nie ma milionów i milionów stron dużych […].

Możesz dokładnie sprawdzić, jak szybko Google indeksuje w Search Console, oraz statystyki indeksowania. A jeśli wygląda to rozsądnie, nawet jeśli nie jest to superszybkie, to naprawdę bym się tym nie martwił”.

Czy powinienem nie zezwalać na żądania API, aby ograniczyć indeksowanie?

5:20 „[…] Nasza strona obecnie wydaje około 20% budżetu na indeksowanie na subdomenie API, kolejne 20% na miniatury obrazów filmów. Żadna z tych subdomen nie zawiera treści, które są częścią naszej strategii SEO. Czy powinniśmy zabronić indeksowaniu tych subdomen lub jak są wykrywane lub używane punkty końcowe interfejsu API?”

Jak powiedział John: „[…] W wielu przypadkach punkty końcowe interfejsu API są używane przez JavaScript na stronie internetowej , a my wyrenderujemy Twoje strony. A jeśli uzyska dostęp do interfejsu API znajdującego się w Twojej witrynie, spróbujemy załadować zawartość z tego interfejsu API i użyć go do renderowania strony.

W zależności od tego, jak skonfigurowany jest Twój interfejs API i jak skonfigurowany jest Twój JavaScript, może być nam trudno buforować te wyniki interfejsu API, co oznacza, że ​​być może indeksujemy wiele żądań API, aby spróbować uzyskać wyrenderowaną wersję Twoich stron, abyśmy mogli wykorzystać je do indeksowania. Więc to jest zwykle miejsce, w którym jest to odkrywane. I to jest coś, w czym możesz pomóc, upewniając się, że wyniki API mogą być buforowane, że nie wstrzykujesz żadnych znaczników czasu do adresów URL […], gdy używasz JavaScript dla API […].

Jeśli nie zależy Ci na zawartości zwracanej z tymi punktami końcowymi API, możesz oczywiście zablokować indeksowanie całej tej subdomeny za pomocą pliku robots.txt. A to zasadniczo zablokuje wszystkie te żądania API.

[…] Przede wszystkim musisz dowiedzieć się, czy te wyniki API […] są częścią […] krytycznej treści, którą chcę zaindeksować z Google? A jeśli tak, to prawdopodobnie nie powinieneś blokować indeksowania. Ale jeśli […] to […] generuje coś […], co nie jest krytyczne dla twoich stron […], warto sprawdzić jeszcze raz, jak to wygląda, gdy są zablokowane.

Jednym ze sposobów, w jaki możesz to sprawdzić, jest utworzenie oddzielnej strony testowej, która nie wywołuje interfejsu API lub używa uszkodzonego adresu URL dla punktu końcowego interfejsu API. […] Możesz zobaczyć, jak ta strona faktycznie renderuje się w mojej przeglądarce? Jak to się renderuje dla Google?”

Czy powinienem używać rel="nofollow" w linkach wewnętrznych?

8:05 „Czy właściwe jest używanie atrybutu nofollow w linkach wewnętrznych, aby uniknąć niepotrzebnych żądań robota do adresów URL, których nie chcemy przeszukiwać ani indeksować?”

Oto jak John odpowiedział: „[…] Myślę, że w większości przypadków używanie nofollow w linkach wewnętrznych nie ma większego sensu. Ale jeśli to jest coś, co chcesz zrobić, zrób to.

W większości przypadków spróbuję użyć rel=canonical , aby wskazać adresy URL, które chcesz zindeksować lub użyć robots.txt do rzeczy, których naprawdę nie chcesz indeksować.

Spróbuj dowiedzieć się, czy to bardziej subtelna rzecz […], że wolisz indeksować, a następnie użyć do tego rel=canonical? A może jest to coś, o czym mówisz – w rzeczywistości, gdy Googlebot uzyskuje dostęp do tych adresów URL, powoduje to problemy dla mojego serwera. Powoduje duże obciążenie. To sprawia, że ​​wszystko jest naprawdę powolne. To jest drogie lub co masz.

W takich przypadkach po prostu zabroniłbym indeksowania tych adresów URL. […] W przypadku rel=canonical, oczywiście, najpierw musimy zaindeksować tę stronę, aby zobaczyć rel=canonical. Ale z biegiem czasu skupimy się na kanonicznym, który zdefiniowałeś. I użyjemy go głównie do przeszukiwania i indeksowania”.

Czy można wymusić wyświetlanie linków do podstron?

16:02 „Czy istnieje jakaś strategia, dzięki której pożądane strony mogą pojawiać się jako link do witryny w wynikach wyszukiwania Google?”

John wyjaśnił, że „[…] Nie ma metatagu ani uporządkowanych danych, których można użyć do wymuszenia wyświetlenia linku do witryny .

[…] Nasze systemy próbują dowiedzieć się, co jest […] powiązane lub istotne dla użytkowników, którzy przeglądają tę jedną stronę internetową […]? […] Naszą rekomendacją jest zasadniczo posiadanie dobrej struktury strony internetowej, posiadanie jasnych linków wewnętrznych, aby łatwo było nam rozpoznać, które strony są powiązane z tymi stronami, oraz posiadanie jasnych tytułów, których możemy używać i […] wyświetlać jako link do witryny.

[…] Nie chodzi o to, że jest gwarancja, że ​​cokolwiek z tego zostanie tak pokazane. Ale to trochę pomaga nam dowiedzieć się, co jest ze sobą powiązane. A jeśli uznamy, że pokazywanie linku do witryny ma sens, o wiele łatwiej będzie nam wybrać go na podstawie tych informacji”.

Nasza strona osadza pliki PDF z ramkami iframe, czy powinniśmy OCR tekstu?

17:14 „Nasza witryna używa ramek iframe i skryptu do osadzania plików PDF na naszych stronach i w naszej witrynie. Czy jest jakaś korzyść z pobrania tekstu OCR z pliku PDF i wklejenia go gdzieś do kodu HTML dokumentu w celach SEO, czy też Google po prostu przeanalizuje zawartość pliku PDF z taką samą wagą i trafnością w celu zindeksowania treści?”

John odpowiedział: „[…] Wygląda na to, że chcesz wziąć tekst PDF i […] ukryć go w kodzie HTML dla celów SEO. I to jest coś, czego zdecydowanie nie polecam. Jeśli chcesz, aby zawartość była indeksowana, ustaw ją na stronie.

[…] Staramy się usunąć tekst z plików PDF i zindeksować go dla samych plików PDF. Z praktycznego punktu widzenia to, co dzieje się z plikiem PDF, jest jednym z pierwszych kroków, konwertujemy go na stronę HTML i staramy się ją indeksować jak stronę HTML. […] To, co robisz, to […] oprawianie pośredniej strony HTML. A jeśli chodzi o elementy iframe, możemy wziąć te treści pod uwagę do indeksowania na stronie głównej. Ale może się również zdarzyć, że i tak zaindeksujemy plik PDF osobno. […] Odwróciłbym pytanie i ułożyłbym je jako to, co chcesz, żeby się stało?

A jeśli chcesz, aby Twoje normalne strony internetowe były indeksowane z zawartością pliku PDF, zrób to tak, aby ta zawartość była natychmiast widoczna na stronie HTML. Dlatego zamiast osadzania pliku PDF jako podstawowego elementu treści, ustaw zawartość HTML jako element podstawowy i łącze do pliku PDF.

A potem pojawia się pytanie, czy chcesz, aby te pliki PDF były indeksowane osobno, czy nie? Czasami chcesz, aby pliki PDF były indeksowane osobno. A jeśli chcesz, aby były zindeksowane osobno, linkowanie do nich jest świetne.

Jeśli nie chcesz, aby były indeksowane osobno, możesz użyć pliku robots.txt do zablokowania ich indeksowania. Możesz również użyć noindex [? x-robots ?] Nagłówek HTTP. Jest to trochę bardziej skomplikowane, ponieważ musisz podać go jako nagłówek dla plików PDF, jeśli chcesz, aby te pliki PDF były dostępne w iframe, ale nie były faktycznie indeksowane”.

Czy Google indeksuje adresy URL w znacznikach danych strukturalnych?

23:24 „Czy Google indeksuje adresy URL znajdujące się w znacznikach danych strukturalnych, czy po prostu przechowuje dane?”

John wyjaśnił, że „W większości przypadków, gdy patrzymy na strony HTML, jeśli widzimy coś, co wygląda jak link, możemy wyjść i wypróbować również ten adres URL. […] Jeśli znajdziemy adres URL w JavaScript, możemy spróbować go podnieść i spróbować go użyć. Jeśli znajdziemy link w pliku tekstowym na stronie, możemy spróbować go zindeksować i użyć. Ale to naprawdę nie jest normalne łącze.

[…] Jeśli chcesz, aby Google uruchomiło i zindeksowało ten adres URL, upewnij się, że jest do niego naturalny link HTML z wyraźnym tekstem kotwicy, który podaje informacje o stronie docelowej.

Jeśli nie chcesz, aby Google indeksowało ten konkretny adres URL, może zablokuj go za pomocą pliku robots.txt lub na tej stronie, użyj rel=canonical wskazującego na preferowaną wersję, cokolwiek w tym rodzaju. […] Nie zakładałbym ślepo, że tylko dlatego, że jest w ustrukturyzowanych danych, nie zostanie znaleziony, ani nie założyłbym ślepo, że tylko dlatego, że jest w ustrukturyzowanych danych, zostanie znaleziony.

[…] Skupiłbym się raczej na tym, co chcesz, żeby tam się wydarzyło. Jeśli chcesz, aby był widziany jako link, ustaw go jako link. Jeśli nie chcesz, aby to było indeksowane lub indeksowane, zablokuj indeksowanie lub indeksowanie […].”