8 marca 2019 r. – Google Help Hangout Notes

W tym tygodniu John odpowiada na kilka świetnych pytań dotyczących Page Speed, Anchor Text, Java Script. Jak zawsze pełny film i transkrypcję znajdziecie poniżej!

Jak traktowane są przetłumaczone treści?

0:33

Myślę, że dobrze jest mieć taką połączoną stronę internetową. Myślę, że dla użytkowników sensowne jest sprawienie, aby była dla nich łatwa do czytania, aby jeśli jesteś anglojęzycznym użytkownikiem i wchodzisz na swoją stronę, nie jest to mieszanka treści rosyjskich, ukraińskich i angielskich. ale to raczej cała angielska treść. Może to nie być cała treść, którą masz w różnych językach, ale jest w porządku. Z punktu widzenia SEO sensowne jest przekształcanie tłumaczeń w treści wysokiej jakości. Więc nie tylko za pomocą Tłumacza Google. Narzędzia do tłumaczenia wciąż są coraz lepsze, ale nadal jest lepiej, jeśli przetłumaczysz je ręcznie lub weźmiesz wersję google tłumacza i wyczyścisz ją i uczynisz bardziej czytelną. To jest coś, co zauważają użytkownicy i jest to również coś, co zauważamy z algorytmicznego punktu widzenia. Jeśli będziemy w stanie stwierdzić, że jest to treść naprawdę wysokiej jakości, potraktujemy ją lepiej w wynikach wyszukiwania.

Podsumowanie: upewnij się, że przetłumaczona treść jest czytelna w innych językach, a nie tylko przetłumaczona automatycznie za pomocą Tłumacza Google. Upewnij się również, że tłumaczenia są wysokiej jakości i mają wartość dla użytkowników.

Jeśli moja witryna działa w języku JavaScript, a czas indeksowania ma krytyczne znaczenie dla treści, jak mogę stwierdzić, że jej indeksowanie zajmie?

3:10

Więc ogólnie rzecz biorąc, pierwsza część jest poprawna. Chodzi o to, że staramy się indeksować treść tak szybko, jak to możliwe, co możemy zrobić, jeśli mamy statyczną wersję HTML, a następnie następnym krokiem jest próba renderowania strony tak, jak zrobiłaby to przeglądarka, i również wybieramy tę treść i użyj go do indeksowania. Te dwie rzeczy połączone ogólnie działają razem, ale nie jest tak, że statyczna wersja HTML byłaby opóźniona (sztucznie) do czasu, gdy wersja javascript będzie gotowa. Tak więc z tego punktu widzenia w przypadku większości witryn nie jest istotne, że istnieje ta różnica i nie mamy wyraźnego czasu, który odnosi się do czasu, jaki zajmuje rozpoczęcie renderowania strony. To może się różnić w zależności od typu strony, kiedy ją znaleźliśmy, jak ją znaleźliśmy, co dzieje się wokół tej strony. Na przykład, jeśli uważamy, że jest to coś, co naprawdę szybko wyświetla się w wynikach wyszukiwania, spróbujemy to natychmiast wyrenderować. Więc trudno to wziąć pod uwagę. Nie ma tam stałego numeru. Ogólnie użyłbym tego jako przybliżonej wskazówki do ustalenia, czy musisz coś zrobić z zawartością JavaScript po stronie klienta. Na przykład, jeśli masz treści, które muszą być szybko zindeksowane, upewniłbym się, że Google może pobrać te treści tak szybko, jak to możliwe, bez konieczności renderowania tych treści osobno. W przypadku witryn z wiadomościami, zwłaszcza na stronach nadrzędnych w witrynach z wiadomościami, w których znajdują się linki do wszystkich nowych artykułów, naprawdę upewniłbym się, że te strony działają dobrze wyłącznie ze statycznym kodem HTML udostępnianym wyszukiwarkom. Więc tak bym o tym myślał, zastanów się, jak ważne jest, aby moja treść została natychmiast zindeksowana, a nie pod względem liczby minut, ponieważ nie ma ustalonego czasu, na jaki może to potrwać.

Podsumowanie : w przypadku witryn JavaScript Google Firsts indeksuje stronę, a następnie potrzebuje czasu na przetworzenie kodu JavaScript. Nie ma ustalonego czasu, jak długo to potrwa. Jeśli więc Twoje treści wymagają częstej aktualizacji, lepiej podać statyczną wersję HTML strony.

Jakie są główne różnice w porównaniu z narzędziem do sprawdzania adresów URL i testem przyjaznym dla urządzeń mobilnych, jeśli oba pobierają strony z serwera na żywo?

9:16

Pomysł z testem przyjazności dla urządzeń mobilnych polega tylko na sprawdzeniu, czy ta wersja jest przystosowana do urządzeń mobilnych, więc jest to główny cel. Narzędzie do sprawdzania adresów URL, narzędzie do testowania na żywo, służy raczej do sprawdzenia „jak ta strona poradzi sobie z indeksowaniem?”. czy weźmiemy tę stronę i umieścimy ją w naszym indeksie, czy nie. Test przyjazny dla urządzeń mobilnych koncentruje się głównie na stronie mobilnej, a narzędzie do sprawdzania adresów URL jest jak ten duży scyzoryk z różnymi funkcjami, których można używać do różnych rzeczy.

Podsumowanie : test przyjazności dla urządzeń mobilnych ma sprawdzić, jak dobrze witryna poradzi sobie na urządzeniach mobilnych, podczas gdy narzędzie do sprawdzania adresów URL sprawdza, czy indeksowanie działa tak, jak powinno, na przykład brak kodów odpowiedzi indeksu.

Zastanawiam się nad podzieleniem stron produktów w mojej witrynie eCommerce. Obecnie można je konfigurować na jednej stronie z pokazanymi wieloma odmianami. Jakie są twoje rekomendacje?

18:00

Myślę, że bardziej przyjrzałbym się temu, czy naprawdę ma sens dzielenie tych produktów na osobne strony, ponieważ to, czym handlujesz, to jedna strona produktu, która jest dość silna dla tego produktu i wszystkich jego odmian, w przeciwieństwie do wielu stron, które muszą pracować na własną rękę i być wspierane na własną rękę. Zamiast więc mieć jedną naprawdę mocną stronę dla „butów do biegania”, masz wiele stron, które muszą walczyć o „niebieskie buty do biegania”, „czerwone buty do biegania”, „zielone buty do biegania”. Więc jeśli ktoś szuka „butów do biegania”, to te małe strony nie są tak silne, jak ta jedna strona produktu, którą masz dla tego głównego produktu. Więc moja ogólna rada jest taka, że ​​jeśli myślisz, że te odmiany są tylko atrybutami głównych produktów, ludzie mają tendencję do wyszukiwania głównej treści, a następnie mówią „och, jakiego koloru chcę, to tak, jakbym znalazł produkt Chcę, ale po prostu muszę wybrać kolor, który chcę.” wtedy umieściłbym je na udostępnionej stronie. Zważywszy, że jeśli ludzie wyraźnie szukają tej odmiany i ta odmiana jest naprawdę wyjątkowa i wyróżnia się sama z siebie, a ludzie nie przychodzą do Twojej witryny tylko mówiąc „Chcę buty do biegania”, ale raczej „Chcę tego konkretnego rodzaju biegania buty w tym kolorze”, to może warto to zrobić jako osobny produkt.

Podsumowanie : o ile odmiany produktów nie wyróżniają się same z siebie, a ludzie szukaliby tej konkretnej odmiany, lepiej jest trzymać je wszystkie na jednej mocnej stronie. W ten sposób różne odmiany stron produktów nie konkurują ze sobą.

Czy szybkość jest ważna dla mobilnej wersji Twojej witryny?

21:00

Dobrą stroną jest to, że mamy wiele czynników rankingowych, więc nie zawsze musisz robić wszystko perfekcyjnie. Ale oznacza to również, że natkniesz się na sytuacje takie jak ta, w których mówisz „Google mówi, że szybkość jest ważna, ale najlepsza strona tutaj nie jest tak szybka, więc nie może być ważna”. Dla nas jest to zdecydowanie ważne, ale to nie znaczy, że przeważa nad wszystkim innym. Możesz sobie wyobrazić, że najszybsza strona, o której możesz pomyśleć, to prawdopodobnie pusta strona. Ale pusta strona byłaby naprawdę okropnym wynikiem wyszukiwania, gdybyś szukał czegoś naprawdę konkretnego. Jest naprawdę szybki, ale nie ma tam treści, więc użytkownik nie byłby zadowolony. Musimy więc zrównoważyć wszystkie te czynniki, treść, linki i wszystkie te sygnały, i spróbować wymyślić, jak zrobić ranking w oparciu o tę mieszankę różnych czynników, które mamy. I wprowadza zmiany w czasie, może się zmienić dość szybko. Na przykład, jeśli coś jest w tej chwili naprawdę warte opublikowania, możemy zdecydować się na pokazanie nieco innych witryn, co jest bardziej tematem badawczym, wiecznie zielonym.

Podsumowanie : Szybkość to tylko jeden z czynników rankingowych, z których korzysta Google. Tylko dlatego, że najlepsze witryny mogą nie być szybkie, nie oznacza to, że nie jest to ważne dla Twojej witryny.

Jaki typ znaczników schematu jest preferowany przez Google, czy powinniśmy używać formatu JSON czy mikrodanych, mikroformatów. Który jest lepszy?

22:30

Obecnie preferujemy znaczniki JSON-LD. Myślę, że większość nowych typów danych strukturalnych pojawia się najpierw dla JSON-LD, więc to jest to, co wolimy.

Podsumowanie: JSON-LD jest preferowany przez Google.

Jak ważny jest tekst kotwicy?

25:10

Myślę więc, że przede wszystkim nie przejmowałbym się zbytnio patentami Google, opatentowujemy wiele rzeczy, które niekoniecznie mają zastosowanie do tego, co muszą zrobić webmasterzy. Myślę więc, że to ciekawe, że nasi inżynierowie pracują nad tym, ale nie musi to oznaczać, że od razu na nas to wpłynie. Jeśli chodzi o tekst zakotwiczenia ogólnie, używamy go do tekstu. To coś, co wychwytujemy. To świetny sposób na przedstawienie kontekstu linku. W szczególności w Twojej witrynie, jeśli masz link, który mówi po prostu „kliknij tutaj, aby uzyskać więcej informacji”, nie jest to dla nas zbyt przydatne. Jeśli masz link, który mówi „możesz znaleźć więcej informacji na tej stronie produktu” i link z nazwą tego produktu do tej strony, to mówi nam, że być może ta strona naprawdę dotyczy tego produktu. Dlatego z pewnością nadal będę przyglądał się tekstowi zakotwiczenia, którego używasz, zwłaszcza wewnętrznie w witrynie, i staram się upewnić, że podajesz tekst zakotwiczenia, który jest naprawdę przydatny i zapewnia kontekst dla tego, co jest połączone na stronie.

Podsumowanie: Anchor Text jest bardzo ważny, ponieważ zapewnia Google kontekst dotyczący tego, o czym jest strona. Tekst kotwicy, taki jak „Kliknij tutaj, aby uzyskać więcej informacji”, nie dostarcza Google wielu informacji, ale tekst kotwicy, taki jak „Możesz znaleźć więcej informacji o tej stronie produktu”, informuje Google, że ta strona dotyczy tej strony produktu.

Nasza uwaga: jeśli tworzysz własne linki, posiadanie zbyt wielu linków ze słowami kluczowymi może być wskazówką dla zespołu zajmującego się spamem w przypadku ręcznego sprawdzenia.

Jak Google wizualnie widzi Twoją stronę?

39:00

Staramy się patrzeć na stronę wizualnie, ale głównie w odniesieniu do tego, czy rzeczywista treść w części strony widocznej na ekranie, czy też obszar strony widocznej na ekranie to tylko jedna wielka reklama. Na tym się skupiamy, również w odniesieniu do przyjazności dla urządzeń mobilnych, staramy się wizualnie zmapować stronę i zobaczyć, czy ta strona będzie dobrze działać na urządzeniu mobilnym. I do tego musimy trochę zamapować stronę, jest ok, jeśli niektóre elementy są nieczytelne, dopóki działają na urządzeniu mobilnym. Jeśli te linki tam są, mają odpowiedni rozmiar i ludzie mogą je klikać, to jest w porządku. Jeśli robisz jakąś fantazyjną transformację CSS, aby przekształcić to w tekst 3D, to całkowicie zależy od Ciebie. Ważną częścią jest to, że sam tekst jest widoczny na stronie i że nie robisz zbyt wyszukanych znaczników, aby podzielić ten tekst. Na przykład, jeśli masz nagłówek w starym systemie, w którym masz układ oparty na tabeli i chcesz podzielić uzdrowienie na wierzch, wydaje mi się, że ludzie umieszczają pojedyncze litery w poszczególnych komórkach tabeli i z naszego punktu widzenia sprawia to, że prawie niemożliwe jest, aby zobaczyć, że jest to w rzeczywistości jedno słowo, ponieważ używasz znaczników, aby podzielić je na niepołączone części. Z punktu widzenia analizy strony jest to naprawdę trudne.

Podsumowanie: Google głównie stara się sprawdzić, czy rzeczywista treść znajduje się w części strony widocznej na ekranie, a nie tylko gigantyczną reklamą. Jeśli chodzi o przyjazność mobilną, Google stara się zrozumieć, czy są tam te same linki, wszystko ma odpowiedni rozmiar i czy ludzie mogą na nie klikać. Najważniejsze jest to, czy sam tekst jest widoczny na stronie.

Czy możesz zamienić adres URL na JavaScript?

43:00

Tak, możemy to odebrać. Myślę, że ważną częścią jest to, że adres URL musi zostać zamieniony po załadowaniu strony. Nie należy go wymieniać, gdy użytkownik wykona określoną akcję. Na przykład, jeśli użytkownik najedzie kursorem na link, a następnie użyjesz JavaScript, aby zamienić adres URL, co nie byłoby czymś, co byśmy zauważyli, lub jeśli użytkownik kliknie link, a następnie użyjesz JavaScript, aby zamienić adres URL, to również nie byłoby czymś, co byśmy zauważyli. Ale jeśli strona się ładuje, a następnie uruchamiasz JavaScript, który czyści adres URL, tak aby łączyły się z odpowiednimi wersjami kanonicznymi, to jest całkowicie w porządku i trochę tak, jak mówiliśmy na początku, jeśli chodzi o renderowanie, czasami zajmuje to trochę czasu czas. Więc nie jest to natychmiastowa rzecz, którą moglibyśmy wybrać, lub jest prawdopodobne, że wybralibyśmy obie te wersje, zarówno oryginalny link, który miałeś, jak i wersję JavaScript. Więc nie byłoby tak, że stare wersje całkowicie odpadły.

Podsumowanie : Google może odebrać, jeśli adres URL został zamieniony po załadowaniu strony. Jedyną rzeczą, o której należy pamiętać, jest upewnienie się, że adres URL nie jest zamieniany, gdy użytkownik wykonuje określoną akcję.

Jeśli lubisz takie rzeczy, pokochasz mój newsletter!

Mój zespół i ja co tydzień informujemy o najnowszych aktualizacjach algorytmu Google, wiadomościach i wskazówkach dotyczących SEO.

Pytanie 0:33 - Pytanie o tłumaczenie. Wiem, że jeśli tłumaczę treści z języka angielskiego na rosyjski lub ukraiński, a większość ludzi korzysta tylko z tłumaczenia Google i po prostu wstawiam treść. Ale wydaje się, że 90% wymaga korekty, jeśli czytasz to jako native speaker. Interesują mnie dwa punkty. Jeśli chcę dodać inną wersję lub inny język do mojej strony internetowej, na przykład angielski, rosyjski lub ukraiński, czy to jest w porządku? Po drugie, znalazłem ciekawy artykuł o mojej niszy i chcę go przetłumaczyć, czy to dobrze, czy nie? Czy muszę dostosować go do domowych czytelników?

Odpowiedź 1:38 - Myślę, że dobrze jest mieć taką połączoną stronę internetową. Myślę, że dla użytkowników sensowne jest sprawienie, aby była dla nich łatwa do czytania, aby jeśli jesteś anglojęzycznym użytkownikiem i wchodzisz na swoją stronę, nie jest to mieszanka treści rosyjskich, ukraińskich i angielskich. ale to raczej cała angielska treść. Może to nie być cała treść, którą masz w różnych językach, ale jest w porządku. Z punktu widzenia SEO sensowne jest przekształcanie tłumaczeń w treści wysokiej jakości. Więc nie tylko za pomocą Tłumacza Google. Narzędzia do tłumaczenia wciąż są coraz lepsze, ale nadal jest lepiej, jeśli przetłumaczysz je ręcznie lub weźmiesz wersję google tłumacza i wyczyścisz ją i uczynisz bardziej czytelną. To jest coś, co zauważają użytkownicy i jest to również coś, co zauważamy z algorytmicznego punktu widzenia. Jeśli będziemy w stanie stwierdzić, że jest to treść naprawdę wysokiej jakości, potraktujemy ją lepiej w wynikach wyszukiwania.

Pytanie 3:10 – Google przemierza i indeksuje zawartość w dwóch krokach. Pierwszym jest renderowanie po stronie serwera, a drugim renderowanie po stronie klienta, zgodnie z poprzednimi stwierdzeniami, zakończenie tego procesu może zająć dni lub tygodnie. W przypadku witryn korzystających z JavaScript mogą wystąpić poważne problemy, jeśli indeksowanie jest krytyczne czasowo. Skąd mam wiedzieć, ile to zajmie?

Odpowiedź 3:46 - Ogólnie rzecz biorąc, pierwsza część jest poprawna. Chodzi o to, że staramy się indeksować treść tak szybko, jak to możliwe, co możemy zrobić, jeśli mamy statyczną wersję HTML, a następnie następnym krokiem jest próba renderowania strony tak, jak zrobiłaby to przeglądarka, i również wybieramy tę treść i użyj go do indeksowania. Te dwie rzeczy połączone ogólnie działają razem, ale nie jest tak, że statyczna wersja HTML byłaby opóźniona (sztucznie) do czasu, gdy wersja javascript będzie gotowa. Tak więc z tego punktu widzenia w przypadku większości witryn nie jest istotne, że istnieje ta różnica i nie mamy wyraźnego czasu, który odnosi się do czasu, jaki zajmuje rozpoczęcie renderowania strony. To może się różnić w zależności od typu strony, kiedy ją znaleźliśmy, jak ją znaleźliśmy, co dzieje się wokół tej strony. Na przykład, jeśli uważamy, że jest to coś, co naprawdę szybko wyświetla się w wynikach wyszukiwania, spróbujemy to natychmiast wyrenderować. Więc trudno to wziąć pod uwagę. Nie ma tam stałego numeru. Ogólnie użyłbym tego jako przybliżonej wskazówki do ustalenia, czy musisz coś zrobić z zawartością JavaScript po stronie klienta. Na przykład, jeśli masz treści, które muszą być szybko zindeksowane, upewniłbym się, że Google może pobrać te treści tak szybko, jak to możliwe, bez konieczności renderowania tych treści osobno. W przypadku witryn z wiadomościami, zwłaszcza na stronach nadrzędnych w witrynach z wiadomościami, w których znajdują się linki do wszystkich nowych artykułów, naprawdę upewniłbym się, że te strony działają dobrze wyłącznie ze statycznym kodem HTML udostępnianym wyszukiwarkom. Więc tak bym o tym myślał, zastanów się, jak ważne jest, aby moja treść została natychmiast zindeksowana, a nie pod względem liczby minut, ponieważ nie ma ustalonego czasu, na jaki może to potrwać.

Pytanie 6:17 – A teraz mamy bardzo długie pytanie o zrozumienie rodzaju oznaczania w konsoli wyszukiwania, na przykład gdy oznaczamy coś jako „duplikat Google wybierz inny kanoniczny niż użytkownik” lub „zduplikowany przesłany adres URL i nie zaznaczony jako problem kanoniczny .

[User Chimes in] To jest strona JavaScript. Jest wstępnie renderowana, cała zawartość jest w statycznym kodzie HTML, a mimo to Google wciąż próbuje uruchomić stronę. W tym środowisku handlu elektronicznego dowiadujemy się, że te unikalne strony produktów z unikalnymi opisami i znaczącą treścią są oznaczane przez Google jako duplikaty. Zakładamy, że jest to spowodowane jakimś niepowodzeniem renderowania JavaScript, w którym Googlebot wciąż widzi tę samą stronę błędu lub coś w tym stylu i dlatego uważa, że ​​są to duplikaty – jak możemy zrozumieć, co to jest, że usługa renderowania stron internetowych kończy się na tym może spowodować, że treść będzie wyglądać na duplikat dla bota Google.

Odpowiedź 7:43 - Musiałbym spojrzeć na kilka rzeczywistych przykładów, więc jeśli mógłbyś przesłać mi kilka przykładów, które byłyby naprawdę przydatne.

Pytanie 8:00 – Czy Google wie o bieżącym problemie?

Odpowiedź 8:00 - Nie… Słyszałem od niektórych stron, które narzekały na to więcej niż inne, więc jeśli prześlesz kilka przykładów, które będą przydatne.

Pytanie 8:24 – Jeśli adres URL jest oflagowany, czy mimo wszystko widać coś na temat renderowania, które miało miejsce w czasie tej analizy. Czy mimo to można zobaczyć błędy ładowania zasobów, które wystąpiły w zaindeksowanym? Nie masz tego interfejsu użytkownika w konsoli wyszukiwania, a przynajmniej nie mogę się do niego dostać. A czy jest jakieś miejsce, w którym możemy zobaczyć, jak faktycznie wygląda zawartość w momencie, gdy przegląda ją indeksator i/lub wykrywacz duplikatów

Odpowiedź 8:41 - Nie w tej chwili. To jest coś, co miałoby sens. W przypadku większości witryn nie jest to krytyczne. Ale w takim przypadku przydałoby się to mieć.

Pytanie 9.16 - Następne pytanie. Test przyjazny dla urządzeń mobilnych. Odwoływałeś się do niego kilka razy, aby zrozumieć, w jaki sposób indeksator widziałby zawartość. Jednak okazuje się, że w ładowaniu zasobów występuje wiele innych błędów, a szybkość, z jaką te błędy występują, wydaje się różnić w zależności od domeny. Więc pierwsze pytanie, czy błędy, które widzimy w teście przyjaznym dla urządzeń mobilnych, są błędami, które usługa napotka podczas indeksowania? A może są różne alokacje zasobów na test MF?

Odpowiedź 10:04 — Więc myślę, że odnosisz się konkretnie do zasobów osadzonych, które są pobierane do testu, prawda? Jak pliki JS CSS różne odpowiedzi tego rodzaju rzeczy? Myślę, że jest to jeden z aspektów, który jest obecnie nieco skomplikowany w tym sensie, że mamy inne priorytety testu przyjaznego urządzeniom mobilnym w porównaniu z normalnym botem Google. Staramy się pobierać zasoby tak szybko, jak to możliwe z działającego serwera, a podczas indeksowania buforujemy wiele zasobów i po prostu pobieramy zbuforowaną wersję strony. To, co możesz zobaczyć w teście przyjaznym dla urządzeń mobilnych, polega na tym, że staramy się renderować tę stronę tak szybko, jak to możliwe i możemy uzyskać wiele z tych zasobów, ale w przypadku niektórych z nich zasadniczo przekraczamy limit czasu, mając zasadniczo możliwość wyciągnięcia tego na żywo z serwer. Jest to w dużej mierze część błędów, które widzisz w teście przyjaznym dla urządzeń mobilnych. Uważam również, że w narzędziu do sprawdzania adresów URL, jeśli używasz testu na żywo, staramy się wyciągnąć wszystko na żywo, a czasami po prostu nie da się tego zrobić na żywo. A na indeksowanie mamy dużo więcej, trochę więcej czasu, który mamy na to do dyspozycji. Jeśli więc zobaczymy, że te zasoby są potrzebne, wyciągniemy je, zbuforujemy je i postaramy się je udostępnić podczas renderowania. Więc to jest coś, czego nie musimy robić na żywo, więc jeśli zajmie to trochę więcej czasu, będziemy cierpliwi i poczekamy, aż to wszystko się połączy. Nadal istnieje pewien aspekt czasu, w którym te zasoby są takie, że nie możemy ich buforować (na przykład identyfikator sesji i wszystkie adresy URL JS), co sprawia, że ​​naprawdę musimy zachować wersję z pamięci podręcznej i użyj go ponownie, to są te, których możemy, nie wiem, z jakiegokolwiek powodu nie być w stanie pobrać do indeksowania. Krótko mówiąc, myślę, że trudno jest zdiagnozować takie problemy, zwłaszcza jeśli masz dużo wbudowanych zasobów. Wytyczne, które zazwyczaj otrzymuję od zespołu inżynierów, są takie, że powinniśmy po prostu powiedzieć ludziom, aby mieli mniej wbudowanych zasobów i zwykle nie napotykają tego problemu. Nie zawsze jest to takie proste, więc ogólnie rzecz biorąc, wziąłbym test przyjazności dla urządzeń mobilnych jako przybliżony przewodnik, więc jeśli działa on w MTF, to zdecydowanie jesteś po bezpiecznej stronie. Jeśli zauważysz, że inne rzeczy przekraczają limit czasu z tym innym błędem, w większości przypadków nadal możemy użyć tego do indeksowania.

Pytanie 12:57 - Dotknąłeś tego, myślę, stycznie, czy powinniśmy być świadomi jakiegokolwiek trudnego lub arbitralnego limitu czasu podczas renderowania przez usługę renderowania stron internetowych. Czy jest jasne, jaka treść jest faktycznie używana, jeśli renderowanie strony przez Googlebota w usłudze renderowania zajmuje dużo czasu. Czy po prostu poddaje się i używa treści html strony, która tam była pierwotnie? Czy mamy jasność co do tego, jak daleko w procesie renderowania możesz skończyć?

Odpowiedź 13:45 - w większości przypadków, gdy coś się zepsuje lub przekroczy limit czasu, po prostu robimy migawkę od czasu do czasu. Więc tak… myślę, że w twoim przypadku, jeśli wstępnie renderujesz zawartość, nie powinno być problemu, ponieważ zawartość jest tam. To, co czasami widzimy w witrynach handlu elektronicznego lub witrynach, które korzystają z bardzo szablonowego frameworka, polega na tym, że napotykamy sytuacje, w których zakładamy, że zawartość jest zduplikowana, zanim faktycznie przetestujemy adresy URL. Może się to zdarzyć, jeśli na przykład zobaczymy wzorzec adresu URL. Jeśli na przykład uzyskujemy dostęp do wielu adresów URL z różnymi wzorcami lub różnymi parametrami i widzimy, że wszystkie te adresy prowadzą do tej samej treści, nasz system może powiedzieć „ok cóż, ten parametr nie jest już tak istotny dla witryny wszystkie” i zwykle porzucamy te adresy URL i mówimy: „ten zestaw adresów URL jest prawdopodobnie taki sam, jak ten inny zestaw adresów URL, które już zindeksowaliśmy. Tak więc w szczególności, jeśli masz rzeczy gdziekolwiek, zobaczmy, jednym z przykładów, które widziałem dość często, jest to, że masz wiele różnych witryn eCommerce i wszystkie sprzedają te same produkty - więc cała ścieżka po części produktu adresy URL są takie same w wielu domenach – wtedy nasz system powie „wszystkie te adresy URL są takie same, wszystkie prowadzą do tego samego produktu”, więc równie dobrze możemy po prostu zaindeksować jedną z tych domen zamiast wszystkich tych domen. Nie wiem, czy miałoby to zastosowanie w twoim przypadku, więc nie wiem, czy to jest przydatne, ale jest to jedna z tych rzeczy, w których nasze systemy próbują optymalizować pod kątem tego, co znajdziemy w sieci i zakładamy, że inne osoby popełniaj błędy również w sieci i staramy się to obejść. Widzimy, że „wszystkie te osoby tworzą duplikaty, ale nie musimy indeksować wszystkich tych duplikatów”, więc możemy skoncentrować się na tym, co uważamy za rzeczywiste adresy URL.

Pytanie 16:22 – Aby skorzystać z testu przyjaznego dla urządzeń mobilnych i testu na żywo w narzędziu do sprawdzania adresów URL. W teście przyjaznym dla urządzeń mobilnych Googlebot próbuje pobrać stronę z działającego serwera, więc czym różni się od narzędzia do sprawdzania adresów URL z tą funkcją? Czym się różni renderowanie lub pobieranie stron i zasobów?

Odpowiedź 17:04 - Więc pomysł z testem przyjaznym dla urządzeń mobilnych polega po prostu na sprawdzeniu, czy ta wersja jest przystosowana do urządzeń mobilnych, więc jest to główny cel. Narzędzie do sprawdzania adresów URL, narzędzie do testowania na żywo, służy raczej do sprawdzenia „jak ta strona poradzi sobie z indeksowaniem?”. czy weźmiemy tę stronę i umieścimy ją w naszym indeksie, czy nie. Test przyjazny dla urządzeń mobilnych koncentruje się głównie na stronie mobilnej, a narzędzie do sprawdzania adresów URL jest jak ten duży scyzoryk z różnymi funkcjami, których można używać do różnych rzeczy.

Pytanie 18:00 - W witrynie eCommerce naszych klientów niektóre produkty są sprzedawane jako konfigurowalne, co oznacza, że ​​wiele różnych odmian produktu jest wyświetlanych i zarządzanych na tej samej stronie. Myślimy o podzieleniu tych stron tak, aby każda z nich miała własną osobną stronę produktu z zupełnie nowym adresem URL. Opinie klientów zostałyby wtedy przeniesione ze starej strony na nowe, proste. Czy fakt, że stara recenzja ma starszą datę niż nowa data utworzenia, może być oznaczony jako black hat SEO?

Odpowiedź 18:37 - Więc nie widzę żadnego problemu z recenzjami, o ile możesz dodawać nowe recenzje do tych stron produktów. Myślę, że bardziej przyjrzałbym się temu, czy naprawdę ma sens dzielenie tych produktów na osobne strony, ponieważ to, czym handlujesz, to jedna strona produktu, która jest dość silna dla tego produktu i wszystkich jego odmian, w przeciwieństwie do wielu stron, które muszą pracować na własną rękę i być wspierane na własną rękę. Zamiast więc mieć jedną naprawdę mocną stronę dla „butów do biegania”, masz wiele stron, które muszą walczyć o „niebieskie buty do biegania”, „czerwone buty do biegania”, „zielone buty do biegania”. Więc jeśli ktoś szuka „butów do biegania”, to te małe strony nie są tak silne, jak ta jedna strona produktu, którą masz dla tego głównego produktu. Więc moja ogólna rada jest taka, że ​​jeśli myślisz, że te odmiany są tylko atrybutami głównych produktów, ludzie mają tendencję do wyszukiwania głównej treści, a następnie mówią „och, jakiego koloru chcę, to tak, jakbym znalazł produkt Chcę, ale po prostu muszę wybrać kolor, który chcę.” wtedy umieściłbym je na udostępnionej stronie. Zważywszy, że jeśli ludzie wyraźnie szukają tej odmiany i ta odmiana jest naprawdę wyjątkowa i wyróżnia się sama z siebie, a ludzie nie przychodzą do Twojej witryny tylko mówiąc „Chcę buty do biegania”, ale raczej „Chcę tego konkretnego rodzaju biegania buty w tym kolorze”, to może warto to zrobić jako osobny produkt. A więc to jest rozróżnienie, o które może bym się martwił - nie martwiłbym się tak bardzo o część z recenzjami.

Pytanie 20:36 Czy nowa funkcjonalność schematu znaczników w Search Console pozostała taka sama jak w starej?

Odpowiedź 20:50 Nie wiem, jakie są dokładne plany nowej konsoli wyszukiwania w odniesieniu do funkcji danych strukturalnych, ale planujemy obsługiwać wszystkie te funkcje danych strukturalnych. Może się więc zdarzyć, że te funkcje trafią do konsoli wyszukiwania w nieco inny sposób.

Pytanie 21:00 A co z prędkością w wersji mobilnej, czy kluczowe znaczenie ma prędkość w zielonej strefie, a jeśli tak, to dlaczego wiele najlepszych witryn wciąż jest tak wolnych?

Odpowiedź 21:20: Dobre jest to, że mamy wiele czynników rankingowych, więc nie zawsze musisz robić wszystko perfekcyjnie. Ale oznacza to również, że natkniesz się na sytuacje takie jak ta, w których mówisz „Google mówi, że szybkość jest ważna, ale najlepsza strona tutaj nie jest tak szybka, więc nie może być ważna”. Dla nas jest to zdecydowanie ważne, ale to nie znaczy, że przeważa nad wszystkim innym. Możesz sobie wyobrazić, że najszybsza strona, o której możesz pomyśleć, to prawdopodobnie pusta strona. Ale pusta strona byłaby naprawdę okropnym wynikiem wyszukiwania, gdybyś szukał czegoś naprawdę konkretnego. Jest naprawdę szybki, ale nie ma tam treści, więc użytkownik nie byłby zadowolony. Musimy więc zrównoważyć wszystkie te czynniki, treść, linki i wszystkie te sygnały, i spróbować wymyślić, jak zrobić ranking w oparciu o tę mieszankę różnych czynników, które mamy. I wprowadza zmiany w czasie, może się zmienić dość szybko. Na przykład, jeśli coś jest w tej chwili naprawdę warte opublikowania, możemy zdecydować się na pokazanie nieco innych witryn, co jest bardziej tematem badawczym, wiecznie zielonym.

Pytanie 22:30 Jaki typ znaczników schematu jest preferowany przez Google, czy powinniśmy używać formatu JSON czy mikrodanych, mikroformatów. Który jest lepszy?

Odpowiedź 22:48 Obecnie preferujemy znaczniki JSON-LD. Myślę, że większość nowych typów danych strukturalnych pojawia się najpierw dla JSON-LD, więc to jest to, co wolimy.

Pytanie 23:00 Czy Google wykonało jakieś duże aktualizacje w lutym lub marcu?

Odpowiedź: 23:15 Nie wiem, cały czas robimy aktualizacje. Nie wiem, co uważasz za ciężkie. To prawdopodobnie zależy od Twojej witryny. Jeśli jedna z tych aktualizacji mocno wpłynęła na Twoją witrynę, prawdopodobnie uważasz, że jest dość ciężka. Jeśli spojrzymy na sieć ogólnie, może to normalne zmiany, które zawsze się zdarzają.

Pytanie 23:24. Co oznacza „cienka treść” dla witryn afiliacyjnych?

Odpowiedź 23:34 Cienka treść nie oznacza nic innego dla witryn stowarzyszonych w porównaniu z innymi witrynami. Widzieliśmy, zwłaszcza w przypadku witryn afiliacyjnych, tendencję do pobierania treści z kanału, ponieważ jest to naprawdę łatwe do zrobienia. Możesz sprawić, że skrypty zrobią to za ciebie dość szybko, jest to łatwe do zrobienia, nie masz dwóch do zrobienia dużo pracy, tworzy wiele adresów URL. Ale oczywiście dla użytkowników i dla Nas nie jest to tak interesujące, ponieważ zapewniasz to samo, co wszyscy inni.

Pytanie 24:40 Czy ukryta zawartość w kartach stanowi problem z indeksowaniem?

Odpowiedź 24:50 Generalnie nie jest to problem z indeksowaniem. Może to stanowić problem dla użytkowników, więc jeśli są tam treści, które Twoim zdaniem użytkownicy naprawdę muszą zobaczyć, aby dokonać konwersji, byłoby to trochę problematyczne z Twojego punktu widzenia. Jeśli chodzi o indeksowanie, możemy pobrać tę zawartość i pokazać ją, więc to mniejszy problem.

Pytanie 25:10 Czy tekst kotwicy nadal jest ważnym czynnikiem rankingowym w 2019 roku? Wiele firm przeprowadziło badania, które wskazują, że nie ma korelacji. A potem jest link do patentu Google.

Odpowiedź 25:30 Myślę więc, że przede wszystkim nie przejmowałbym się zbytnio patentami Google, opatentowujemy wiele rzeczy, które niekoniecznie mają zastosowanie do tego, co muszą zrobić webmasterzy. Myślę więc, że to interesujące, że nasi inżynierowie pracują nad tym, ale nie musi to oznaczać, że od razu na nas to wpłynie. Jeśli chodzi o tekst zakotwiczenia ogólnie, używamy go do tekstu. To coś, co wychwytujemy. To świetny sposób na przedstawienie kontekstu linku. W szczególności w Twojej witrynie, jeśli masz link, który mówi po prostu „kliknij tutaj, aby uzyskać więcej informacji”, nie jest to dla nas zbyt przydatne. Jeśli masz link, który mówi „możesz znaleźć więcej informacji na tej stronie produktu” i link z nazwą tego produktu do tej strony, to mówi nam, że być może ta strona naprawdę dotyczy tego produktu. Dlatego z pewnością nadal będę przyglądał się tekstowi kotwicy, którego używasz, zwłaszcza wewnętrznie w witrynie, i staram się upewnić, że podajesz tekst kotwicy, który jest naprawdę przydatny i zapewnia kontekst dla tego, co jest połączone na stronie.

Pytanie 27:00 Czy możesz nam powiedzieć, jak działa proces DMCA?

Odpowiedź 27:01 Nie mogę ci powiedzieć, jak to działa, ponieważ nie znam szczegółów na ten temat, a jest to również proces prawny i nie mogę ci udzielić porady prawnej.

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

Odpowiedź 47:54 - Obie te metody działają. Tak więc plik mapy witryny pomaga nam lepiej zrozumieć nowe i zmienione strony w witrynie. Nie jest to czynnik rankingowy, więc nie osiągniesz wyższej pozycji tylko dlatego, że masz plik mapy witryny, pomaga nam to zrozumieć, które z tych stron są dostępne w witrynie, ale w większości przypadków, zwłaszcza w przypadku mniejszych witryn, możemy je normalnie zaindeksować również i nie ma dużej różnicy w sposobie wyświetlania witryny w wynikach wyszukiwania, czy możemy ją zaindeksować normalnie, czy też zaindeksujemy ją za pomocą pliku mapy witryny. Tak więc plik mapy witryny zdecydowanie nie jest krytyczny dla większych witryn, jeśli zmieniasz fragmenty treści, które czasami są nieco niższe w witrynie, to oczywiście plik mapy witryny pomaga nam znacznie szybciej znaleźć te zmiany, ale jeśli dopiero zaczynasz blog, który niekoniecznie musi zawierać plik mapy witryny.

Pytanie 48:50 – Odsprzedajemy hotele w Grecji za pośrednictwem naszej strony internetowej, opracowaliśmy dobrą, przyjazną sekcję dla hoteli, jednak powielamy również treść i tytuły tych hoteli, osadzając filmy wideo z tych hoteli na YouTube. Czy to jest dla nas szkodliwe?

Odpowiedź 49:10 — Myślę, że ten rodzaj powraca do innych pytań, które mieliśmy na temat zduplikowanych treści. Zduplikowane treści, w których naprawdę musisz się skupić na upewnieniu się, że masz coś wyjątkowego w swojej witrynie, jeśli tak naprawdę udostępniasz to samo na wielu różnych witrynach, to bardzo trudno nam powiedzieć, że tak jest właściwie strona internetowa, której potrzebujemy, aby pokazać wyniki wyszukiwania. Więc to jest coś, co polecam zrobić krok wstecz i pomyśleć o tym, co możesz zrobić, aby upewnić się, że Twoja witryna jest naprawdę wyjątkowa i atrakcyjna sama w sobie, a nie tylko to samo, co wszystkie inne witryny.

Pytanie 50:00 – Jeśli artykuł został przekierowany, ponieważ zawierał mało treści i miał wiele lat, czy negatywne skutki artykułu są przekazywane wraz z przekierowaniem?

Odpowiedź 50:12 - Niekoniecznie. Dlatego szczególnie jeśli chodzi o treść, przyglądamy się treściom, które znajdujemy na ostatecznej stronie, na której lądujemy. Więc jeśli usunąłeś zawartość, jeśli coś posprzątałeś i myślę, że dzieje się to automatycznie. jeśli przekierujesz tę stronę, a starej zawartości już nie ma, a my mamy tylko nową zawartość, to jest w porządku. Więc to nie byłoby nic, co mogłoby być kontynuowane.

Pytanie 50:45 – Czy to naturalne, że konsola wyszukiwania zgłasza błędy dostosowane do urządzeń mobilnych w testowej wersji strony, gdy powiążemy wersję strony dostosowaną do urządzeń mobilnych z działaniem link rel alternatywnym

Odpowiedź 50:57 - Zwykle oznacza to, że nie mamy jasnego zrozumienia, które z tych stron należą do siebie. Dlatego z tego czy innego powodu indeksowaliśmy te strony pojedynczo, a nie jako parę, o której wiemy, że ta strona na komputery należy do tej strony mobilnej. Wskazuje to na być może niezgodność ze sposobem, w jaki skonfigurowałeś link alternatywny lub link kanoniczny rel na tych stronach. Zastanawiam się też nad tym, a drugą rzeczą jest oczywiście sprawdzenie, czego potrzeba, aby przejść do projektowania responsywnego, ponieważ szczególnie w przypadku pierwszego indeksu mobilnego wszystkie tego rodzaju problemy, w których mamy osobny telefon komórkowy Adresy URL po prostu wszystko niepotrzebnie komplikują. Zważywszy, że jeśli możesz przejść do projektu responsywnego lub projektu, który używa tych samych adresów URL dla wersji na komputery i urządzenia mobilne. Więc oszczędzasz sobie tyle kłopotów, więc zamiast podążać za tego rodzaju problemami, może poświęć trochę czasu, aby powiedzieć, dobrze, powinienem zainwestować w plan przejścia na responsywny projekt, abym nie musiał się na nich koncentrować problemów w przyszłości.

Pytanie 1:01:01 – Czy to dobry pomysł, aby dodać link nofollow do linku wikipedii i artykułów pomocy Google, tak jak inne linki zewnętrzne? A ile czasu zajęło dobre zakreślanie danych, aby zacząć działać w wyszukiwaniu?

Odpowiedź 1:01:16 - Skay, więc dodaj nofollow do linków Wikipedii. Myślę, że nie ma to większego sensu, chyba że Wikipedia płaci ci za umieszczenie tych linków. Więc II dodałbym nofollow do linków, których nie chcesz kojarzyć ze swoją witryną. Ale w przeciwnym razie, jeśli jest to normalny link w treści i wyglądałbym normalnie, więc chyba że Wikipedia płaci za te linki, myślę, że po prostu myślę normalnie. W przypadku markera danych to, co się dzieje, jest rodzajem procesu algorytmicznego, który może zająć trochę czasu, ponieważ opiera się na stronach pamięci podręcznej, których uczy się ze stron indeksowych w Twojej witrynie i oczywiście na podstawie znaczników, które wykonujesz na danych zakreślacz, a następnie pobiera to i stosuje do nowych stron, gdy ponownie je indeksujemy i ponownie indeksujemy w Twojej witrynie. Jest to więc coś, co zajmuje trochę czasu, gdy dotyczy treści, ponieważ ponownie ją indeksujemy i ponownie indeksujemy w Twojej witrynie. Więc nie ma ustalonej osi czasu, która czasami jest dość szybka dla wielu stron, a czasami może minąć kilka miesięcy, zanim będą widoczne. Więc nie ma na to żadnego przycisku natychmiastowego, zajmuje to trochę czasu, podobnie jak inne uporządkowane dane, które dodałbyś do swoich stron ręcznie.

Pytanie 1:02:58 – Czy firma Google jest świadoma i ogłasza istotną zmianę w sposobie traktowania duplikatów treści pod koniec listopada na początku grudnia ubiegłego roku? A może nastąpiła istotna zmiana w sposobie działania usługi renderowania stron internetowych lub relacji między renderowaniem i indeksowaniem stron internetowych a indeksowaniem indeksowanym w tym okresie, ponieważ nic się nie zmieniło w naszym systemie i od tego czasu widzieliśmy, jak powiedziałem, poważne problemy w szczególności nie tylko dla nas samych, ale zauważyliśmy również wiele innych obserwacji tej klasy problemu w tym samym okresie?

Odpowiedź - 1:03:47 - Gdzie coś się zmieniło. Jedyną rzeczą, która moim zdaniem wydarzyła się mniej więcej jesienią, jest to, że zaczęliśmy dodawać tę funkcję do konsoli wyszukiwania, aby w pewien sposób wyróżnić te problemy i myślę, że również tam, gdzie zacząłem widzieć więcej tych raportów, kiedy już to podkreśliliśmy użytkownicy, którzy, hej, porzucaliśmy te adresy URL i lubimy, że jest ich wykres, ponieważ uważamy, że wszystkie są zduplikowane, i oczywiście wszyscy mówią: och, to jest nowy problem, ale w dużej mierze zawsze tak było że po prostu nigdy o tym nie rozmawialiśmy w Search Console. Więc nie wiem dokładnie, kiedy zaczęliśmy wprowadzać tę funkcję w konsoli wyszukiwania, ale prawdopodobnie tak jak w drugiej połowie zeszłego roku, coś w tym czasie.