LOADING

Optymalizacja sklepu internetowego


Poradnik – menu.
Część 1. Promocja i rozwój sklepu internetowego.
Część 2. Optymalizacja sklepu internetowego
Część 3. Indeksacja sklepu internetowego
Część 4. Treści w sklepie internetowym
Część 5. Linkowanie sklepu internetowego
Część 6. Narzędzia pomocne przy pozycjonowaniu


Dobra optymalizacja sklepu jest kluczowa dla skutecznego pozycjonowania. Im większy sklep, tym ma większe znaczenie. Trzeba sprawdzić wiele różnych aspektów naszego sklepu, często przy wdrożeniu zmian przyda się pomoc programisty.

Optymalizacja title w sklepie

Title to najważniejsza część optymalizacji strony. Od jego zawartości zależy na które zapytania będzie się pojawiała nasza strona.

W większości przypadków title jest ułożony na podstawie tytułu podstrony.

Ważne jest by nie przyspamować title. Pamiętajmy – title to nie tylko informacja dla bota. Na podstawie title użytkownik decyduje czy kliknąć w wynik czy też nie. Trzeba znaleźć tu złoty środek tak by title wyglądał przyjaźnie dla użytkownika (był informacyjny, zachęcał do kliknięcia) oraz by zwierał najważniejsze frazy.

Skąd dobrać frazy, które powinny znaleźć się w title? Narzędzie Keyword Planner czy KWFinder pomoże nam zdecydować, które to frazy są najważniejsze:

kwfinder-frazy

Przykład

Chcemy stronę kategorii ze sztucznymi storczykami promować na frazy odpowiadające zawartości kategorii:

  • sztuczne storczyki
  • sztuczne storczyki w doniczce
  • sztuczny storczyk jak żywy
  • sztuczne storczyki silikonowe

Można tu łatwo ułożyć całkiem sensowny title:

Silikonowe sztuczne storczyki jak żywe – Flowersatelier

Jak widać, można stosować odmiany fraz, nie muszą one też występować bezpośrednio koło siebie.

Czasem trzeba trochę się nasilić, by ułożyć dobry title, zawierający najważniejsze frazy. Z doświadczeniem przychodzi to łatwiej i takie rzeczy najczęściej zmienia czy sugeruje zmiany pozycjoner.

Długość w title

Title może być bardzo długi, ale pamiętajmy, że zawsze w wynikach wyszukiwania będzie prezentowana tylko jego część a potem będzie wstawiony trzykropek. Przykładowo taki długi title:

title-w-kodzie

Będzie tak skrócony:

title-skrocony-przez-googleKiedyś zawsze title był ucinany po danej liczbie znaków. To jednak się zmieniło i teraz jest ucinany po określonej długości pikseli.
Jaka zatem jest długość, która mieści się w wynikach wyszukiwania? Obecnie jest to około 600 pikseli co przekłada się na około 70 znaków.

Zmiany w title

Warto wspomnieć, że nie zawsze w wynikach wyszukiwania musi się pojawić dokładnie taki sam title jak ustalaliśmy. Google często eksperymentuje ze sposobem prezentacji wyników i nie omija to również title. Co jakiś czas można np. spotkać wyniki, gdzie na początek title przenoszona jest marka strony.

Podkreślmy jeszcze raz. Title jest ważny nie tylko dlatego, że zawiera słowa kluczowe. Pamiętajmy, że to on jest prezentowany w wynikach wyszukiwania i może mieć wpływ na to, czy użytkownik kliknie wynik lub nie. Trzeba znaleźć kompromis pomiędzy umieszczeniem słów kluczowych w title, a jego czytelnością.

3.2. Description

Tag description nie jest brany pod uwagę przy układaniu rankingu, co nie znaczy, że przy pozycjonowaniu można go pomijać.

Ale po kolei. Czym jest tag description? Jest to opis danej podstrony, który pojawia się w wynikach wyszukiwania:

description-przyklad

Definiuje się go w kodzie (oczywiście najczęściej CMSy pozwalają to zdefiniować w panelu, ale docelowo będzie umieszczony jak niżej):

description-w-kodzieI tu ważna uwaga. Użytkownik może sam zdefiniować treść description dla danej podstrony, ale bot może, nie musi wyświetlić nasz lub inny opis. Jeśli uzna, że inny fragment zawartości danej podstrony lepiej pasuje do danego zapytania to przedstawi ten fragment zamiast naszego opisu description.

Jeśli natomiast nie zdefiniujemy tagu description (będzie pusty albo zabraknie go w kodzie) to wtedy bot sam sobie wybierze fragment z treści strony.

Już jasne jest jak się definiuje description i jak się wyświetla. Czemu jednak jest ważny w pozycjonowaniu, skoro nie brany jest pod uwagę przy układaniu rankingu?

Bo wpływa na klikalność wyników.

W pozycjonowaniu chodzi oczywiście o uzyskanie jak najlepszych pozycji. Ale te pozycje powinny generować kliknięcia i ruch na naszej stronie a description jest z tym bezpośrednio związany. To on przekonuje użytkownika, że warto kliknąć dany wynik. Warto zwrócić uwagę, że szukana fraza także jest podkreślana w samym description.

Nagłówki h1, nagłówki śródtekstowe

Nagłówki pojawiają się w tekście. Zawsze porównujemy je, dla lepszego zrozumienia ich funkcji, do nagłówków w gazecie. W każdym artykule mamy tytuł (h1) oraz nagłówki śródtekstowe (h2, h3…).

Są też wytyczne co do ich stosowania w tekstach.

Nagłówek h1 powinien zawierać tytuł podstrony, a co za tym idzie powinien występować na danej podstronie tylko jeden raz. Czy jak pojawi się więcej razy, to będzie duży błąd? Google uspokaja że nie – możemy mieć więcej nagłówków H1.

Natomiast pamiętajmy o przejrzystości. Jeśli na podstronę zajrzy bot, znajdzie jeden nagłówek h1, to będzie to miało większą wartość (jako tytuł artykułu) niż jak znajdzie kilka nagłówków h1 (co jest wtedy tytułem?). Dlatego dobra praktyka mówi, by starać się stosować tylko jeden nagłówek h1 dla tytułu podstrony.

Dalsze nagłówki mogą być już stosowane wielokrotnie, bo są to po prostu nagłówki śródtekstowe. Służą do tego, by podzielić dłuższy tekst na logiczne części i by ułatwić czytanie.

Czyli struktura podstrony powinna być następująca:

struktura-naglowkowJeśli hierarchia trochę się zaburzy, przykładowo użyty będzie h1 do tytułu a po nim h3, z pominięciem h2 to nie stanie się nic złego. Najważniejsze o czym trzeba pamiętać to stosowanie h1 jeden raz, najlepiej powyżej pozostałych nagłówków.

Zawartość nagłówków

Nagłówki powinny zawierać ważne dla danej strony słowa kluczowe. Wspomnieliśmy, że to między innymi z ich pomocą bot definiuje do jakich zapytań będzie pasować dana podstrona. Jednak nie warto tu przesadzać z optymalizacją tylko pod bota. Nagłówki powinny być czytelne dla odwiedzającego. Ponownie – trzeba znaleźć złoty środek.

Najczęstsze błędy

Najczęstszy błąd to używanie pogrubienia dla nagłówków śródtekstowych zamiast samych nagłówków. Problem bierze się często stąd, że do pisania tekstu używany jest wizualny edytor. Autor podczas pisania pogrubia nagłówek. Prawidłowo powinien wybrać odpowiedni nagłówek z listy. W przypadku WP i wielu innych frameworków można go znaleźć w lewym rogu:

wybor-naglowkow-w-wordpressieCzyli tu po wybraniu pozycji np. Nagłówek 2 w kodzie będzie to przedstawione jako nagłówek w h2.

Szybkość ładowania strony

Nie ma specjalnie dużego znaczenia przy ostatecznej ocenie strony i pozycji w rankingu, ale to ważna rzecz do sprawdzenia. Powód jest prosty – każda sekunda dłużej przy ładowaniu strony to większa liczba użytkowników, którzy się zniecierpliwią i porzucą stronę.

Przeprowadzono wiele testów i analiz tego zagadnienia. Najciekawsze dotyczą badań nad sklepami internetowymi. Tam najlepiej widać, jak dłuższy czas ładowania strony obniża konwersję. Zależność jest więc prosta – dłuższy czas ładowania strony = mniejsza sprzedaż.

Google przyszedł z pomocą webmasterom i stworzył narzędzie PageSpeed Insights. To bardzo dobre narzędzie, które ocenia szybkość ładowania strony zarówno na komórki jak i komputery w skali od 0 do 100. Niżej znajdziemy listę rzeczy do poprawy, z podziałem na kategorie ważności:

wersja-mobilna-uwagi

Gdy klikniemy link Pokaż jak to naprawić pojawi się szczegółowy opis z propozycją rozwiązania problemu:

uwagi-optymalizacyjne-mobile

Często są tu zalecenia do technicznej strony serwisu, które musi wdrożyć webmaster. Czasem mogę wymagać większych nakładów pracy. Bardzo pomocne są jednak szczegółowe podpowiedzi i jasny podział listy na rzeczy ważne i mniej pilne, co pozwala szybko usunąć problemy w kluczowych miejscach.

Walidacja

Ponownie czynnik jak szybkość ładowania stron – raczej nieistotny przy pozycjonowaniu, ale dobre praktyki nakazują zwrócić na niego uwagę. O co chodzi z walidacją? O to, by kod strony był prawidłowo napisany. Opracowywaniem standardów webowych zajmuje się organizacja The World Wide Web Consortium (W3C) – https://www.w3.org – i to na jej stronie udostępniony jest walidator https://validator.w3.org. Po podaniu adresu przedstawiona jest lista błędów i sugestie poprawek:

walidacja-w3-wynikiJak podejść do tej listy? Jeśli mamy małą stronę i błędów jest kilka to warto je usunąć zgodnie z wytycznymi walidatora. Jeśli jednak strona jest bardzo duża i pojawia się spora liczba błędów to raczej warto skupić się tylko na tych najważniejszych. Po prostu środki poświęcone na naprawdę dużej liczby błędów nie przełożą się specjalnie na aż tak duże korzyści.

Wersje mobilne

Nadal można spotkać strony, które nie mają wersji mobilnej, a to duży błąd. Zdarza się, że nawet połowa wyszukań pochodzi z urządzeń mobilnych. Jak to rozróżnić? W Google Analytics z lewej strony jest sekcja Ruch mobilny, gdzie znajdziemy podział na urządzenia:

analytics-wejscia-mobilne

Widać, że w przykładzie 56% ruchu pochodzi z komputerów, 36% ze smartfonów, 8% z tabletów. Czyli jak zsumujemy komórki i tablety to mamy 44% ruchu, który pochodzi z innych urządzeń niż komputery. Podobne statystyki można zobaczyć na wielu innych serwisach.

Liczby wyżej wyraźnie pokazują, że ruch mobilny jest ważny i nie mając odpowiednio przygotowanej strony taki użytkownik najpewniej zamknie stronę.

Aby nie było wątpliwości, czy strona będzie miała problemy, czy nie, Google przygotowało test zgodności z urządzeniami mobilnymi. Test można znaleźć pod adresem.

Działa bardzo prosto. Wpisujemy adres strony do sprawdzenia. Po chwili dostajemy wynik. Jeśli wszystko jest ok, to dostaniemy prosty komunikat.

Jeśli natomiast będą problemy, to dostaniemy listę potencjalnych problemów, które utrudniają prawidłowe wyświetlanie na urządzeniach mobilnych, tak jak na przykładzie niżej.

Wersja mobilna sklepu internetowego – najczęstsze błędy

Dlaczego wersja mobilna jest tak ważna?

Pierwszy powód, który poda wielu pozycjonerów to wpływ wersji mobilnej na pozycje witryny w wynikach wyszukiwania. Google otwarcie przyznał, że jeśli witryna nie ma wersji mobilnej (lub jest niedopracowana) to gdy wyszukiwanie ma miejsce na urządzeniach mobilnych strona będzie niżej w wynikach. Co więcej, tu plany idą jeszcze dalej, bo w przyszłym roku Google planuje uruchomić całkowicie osobny indeks wyników dla wyszukań mobilnych.

Drugi powód jest oczywiście związany z kwestiami usability i konwersji. Jeśli użytkownik nie będzie mógł poprawnie wyświetlić witryny na swoim urządzeniu to po prostu zamknie stronę i przejdzie do następnej witryny.

To dwa całkiem dobre powody dla których warto zadbać o wersję mobilną strony. Zobaczmy więc jakie są najczęstsze problemy.

Brak wersji mobilnej

Oczywiście największym problemem przy wersji mobilnej jest jej brak :). Pomimo że dane o tym, że wyszukiwania z urządzeń mobilnych są tak liczne jak z urządzeń stacjonarnych to nadal znajdziemy sporo przykładów stron, które takowych wersji nie mają. Każdy dąży do większego ruchu, większej sprzedaży ale trzeba najpierw zadbać o podstawy.

Sprawdziliśmy jak to wygląda na kilku losowych serwisach naszych klientów o różnej tematyce (taką możliwość daje np. Google Analytics w części Odbiorcy → Ruch mobilny ). Wyniki przedstawiają się następująco:

Klient 1 – sklep internetowy:
Desktop: 59%
Tablety: 6%
Telefony: 35%

Klient 2 – portal medyczny:
Desktop: 48%
Tablety: 7%
Telefony: 45%

Klient 3 – portal finansowy:
Desktop: 76%
Tablety: 4%
Telefony: 20%

Klient 4 – strona lekarza, usługi lokalne w ramach miasta:
Desktop: 64%
Tablety: 5%
Telefony: 31%

Klient 5 – blog:
Desktop: 46%
Tablety: 4%
Telefony: 50%

Ciekawe jest, że udział tabletów jest raczej mały, co nie znaczy że można pominąć je przy tworzeniu wersji mobilnej. .

Natomiast liczby desktop vs. telefony różnią się zależnie od branży. W kilku przypadkach ruch z wersji desktop stanowił mniej niż 50%. Nawet jeśli dla danej branży ruch mobilny jest mniejszy to i tak oscyluje w granicach 20-30%. Jakby na to nie patrzeć, 30% ruchu to nadal spora część odwiedzających o których warto zadbać.

Wersja dostosowana tylko do niektórych urządzeń

W przypadku wersji mobilnych można mówić o dwóch głównych typach to jest:

– wersja RWD (Responsive Web Design) – strona responsywna, która dostosowuje się do danego urządzenia. Czyli mamy jeden kod html strony, a style CSS są napisane tak że dostosowują się do rozdzielczości danego urządzenia

– wersja AWD (Adaptive Web Design) – wersja adaptacyjna strony, pisana z myślą o konkretnym urządzeniu. Przy otwieraniu strony rozpoznawany jest typ urządzenia i wyświetlany jest odpowiedni kod. Dla każdej wersji mamy osobny kod html, stąd często ładowany jest z subdomeny (np. http://m.strona.pl).

Najpopularniejszy obecnie format to RWD, zaś AWD rzadko kiedy ma uzasadnienie w dzisiejszych czasach.

Jeszcze jeden problem jest w ramach samego RWD. Dobra wersja RWD dostosuje się do każdego urządzenia, ale żeby tak było trzeba napisać dobry kod jak również przetestować naszą wersję RWD. Tymczasem często zdarza się, że deweloper ogranicza się tylko do testów na swoim smartfonie albo smartfonie klienta :). A tu przecież nie o to chodzi. Jest dużo różnych urządzeń, o różnych rozdzielczościach.

Długi czas ładowania

Prędkość ładowania to wiele razy poruszany temat. Można przeczytać wiele badań na temat tego jak szybkość ładowania strony wpływa na zachowania użytkowników, porzucenia itd. Jednak prawda jest taka, że tu nawet bez zapoznawania się z wynikami testów można dojść do podobnych wniosków. Nawet na bazie własnych doświadczeń :).

Ile to razy zdarzyło się nam zamknięcie strony lub przejście do następnej zakładki gdy pierwsza strona nie chciała się otworzyć? Użytkownicy chcą dane tu i teraz i jest to coś do czego się trzeba dostosować.

Narzędzie Google PageSpeed Insights pokazuje wyniki szybkości ładowania strony osobno dla PC i urządzeń mobilnych.

pagespeed-insights

Bardzo fajne jest w tym narzędziu to, że po analizie dostajemy dokładne sugestie co wymaga poprawy. Nawet jak nie jesteśmy się w stanie z czymś sami uporać to zawsze możemy przekazać dokładne wytyczne programiście odpowiedzialnemu za stronę.

Niepoprawne ładowanie / Źle wykonana wersja mobilna

Zdarza się to dość często. Wersja mobilna źle się wyświetla na naszym urządzeniu mobilnym. Bierze się to stąd, że jest po prostu niedopracowana. Czasem są to błędy, które psują tylko wizualny odbiór strony, czyli np. źle wyświetlający się obrazek, źle dobrany rozmiar czcionki.

Są też błędy, które uniemożliwiają całkiem korzystanie z niektórych elementów witryny jak np. schowany przycisk wyślij przy formularzu, nieczytelne menu. Jeszcze raz widać tu, że testy są po prostu konieczne i nie można zadowolić się faktem, że na jednym urządzeniu strona wyświetla się poprawnie.

Zła nawigacja mobilna

To mogłoby wpaść pod temat źle wykonanej wersji mobilnej, ale warto osobno omówić osobno nawigację mobilną. Musi ona być czytelna i łatwa w obsłudze. Nie jest to takie łatwe do osiągnięcia, szczególnie przy stronach, które mają mocno rozbudowaną strukturę.

Na szczęście z pomocą przychodzi jQuery i jest sporo sposobów, by zrobić czytelne menu gdy mamy do czynienia z rozbudowaną strukturą. Na tej stronie zaprezentowane zostały najróżniejsze podejścia do nawigacji mobilnej.

W przypadku wersji mobilnej często wdrażałem to wielopoziomowe menu. Jest trochę ciężkie do wdrożenia i ostylowania, ale efekt końcowy zawsze jest dobry. Jest przejrzyste i bardzo funkcjonalne:

menu-mobilne

Popupy

Wtyczki popup jak również sam CSS (z pomocą media query) dają możliwość wyłączenia popupów na urządzeniach mobilnych. Nie ma chyba nic bardziej irytującego niż popupy na smartfonie, bo najczęściej zajmują one od razu cały ekran. Co gorsza, zdarza się że przycisk do zamknięcia chowa się gdzieś poza ekranem… Samo zło.

Długie formularze i inne grzechy UX

Strona może dobrze się wyświetlać na urządzeniach mobilnych i na desktop. Jednak co do samej funkcjonalności to nie zawsze to co zdało egzamin na dużym monitorze komputera będzie działać tak samo dobrze na smartfonie. Przykład który pierwszy przychodzi na myśl to długie formularze składające się z wielu pól. Mało komu będzie chciało się wypełniać taki formularz na komórce.

To tylko przykład. Warto zrobić analizę UX zarówno wersji desktop jak i wersji mobilnej, by wyłapać problemy tego typu.

Brak dostosowania do starszych urządzeń pod kątem wyświetlacza

Nowe smartfony pojawiają się teraz średnio co roku a nawet częściej (przykład Galaxy S, iPhone) i wielu użytkowników idzie tym trendem i chce mieć najnowszy dostępny model. Jest jednak spora grupa użytkowników, która wymienia swoje telefony rzadziej lub kupuje urządzenia używane.

Co za tym idzie, mają smartfona ale o mniejszym wyświetlaczu. Przykładem jest iPhone 5, który przez długi czas był bardzo popularny ale jego mały wyświetlacz znacznie odbiegał od konkurencji. Nie znaczy to jednak że przy tworzeniu strony można pomijając użytkowników piątki.

Po premierze modelu 6 i 7 piątki mocno staniały i krążą gdzieś w obiegu na rynku telefonów używanych. Dlatego warto przy testowaniu wersji mobilnej strony sprawdzić jak zachowuje się strona na nieco starszych smartfonach. Oczywiście bez przesady, nie trzeba cofać się w czasie do pierwszych smartfonów. Ale sprawdzenie jak strona wyświetla się na modelach telefonów sprzed 3-4 lat jest dobrą zasadą.

Niedostosowana do Safari / różnych przeglądarek

Bardzo często zapominana rzecz przy tworzeniu urządzeń mobilnych to różnorodność oprogramowania i przeglądarek. Na androidzie mamy wbudowane przeglądarki, ale użytkownik może też zainstalować Firefoxa, Chrome lub inną. Trzeba sprawdzić jak na wersji mobilnej na każdej z nich wyświetla się strona.

Osobny przykład to Safari na iOS. Szczególnie starsze wersje Safari to jest niezła zabawa przy tworzeniu wersji mobilnej, prawie taka jak walka z Internet Explorerem ;). W skrócie, pewne style interpretowane są inaczej na Safari niż na Firefox czy Chrome. W efekcie dopracowana wersja mobilna pięknie działająca na Firefox i Chrome totalnie się sypie na Safari. Dotyczy to zarówno wersji desktop jak i wersji mobilnych.

Stąd popularność strony Can I use wśród web developerów. Dzięki niej mogą sprawdzić, które funkcje i style działają na określonych przeglądarkach i konkretnych ich wersjach. Przykład: http://caniuse.com/#feat=dragndrop.

Liczby mówią same za siebie. Jest moda na telefony od Apple i nawet jeśli w naszym gronie przeważają androidowcy to nie znaczy to wcale, że liczba osób przeglądających stronę na iPhone będzie mała. Wręcz przeciwnie, a szczególnie jeśli strona ma wersję zagraniczną. Na Zachodzie iPhone dominuje i dlatego warto zadbać o wersję mobilną, która dobrze wyświetla się na iOS.

Niedostosowana do tabletów

Często przy tworzeniu wersji mobilnej koncentracja jest na smartfonach, a zapomina się o tabletach. Wersja responsywna strony powinna zapewnić dobre wyświetlanie także na nich, ale warto to sprawdzić.

Nacisk warto położyć na popularne iPady. Jest tam Safari i są podobne problemy z wyświetlaniem jak opisane wcześniej przy smartfonach.

Jak sprawdzić wyświetlanie naszej strony na różnych urządzeniach?

Dużo we wpisie było o testowaniu, sprawdzaniu na różnych systemach, przeglądarkach, urządzeniach. Jak najlepiej testować to w praktyce?

Na pewno najlepsze są testy na prawdziwych urządzeniach. Dobrze jest przynajmniej przetestować po jednym urządzeniu z Androidem i iOSem. Już to powinno pozwolić wyłapać większe błędy i niedociągnięcia.

Inny sposób to narzędzia dostępne w przeglądarkach.

W przeglądarce Google Chrome po przejściu do opcji i włączeniu Narzędzi dla programistów możemy wybrać zakładkę do testowania urządzeń mobilnych (druga ikona od lewej):

chrome-podglad-mobileTo tworzy nam podgląd jak wyświetla się strona w rozdzielczości typowej dla danego urządzenia (lista urządzeń jest większa niż na screenie, można ją poszerzyć):

podglad mobile na chromeRównież w Safari jest podobna opcja. Po włączeniu menu Programowanie mamy do wyboru podgląd na różnych przeglądarkach i urządzeniach:

testowanie-wersji-mobilnej-safari

Jeśli ktoś chce jeszcze dokładniej sprawdzić wersję mobilną to są strony oferujące emulatory jak np. https://www.browserstack.com. To płatne narzędzie ale daje możliwość sprawdzenia strony na naprawdę dużej liczbie urządzeń.

Podsumowując

Jak widać temat wersji mobilnej nie jest tak prosty jakby mogło się wydawać. Jest tu kilka pułapek i sporo rzeczy o których warto pamiętać. Technika idzie do przodu i wersja mobilna po prostu musi być dobrze dopracowana.

2.5. Not provided w Google Analytics – co oznacza

Przeglądając informacje o odwiedzinach w Google Analytics na pewno zobaczymy w kolumnie Słowa kluczowe, że najwięcej wejść jest z (not provided). Najczęściej ponad 90% wyszukań będzie właśnie przypisanych do not provided.

O co tu chodzi i czym jest tajemniczy not provided? Jest to wynik zmiany zapowiedzianej przez Google w 2011 roku, a wprowadzonej w życie na początku 2012 roku. Kiedyś mogliśmy bez problemu przeglądać całą listę fraz, dzięki którym użytkownicy trafili na naszą stronę. Jednak Google postanowiło zatroszczyć się o bezpieczeństwo szukających i ich prywatność. Od 2012 roku jeśli wyniki są dokonywane z użyciem https w adresie to szukane frazy będą szyfrowane. Kiedy tak się dzieje? Np. kiedy jesteśmy zalogowani na konto Google (bo korzystamy z Gmail lub innej usługi) lub po prostu kiedy wyszukujemy wchodząc na https://google.pl. Tutaj dokładne wyjaśnienie na czym polega problem: więcej.

Ile not provided stanowi wszystkich wyszukań? Ekipa z http://www.notprovidedcount.com postanowiła to mierzyć biorąc do testów 60 stron. Dzięki temu dokładnie widać jak liczba not provided wzrastała od 2012 roku:

licznik-not-providedWidać wyraźnie, że dla większości serwisów średnio 80% ruchu ukryta jest pod not provided.

Wersje www i non www

Dość częsty problem ze stronami. Dla wielu właścicieli strona po prostu jest pod danym adresem http://przyklad.pl. Jest jedna, więc jak pozycjoner tłumaczy, że jest problem z kopiami strony, to pojawia się zdziwienie o jakie kopie chodzi.

O tym, czy strona ma mieć www przed adresem czy nie, decyduje właściciel strony ustalając odpowiednie przekierowania. Czyli może zdecydować, że chce mieć adres z www:

http://www.przyklad.pl

lub bez www:

http://przyklad.pl

Nie ma to wpływu na wyniki, obie wersje są w porządku. Są to jednak dwie różne wersje. Jeśli webmaster czy właściciel witryny zapomni zdefiniować, jaka jest preferowana wersja to może zdarzyć się, że będą one współistnieć obok siebie, czyli będziemy mieli kopie.

Jak sprawdzić czy strona ma kopie www/bez www?

Najprościej wpisać obie wersje w pasku adresu w przeglądarce. Załóżmy, że preferowana wersja jest z www. Wtedy po wpisaniu http://przyklad.pl powinniśmy zostać przekierowani na http://www.przyklad.pl. Jeśli nie ma ustalonej preferowanej wersji, to nie będziemy przekierowani i będziemy mogli otworzyć oba adresy.

Drugi sposób to sprawdzenie site’a. W pasku szukania wpisujemy site:adres.pl i sprawdzamy, jakie rodzaje adresów są w indeksie. Niżej po sprawdzeniu widać, że wszystkie adresy mają www (patrzymy na zielone adresy URL):

sprawdzenie-site

Gdyby był tu problem to zobaczylibyśmy wersje adresów bez www oraz z www.

Można też skorzystać z narzędzi do sprawdzenia przekierowań typu http://www.redirect-checker.org/. Wklejamy dwie wersje adresu strony głównej (z i bez www) i sprawdzamy czy jest przekierowanie 301. Na jednej z wersji powinno być ustawione przekierowanie 301 na pożądaną wersję. Jeśli się pokaże kod 200 to znaczy że jest to prawidłowa, docelowa wersja.

Jak usunąć problem z kopiami www?

Za pomocą odpowiedniej reguły przekierowań, którą robi się po stronie serwera. W przypadku popularnego Apache edytuje się plik htaccess i dodaje kilka linijek kodu, które załatwiają sprawę.

Niektóre skrypty jak np. WordPress od razu po instalacji jest już prawidłowo skonfigurowanych i nie ma tego problemu. Jednak wiele innych CMSów, szczególnie autorskich, ma ten problem.

Zdjęcia– optymalizacja grafik

Obrazki to często niedoceniony temat w przypadku optymalizacji serwisu i przy samym pozycjonowaniu. Wynika to stąd, że dla wielu osób pozycjonowanie to tylko wyniki organiczne i ich celem jest pojawienie się w wynikach 1-10. Tymczasem ruch można ściągać też z mapek (które pokazywane są ponad wynikami) czy właśnie z obrazków. Często są one prezentowane w ten sposób (wmieszane w pozostałe wyniki):

zdjecia-w-wynikachPamiętajmy też, że jest grupa fraz, które są szukane przez wyszukiwarkę obrazów.

Oczywiście będą strony o takiej tematyce, że obrazki nie ściągną za wiele ruchu. Jednak widzieliśmy bardzo dużo przykładów sklepów, gdzie dzięki dobrze zoptymalizowanym grafikom ściągany był zauważalny ruch.

Co w takim razie trzeba zrobić, żeby dobrze zoptymalizować obrazki, tak by pomagały one przy pozycjonowaniu strony i ściąganiu ruchu?

Nazewnictwo plików

Ważne jest nazewnictwo plików. Jest ono pomocne zarówno dla botów jak i użytkowników. Nazwy powinny być krótkie, powinny oddawać zawartość zdjęcia a poszczególne słowa w nazwie należy oddzielać myślnikami.

Złe nazwy plików:

  • 1245824_DS_12042016.jpg
  • zdjecie.jpg
  • to_ja.png

Dobre nazwy plików:

  • plaza-wejherowo-12.jpg
  • skoda-octavia-wnetrze.jpg
  • rozowy-storczyk-5.jpg

Od razu widać, że przy właściwym nadawaniu nazw plików można powiedzieć, co przedstawiają zdjęcia. Pamiętajmy, że dziennie dodawanych są miliony zdjęć i jeśli nie zadbamy o ich prawidłową optymalizację, to nie będą prawidłowo rozpoznane.

Znacznik ALT

Drugi, bardzo ważny element, który należy wypełniać. Znajduje się on w kodzie, przy wskazywaniu lokalizacji obrazka:

znacznik-alt-w-pozycjonowaniu

Pełni on dwie funkcje. Jeśli jest problem z załadowaniem zdjęcia (np. z powodu wolnego łącza, złej ścieżki do pliku) to wyświetlona zostanie zawartość znacznika ALT. Dzięki temu, nawet bez zdjęcia, użytkownik będzie wiedział, co powinno być w tym miejscu. Przykład niżej pokazuje sytuację, gdy dwa zdjęcia się nie załadowały, ale nawet wtedy widać, co powinno być w danym miejscu dzięki wyświetleniu ALTa.

Druga ważna funkcja to pomoc w zrozumieniu zawartości dla robota. Pokazywane wcześniej wyniki wyszukiwania obrazków według danej frazy muszą być dopasowane do danego zapytania. Zawartość alt pomaga dopasować robotowi zdjęcie do danego zapytania. Dlatego ważne jest odpowiednie uzupełnianie altów przy obrazkach. Warto się kierować następującymi zasadami:

  • opisy powinny być zwięzłe
  • powinny zawierać słowa kluczowe związane z danym obrazkiem

Rozmiar plików i rozszerzenia

Warto zapisywać zdjęcia w formatach, które zapewniają odpowiednią kompresję, czyli np. jpg, png. Należy unikać formatów jak bmp czy innych, które generują zdjęcia w bardzo dużych rozmiarach.

Rozdzielczość zdjęć

Dobrze jest zamieszczać zdjęcia w na tyle dużych rozdzielczościach, aby dobrze prezentowały się na różnych urządzeniach, w tym na dużych monitorach. Nie ma co jednak przesadzać i publikować zdjęć w bardzo dużych rozmiarach, gdyż będą miały one duże rozmiary i będą długo się ładowały.

Sitemapa dla obrazków

Jeśli na stronie publikowanych jest dużo obrazków, to warto dodać sitemapę obrazków. Jest to plik, w którym wskazuje się robotowi wszystkie lokalizacje zdjęć. Dzięki temu mamy pewność, że robot uzyska listę wszystkich zdjęć na stronie i nie będziemy musieli czekać, aż sam je odnajdzie i zaindeksuje.

Sitemapy

Sitemapy to, jak podpowiada nazwa, mapa strony. Aby lepiej zrozumieć, po co są potrzebne, sprawdźmy co się dzieje, gdy ich nie ma.

W indeksie Google znajdują się podstrony, które uznane zostały za warte dodania. Można to sprawdzić, szukając z komendą site:adresstrony.pl:

przeglad-siteNa powyższym przykładzie widać, że do indeksu trafiło niecałe 30 podstron. To mała strona, najpewniej trafiły tu wszystkie podstrony.

Tylko jak się tam znalazły? Robot wchodzi na stronę i stara się rozeznać w strukturze wewnętrznej serwisu. Robi to oczywiście za pomocą linków wewnętrznych, za pomocą których odkrywa kolejne strony. Większość z nich zostanie dodana do indeksu.

W przypadku małych stron, jak ta z przykładu wyżej, robot szybko rozezna się w strukturze i znajdzie wszystkie podstrony. Problem pojawia się przy dużych serwisach jak sklepy czy portale, które mają po kilkaset tysięcy albo kilka milionów podstron. Są i takie przypadki. Crawlery Google radzą sobie bardzo dobrze w indeksowaniu podstron, ale przy dużych stronach kosztuje je to więcej czasu. I tak jak w przykładzie wyżej bot wszedł i od razu znalazł wszystkie 29 podstron, to tak łatwo i szybko nie pójdzie mu przy dużym sklepie.

To jeden z powodów, dlaczego warto stosować sitemapy. Gdy robot widzi, że webmaster udostępnia mu sitemapę, wtedy wie, że są to adresy, które webmaster chciałby prezentować użytkownikom. Dostaje wszystkie adresy podane na talerzu i nie musi tracić czasu na ich samodzielne odnajdywanie. Po prostu wchodzi pod podane adresy podstron z listy.

Mamy rodzaje sitemap:

sitemapa XML – dodaje się ją w formacie XML (https://pl.wikipedia.org/wiki/XML) w Google Search Console. To sitemapa przeznaczona tylko dla robota. Po jej przesłaniu widać, ile adresów zostało przesłanych a ile z nich trafiło do indeksu.

sitemapa HTML – najczęściej umieszcza się ją na osobnej podstronie i link do tej podstrony z sitemapą dodaje się w stopce. Robot też z niej może skorzystać, ale tworzy się ją również z myślą o odwiedzającym. Wyobraźmy sobie sklep z wieloma kategoriami, podkategoriami. Czasem nawigacja może być utrudniona. Mapa strony może być w takim wypadku bardzo przydatna. Dobrym przykładem jest mapa strony z cyfrowe.pl http://www.cyfrowe.pl/mapa-strony.html.

Od razu widać tu podział na kategorie i podkategorie. Użytkownik łatwo może znaleźć to czego szuka. Jest to też przydatne na urządzeniach mobilnych. Niektóre menu są po prostu toporne, szczególnie przy bardzo dużej liczbie kategorii i podkategorii. Wtedy szybciej jest przejść na mapę strony i znaleźć interesującą nas pozycję.

Robots.txt a meta tag robots

Pomimo podobnych nazw są to dwie różne rzeczy, aczkolwiek o zbliżonej funkcji. Każda strona jest odwiedzana przez roboty – nie tylko Google, ale też innych wyszukiwarek czy stron (np. crawlery Majestic, Ahrefs). Właściciel strony ma możliwość wpływu na to, co robią roboty na jego stronie i z jego stroną.

Meta tag robots

Służy głównie do informowania bota, czy chcemy by dana strona była włączona do indeksu. W kodzie ma on postać jak niżej, znajduje się w sekcji head:

robots-txt-przyklad

Domyślna wartość dla niego to follow. Jeśli jednak nie chcemy, by strona pojawiała się np. w wynikach wyszukiwania Google to mamy możliwość ustalenia tagu robots na nofollow dla całej strony lub pojedynczej strony i wtedy robot potraktuje to jako informację, żeby strony nie indeksować.

Robots.txt

To plik robots.txt który zawsze znajduje się bezpośrednio w folderze root tzn. znajdziemy go pod adresem http://www.strona.pl/robtos.txt. Najczęściej będzie on miał postać:

Oczywiście pliki robots.txt mogą być dużo dłuższe niż przykład wyżej.

Do czego służy robots.txt? Wyobraźmy sobie sytuację, że prowadzimy bardzo duży sklep – setki tysięcy podstron, obrazków itp. Jak wspomnieliśmy, stronę odwiedzają nie tylko roboty Google ale także inne roboty, które przeglądają całą naszą stronę. Generują przy tym duże obciążenia serwera. Wbrew pozorom to częsty problem dużych serwisów, gdy boty potrafią zauważalnie obciążyć serwer. Dzięki robots.txt możemy tak pokierować ruch robotów, by niektóre np. w ogóle nie wpuszczać lub wpuszczać je tylko do określonych części strony.

Należy pamiętać, że instrukcje w robots.txt to polecenie, które niektóre roboty mogą zignorować. Najczęściej jednak stosują się do poleceń i daje to możliwość webmasterom pewnej kontroli nad robotami.

Więcej o robots.txt tutaj.

Alternatywnie można dodać też odpowiednie blokady w pliku htaccess.

Przyjazne URLe

Format adresów URL ma znaczenie. Adresy podstron można podzielić na dwie kategorie:

  1. a) nieprzyjazne URLe, przykład:

strona.com/section/9/article-id-99
strona.com/section/9/article-id-99/bardzodlugiurl,ciezkidoprzeklejenia,192.html

  1. b) przyjazne URLe, przykład:

strona.com/motoryzacja/uzywane-samochody-do-10-tys

Na szczęście teraz wiele CMSów i skryptów sklepowych ma już wbudowane moduły do generowania przyjaznych URLi. Nadal jednak trafiają się strony, gdzie się o tym zapomina i warto to poprawić.

Dlaczego ważne jest, by na stronie były przyjazne URLe?

  1. Opisowe, przyjazne URLe ułatwiają robotom poruszanie się i indeksację podstron serwisu.
  2. Gdy na stronie są krótkie, przyjazne URL to zachęca odwiedzających do przekopiowania adresu i np. podzielenia się nim na forum lub innym miejscu. Wbrew temu co mówią niektórzy, istnieje nadal coś takiego jak naturalne linki i ludzie udostępniają je dalej – czy to publicznie na forum, blogu czy też prywatnie w mailu czy przez social media. Dlatego dobrze jest im to ułatwić.
  3. URLe podstron są prezentowane w wynikach wyszukiwania i jeśli zawierają szukane słowo kluczowe to również ono jest wyróżnione.

Należy dopilnować, by w adresach podstron poszczególne słowa oddzielone były myślnikami a nie podkreśleniem, tzn.:

nieprawidłowo: strona.com/adres_podstrony
prawidłowo: strona.com/adres-podstrony

Adresy nie powinny zawierać spacji oraz znaków specjalnych (procenty, gwiazdki itp.). To kilka podstawowych rzeczy, które mogą mieć zauważalny wpływ na strukturę i i wyniki pozycjonowania serwisu.

Nawigacja w sklepie internetowym

Kluczowy element dla wygodnego użytkowania strony. Dobrze rozwiązana nawigacja pomaga też botom odnaleźć wszystkie podstrony i jest pomocna w rankingu dla najważniejszych podstron.

W przypadku nawigacji należy pamiętać o urządzeniach mobilnych. Tu najczęściej pokazywana jest osobna nawigacja mobilna, rozwijana przyciskiem hamburgera.

Niby szczegół, ale jednak bardzo często można spotkać strony, które są bardzo trudne w nawigacji na urządzeniach mobilnych, właśnie przez źle wykonaną nawigację.

Http i https

Podobna sytuacja jak z opisywanym wcześniej problemem www i możliwymi kopiami. Rzadko, ale zdarza się, że przez błędne ustawienie strona pojawia się zarówno w wersji http i https, co tworzy kopie. Można to sprawdzić przeglądając site strony. Jeśli dla zapytań ‚site:http://www.strona.pl‚ oraz ‚site:https://www.strona.pl‚ dostaniemy podobne wyniki, gdzie ta sama podstrona będzie występowała w dwóch wersjach, to prawdopodobnie mamy do czynienia z kopią.

Mała uwaga – czasem zdarza się, że strona jest na http:// ale niektóre części (logowanie, koszyk itp.) są już na https://. W tym przypadku te dwie wersje występują koło siebie, ale nie tworzą kopii.

Która wersja powinna być używana? Pamiętajmy, jakie jest przeznaczenie https – szyfrowanie przesyłanych danych. Zatem jeśli na stronie prosimy użytkowników o podanie wrażliwych danych, to jak najbardziej wskazane jest używanie https. W przypadku stron informacyjnych, gdzie nie ma logowania, zakupów i przesyłania innych wrażliwych danych można spokojnie stosować http.

Google oficjalnie potwierdziło, że https jest preferowaną wersją i jest to czynnik rankingujący. Jednak dotychczasowe testy pokazały, że ma to znikomy wpływ na końcową pozycję strony. Stąd też przy decyzji o przejściu bądź nie na https trzeba się kierować względami bezpieczeństwa – jeśli na stronie są przesyłane dane wrażliwe to tak, warto, a przy okazji będzie to zgodne z wytycznymi Google.

Efekt wdrożenia optymalizacji a oczekiwania klientów

Do tej pory dość dokładnie przyjrzeliśmy się, jakie elementy strony podlegają optymalizacji. Jak widać, dużo z nich to elementy strony wymagające bezpośrednio zmian w kodzie lub modyfikacji CMSa/skryptu sklepu tak, by wprowadzone dane prawidłowo były pokazane w kodzie. Treści też stanowią ważny element w procesie optymalizacji i pozycjonowania stron. Opisane zostały w osobnym rozdziale.

Osobiście, gdybyśmy mieli wybierać pomiędzy bezbłędnie zoptymalizowaną stroną ale ze średnią treścią, a stroną słabo zoptymalizowaną, ale z bardzo dopracowaną, ciekawą treścią to zawsze wybralibyśmy serwis gdzie lepsza jest treść.

Dlaczego? O tym za chwilę. Najpierw jednak musimy wyjaśnić, dlaczego optymalizacja techniczna serwisu jest często źle interpretowana przez klientów i właścicieli stron.

Co myśli właściciel serwisu: po wprowadzeniu zaleceń mój serwis wskoczy od razu do top 10, zwiększy się też ruch, bo przecież będzie lepiej zoptymalizowany pod konkretne frazy.

Jaka jest rzeczywistość: czasem optymalizacja przynosi rzeczywiście bardzo dobre efekty (np. gdy domena jest bardzo mocna, a po prostu kulała optymalizacja serwisu), ale zdarza się dość często, że po samej optymalizacji nie ma oczekiwanego efektu wow. Są zmiany na plus, ale nic spektakularnego.

Dlaczego tak się dzieje: optymalizacja to szereg zmian, które mają na celu poprawienie strony (kodu, układu, treści itp.) tak aby była zgodna z wytycznymi Google. Niektóre zmiany rzeczywiście mogą być robione intuicyjnie według doświadczenia danego pozycjonera, ale i tak biorą się one stąd, że Google zaleca dany kierunek. Można to porównać do wyścigu samochodów rajdowych. Specyfikacja jasno określa jakie zmiany są dozwolone, a jakie zabronione. Dzięki temu na linii startu żaden z samochodów nie wybije się ponad konkurencję, bo zamontowano tam mocniejszy niż dozwolony silnik. Do tego też dąży optymalizacja stron – aby była jak najbardziej zgodna z wytycznymi Google. Później o tym która strona będzie uznana za lepszą zdecydują rzeczy jak moc domeny, linki, treści.

Wiele serwisów z topów jest już dobrze zoptymalizowana, szczególnie tam gdzie konkurencja jest bardzo silna. Dlatego jeśli serwis klienta był źle/słabo zoptymalizowany i poprawimy te błędy optymalizacyjne to nie jest to argument by tenże serwis przeskoczył całą konkurencję i wskoczył na jedynkę. On po optymalizacji po prostu równa się z konkurencją i w grę wchodzą pozostałe czynniki jak moc domeny, zaufanie, dopasowanie treści.

Wracając do pytania z początku – czemu wybralibyśmy serwis gorzej zoptymalizowany, ale z lepszą treścią?

  1. a) Jeśli treść w serwisie jest naprawdę dobra, to nawet pomimo gorszej optymalizacji ma szansę pojawiać się wysoko. Widzieliśmy takie zjawisko nie raz przez lata pracy.
  2. b) Ludzie linkują do dobrej treści. Szczególnie jeśli jest to przydatna, informacyjna treść – możemy spodziewać się naturalnych linków z forów, blogów, mediów społecznościowych i różnych stron.
  3. c) Dobra treść generuje ruch z długiego ogona. Jeśli dany artykuł wyczerpuje temat, to pojawia się nie tylko na główne zapytanie, ale często też na setki innych, długoogonowych złożeń, generując przy tym zauważalny ruch.

To chyba dość dobrze oddaje fakt, jak ważna jest treść w procesie pozycjonowania, walki o ruch i dobre miejsca.

Canonicale

Bardzo przydatna funkcja, szczególnie ważna w sklepie internetowyn. Pozwala ona wskazać robotowi, gdzie znajduje się oryginał treści. Wyobraźmy sobie scenariusz, gdzie zarządzamy mocno rozbudowanym sklepem i chcemy przyporządkować produkt do kilku kategorii. Jednak jeśli to zrobimy, to będzie on występował w kilku miejscach co jest równoznaczne z tym, że będzie miał kilka kopii wewnętrznych w obrębie sklepu. Dzięki canonicalom możemy wskazać jedną podstronę, która powinna być potraktowana jako główna.

W kodzie definiuje się canonicale w sekcji head, mają one postać jak niżej:

canonical-wazny-element-optymalizacji-seoCanonicale są bardzo ważne w pozycjonowaniu, bo pozwalają uniknąć kopii treści i związanych z tym problemów. Przy większych serwisach trzeba dobrze przemyśleć i zaplanować ich użycie i najczęściej dobrze by pomagał przy tym pozycjoner z doświadczeniem.

Więcej o stosowaniu przekierowań kanonicznych tutaj.


Poradnik – menu.
Część 1. Promocja i rozwój sklepu internetowego.
Część 2. Optymalizacja sklepu internetowego
Część 3. Indeksacja sklepu internetowego
Część 4. Treści w sklepie internetowym
Część 5. Linkowanie sklepu internetowego
Część 6. Narzędzia pomocne przy pozycjonowaniu