5 mitów SEO - maria cieślak

Na co dzień zajmuję się optymalizacją stron chciałabym przedstawić mity związane optymalizacją i działaniem niektórych elementów on-page. Wybór 5 mitów SEO to wynik pytań (i wątpliwości) jakie dostaję od klientów, newsów w branży, a część powstała na podstawie częstych problemów jakie napotykam w czasie audytów SEO.

Mit 1. Google Cache nie wyświetla mojej strony to znaczy Google niepoprawnie renderuje moją stronę.

Mam na myśli tutaj to, co zobaczymy po kliknięciu w Cache (Kopia) z wyników wyszukiwania Google lub wpisując w pasku adresu: cache:https://www.twoj-adres-url.pl  

Zdarza się, że klienci są zaniepokojeni, jeśli w Google Cache zobaczą niepoprawnie wyrenderowaną stronę. W wielu przypadkach nie powinniśmy się tym mocno przejmować. Dlaczego? To, co zobaczymy w Google Cache to czysty kod HTML, który został pobrany przez Googlebota, a następnie został wyrenderowany przez Twoją przeglądarkę. Wystarczy, że jeden z zasobów został zmodyfikowany zanim Google ponownie przecrawluje stronę i możemy zobaczyć niepoprawnie wyrenderowaną stronę.

Zatem jeśli chcemy podejrzeć czy Google poprawnie renderuje stronę powinniśmy zajrzeć do raportu Fetch & Render w GSC.

Mit 2. Dla domen targetujacych rynki międzynarodowe i wykorzystujace hreflangi: każda wersja językowa musi mieć osobny URL podany w hreflangach.

W ostatnim czasie temat implementacji hreflangów stał się dość gorący i w związku z tym  Google ujawniło kilka ciekawych informacji w tym zakresie. Dla mnie najciekawszym wątkiem jest wykorzystywanie tego samego adresu URL do targetowania wielu krajów (wersji językowych). Wcześniej, pogląd był taki że każda wersja językowa mysi mieć swój osobny adres URL czyli hreflangi powinny wygladać tak:

<link rel=”alternate” href=”https://www.example.com/us/about/” hreflang=”en-us”>

<link rel=”alternate” href=”https://www.example.com/gb/about/” hreflang=”en-gb”>

<link rel=”alternate” href=”https://www.example.com/ie/about/” hreflang=”en-ie”>

Powyżej mamy sytuację, gdzie wszystkie wersje językowe są po angielsku. Katalog /us/ targetuje Stany Zjednoczone, natomiast katalogi /gb/ i /ie/ powinny być wyświetlane w odpowiednich anglojęzycznych krajach europejskich. W ostatnim czasie Google ujawnił, że następująca implementacja też zadziała:

<link rel=”alternate” href=”https://www.example.com/us/about/” hreflang=”en-us”>

<link rel=”alternate” href=”https://www.example.com/eu/about/” hreflang=”en-gb”>

<link rel=”alternate” href=”https://www.exmaple.com/eu/about/” hreflang=”en-ie”>

Czyli w tym przykładzie dla dwa różne kraje europejskie targetujemy jednym adresem URL (/eu/).

Mit 3. Stosowanie tagu rel=canononical i metatagu noindex na tej samej podstronie

Podczas analizy stron zdarza mi się natrafiać na podstrony, które zawierają tag canonical do innej podstrony oraz równocześnie mają ustawiony tag: noindex. Domyślam się, że jest to próba upieczenia dwóch pieczeni na jednym ogniu. Z jednej strony chcemy usunąć z indeksu mało wartościową lub zduplikowaną stronę, a z drugiej strony chcemy jeszcze z niej coś wycisnąć i przekazać autorytet do innej podstrony.

To rozwiązanie to tak naprawdę wysyłanie sprzecznych sygnałów do Google i możemy uzyskać odwrotny efekt niż oczekujemy. Canonical informuje Google, że dwie strony są takie same. Zatem jeśli zastosujemy canonical w takiej sytuacji:

  1. Google może go po prostu zignorować go interpretując to jako pomyłkę w implementacji. Jeśli jedna strona jest indeksowalna, a druga nie to jak mogą być takie same?
  2. Google może przekazać “noindex” to strony wskazanej w canonicalu – to ten gorszy scenariusz kiedy w rezultacie może dojść do wyindeksowania strony którą chcemy zachować w indeksie.

Mit 4. Noindex jako bezpieczna metoda usuwania stron niskiej jakości z indeksu Google

Faktem jest że noindex powinien być wykorzystywany w celu ograniczenia wyświetlania się w Google małowartościowych stron dla użytkowników. Jednakże, w świetle ostatnich informacji ze strony Google powinniśmy wziąć pod uwagę ważną informacje. Jeśli strona przez dłuższy czas jest nieindeksowalna, Google zaczyna traktować linki wewnętrzne wychodzące z tej podstrony jako mające ”nofollow”. Możliwe, że wywodzi się to z podejścia – jeśli strona jest mało wartościowa i nie zasługuje na bycie w indeksie, to dlaczego linki wewnętrzne mają przekazywać wartość.

Zanim dodamy do jakiejś podstrony lub sekcji tag noindex, zastanówmy się najpierw czy nie da się danej podstrony przebudować, tak aby miała większą wartość. Może mieć to szczególne znaczenie jeśli jest to podstrona nawigacyjna (strona, która zawiera głównie linki np. do głębszych sekcji strony).

Mit 5. Speed Update ma wpływ na rankingi – szybkie strony mogą pójść do góry, wolne spadają.

W ostatnim czasie (Lipiec 2018) Google wprowadziło aktualizację algorytmu związaną z szybkością ładowania się – performance stał się czynnikiem rankingowym dla stron mobilnych. Spotkałam się z podejściem, w którym w natychmiastowym tempie trzeba było przyspieszać stronę, bo możemy zyskać w rankingach. Niestety, jest to mit. Ostatnia aktualizacja algorytmu była skierowana w obniżenie widoczności najwolniejszych stron w internecie. I nie chodzi tu o strony, które ładują się kilka, kilkanaście sekund.

Nie oznacza to oczywiście że nie powinniśmy dbać o to jak szybko się strona ładuje. Wręcz przeciwnie!

Performance po stronie frontendu wpływa na to ja użytkownicy odbierają Twoją stronę, odbija się to oczywiście na konwersji. Google oceniając performance strony bierze również pod uwagę dane z Chrome User Experience, czyli z raportu który zbiera podstawowe dane dotyczące szybkości ładowania się strony z przeglądarki użytkowników.

Natomiast, performance po stronie backendu bezpośrednio wpływa na crawlowanie strony – jeśli serwer zwalnia pod wpływem crawlowania, Googlebot zmniejsza liczbę requestów.

Maria CieślakArtykuł opracowała:

Zmiana na Maria Cieślak – Head of Technical SEO – Onely

Comments

  • Tomek

    "Google może przekazać “noindex” to strony wskazanej w canonicalu – to ten gorszy scenariusz kiedy w rezultacie może dojść do wyindeksowania strony którą chcemy zachować w indeksie."

    Nie jest to trochę wniosek wyciągnięty na siłę? Mamy ponad rok no index i canonical i nigdy wyżej opisana sytuacja nie miała miejsca.

    September 18, 2018 at 12:56 pm
  • Adam

    A mi się to przytrafilo. Dzięki za info. Noindex z canonial wyindeksowal mi najważniejsze strony.

    September 19, 2018 at 9:34 pm

Comments are closed.