Twoja wiadomość już do nas leci - napiszemy bądź zadzwonimy do Ciebie tak szybko, jak to możliwe.
Tymczasem, zajrzyj na nasze social media:
Zajrzyj na swoją pocztę, aby poznać szczegóły oferty ;)
Tymczasem, sprawdź nowości na naszym blogu semahead.agency/blog/
Zespół Semahead
Na Twoją skrzynkę wysłaliśmy wiadomość potwierdzającą subskrypcję.
Tymczasem, zajrzyj na nasze social media:
'
Twój formularz już do nas leci - za chwilę otrzymasz informację zwrotną na podany w zgłoszeniu email.
Tymczasem, możesz zajrzeć na nasze social media:
Prawdopodobnie nie ma na świecie osoby, która z zadowoleniem przyjęłaby konieczność czekania na załadowanie się treści. Tyczy się to zwłaszcza millenialsów oraz pokolenia Z, którzy są przyzwyczajeni do natychmiastowych odpowiedzi. Według badań z 2018 roku dla Google, jeśli wczytywanie strony zajmuje 5 sekund, to prawdopodobieństwo zamknięcia jej wynosi 50 procent, co jasno świadczy o tym, że szybka strona to nie tylko dobre rozwiązanie, ale obecnie konieczność.
Z tego artykułu dowiesz się między innymi:
Masz zaledwie chwilę, by zrobić dobre pierwsze wrażenie. Jeśli ci się nie uda, istnieje wysokie prawdopodobieństwo, że nie będzie drugiej szansy i nie zatrzymasz użytkownika na dłużej. Dostępność rozmaitych stron internetowych sprawia, że wygrają najlepsi, najlepiej zoptymalizowani pod kątem SEO i UX.
Równie niecierpliwy jest robot Google, który również nie będzie czekał w nieskończoność na załadowanie treści znajdującej się na danej stronie. Zarówno użytkownicy, jak i roboty są coraz bardziej wymagający a ich akceptowalny czas oczekiwania na daną treść to: natychmiast.
Google nie zostawia jednak stron internetowych bez pomocy. Narzędzie o nazwie Google Page Speed jest w stanie wygenerować listę błędów, które powodują spowolnienie strony. Daje również zalecenia, których wprowadzenie spowoduje przyśpieszenie witryny. Jednym z zaleceń jest wdrożenie tzw.mechanizmu „Lazy Loading”.
Lazy loading (inaczej opóźnione ładowanie) występuje najczęściej w formie skryptu, który powoduje, że część treści, która nie jest istotna w danym momencie, ładuje się dopiero w momencie, kiedy zachodzi taka potrzeba, czyli jeśli użytkownik do niej „zescrolluje”. Przykład:
Źródło: https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video
Mechanizm ten występuje najczęściej w parze z obrazkami, które znajdują się np. na końcu strony. Nie ma potrzeby, by ładowały się one od razu, ponieważ może to znacząco spowolnić podstawowe elementy strony. Dopiero gdy użytkownik zjedzie do danego obszaru, to wtedy on się załadowuje.
Nie oszukujmy się, użytkownik często nawet nie dotrze do galerii na samym dole strony, ani do filmu below the fold, czyli treści, którą zobaczmy dopiero po przescrollowaniu się przez stronę – części której nie widać od razu po załadowaniu się witryny. Dlatego nie warto marnować na nie czasu.
Poprzez opóźnienie ich załadowania (tzw. initial render) można zyskać ułamki sekund, jednak są one bardzo cenne, biorąc pod uwagę, że strona osiąga dobry wynik, jeśli ładuje się około 2 sekundy. Dzięki zastosowaniu tej techniki pierwsze ładowanie strony zajdzie dużo szybciej również dla robota Google.
Wiele osób z pewnością spotkało się, nawet nieświadomie, z obecnością lazy loading w serwisach, które przeglądają. Jeśli widziałeś rozmyte obrazki, które dopiero po chwili nabierają ostrości, coś, co wydawało się tylko obrazkiem, okazywało się filmem, bądź też pod koniec listy z artykułami pojawiał się znak ładowania i pojawiały się kolejne artykuły – oznacza to, że na danej stronie najprawdopodobniej zastosowano lazy loading.
Wszystkie logo znajdujące się na stronie powinny wczytać się od razu. Ponadto zdjęcia, filmy i inne treści, które znajdują się na samej górze strony, czyli treści, które widzimy zaraz po wejściu na stronę, powinny wczytać się priorytetowo.
Jeśli zaimplementujemy błędnie ten skrypt, możemy sprawić, że na stronie pojawi się chaos, a użytkownik nie zobaczy w odpowiednim czasie grafik, które zdecydowanie powinien zobaczyć.
Czym jest pojęcie above the fold/below the fold?
https://www.alltechbuzz.net/google-allows-large-ads-above-fold/
Szybkość ładowania się strony jest jednym z istotnych czynników rankingowych wpływających na pozycję strony w wyszukiwarce. Ponadto, co dla wielu osób jest bardzo istotne – można wprowadzić lazy loading zupełnie za darmo (kosztem w tym wypadku jest programista posiadający odpowiednią wiedzę o implementacji lazy loading).
By zastosować lazy loading, należy sprawnie posługiwać się JS. Najpopularniejsze CMS-y wychodzą naprzeciw właścicielom sklepów i osobom bez wsparcia programistycznego, proponując rozmaite wtyczki. Do WordPressa można zaimplementować Lazy Loader. Pozwala ona na wprowadzenie lazy loading na obrazki, elementy audio i video. Wtyczki do lazy loading są dostępne również w CMSach takich jak: Joomla, Drupal, Magento, Presta.
Jednym z rozwiązań jest skorzystanie z darmowych i lekkich gotowych bibliotek. Przykładowa lekka biblioteka.
Z jednej strony Google zaleca, by witryny były jak najszybsze. Z drugiej jednak strony w pewnym sensie lazy loading blokuje robotowi Google pełny dostęp. Parę lat temu Google boty całkowicie ignorowały kod JS, jednak aktualne przeznaczone są pewne zasoby Googla do renderowania kodu Java Script, jednak Robot Google nie scrolluje, ani nie wykonuje żadnych akcji na stronie.
Oznacza to, że obrazki się po prostu nie wczytają. Rozwiązaniem są tzw. fallbacki, które uruchamiają się, gdy Java Script nie działa – wówczas obrazki załadują się „normalnie”. To zabezpieczenie dla robota, ale również np. dla użytkowników, którzy w swojej przeglądarce mają wyłączone JS. Można użyć np. tagu <noscript>, a w nim umieścić adres zdjęcia. Co ważne, fallback powinien uruchamiać wtedy, gdy JS nie jest obsługiwany (i tylko wtedy).
Są to skuteczne sposoby implementacji, jednak przeglądarka chrome wychodzi naprzeciw twórcom i właścicielom stron internetowych i przygotowuje natywne wsparcie lazy loading w najnowszej wersji Chrome.
Od wersji 75 oferuje tzw. natywne lazy loading. Polega to na tym, że Chrome po swojej stronie wprowadza to rozwiązanie na stronach posiadających dużą liczbę grafik. Zaletą tego rozwiązania jest to, że nie tylko ograniczony zostanie czas potrzebny na wczytanie obrazków, ale również ograniczamy liczbę Java Scriptów na stronie.
Więcej o tym rozwiązaniu opowiada Addy Osmani, który jest inżynierem ds. technicznych w Google odpowiedzialnym za przeglądarkę Chrome – https://addyosmani.com/blog/lazy-loading/.
Takim przykładem jak miałoby to być zaimplementowane w kodzie z użyciem odpowiednich atrybutów dla obrazków, może być kod:
<!– Lazy-load an offscreen image when the user scrolls near it –> <img src=”unicorn.jpg” loading=”lazy” alt=”..”/> <!– Load an image right away instead of lazy-loading –> <img src=”unicorn.jpg” loading=”eager” alt=”..”/> <!– Browser decides whether or not to lazy-load the image –> <img src=”unicorn.jpg” loading=”auto” alt=”..”/> <!– Lazy-load images in <picture>. <img> is the one driving image loading so <picture> and srcset fall off of that –> <picture> <source media=”(min-width: 40em)” srcset=”big.jpg 1x, big-hd.jpg 2x”> <source srcset=”small.jpg 1x, small-hd.jpg 2x”> <img src=”fallback.jpg” loading=”lazy”> </picture> <!– Lazy-load an image that has srcset specified –> <img src=”small.jpg” srcset=”large.jpg 1024w, medium.jpg 640w, small.jpg 320w” sizes=”(min-width: 36em) 33.3vw, 100vw” alt=”A rad wolf” loading=”lazy”> <!– Lazy-load an offscreen iframe when the user scrolls near it –> <iframe src=”video-player.html” loading=”lazy”></iframe>
Aktualnie jest to domyślne w Google Chrome. Jeśli zaawansowany użytkownik ma potrzebę wyłączenia lazy loading należy przejść w Chromie do: chrome://flags a następnie wyłączyć „Enable lazy image loading” oraz „Enable lazy frame loading”. W tym samym miejscu można również ponownie włączyć lazy loading.
Jeśli wprowadzimy lazy loading, należy sprawdzić, czy nie ukryliśmy niechcący treści przed robotem. Google udostępnia jednak narzędzie, które pozwoli sprawdzić, czy implementacja zaszła tak, by robot zobaczył wszystko, co powinien. Więcej o sprawdzeniu lazy loading dowiesz się w dokumentacji Google: https://developers.google.com/search/docs/guides/lazy-loading?hl=pl.
Znajduje się tam m.in. skrypt Puppeteer, który pozwala przetestować implementację lokalnie, jednak niezbędna jest wiedza programistyczna. Po uruchomieniu skryptu zostaną wykonane zrzuty ekranu, tego, jak widzi daną stronę Google – można wówczas porównać screeny z tym, co powinien widzieć zarówno użytkownik, jak i Google.
Inną, łatwiejszą opcją by sprawdzić, jak rednerowana jest strona przy zastosowaniu lazy loadingu, a więc czy wszystkie obrazki i treści wyświetlają się prawidłowo w oczach Google, jest użycie Google Search Console – udostępniona jest tam opcja sprawdzenia tego.
Bez wątpienia szybkość strony jest jednym z ważniejszych czynników rankingowych. Pojawia się pytanie – czy warto walczyć o każdą milisekundę? Zdecydowanie tak – będzie to nie tylko dobrze wpływało na SEO, ale również zyskamy w oczach użytkowników. Akamai sprawdziło, że dla prawie połowy użytkowników więcej niż 2 sekundy to zbyt długi czas, by czekać na odpowiedź strony – zadbajmy o naszych użytkowników i nie pozwólmy im czekać.
Zgłoś się do nas – a pomożemy ogarnąć Twoje SEO.
Dostępność narzędzi i źródeł wiedzy na temat SEO sprawia, że wiele działań jesteśmy w stanie przeprowadzić we własnym zakresie. Na co zwrócić uwagę, kiedy decydujemy się na samodzielną optymalizację witryny i które działania w szczególności wdrożyć?
Z tego artykułu dowiesz się między innymi:
To, czy warto podjąć się prowadzenia SEO we własnym zakresie, zależy od kilku czynników. Przede wszystkim należy wziąć pod uwagę skalę naszego biznesu. Jeśli strona ma już zbudowaną historię i przynosi realne zyski, nieodpowiednimi działaniami możemy przynieść więcej strat niż korzyści.
W takim przypadku dobrym pomysłem jest utworzenie dodatkowego serwisu w celach testowych, gdzie będziemy mogli sprawdzić skuteczność naszych rozwiązań i dopiero wtedy stosować je na właściwej stronie. Jednak jeśli nie mamy pewności co do efektów naszych działań, bezpieczniej skonsultować je ze specjalistą SEO.
W przypadku gdy rozpoczynamy pracę nad nową stroną lub też zajmujemy się niewielką witryną, która nie wypracowała jeszcze widoczności i ruchu, nic nie stoi na przeszkodzie, aby samodzielnie podjąć się działań optymalizacyjnych.
W przypadku niewielkiej strony możemy zadbać o optymalizację elementów takich jak:
Zmiany dotyczące tych elementów są możliwe do wprowadzenia z poziomu panelu większości systemów CMS i ich wdrożenie nie powinno przysporzyć problemów. Wiedzę na temat ich optymalizacji możemy czerpać z licznych blogów branżowych, e-booków, kursów czy też oficjalnych wytycznych Google. Możemy też skorzystać z darmowych wtyczek czy „audytów SEO online” i zapoznać się z aktualną sytuacją strony. Ważne, aby stale monitorować wyniki testowanych rozwiązań, dzięki czemu sami możemy weryfikować, co jest skuteczne w przypadku naszej witryny.
Pierwszym krokiem przy pracy nad naszym serwisem powinien być dobór fraz kluczowych, na które chcemy być widoczni w wyszukiwarce. W tym celu warto najpierw przeprowadzić analizę konkurencji i sprawdzić, na jakie frazy wyświetlają się rywalizujące z naszą stroną witryny, co pomoże w wytypowaniu najważniejszych także z naszego punktu widzenia słów. Do wybrania odpowiednich fraz możemy skorzystać z dedykowanych narzędzi takich jak Planer słów kluczowych Google czy Ubbersuggest. Propozycje słów kluczowych otrzymujemy też już na poziomie samej wyszukiwarki, która przy wpisywaniu zapytania podpowiada frazy wyszukiwane przez internautów.
Zanim przejdziemy do uzupełnienia witryny o dobrane wcześniej frazy, musimy dopasować je do odpowiednich stron w serwisie. Jeśli umieścimy je w zbyt wielu miejscach, doprowadzimy do zjawiska kanibalizacji treści, czyli sytuacji, w której kilka stron zoptymalizowanych pod te same słowa kluczowe rywalizuje ze sobą o widoczność w wyszukiwarce. Aby temu zapobiec, należy zadbać o czytelną, zarówno dla użytkowników, jak i wyszukiwarki, strukturę serwisu. Przemyślana architektura informacji znacznie ułatwi osiągnięcie założonych efektów, dlatego jej zaplanowanie powinno stać się punktem wyjściowym dla dalszych prac nad serwisem.
Drugim krokiem jest krótki audyt SEO, który pozwoli zweryfikować nam, w jakim stopniu strona jest zoptymalizowana pod interesujące nas słowa kluczowe. Nawet bez zaawansowanej wiedzy na temat optymalizacji, jesteśmy w stanie sprawdzić poprawność wdrożenia wielu elementów na stronie. Z pomocą przychodzą różne darmowe narzędzia i wtyczki, dzięki którym możemy przyjrzeć się ewentualnym błędom.
Przykładem są rozszerzenia takie jak SEOquake i Web Developer przydatne przy analizie onsite witryny. Narzędzie Screaming Frog, którego bezpłatna wersja umożliwia sprawdzenie 500 adresów URL, dostarczy nam istotnych informacji na temat struktury serwisu. Nie można też zapomnieć o dodaniu strony do Google Search Console i Google Analytics, aby na bieżąco śledzić stan indeksowania, monitorować ruch i wykrywać pojawiające się problemy.
Jak zdobywać linki, prowadząc samodzielne działania SEO? Przede wszystkim warto obserwować, a także udzielać się w roli eksperta na blogach, forach oraz w branżowych social mediach. W ten sposób zwiększymy rozpoznawalność brandu, a tam, gdzie to możliwe, do merytorycznego i wyczerpującego komentarza dodamy również odnośnik do naszej witryny.
Płatne działania link buildngowe, jeśli nie mamy w nich doświadczenia, lepiej zlecić freelancerowi lub agencji. Bez odpowiedniej wiedzy i narzędzi trudno zweryfikować, czy zainwestowane pieniądze przyniosą adekwatny rezultat.
Konsultacji ze specjalistą wymagają też elementy związane z technicznym SEO. Jeśli chcemy uniknąć poważnych błędów na stronie, których konsekwencje mogą być odczuwalne przez długi czas, działania takie optymalizacja przekierowań czy zarządzanie dostępem dla robotów warto powierzyć specjaliście SEO.
Jeśli współpracujemy z deweloperem, we własnym zakresie możemy również wykonać optymalizację szybkości strony. Samo zmniejszenie rozmiaru grafik pozwoli nam na znaczne przyspieszenie działania witryny. Do tego możemy dodać optymalizację pod kątem UX, która przełoży się na lepszy odbiór naszej strony przez użytkowników i poprawę współczynnika konwersji.
Wiele z istotnych zmian, które przekładają się na wyniki w postaci widoczności i ruchu, możemy wprowadzić we własnym zakresie. Testowanie różnych rozwiązań i stałe monitorowanie wyników naszych działań pomoże nam w weryfikacji, które z nich się sprawdzają i przynoszą najlepsze efekty.
Kiedy chcemy optymalizować serwis, który ma już zbudowaną historię i przynosi realne zyski, bezpieczniej jest utworzyć stronę testową, gdzie będziemy sprawdzać rezultaty naszych działań, lub też skonsultować się ze specjalistą SEO. W ten sposób nie narazimy strony na trudne do odbudowania spadki.
Nikogo nie trzeba przekonywać, że marzec to trudny czas, także dla SEO. Obecny miesiąc stoi pod znakiem spadków w wielu branżach oraz konieczności odwołania branżowych spotkań. Jednak jak po burzy zawsze wychodzi słońce, tak po spadkach – wzrosty. Dlatego, aby być na bieżąco z nowościami, zapraszam na marcowe wydanie SEO&Content Express.
W 2017 roku Google uruchomiło zestaw funkcji w wyszukiwarce oraz mapach, które aktywowane są w czasie dużych kryzysów jak np. klęski żywiołowe. Mają one na celu zwalczanie dezinformacji i paniki – użytkownik ma dostać najświeższe, wiarygodne informacje, bez konieczności odsiewania niepotwierdzonych źródeł.
Wyświetlane wiadomości mogą się różnić w zależności od lokalizacji. Obecnie wpisując hasło koronawirus w przeglądarce, pojawia się panel z czerwoną belką. Pod nią znajdują się Najważniejsze artykuły oraz sekcja Pomoc i informacje pochodzące z zaufanych źródeł (https://www.who.int/, www.gov.pl), a także sekcja Obszar obrazująca zasięg wirusa na mapie.
Również mniej popularne w Polsce wyszukiwarki, jak na przykład Bing, angażują się w pomoc w opanowaniu pandemii i paniki, którą może wywołać przesycenie sprzecznymi informacjami. Specjalnie dedykowana strona https://www.bing.com/covid pokazuje mapę zagrożeń, oficjalne statystyki, a po kliknięciu na dany kraj (w Stanach nawet miasto), wszystkie aktualne i najświeższe informacje z oficjalnych źródeł.
Senuto przeprowadziło szczegółowe badanie na temat pracy w branży SEO w lutym 2020 roku. Już teraz możecie zobaczyć pełny i przejrzysty raport z wynikami. W opracowaniu znajdziecie informacje m.in o tym:
Poruszono również kwestę budzącą jak zwykle najwięcej emocji, czyli temat wynagrodzeń. Zachęcam do pełnej lektury pod adresem: https://www.senuto.com/pl/raport-praca-w-branzy-seo-2020/
Zachęcam do zapoznania się z raportem „Whitepress Top 100 kobiet w polskiej branży SEO„, w którym specjalistki dzielą się swoimi spostrzeżeniami. Robię to z jeszcze większą przyjemnością, ponieważ wśród grona specjalistów znalazła się nasza semaheadowa koleżanka Klaudia Kosińska (Gratulacje!). Raport zwraca uwagę na ważne kwestie – zarówno te pozytywne, jak i wymagające refleksji.
Dokument dostępny jest tutaj: https://www.whitepress.pl/baza-wiedzy/649/top-100-kobiet-w-polskiej-branzy-seo
Użytkownicy często szukają odpowiedzi na pytania w formie filmu-poradnika. Niech rzuci kamieniem ten, kto nigdy nie przesuwał po pasku timeline na YouTube w poszukiwaniu konkretnego fragmentu (lub oglądał film w przyspieszeniu, ze znużeniem czekając na właśnie TEN moment). Obecnie funkcja osi czasu wideo zyskuje na widoczności w wyszukiwaniu mobilnym.
Warunkiem dostępności funkcji jest opis tych momentów wprowadzony przez autora filmu w serwisie YouTube, który – póki co – jest jedyną platformą, którą obsługuje Google w tym zakresie. Więcej na: https://searchengineland.com/google-showing-key-moments-feature-on-multiple-videos-in-search-results-330409
John Mueller z Google został zapytany, czy błędy podczas walidacji W3C wpływają na szybkość ładowania strony. Odpowiedź była negatywna. Dodał również, że nie ma to wpływu na wyniki wyszukiwania. Ale! Jednocześnie rekomenduje, aby korzystać z niej z innego powodu. Chodzi o kwestię dostępności stron – poprawny kod pozwoli na spełnienie potrzeb różnych użytkowników, również tych z niepełnosprawnościami.
https://www.searchenginejournal.com/googles-john-mueller-we-do-not-use-w3c-validation-in-search-results/355114/
6 marca Dev Group w krakowskim Muzeum Sztuki i Techniki Japońskiej Manggha zorganizowała 14. edycję semKRK. Wśród prelegentów znaleźli się:
Pełne sprawozdanie na stronie organizatorów (można tam również znaleźć materiały z prezentacji): https://www.devagroup.pl/blog/networking-wiedza-i-smok-w-3d-semkrk14-za-nami
1 marca 2020 Google wdrożyło aktualizację przynoszącą zmianę interpretacji wewnętrznych linków nofollow (atrybut linku mówiący robotom, aby za nim nie podążać). Wcześniej Google traktowało linki nofollow jako dyrektywę, od marca mogą służyć jako wskazówka do crawlowania i indeksowania. Na razie trudno przewidzieć jak może to wpłynąć na ranking, ale warto obserwować zmiany i sprawdzić jak wygląda użycie atrybutu na naszych stronach.
https://www.searchenginejournal.com/nofollow-crawl-indexing-update/349994/
Rozpoczęte niedawno kampanie reklamowe niektórych firm nie będą dobrze wspominane przez ich twórców. Obrazy, hasła zachęcające do wykonywania czynności, które w czasie pandemii nie są akceptowane, zmusiły np.: KFC (“Finger Lickin’ Good”) czy Hershey, producenta czekoladek, który w reklamach przekonywał do przytulania i podawania sobie dłoni, do wstrzymania kampanii i wycofania spotów i banerów. Więcej na: https://marketingprzykawie.pl/espresso/marki-wstrzymuja-reklamy-ktore-moglyby-zostac-zle-zrozumiane-czasie-epidemii/
Autokorekta w Word czy nawet w Google Docs potrafi całkiem sporo. Czasami jednak popełnia błędy. Jeżeli chcesz uczyć się na swoich błędach w trakcie tworzenia tekstu, powinieneś spróbować darmowych narzędzi dedykowanych dla języka polskiego.
Jednym z ciekawszych przykładów jest LanguageTool. Poza wskazaniem błędów sugeruje poprawne sformułowanie, a także odsyła do konkretnych zasad języka, które o tym decydują. Więcej bardzo ciekawych programów, które pokażą Ci nawet wydźwięk emocjonalny tekstu pod linkiem: https://marketingdlaludzi.pl/narzedzia-do-korekty-tresci/
„Na dzień dzisiejszy można wziąść pierwszy z brzegu tekst w internecie i napewno znajdziesz w nim conajmniej niewiem ile błędów językowych”. To tylko przykład, w którym, dla sporej ilości osób czytających, nie ma nic niewłaściwego, gdyż przekaz jest zrozumiały (podczas pisania tego zdania musiałam ze sobą walczyć przy każdym nieprawidłowo napisanym wyrazie – to była naprawdę ciężka walka).
W internecie błędy językowe zdarzają się co 7 sekund. Dziennie jest ich ponad 12000. Językoznawcy biją na alarm. Niestety jakość redakcji tekstów oraz poziom faktycznej znajomości języka i jego zasad, wśród osób odpowiedzialnych za treści, nie napawa optymizmem. Badania przeprowadzone przez Nadwyraz.com oraz Polszczyzna.pl wskazują 100 najczęściej popełnianych błędów w roku 2019 (najlepiej przeczytać i szybciutko zapomnieć, żeby niepoprawne formy nie zdążyły się przypadkiem utrwalić).
Pełny raport z badania dostępny na: https://polszczyzna.pl/100-najczesciej-popelnianych-bledow-w-internecie-w-2019-roku/
Powierz swoje SEO specjalistom. Skontaktuj się z nami!
W 2019 roku trudno wyobrazić sobie stronę internetową bez zalet, oferowanych przez JavaScript. Dzięki niemu witryna nabiera interaktywności oraz atrakcyjności wizualnej. Obok wielu zalet niestety mogą pojawić się także wady. Nieumiejętne jego użycie może prowadzić na przykład do pogorszenia prędkości ładowania strony. Jak wykorzystać kod JavaScript w SEO? Jak sprawdzić poprawność jego wdrożenia? To tylko dwa pytania, na które odpowiedź znajdziesz poniżej.
JavaScript jest skryptowym językiem programowania, który umożliwia interakcje użytkownika z witryną. Jego użycie dynamiczne zmiany na stronie, np. dotyczące jej wyglądu lub sposobu wyświetlania treści.
Używając JS na stronach opartych o kod HTML, wykorzystujemy tzw. DOM, czyli Obiektowy Model Dokumentu. To sposób w jaki opisywany jest dokument HTML poprzez elementy uporządkowane w hierarchicznej strukturze drzewa. Innymi słowy przeglądarka pobierając kod źródłowy HTML z serwera, nadaje mu odpowiednią strukturę drzewa DOM. Następnie wykorzystując JavaScript możemy dowolnie zmieniać jego konkretne elementy.
Przykładowo: po kliknięciu przycisku umieszczonego w danym miejscu, w konkretnym znaczniku HTML (np.<span>) zostanie wykonana akcja polegająca na pojawieniu się nowego tekstu na danej podstronie. Dzięki JavaScript możliwe jest dokonywanie zmian na danej podstronie bez potrzeby ponownego jej przeładowywania (odświeżania). Dzieje się tak dlatego, ponieważ bazujemy na już wcześniej pobranym z serwera dokumencie HTML.
Jeszcze kilka lat temu roboty Google interpretując stronę internetową całkowicie ignorowały kod JavaScript. Przełom nastąpił w 2014 roku. Firma ogłosiła wówczas, że posiada zasoby pozwalające na lepsze zrozumienie nowoczesnych stron www oraz renderowanie kodu JS, co w konsekwencji wpłynęło na wyniki wyszukiwania.
Pobieranie i renderowanie kodu JS było i nadal jest dla Google dosyć czasochłonne. Ze względu na te ograniczenia interpretacja JavaScript przez odpowiednią usługę wyszukiwarki nie była pełna. Oczywiście potentat z Doliny Krzemowej stale usprawnia swoje algorytmy. Dzięki temu w maju 2019 ogłosił, że Googlebot będzie aktualizowany tak często jak przeglądarka Chrome, co w uproszczeniu oznacza obsługę nowych funkcji w niej zawartych. To z kolei umożliwia dostrzeżenie nowych treści przez robota, które wcześniej mogły być dla niego niedostępne.
Co istotne, jeszcze do niedawna do renderowania witryn Google używało mechanizmów opartych na wersji 41 Google Chrome. Obecnie wszystko realizowane jest w ramach jej najnowszej wersji (w trakcie pisania tego artykułu jest to wersja 74). Warto dodać, że zarówno starsza wersja 41 jak i najnowsza nie używają wszystkich funkcji silnika Chrome. Nadal więc pewne elementy nie są obsługiwane.
Dla lepszego zrozumienia dalszej części artykułu w uproszczeniu opiszę teraz działania robotów wyszukiwarki na stronie oraz sposób ich renderowania i analizowania przez algorytmy.
1. Googlebot (crawler Google) na początku wykorzystując domyślne ustawienia, odwiedza daną witrynę z zamiarem pobrania z niej odpowiednich danych.
2. Po odwiedzeniu kolejnych podstron oraz pobraniu z nich zawartości w postaci kodu HTML oraz CSS Googlebot przesyła zebrane dane do odpowiednich usług Google. Są one odpowiedzialne za interpretowanie tego, co otrzymują. Jeśli na stronie nie ma kodu JavaScript indexer Caffeine bardzo szybko indeksuje stronę.
Jeśli natomiast na stronie znajdują się pliki JS, indeksowanie pełnej zawartości strony trwa dłużej, ponieważ Google musi pobierać dane, przesłać je dalej oraz muszą one być zinterpretowane przez odpowiednią usługę.
Za renderowanie strony odpowiada usługa WRS (Web Rendering Service), która po przetworzeniu danych przesyła je do odpowiednich algorytmów oraz niektóre z nich z powrotem do Googlebota. Otrzymuje on głównie informacje o linkach z danej podstrony, do których nie mógł się dostać z uwagi na potrzebę renderowania JS.
Google w 2018 roku oficjalnie ogłosił też, że renderowanie witryn obsługiwanych przez JavaScript w wyszukiwarce Google bywa odroczone do czasu, gdy WRS będzie dysponował odpowiednimi zasobami do przetwarzania tej treści.
Warto w tym kontekście wspomnieć, że jeśli zależy nam na sprawnym crawlowaniu witryny przez roboty, to bardzo ważne jest używanie linków wewnętrznych umieszczonych w znacznikach, które nie utrudniają „chodzenia po serwisie” robotom, ponieważ nie muszą one czekać na wyeksportowanie linków z kodu JS przez usługę WRS.
Poniżej znajduje się grafika, którą przedsiębiorstwo z Mountain View zaprezentowało podczas Google I/O w 2018 roku. Przedstawia ścieżkę od pobrania do indeksacji strony.
3. Po otrzymaniu pełnej zawartości strony, algorytmy wyszukiwarki za pośrednictwem odpowiednich mechanizmów decydują o całkowitym indeksowaniu oraz ustalaniu pozycji danej podstrony w wyszukiwarce.
Jak widać, crawlowanie strony i ustalanie jej pozycji w wyszukiwarce to złożone działania, które potrzebują odpowiednio dużych zasobów mocy obliczeniowej. Dlatego z kolei (nawiązując głównie do kontekstu tego artykułu) tak ważne jest, aby kod JavaScript nie wpływał na podstawowe pobranie zawartości HTML i nie utrudniał interpretacji kodu przez algorytmy wyszukiwarek.
Jeśli nie blokujemy robotom dostępu do plików JS wówczas Google powinien renderować drzewo DOM w taki sposób, jak robi to odpowiednia wersja przeglądarki Chrome. Jak jednak wcześniej wspomniałem, nadal istnieją elementy, których usługa WRS nie obsługuje. Można się domyślić, że jest to więc zależne od używanych przez systemy CMS oraz programistów technologii.
Użyty na stronie rodzaj oraz wersja frameworka języka JavaScript są z kolei istotne w kontekście wspierania danego sposobu, w jaki witryna jest renderowana (SSR, CSR, Hybrid Rendering, Prerendering). Wspomnę jeszcze o tym nieco później.
W celu sprawdzenia funkcjonalności kodu naszej strony, wyszukiwania potencjalnych błędów oraz utrudnień dla Google możemy użyć różnych rozwiązań opisanych poniżej. Większość z nich nie stanowi jednak sposobu na dokładne sprawdzenie tego, jak Google tak naprawdę „widzi” naszą witrynę. Na samym początku napiszę jednak, dlaczego do badania poprawności renderowania JavaScript przez Google nie warto korzystać z użycia komendy cache.
Aby sprawdzić zawartość pamięci podręcznej Google na temat danej podstrony należy użyć komendy cache: przed adresem URL danej podstrony w pasku przeglądarki, na przykład:
cache:http://przykladowadomena.pl/adres
Otrzymamy dzięki temu zrzut z pamięci podręcznej Google przedstawiający ostatnią zapisaną wersję wybranej podstrony, którą robot otrzymał od serwera. Wiemy dzięki temu, kiedy robot odwiedził ją ostatni raz.
Nie jest to jednak wyrenderowana przez usługę WRS treść. Jest tutaj widoczny obraz tego, w jaki sposób przeglądarka, z której korzystamy interpretuje kod, jaki zebrał Googlebot odwiedzając daną witrynę. Przeglądarka – nie Google.
Dlatego nie można przywiązywać dużej wagi do tego, co tutaj otrzymujemy i w ten sposób podejmować decyzji o poprawności naszego kodu JS. Obraz witryny, jaki tutaj zobaczymy, to nie jest to, co w rzeczywistości jest indeksowane i oceniane przez algorytmy wyszukiwarki. Sam John Mueller wielokrotnie potwierdzał, że jest to jedynie podstawowy kod HTML, jaki Googlebot otrzymuje od serwera (bez wglądu w to jak Google go wyrenderował).
Jeśli natomiast chcemy zbadać, czy Google indeksuje poprawnie dane treści implementowane z pomocą JS na stronie, np. opisy kategorii, znacznie lepiej użyć do tego komendy site w kontekście danej podstrony, oraz wpisania z niej fragmentu tekstu w cudzysłów.
Jak widzimy powyżej, pogrubiony tekst został poprawnie zaindeksowany.
Istotne jest posiadanie dostępu do konta Google Search Console danej witryny. Za jego pomocą możemy zbadać dowolny adres URL, który do niej należy. Aby to zrobić wystarczy wpisać go w okienko znajdujące się w górnej części narzędzia i wcisnąć enter:
Po zakończonej pracy program wskaże nam podstawowe informacje na temat danej podstrony. Dowiemy się między innymi czy jest ona zindeksowana w wyszukiwarce, czy jest dostosowana do urządzeń mobilnych i tym podobne. Nam zależy jednak na sprawdzeniu jak Google radzi sobie z renderowaniem aktualnej wersji podstrony. Żeby to sprawdzić, klikamy więc w szary przycisk „Sprawdź URL wersji aktywnej”. Po nieco dłuższym czasie oczekiwania, możemy wyświetlić przetestowaną stronę. Dzięki zakładce „Zrzut ekranu” dowiemy się jak Google zobaczył naszą stronę. Należy mieć jednak świadomość, że nie otrzymamy tutaj pełnej długości strony, a najczęściej jedynie jej część.
Zakładka „Więcej informacji” wskaże nam wszystkie zasoby jakie wykrył Google, te, z którymi może sobie nie radzić (np. z powodu blokady dostępu przez plik robots.txt) oraz komunikaty z konsoli JavaScript.
Oczywiście informacje podawane tutaj nie muszą być w 100% zgodne z rzeczywistością, jednak zalecam, aby dokładniej przyglądać się potencjalnych problemom z witryną.
Aby wyszukać niektóre błędy renderowania kodu naszej strony związane z niedopasowaniem do urządzeń mobilnych, możemy użyć specjalnie do tego przeznaczonego narzędzia Google dostępnego pod adresem: https://search.google.com/test/mobile-friendly. Pozwoli ono nam zajrzeć w wyrenderowany przez Google DOM oraz sprawdzić błędy konsoli, a także zasoby, które są blokowane przez robots.txt.
W tym miejscu chciałbym pokrótce omówić wybrane funkcje programu Screaming Frog, pozwalające na badanie Java Script w serwisach. Kiedy już otrzymamy raport dostępny po przecrawlowaniu witryny przez narzędzie (przy zachowaniu domyślnych ustawień), możemy dowiedzieć się czegoś więcej na temat odnalezionych przez program plików JS. Listę otrzymamy używając odpowiedniego filtrowania wyników:
Otrzymamy w ten sposób bazę plików, które możemy sprawdzić pod kątem dostępności dla robotów, zwracanych przez nie kodów odpowiedzi, czy czasu odpowiedzi. Możemy także sprawdzić, gdzie w witrynie znajdują się odwołania do takich zasobów. W kontekście szybkości ładowania strony należy jednak pamiętać o ładowaniu asynchronicznym plików JS, które mogło zostać użyte w serwisie. Jeśli natomiast chcemy otrzymać widok tego, jak Google może renderować naszą witrynę, wówczas musimy odpowiednio skonfigurować Screaming Froga.
Na początku przechodzimy do opcji Spider:
Kolejnym krokiem jest przejście do zakładki „Rendering” i kliknięcie opcji „JavaScript”:
Co istotne, domyślnie crawler ma ustawione 5 sekund na wyrenderowanie danej podstrony zanim przejdzie do następnej (AJAX Timeout). Możemy to zmienić, jednak nie zalecam tego robić, z uwagi na to, że Google również ma ograniczony czas podczas wizyty w serwisie. Najczęściej może to być właśnie około 5 sekund.
W przypadku, kiedy skończy się czas, przełoży się to na brak widoku całej treści lub layoutu przez Google. Chodzi tutaj m.in. o crawl budget oraz render budget. Starajmy się więc, aby wyrenderowanie strony nie wymagało zbyt długiego czasu oczekiwania. Oprócz straconego potencjału crawl budgetu, możemy zniechęcić do witryny użytkowników, którzy opuszczą stronę, jeśli nie będzie ładowała się ona zbyt szybko.
Jak widzimy na poprzedniej grafice, w okienku konfiguracji robota pod kątem wykorzystania przez niego JavaScript mamy do wyboru różne typy rozdzielczości, jakie Screaming Frog będzie brał pod uwagę podczas crawlowania. Jedne z najbardziej przydatnych zostały nazwane „Googlebot Mobile: Smartphone” oraz „Googlebot desktop”. Skupmy się teraz na tej drugiej.
Oprócz tego warto zaznaczyć ptaszki obok dwóch opcji crawlu: „Store HTML” oraz „Store Rendered HTML”. Są one dostępne w zakładce „Advanced”. Dzięki nim otrzymamy do wglądu kod źródłowy oraz wyrenderowany DOM. Dodatkowo możemy wybrać odpowiedni rodzaj user-agent, jakiego ma używać Screaming Frog (np. Googlebot).
Po skończonej analizie otrzymujemy w raporcie między innymi:
Jak widać, otrzymujemy tutaj więcej informacji na temat witryny niż podczas standardowego crawlu. Trzeba jednak pamiętać, że renderowanie JavaScript jest czasochłonne i zebranie danych o całym serwisie będzie znacznie dłużej trwać.
Chciałbym zaznaczyć, że nie należy ufać wszystkiemu, co tutaj zaobserwujemy. Jest to spowodowane brakiem możliwości całowitego wcielenia się robota Screaming Froga w rolę Google oraz w sposób jego chodzenia po witrynie.
Dodam jeszcze, że oprócz Screming Froga renderowanie JavaScript na stronie oferują inne crawlery, m.in. Sitebulb. Natomiast więcej na temat konfiguracji oraz zaawansowanego użycia Screaming Froga znajduje się w innym artykule: Jak crawlować duże serwisy za pomocą Screaming Froga?
Wyłączenie obsługi kodu JavaScript w przeglądarce jest możliwe na kilka sposobów. Osobiście korzystam z odpowiedniej funkcji dostępnej we wtyczce „Web Developer” (można ją instalować m.in. w Chrome). Po wybraniu tej opcji, należy odświeżyć stronę, na której się znajdujemy.
Ta metoda co prawda nie przybliży nas do sprawdzenia tego, jak Google widzi daną witrynę, jednak w bardzo prosty sposób dowiemy się, w jaki sposób strona jest widoczna z wyłączoną obsługą kodu JavaScript. Jest to podstawa, jeśli modyfikujemy serwis za pomocą skryptów i chcemy dowiedzieć się, czy nie wpływa to negatywnie na widoczność głównych treści.
Pamiętajmy, że najlepsza droga do tego, aby Google indeksował sprawnie nasz serwis, to dobra widoczność linków, tekstów oraz grafik bez potrzeby renderowania kodu JS. Jeśli korzystamy więc z zaawansowanych sposobów serwowania treści użytkownikom, korzystajmy z odpowiednich mechanizmów fallback.
Innymi słowy: postarajmy się, aby elementy witryny, takie jak grafiki były widoczne tak samo w sytuacji, kiedy przeglądarka obsługuje JavaScript oraz kiedy takiego kodu nie obsługuje. Przykład kiedy możemy się z tym spotkać to tzw. „lazy loading”. Mechanizm ten stosowany jest w celu przyspieszenia ładowania się serwisu poprzez doczytywanie grafik dopiero wtedy, kiedy znajdą się w polu widzenia użytkownika. Znajdują się one poniżej aktualnego widoku w przeglądarce i ładowane są niejako „w tle”.
Fallbackiem w tym przypadku będzie zastosowanie rozwiązania, które pozwoli na pojawienie się tych samych grafik co wcześniej na danej podstronie przy wyłączonej obsłudze kodu JavaScript. Nieco upraszczając, jedną z możliwości jest tutaj użycie tagu HTML <noscript> i umieszczenie w nim odpowiedniego adresu obrazka. Powinien on ładować się w drzewie DOM jedynie w przypadku braku obsługi JavaScript.
W kontekście crawlowania jest to o tyle istotne, że googlebot może od razu z łatwością dotrzeć do danych obrazków i zaindeksować je bez potrzeby renderowania JS. Zrobi więc to zawsze szybciej i sprawniej, zwłaszcza jeśli treści na stronie zmieniają się dość często.
Bardzo pomocnym narzędziem do badania skryptów są narzędzia deweloperskie Google. Dostępne są po kliknięciu przycisku „Zbadaj” w dowolnym miejscu na stronie internetowej. Przykładowo w sekcji „Network” dowiemy się m.in. jakie pliki są wczytywane podczas ładowania strony, jak szybko oraz w jakiej kolejności.
Kiedy przejdziemy do tej zakładki należy odświeżyć stronę za pomocą „Ctrl +R”. Wówczas otrzymamy odpowiednie dane do analizy. Na górnym pasku (1) możemy filtrować listę pobieranych zasobów (2) po ich typie. Widzimy tutaj również rozmiar (4) poszczególnych plików, czas potrzebny do ich pobrania (5) oraz te dwa elementy razem, przedstawione w formie graficznej (6).
Z danych dowiemy się m.in. jakie zasoby zajmują najwięcej czasu na pobranie oraz czy kolejność ładowania poszczególnych zasobów jest poprawna. Zbędne skrypty mogą blokować istotne treści ponieważ ładują się przed nimi, zamiast być renderowane asynchronicznie.
Szczegółowe wyjaśnienie jak efektywnie wykorzystywać potencjał tych narzędzi znajduje się między innymi tutaj.
Jeśli chcemy zacząć śledzić ruchy i zachowanie googlebota w trakcie jego przebywania w obrębie naszej witryny – warto korzystać z dobrodziejstw analizy logów serwera. Logi serwera są bardzo przydatne w celu wyszukiwania błędów oraz prac nad optymalizacją witryny.
Kiedy już pozyskamy logi serwera dotyczące ruchu robotów w witrynie (ruch użytkowników nie jest nam tutaj potrzebny) od webmastera, obsługi hostingu lub na własną rękę, możemy zacząć je analizować. Wystarczy jeśli użyjemy do tego zwykłego Excela, jednak do sprawnego wyciągania interesujących nas danych potrzebna może okazać się zaawansowana wiedza z zakresu znajomości tego programu oraz duża ilość pamięci RAM. Przykładowym przydatnym narzędziem, które usprawni naszą pracę jest Screaming Frog File Analyser.
Zyskamy dzięki niemu łatwy dostęp do wielu danych, np. na temat tego co odwiedzają roboty, jak często, ile czasu spędzają danego dnia w naszej witrynie oraz jakie kody odpowiedzi otrzymują w trakcie wysyłania żądań.
Dzięki posiadaniu takich danych możemy dowiedzieć się do jakich zasobów roboty docierają, z jakimi sobie nie radzą i których używają zbyt często. Mamy dostęp do wszystkich podstron, jakie zobaczył googlebot. Sprawdzimy więc, czy implementacja skryptów na stronie najprawdopodobniej nie przeszkadza w dostaniu się do danej części serwisu, np. przez obecne na stronie linki generowane za pomocą JS. Dowiemy się tego na przykład poprzez wyszukanie danej podstrony na liście oraz ewentualnie porównaniu ilości odwiedzin jej przez robota w porównaniu do pozostałych stron.
Sprawdzimy także, czy dane strony nie obciążają zbyt bardzo jego „mocy przerobowych”, przez co niektóre strony mogą być pomijane. Zrobimy to sortując w programie listę podstron oraz zasobów według częstotliwości ich odwiedzin. Przykładowo: na poniższym screenie widzimy, że jeden rekord generuje aż 9 339 żądań, co w porównaniu do pozostałych elementów na liście stanowi sporą wartość.
Ilość żądań dla plików JavaScript, CSS oraz strony głównej nie odbiega od normy, dlatego możemy stwierdzić, że omawiany tutaj zasób stanowi problem podczas crawlowania. Może być to związane z np. z zastosowanymi dla niego technologiami. Po sprawdzeniu podstrony okazuje się, że jest ona wykorzystywana w procesie zakupowym. Możemy więc zablokować robotom dostęp do takiego pliku, co powinno przełożyć się na optymalizację crawl budgetu. Dodam, że Screaming Frog z włączonym renderowaniem JavaScript nie odnalazł tej podstrony.
Logi serwera pozwalają na zbadanie wielu zachowań robotów i reagowanie do pewnego stopnia na to jak wykorzystują czas w serwisie, jednak nie jest oczywiście możliwe dokładne zrozumienie ich przez nas.
Renderowanie kodu JavaScript może odbywać się na kilka sposobów. Jednym z nich jest renderowanie po stronie klienta. Możemy spotkać je dość często w Internecie. Klientem może być np. przeglądarka lub robot Google. Jak już wspominałem wcześniej, interpretacja skryptów i prezentowanie jej w odpowiednim środowisku wymaga zasobów mocy obliczeniowej. Często mogą być one bardzo duże, głównie z uwagi na ilość zastosowanych elementów JS, stopień optymalizacji kodu lub błędy, które może on generować. Co więc zrobić, jeśli chcemy pomóc robotowi w osiągnięciu lepszej dostępności treści strony?
Obecnie najprawdopodobniej jedynym sposobem na to, aby Google nie miał problemów z interpretacją kodu JavaScript, jest renderowanie tego typu skryptów po stronie serwera i przesyłanie tzw. HTML snapshots. Innymi słowy: możliwe jest wykorzystanie zasobów serwera do tego, aby googlebot błyskawicznie otrzymywał gotową, wyrenderowaną treść. Co istotne, oprócz szybkiego otrzymania zawartości serwisu przez roboty, najprawdopodobniej istotnie poprawi się wynik czasu ładowania strony.
Renderowanie po stronie serwera jest znacznie chętniej stosowane przez aplikacje internetowe, ponieważ ich budowa może w znacznym stopniu opierać się na kodzie JavaScript oraz jego frameworkach. Warto dodać, że jeśli kod naszej stronie jest bardzo skomplikowany oraz zależy nam na poprawnym zrozumieniu wszystkich treści przez roboty, to prerenderowanie może okazać się dobrym pomysłem. Warto jednak pamiętać o jego wadach – głownie jest to dodatkowe obciążenie serwera i zwiększony koszt z powodu zwiększenia ilości serwowanych zasobów.
Dobrym narzędziem, które pomaga w renderowaniu strony po stronie serwera jest https://prerender.io/.
Zainteresowanych odsyłam po więcej do wiedzy przedstawionej przez Google: https://developers.google.com/web/tools/puppeteer/articles/ssr
Optymalne wydaje się używanie prerenderowania jedynie dla robotów wyszukiwarki. Należy jednak pamiętać, że poprawny efekt uzyskamy, kiedy odpowiednio skonfigurujemy serwer tak, aby po wykryciu odpowiedniego user-agenta serwował robotowi wyrenderowaną treść, natomiast użytkownikowi zwykłą. Co istotne, te dwie wersje nie powinny różnić się między sobą jeśli chodzi o główne treści oraz linki wewnętrzne. Wyrenderowane drzewo DOM musi odpowiadać temu, co przesyłamy robotom. W innym przypadku możemy narazić się na karę od Google.
Tym, co zaleca sam Google, jest wykorzystywanie izomorficznego kodu JavaScript. Pozwala on na prerenderowanie treści strony zarówno dla użytkownika jak i robota w ten sam sposób. Co istotne, nie wszystkie frameworki, których używamy w serwisie obsługują renderowanie po stronie serwera.
Dostępne rodzaje renderowania stron i aplikacji internetowych to:
1. Client side rendering – renderowanie po stronie klienta (robota oraz przeglądarki internetowej).
2. Server side rendering – renderowanie odbywa się po stronie serwera, każdy klient (przeglądarka oraz robot) otrzymuje gotowy, statyczny HTML.
3. Hybrid rendering – klient-przeglądarka oraz crawler otrzymują wyrenderowany przez kod HTML, a dopiero później serwer przesyła kod JavaScript.
4. Dynamic rendering (sposób preferowany przez Google) – po wykryciu informacji o user-agent przez stronę klient w postaci crawlera otrzymuje statyczny HTML po wcześniejszym wyrenderowaniu kodu JavaScript przez serwer, natomiast klient-przeglądarka otrzymuje standardową wersję strony.
JavaScript to wciąż trudny temat dla robotów Google. Chociaż firma deklaruje, że radzi sobie sprawnie z renderowaniem go oraz indeksacją w wyszukiwarce, zalecam uzasadnione używanie tego typu kodu. Opierajmy się przede wszystkim na semantyce kodu HTML oraz optymalizacji SEO naszych witryn. Animacje, używanie JS w celu dodania zbędnych „fajerwerków” może być niekiedy zabójcze dla prędkości ładowania oraz sprawnej indeksacji serwisu.
Prezentujemy kolejne podsumowanie wiadomości ze świata SEO i content marketingu. W tym miesiącu piszemy m.in., o tym jak poprawić szybkość ładowania strony, o nowych funkcjonalnościach Google, związku PPC i content marketingu oraz sztucznej inteligencji. Zapraszamy!
Google udostępnia kolejne narzędzia, które mają pomóc w optymalizacji wydajności stron mobilnych. Pierwsze z nich to Speed Scorecard, czyli karta wyników prędkości, która pozwala na porównanie czasu ładowania się naszej strony mobilnej ze stronami konkurencji. W tej chwili Speed Scorecard umożliwia analizę szybkości stron z 12 krajów – na razie nie ma wśród nich Polski. Drugie narzędzie, kalkulator wpływów, pokazuje, jak zmniejszenie czasu ładowania przekłada się na zyski ze strony. Jego działanie oparte jest na szacunkach Google, według których każda sekunda opóźnienia ładowania strony oznacza spadek konwersji sięgający nawet 20%. Nowe narzędzia dostępne są tutaj: https://www.thinkwithgoogle.com/feature/mobile/.
Według danych z WPEngine nawet jednosekundowe opóźnienie w ładowaniu strony może spowodować spadek konwersji o 7%. Tymczasem analizy pokazują, że średni czas ładowania strony w Polsce to 11 sekund, czyli aż o 8 sekund za długo w stosunku do rekomendowanego przez Google czasu 3 sekund. O skutecznych sposobach przyspieszenia strony można przeczytać na blogu Semahead: https://semahead.agency/blog/9-sprawdzonych-sposobow-poprawe-szybkosci-ladowania-strony.html.
Google dodało do wyszukiwarki nową funkcjonalność, czyli „wieloznaczne opisy fragmentów”. W przypadku niejednoznacznego zapytania Google wyświetli więcej niż jedną pasującą do niego odpowiedź. Algorytm odczyta intencje korzystającego z wyszukiwarki i jego zapytanie przedstawi w formie pytania, które użytkownik prawdopodobnie chciał zadać. Wieloznacznie odpowiedzi najpierw pojawią się w mobilnych wynikach wyszukiwania. Więcej informacji na ten temat można znaleźć tutaj: https://searchengineland.com/multifaceted-featured-snippets-begin-rolling-google-search-results-293188.
Google prezentuje AMP Stories, czyli dobrze znany ze Snapchata czy Instagrama format umożliwiający udostępnianie materiałów wideo, audio, obrazów i tekstów. AMP Stories można znaleźć w mobilnych wynikach wyszukiwania. Więcej informacji na temat działania i wdrożenia Stories w technologii AMP można znaleźć tutaj: https://searchengineland.com/making-first-amp-story-googles-answer-snapchat-instagram-292598.
Google potwierdziło, że Google Assistant pod koniec 2018 roku będzie obsługiwał już 30 języków. Oznacza to, że stanie się dostępny dla 95% wszystkich użytkowników smartfonów z Androidem na świecie. Na razie nie została podana pełna lista języków, które mają dołączyć do ośmiu obecnie obsługiwanych, więc nie wiadomo, czy asystent Google trafi w tym roku na polski rynek. Więcej informacji na ten temat można przeczytać tutaj: https://searchengineland.com/google-assistant-get-new-languages-distribution-capabilities-292887
Za dużymi wahaniami i spadkami pozycji w SERPie może stać kanibalizacja słów kluczowych. Diggity Marketing opublikował artykuł, który podpowiada, w jaki sposób zdiagnozować to zjawisko. W tekście podano także trzy sposoby rozwiązania problemów dotyczących kanibalizacji. Materiał dostępny jest pod tym adresem: https://diggitymarketing.com/keyword-cannibalization/.
Co spowodowało spadek ruchu organicznego? Z pomocą w odpowiedzi na to pytanie przychodzi poradnik Moza, czyli przegląd najważniejszych wskaźników, jakie należy w takiej sytuacji przeanalizować. Artykuł można znaleźć pod tym adresem: https://moz.com/blog/declining-organic-traffic.
Po dwóch latach od wprowadzenia przyspieszonych stron mobilnych Google chce uczynić technologię AMP sieciowym standardem, o czym można przeczytać w tym poście. Standaryzacja ma wspomóc szybkie ładowanie się treści na stronach nieopartych na AMP. Umożliwi też między innymi pojawienie się takich witryn w karuzeli Google. Więcej informacji na ten temat można znaleźć tutaj: https://searchengineland.com/google-working-to-integrate-amp-benefits-into-future-open-web-standards-293753.
Czy sztuczna inteligencja zabierze pracę specjalistom z branży content marketingu? Jak na razie bardziej im pomaga niż szkodzi – AI pozwala spersonalizować treść i dostarczyć ją użytkownikom w odpowiednim momencie, a samouczące się algorytmy znacznie ułatwiają codzienne zadania. Więcej o sztucznej inteligencji w content marketingu można przeczytać tutaj: https://www.searchenginejournal.com/artificial-intelligence-in-content-marketing/239749/.
Długofalowe działania content marketingowe czy szybkie rezultaty osiągnięte za pomocą PPC? Search Engine Journal podsumowuje dobre i złe strony przyjęcia obu wymienionych strategii. Odpowiedź na to, jak wybrać metodę odpowiednią dla siebie i czy możliwe jest połącznie content marketingu i PPC znajduje się w tym artykule: https://www.searchenginejournal.com/content-marketing-vs-ppc/236107/.
Według badań średni czas ładowania strony mobilnej w Polsce wynosi aż 9,2 sekund. Tymczasem Google rekomenduje, by otwarcie strony trwało nie dłużej niż 3 sekundy. Jak poprawić szybkość strony i zmniejszyć współczynnik odrzuceń?
Na pewno wielu z was przeglądając strony internetowe natknęło się na witrynę, która ładowała się zbyt długo, co spowodowało wasze zdenerwowanie i w końcowym efekcie zamknięcie karty przeglądarki. W dzisiejszych czasach tworzone są piękne strony, które niestety zawierają coraz więcej rozwiązań, funkcjonalności oraz grafik. Zwiększają one wagę witryny, a co za tym idzie, też czas jej ładowania. W przypadku ładowania się witryny WWW każda sekunda ma znaczenie, ponieważ każda dodatkowa sekunda zmniejsza zadowolenie użytkowników o 16%, liczbę odsłon o 11% i powoduje spadek konwersji o 7% (wg danych z WPEngine). Może się również zdarzyć, że użytkownik już nigdy nie
powróci na nasza stronę. Wg ostatnich doniesień również Google będzie przywiązywało coraz większa uwagę do szybkości ładowania strony, o czym opisaliśmy we wpisie Nadchodzi aktualizacja Speed Update.
Specjalnie dla was przybywamy z 9 sposobami na skuteczne przyspieszenie strony, które pozwolą zmniejszyć zdenerwowanie użytkowników i uratować współczynnik konwersji.
Nawet najlepiej zoptymalizowana strona internetowa może mieć wydłużony czas ładowania. Jednym z powodów mogą być słabe parametry serwera, na którym znajduje się strona, co znacznie wydłuża czas jego odpowiedzi. Google zaleca, by czas odpowiedzi serwera nie był dłuższy niż 0,2 sekundy. Dzisiejszy rynek firm oferujących hosting stron jest bardzo duży, więc jeśli jesteśmy na etapie zmiany lub wyboru hostingu, to warto porównać oferty różnych dostawców i unikać tych najtańszych. Ze względu na wielkość tego rynku usług, można z łatwością znaleźć naprawdę konkurencyjne oferty w dobrych cenach.
Grafiki bez wątpienia są jednym z najczęstszych elementów, powodujących dużą wagę strony i długi czas jej ładowania. Wiele osób tworzących własne strony zapomina o tym ważnym aspekcie. Do błędów optymalizacyjnych grafik zaliczamy brak ich kompresji lub osadzenie zdjęcia w zbyt dużym rozmiarze, pomimo wyświetlania go na stronie w mniejszym.
W celu optymalizacji grafik można skorzystać z takich narzędzi jak:
Jeśli chodzi o osadzanie grafik we właściwym rozmiarze, to miejmy na uwadze jedną kwestię: jeśli obrazek wyświetla się rozmiarze 250×250 to powinien zostać dodany na stronę w takim rozmiarze, a nie większym. Z pomocą tutaj przyjdą nam proste edytory grafik, które mają możliwość skalowania i przycinania obrazów.
Jeśli na stronie występuje duża ilość elementów graficznych, to zaraz po ich optymalizacji zobaczymy widoczne efekty w postaci większej wydajności strony.
Łączenie wszystkich plików CSS i JS w jeden pozwala zmniejszyć ilość zapytań do serwera, co minimalizuje czas ładowania strony. Dzieje się tak dlatego, że szybciej pobrany zostanie 1 większy plik niż 20 mniejszych. Każdy plik jest bowiem pobierany po kolei, więc przeglądarka aby ściągnąć kolejne pliki, musi poczekać, aż zakończy pobieranie aktualnych. Kolejnym etapem po połączeniu plików CSS i JS jest ich minifikacja, czyli usunięcie zbędnych znaków, linii oraz spacji, bez zmiany funkcjonalności kodu. Taki zabieg jest w stanie zmniejszyć nasze pliki od kilkudziesięciu do kilkuset kilobajtów, w zależności od rozmiaru pliku.
Do minifikacji plików możemy wykorzystać narzędzie:
Wszystkie skrypty JS, które nie wpływają na poprawne ładowanie się witryny, powinny zostać przeniesione na dół strony przed zamknięciem znacznika </body> (oczywiście wyłącznie w wypadku, jeśli nie wpływa to negatywnie na działanie strony). Taka zmiana pozwoli na szybsze załadowanie się treści właściwej, ponieważ skrypty nie będą pobierane na początku ładowania się WWW, co też pozytywnie wpłynie na odbiór witryny przez użytkownika.
Nowoczesne strony mają to do siebie, że zawierają wiele małych elementów graficznych (w postaci ikonek, strzałek itd.), które nadają stronie lepszego i nowocześniejszego wyglądu. Ich występowanie może jednak powodować wydłużenie ładowania się strony i zwiększenie ilości zapytań do serwera, ze względu na pobieranie każdej małej grafiki po kolei. Rozwiązaniem tego problemu jest CSS Sprites, który jest techniką pozwalającą na połączenie małych grafik w jeden plik, i wykorzystanie ich na stronie w taki sam sposób za pomocą styli CSS.
Bardzo dobrym sposobem na poprawę wydajności strony jest skonfigurowanie przetrzymywania danych w pamięci podręcznej. Dzięki temu rozwiązaniu przeglądarka będzie przechowywała na dysku użytkownika zasoby WWW. Można to wykonać za pomocą wtyczki (np. w WordPressie) lub dodanie kilku linijek kodu w pliku .htaccess. Dla osoby, która odwiedzi naszą stronę drugi i kolejny raz, zasoby strony nie będą pobierane z serwera. Zostaną one wczytane z pamięci podręcznej, dzięki czemu strona załaduje się o wiele szybciej.
Jeśli serwer posiada zainstalowany moduł mod_expires, to możemy użyć w naszym pliku .htaccess następującego kodu:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg „access plus 1 year”
ExpiresByType image/jpeg „access plus 1 year”
ExpiresByType image/gif „access plus 1 year”
ExpiresByType image/png „access plus 1 year”
ExpiresByType text/css „access plus 1 month”
ExpiresByType application/pdf „access plus 1 month”
ExpiresByType text/x-javascript „access plus 1 month”
ExpiresByType image/x-icon „access plus 1 year”
ExpiresDefault „access plus 2 days”
</IfModule>
Gzip jest niczym innym, jak metodą bezstratnej kompresji po stronie serwera, która pozwala na zredukowanie wagi plików nawet do 70%. Dzięki temu dane zostaną szybciej przesłane. Ich dekompresja nastąpi dopiero na poziomie przeglądarki. Należy jednak pamiętać, że kompresja powoduje dodatkowe obciążenie serwera, co warto wziąć pod uwagę w przypadku dużych serwisów.
Aby włączyć kompresję gzip na serwerze należy dodać do pliku .htaccess następujące kody: (działa tylko z serwerami Apache)
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>
Często można spotkać się z tym, że strona ładuje niepotrzebne elementy, które nie zostają wykorzystane na stronie. Dotyczy to na przykład dodatkowych czcionek lub skryptów. Warto przejrzeć kod strony w celu znalezienia niepotrzebnych elementów, powodujących dłuższe ładowanie się strony i zwiększenie ilości zapytań do serwera. Zrezygnujmy również z tych funkcjonalności strony, które prawdopodobnie nie są istotne dla użytkownika, a powodują zmniejszenie wydajności serwisu, np. widgety pogodowe, zegarek, kalendarz.
Wielokrotne przekierowania, które występują po wejściu na stronę, pochłaniają dodatkowe zasoby i wydłużają czas jej ładowania. Optymalizacja przekierowań do jednego gwarantuje nam mniejsze zużycie zasobów i szybsze ładowanie strony.
Przykład wielokrotnego przekierowania:
Podczas optymalizacji strony warto skorzystać z narzędzi, które zmierzą wydajność naszej witryny. My rekomendujemy narzędzia takie jak:
PageSpeed Insights jest oficjalnym narzędziem od Google, które pozwala przeanalizować podstawowe parametry wydajności strony. Narzędzie analizuje np. wielkość zdjęć i ich osadzenie, wagę plików HTML, wykorzystanie pamięci podręcznej, czy czas odpowiedzi serwera. Wadą narzędzia jest dosyć mały stopień rozbudowania i przydatność tylko w początkowym etapie optymalizacji stron. Dla bardziej zaawansowanej optymalizacji wydajności warto skorzystać z bardziej rozbudowanego narzędzia.
GTmetrix jest zaawansowanym narzędziem do analizy stron internetowych. Pozwala na dokładne sprawdzenie całego serwisu m.in. pod kątem: czasu ładowania strony, wagi, ilości zapytań do serwera, ładowania poszczególnych zasobów strony i wielu innych. Niestety, niektóre funkcje wymagają zalogowania się.
Pingdom jest mniej zaawansowanym narzędziem w stosunku do GTmetrix, ale może być dobrym uzupełnieniem przy optymalizacji wydajności. Narzędzie pozwala między innymi na sprawdzenie czasu ładowania strony, wagi, ilości zapytań do serwera, czy również podgląd ładowanych zasobów strony z ich czasem.
Lighthouse to stosunkowo nowe rozwiązanie stworzone przez Google. Narzędzie działa w formie wtyczki do przeglądarki i pozwala na podstawową analizę serwisu. Lighthouse jest bardziej zaawansowany od PageSpeed Insights i pozwala sprawdzić serwis pod kątem wydajności, użyteczności, dobrych praktyk SEO oraz zgodności z Progressive Web Apps. Więcej o Lighthouse możecie przeczytać w naszym artykule.
Jeśli wszystkie powyższe punkty zostały zawarte w optymalizacji waszej strony to macie pewność, że jej wydajność jest na wysokim poziomie. Należy pamiętać, że optymalizacja wydajności strony jest jednym z istotniejszych elementów, które wpływają na pozytywne postrzeganie witryny przez Google oraz użytkowników. Warto na bieżąco kontrolować wydajność stron i w razie konieczności poddać ją optymalizacji, a na pewno będzie to miało pozytywne rezultaty we wzroście współczynnika konwersji.
Od 2010 roku szybkość ładowania strony, jest jednym z czynników rankingowych w wyszukiwarce Google. Od lipca 2018 będzie miała również wpływ na wygląd wyników w wyszukiwaniu mobilnym. Jak przygotować się na tę aktualizację? Kiedy możemy powiedzieć, że strona jest szybka?
Na rynku dostępnych jest wiele narzędzi, za pomocą których możemy zmierzyć prędkość naszych stron. Dziś przyjrzymy się bliżej narzędziu, które podchodzi inaczej do całego tematu, prezentując nie tylko cyfry i wskaźniki, ale próbując przedstawić nam „realne odczucia” użytkowników. Narzędziem tym jest Google Lighthouse.
Nie wiemy jak mocny wpływ na pozycję witryn ma szybkość ładowania strony. Część osób może nie być przekonana, że jest on na tyle duży, że warto poświęcać czas na optymalizację witryny pod tym kątem. Ale nie możemy zapominać, o jeszcze jednym elemencie, który pozostaje w zależności z szybkością serwisu. Mowa oczywiście o współczynniku konwersji. Szybka dostępność i użyteczność strony może w znacznym stopniu przyczynić się do zmniejszenia liczby odrzuceń, czy liczby porzucanych koszyków. Argumenty te przemawiają za tym, że jednak warto pochylić się nad tym tematem.
Lighthouse to narzędzie open source stworzone przez firmę Google. Początkowo miało służyć do audytowania progresywnych aplikacji internetowych (PWA – Progressive Web Applications), w obecnej formie końcowy raport zawiera informację na temat błędów dotyczących szeroko pojętej wydajności i jakości stron oraz aplikacji internetowych. Oprócz listy niedociągnięć, otrzymujemy również użyteczne wskazówki jak je poprawić i dlaczego jest to istotne.
Dostęp do narzędzia możemy uzyskać na kilka sposobów:
Po uruchomieniu audytu, Lighthouse przeprowadza serię testów na naszej stronie. Symulacja przeprowadzona jest w taki sposób, jakby na nasza witryna była odwiedzana przez urządzenie korzystające z połączenia 3G i dodatkowo procesor tego urządzenia był obciążony (możemy dezaktywować te ustawienia, jeśli korzystamy z programu z poziomu konsoli).
Końcowy raport zawiera ocenę pięciu obszarów:
I. Progressive Web App: Raport zwierający aspekty ważne dla aplikacji PWA. W tej kategorii możemy otrzymać od 0 do 100pkt. Audyt opiera się na liście „Baseline PWA Checklist” (https://developers.google.com/web/progressive-web-apps/checklist#baseline). Wszystkie elementy są tej samej wagi, która przekłada się na końcową punktację.
II. Performance: Raport zawiera informację na temat wydajności strony/aplikacji i możliwości jej poprawy. Wynik może znajdować się w trzech zakresach:
Każdorazowe przeprowadzenie testu może dać różne wyniki. Może to być spowodowane ładowaniem różnych reklam, skryptów, warunkami sieciowymi, czy aplikacjami zainstalowanymi na naszym komputerze takimi jak antywirusy. Aby pozbyć się fluktuacji należy wyłączyć programy mogące zakłócić cały proces lub skorzystać z usługi hostowanej, np. przy pomocy strony https://webpagetest.org/
III. Accessibility: Lista elementów, które mogą poprawić dostępność naszej aplikacji. Końcowy wynik tego audytu jest średnią ważoną wszystkich poszczególnych czynników. Lista elementów, wraz z ich wagą, dostępna jest pod adresem: https://docs.google.com/spreadsheets/d/1dXH-bXX3gxqqpD1f7rp6ImSOhobsT1gn_GQ2fGZp8UU/edit?ts=59fb61d2#gid=0 Należy zwrócić uwagę na to, że w przeciwieństwie do audytu Performance, nie dostajemy pkt za częściowe spełnienie warunków. Jeżeli na naszej stronie znajdzie się przykładowo jeden obrazek bez atrybutu alt, to mimo tego, że wszystkie inne grafiki posiadają ten atrybut, to za element „image-alt” otrzymamy 0 pkt.
IV. Best Practises: Audyt listujący elementy będące dobrymi praktykami, które pozwalają na uniknięcie poważniejszych błędów z wydajnością. Ocena również w skali od 0 do 100.
V. SEO: Audyt sprawdzający krótką checklistę podstawowych elementów w optymalizacji SEO. Ww przyszłości ma zostać rozbudowany i udostępniony w stabilnej wersji narzędzi dla programistów https://productforums.google.com/forum/#!topic/webmaster-pl/raWjrgVhpYE;context-place=forum/webmaster-pl.
Jako że naszą uwagę do „Latarni morskiej” od Google przykuła głównie kwestia chęci lepszej optymalizacji szybkości witryn na urządzeniach mobilnych, to skupimy się w tej części wpisu na raporcie Performance.
Podczas mierzenia wydajności Lighthouse wyróżnia następujące metryki:
Jak widać powyżej, Google próbuje odzwierciedlić za pomocą metryk doświadczenia użytkowników w kontakcie ze stroną czy aplikacją. Analizując cały raport, wniosek jest jeden, najistotniejszym elementem jest jak najszybsze renderowanie najważniejszej treści strony i umożliwienie użytkownikom szybkiej interakcji. Dużą wagę ma optymalizacja krytycznej ścieżki renderowania (https://developers.google.com/web/fundamentals/performance/critical-rendering-path/)
Poniżej wyników poszczególnych metryk mamy kolejne zakładki, pierwszą z nich jest: „Opportunities” – przegląd wszystkich rzeczy, które możemy zrobić, aby przyspieszyć działanie witryny. Duży nacisk kładziony jest na odroczenie wykonywania nieistotnych skryptów JS, CSS, czy ładowania obrazów. Ważnym elementem jest też zapewnienie odpowiednich rozmiarów grafik dla różnych urządzeń.
Następna sekcja to „Diagnostics”. Zawiera w sobie między innymi element o nazwie „Critical Request Chains” – pokazuje on jakie zasoby wczytywane są w pierwszej kolejności, aby pokazać pierwszy render strony. Żeby usprawnić ładowanie strony należy rozważyć: zmniejszenie długości łańcucha całej ścieżki, zmniejszenie rozmiaru zasobów i opóźnić ładowanie nieistotnych elementów.
Po rozwinięciu poszczególnych sekcji mamy dokładny podgląd na to, których elementów na stronie dotyczy dana kwestia. Dodatkowo przy każdym z nich jest odnośnik do wpisów w poradniku Google dla developerów, który opisuje szerzej dany problem i przedstawia sposób jego poprawy.
Ostatnia zakładka „Passed Audits” listuje segmenty, które wdrożone są poprawnie.
Niewątpliwie jednym z najbardziej popularnych obecnie narzędzi używanych do analizy prędkości strony jest PageSpeed Insights, który dostarcza ogólnego przeglądu wskaźników wydajności strony. Jednak mimo otrzymania końcowej oceny w 100 stopniowej skali oraz listy elementów do poprawy, narzędzie to nie daje nam żadnego wyobrażenia o faktycznej prędkości ładowania witryny. Ponadto, zalecenia sugerowane przez program często są bardzo trudne do wdrożenia, a czasami nawet niemożliwe. Osiągnięcie 100 punktów często jest po prostu sztuką dla sztuki i nie przekłada się bezpośrednio na poprawę szybkości.
Lighthouse w tym wypadku ma dużo bardziej praktyczne podejście, skierowane na potrzeby użytkownika. Sprawdza jak szybko może zajść interakcja ze stroną i jak oraz w jakim czasie po otrzymaniu danych wejściowych strona jest w stanie odpowiedzieć. Test przebiega w nieprzypadkowych warunkach, nie zawsze jesteśmy w zasięgu super szybkiego LTE, a nasze urządzenia często obciążone są przez inne aplikacje. Lighthouse skutecznie emuluje warunki, które doświadczamy w prawdziwym świecie. Dzięki temu otrzymujemy wskazówki nawet dla stron, które w świetle innych aplikacji były oceniane jako szybkie.
Jeśli w codziennej pracy używasz też innych narzędzi, takich jak GTmetrix, czy WebPageTest, to Lighthouse znakomicie uzupełni ten zestaw.
Czy Lighthouse będzie wyznaczał nowy standard dla narzędzi służących do pomiarów wydajności stron? Chyba za wcześnie, aby wysuwać takie wnioski. Natomiast na pewno jest świetnym uzupełnieniem dla wszystkich obecnych na rynku aplikacji tego typu.
Rozbudowanie PageSpeed Insights o realne dane użytkowników Chrome, czy ogłoszenie daty aktualizacji dotyczącej szybkości stron dla algorytmu w wyszukiwarce mobilnej – to wyraźne sygnały, mówiące o tym, że Google kładzie coraz większy nacisk na doświadczenia użytkowników oraz wydajność stron na urządzeniach mobilnych.
Jeśli jeszcze zastanawiasz się czy warto skorzystać z zaleceń zawartych w audytach Lighthouse i spróbować wyśrubować możliwie jak najwyższy wynik, to jedno jest pewne – nawet jeśli optymalizacja zgodna z Lighthouse nie pomoże w osiąganiu lepszych pozycji, to z pewnością im nie zaszkodzi. Poprawa komfortu użytkowników mobilnych może bowiem przynieść tylko profity.
Jakie są wasze opinie na temat Lighthouse? Jak prezentuje się na tle konkurencyjnych rozwiązań? Podzielcie się swoją opinią w komentarzu.
W tym wpisie przedstawię darmowe narzędzia SEO, które będą pomocne podczas analizy serwisu pod kątem optymalizacji dla wyszukiwarek internetowych. Lista częściowo bazuje na narzędziach, z których korzystam podczas pracy nad klientami naszej agencji, dlatego uważam, że niektórym z Was również może ułatwić życie i przyspieszyć proces analizy własnej witryny. Wszystkie narzędzia SEO z listy są darmowe lub mają darmowe (zazwyczaj ograniczone) wersje.
Narzędzie online, które pozwala na przeprowadzenie prostego audytu strony głównej. Poza elementami SEO analizuje także wygodę użytkowników, użyteczność strony, widoczność w mediach społecznościowych oraz kwestie związane z bezpieczeństwem.
Podobnie jak poprzednie narzędzie, pozwala na analizę serwisu pod kątem SEO, wyświetlania na urządzeniach mobilnych oraz użyteczności. Dodatkowo ocenia witrynę pod kątem zastosowanych technologii, linków zwrotnych oraz ruchu. Większość funkcji jest dostępna po aktywacji darmowego, 14-dniowego okresu testowego.
Siteliner sprawdza duplikację treści w obrębie witryny i pozwala na tworzenie raportu zawierającego powielone słowa, ich procentowy udział oraz adresy zawierające zduplikowaną treść. Darmowy raport oparty jest o 250 najważniejszych podstron i dzięki niemu możemy w prosty sposób wyłapać szkodliwą duplikację treści.
Narzędzie Copyscape sprawdza, czy treść na wskazanej podstronie jest unikalna w obrębie sieci Internet. W raporcie wskazuje adresy stron, które zawierają te same fragmenty tekstu.
http://www.seoreviewtools.com/duplicate-content-checker
Narzędzie pozwala na sprawdzenie wewnętrznej oraz zewnętrznej duplikacji treści. Podobnie jak Copyscape wskazuje adresy URL, które mają problem z unikalnością contentu. Żeby w pełni skorzystać z narzędzia, należy zarejestrować darmowe konto.
http://smallseotools.com/plagiarism-checker/
Plagiarism checker od Small Seo Tools, to kolejne darmowe narzędzie pozwalające na weryfikacje unikalności tekstu. Niestety w darmowym raporcie nie wskazuje adresów, na których występuje dana treść.
ttps://www.google.com/webmasters/tools/home?hl=pl
O Google Search Console (dawniej Google Webmaster Tools) należałoby napisać osobny artykuł. Narzędzie jest kopalnią wiedzy, które pozwala na śledzenie danych oraz analizę serwisu pod kątem widoczności w wyszukiwarce Google. To absolutny niezbędnik każdego, komu zależy na widoczności w wynikach organicznych.
https://developers.google.com/speed/pagespeed/insights
Narzędzie ocenia w skali punktowej od 0 do 100 prędkość ładowania serwisu na urządzeniach mobilnych oraz desktopach. W raporcie otrzymujemy sugestie dotyczące tego, co należy oraz tego, co warto poprawić, żeby skrócić czas ładowania witryny.
https://search.google.com/structured-data/testing-tool
Narzędzie Structured Data Testing Tool pozwala na sprawdzenie implementacji danych strukturalnych, które wyróżnią Twoją stronę w wynikach wyszukiwania.
Kompleksowe narzędzie do analizy działań marketingowych. Dzięki Google Analytics możesz sprawdzić np. jak zachowywali się użytkownicy na stronie, który kanał ruchu najlepiej konwertuje, czy który produkt najlepiej sprzedawał się u użytkowników pochodzących z bezpłatnych wyników wyszukiwania. Więcej o jego możliwościach przeczytasz tutaj.
https://search.google.com/search-console/mobile-friendly
Test optymalizacji mobilnej sprawdza witrynę pod kątem poprawnego wyświetlania na urządzeniach mobilnych. W raporcie podsumowującym są zawarte wskazówki, które elementy należy poprawić, aby zostać mobile friendly 🙂
https://www.google.com/webmasters/tools/submit-url?hl=pl
Submit URL to darmowe narzędzie służące do indeksowania nowych stron/podstron w Google. Po zgłoszeniu strona jest widoczna w indeksie po kilku sekundach.
https://www.google.com/webmasters/tools/disavow-links-main
Disavow Tool służy do zrzekania się linków przychodzących do naszego serwisu. Jeżeli zauważasz spadki w ruchu, widoczności czy pozycjach, to warto zainteresować się właśnie tym narzędziem.
Narzędzie do analizowania trendów w wyszukiwarce, dzięki niemu otrzymujemy możliwość sprawdzenia, jak zmienia się popularność danej frazy, czy sprawdzenia wątków, które zyskują na popularności w danym regionie.
https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html
Raport pozwala sprawdzić, czy nasza strona w oczach Google jest bezpieczna. Jest to istotne ze względu na komunikaty z ostrzeżeniem, które są wyświetlane w wyszukiwarce oraz przeglądarkach. Strony oznaczone jako niebezpieczne są bowiem rzadko odwiedzane przez użytkowników.
Poza wspomnianym powyżej narzędziem Page Speed Insights, mamy dwa ciekawe narzędzia, które pozwolą na analizę czasu ładowania strony:
Pingdom jest darmowym narzędziem, które po wykonaniu testu generuje listę ładowanych plików wraz z oceną szybkości pobierania z serwera (wczytywania). Podobnie jak w przypadku PSI otrzymujemy listę elementów, które należy poprawić.
GTmetrix jest kolejnym narzędziem do testowania wydajności witryny. Po wykonanym teście otrzymujemy raport z dwóch innych narzędzi, PageSpeed oraz YSlow, które w przejrzysty sposób zebrane są w jednym miejscu.
https://www.screamingfrog.co.uk/seo-spider
Screaming Frog to przydatne narzędzie do analizy SEO stron internetowych. W darmowej wersji programu możemy przecrawlować do 500 adresów, mamy ograniczone możliwości konfiguracji narzędzia i nie możemy zapisać projektu. W przypadku niewielkich serwisów wersja darmowa będzie jednak wystarczająca.
http://home.snafu.de/tilman/xenulink.html
Xenu jest darmowym narzędziem, służącym do analizy technicznej strony. Jego głównym zadaniem jest wychwytywanie uszkodzonych linków wewnętrznych i zewnętrznych. Przy okazji crawlowania otrzymujemy ciekawe dane, takie jak kod http zwracany przez adres url, rozmiar pliku/strony, meta title czy informacja, ile kliknięć potrzeba na dotarcie do danego adresu.
https://wildshark.co.uk/spider-tool
WildShark SEO Spider jest kolejnym crawlerem, służącym do analizowania serwisu. Funkcjonalności narzędzia są zbliżone do Screaming Froga. Jego największym mankamentem, podobnie jak w przypadku darmowej wersji SF, jest brak możliwości zapisywania projektów.
Poniższe narzędzia są szczególnie pomocne, od kiedy algorytm Pingwin działa w czasie rzeczywistym. Możemy na ich podstawie ocenić, czy ruchy w pozycjach dotknęły tylko nasz serwis, czy może zaobserwowano większe ruchy w wynikach wyszukiwania.
MozCast to wskaźnik zmian w algorytmie od firmy SEOmoz w formie prognozy pogody. Raport narzędzia jest czytelny i łatwy w interpretacji.
Algoroo jest narzędziem od DEJAN, które monitoruje zmiany w google.com oraz google.com.ua. Wykres słupkowy wskazuje stan w wynikach wyszukiwania każdego dnia, odchylenia od normy oznaczone są kolorem żółtym oraz czerwonym.
SerpWatch od Bartosza Góralewicza jest narzędziem, z którego korzystam najczęściej ze wzglądu na analizę polskich wyników wyszukiwania. Narzędzie poza wyborem wyszukiwarki umożliwia sprawdzanie zmian w konkretnej branży oraz rozdziela raport na urządzenia mobilne i desktopowe.
Proste, intuicyjne i przydatne narzędzie, dzięki któremu możemy w szybki sposób mnożyć frazy kluczowe i generować frazy longtailowe.
Po wpisaniu interesującej nas frazy i wyborze języka, otrzymujemy gotowe zestawy fraz longtailowych w formie pytania, zdań z przyimkami oraz zestawienia alfabetycznego. Warto skorzystać z tego narzędzia podczas szukania inspiracji na kolejny wpis blogowy 😉
Ubersuggest to darmowe narzędzie, które generuje listę fraz opartych o słowo kluczowe. Obsługa jest prosta i intuicyjna. W porównaniu do Answer The Public, narzędzie oferuje dużo większą bazę języków.
Narzędzie służy do sprawdzania historii domen. Dzięki niemu możemy sprawdzić, od kiedy dana domena jest widoczna w Internecie oraz jakie zawierała treści w wybranym przez nas okresie. Wayback Machine będzie pomocny podczas szukania nowej domeny – zła historia może bowiem niekorzystnie wpłynąć na efekty pozycjonowania w przyszłości.
Dzięki HTTP Status Code Checker możemy sprawdzić, jaki kod zwraca podany adres URL. Szczególnie przydatne jest to do oceny, czy w obrębie witryny nie występują dodatkowe, pośrednie przekierowania, które niepotrzebnie obciążają serwer.
http://www.webconfs.com/web-tools/domain-age-tool
Proste narzędzie do analizy wieku domen. Pozwala na hurtowe sprawdzenie do 10 domen za jednym razem.
http://www.scrapebox.com/free-do-follow-test-tool
Darmowy program, dostępny również jako rozszerzenie do ScrapeBoxa. W narzędziu można sprawdzić jakiego rodzaju linki (dofollow/nofollow) prowadzą z listy adresów do wskazanej domeny.
Flang to darmowe narzędzie, które analizuje poprawność wdrożenia atrybutów hreflang na wskazanej podstronie. Jeżeli planujesz rozszerzenie działalności o rynki zagraniczne, to to narzędzie będzie dla Ciebie pomocne.
Narzędzie wskaże, jakie elementy w kodzie strony należy poprawić, żeby był on maksymalnie zgodny ze standardami. Dodatkowo raport umożliwia webmasterom znalezienie błędów.
https://sitecheck.sucuri.net/results
Jeżeli chcesz dowiedzieć się, czy Twoja witryna jest bezpieczna, to narzędzie na pewno będzie pomocne.
Mam nadzieję, że powyższa lista będzie dla Was przydatna.
Temat oczywiście nie został wyczerpany, więc jeżeli interesuje Was kolejne zestawienie darmowych narzędzi SEO, np. służące do analizy linków, to dajcie znać!
