Ten tekst jest wynikiem ostatnich kilku potyczek z deweloperami, którzy, przy całym szacunku do ich wiedzy i ogromnego talentu programistycznego, wiedzą co i jak wdrożyć na serwisie, ale nie kumają przeznaczenia. Poniżej taka checklista z linkami oraz informacjami, które można przekazać. Chciałbym miec to wszystko w SaaS’ach <3

1.  Fragmenty rozszerzone

Jest wiele typów fragmentów rozszerzonych. Generalnie służą do przekazania informacji do wyszukiwarek bez potrzeby czytania przez nie całego HTMLa. Fragmenty rozszerzone pozwalają na wzbogacenie wyników wyszukania ponieważ wyświetlają cenę, gwiazdki, dostępność etc.

Pod tym adresem są opisane najbardziej popularne dane uporządkowanehttps://developers.google.com/search/reference/overview.

Najczęstsze problemy spotkane w implementacjach:

  • wstawienie nagłówków Hx do menu okruszkowego
  • implementacja typu Organization wewnątrz drzewa Product (czyli tam gdzie był producent na karcie produktu wstawiono, niezgodnie z przeznaczeniem, typ Organization, który służy do oznaczenia właściciela serwisu, sklepu a nie producenta)
  • wstawienie „na sztywno” (na stałe) w danej pozycji np. gwiazdek 5 na 5
  • implementacja gwiazdek na stałe w kategoriach zamiast skorzystanie z np ListItem

2. Canonical oraz prev/next

Cholernie istotna kwestia, krytyczna bo zła implementacja z reguły wyindeksowywuje cały serwis. Najczęstsze problemy przy implementacji:

  • nie da się – tak bo to skomplikowane
  • wstawienie canonical na główna stronę – very funny
  • błędna implementacja canonical wraz z alternate pod kątem wersji językowych
  • błędne wdrożenie dla wersji mobilnych w przypadku korzystania z wersji mDot
  • niezwykle istotny parametr przy stronicowaniu (paginacji)

To czego brakuje w skryptach sklepowych to możliwość ustawienia canonicala dla każdej podsrtony czy produktu. Tak jak jest to w WordPressie, że pod każdym tworzonym artykułem jest pole typu canonical i można to sobie dowolnie wstawiać:

Do zapoznania się przez deweloperów:

 

3. Przekierowania 301

Trudne do przypilnowania i jeszcze trudniejsze w realizacji – wykonanie tabeli przekierowań w przypadku przebudowy serwisu a jeszcze trudniejsze w bieżącym zarządzaniu przekierowaniami.

Z mojej perspektywy należy dać możliwość w oprogramowaniu (np. skrypcie sklepu internetowego typu SaaS) dwie możliwości:

  • ustawianie przekierowań z poziomu skryptu za pomocą jakichkolwiek wtyczek czy modułów i wykonywanie ich za pomocą tego skryptu
  • lub też to co wyżej, żeby to jeszcze zapisywało się automatycznie do pliku htaccess

Jest to bardzo ważny aspekt w przypadku usuwania podstron z produktami czy wpisami blogowymi – trzeba wykonać przekierowanie 301 ze starego adresu na nowy. Tutaj od razu uczulam – zrobienie przekierowania na główną nie działa korzystanie ani na SEO ani na UX (czyli wstawienie „ErrorDocument 404 /” w htacess to karygodny błąd).

Na kwestię przekierowań należy szczególnie zwrócić uwagę deweloperem – oni to zaprogramują ale zawsze licze (i się przeliczę), że zapytają „a po co?” albo „czy to na pewno tak ma być?”. Bo na przykład zdarza się, że piszesz o zmianach w adresach URL a „woocommerce” odwali numer i nie wykona automatycznie przekierowań 301 i dopiero po miesiącu zastanawiasz się „Czemu kura spadają mi pozycje”.

4. Wersje językowe

To jest totalny sajgon i poligon. Zła implementacja wersji językowych powoduje, że kod sklepu trzeba niemalże pisać od nowa. Pod tym adres jest pełen opis co i jak wybrac i zrobić: https://support.google.com/webmasters/answer/182192?hl=pl. Jedyną i najgorszą rzeczą jaką można wykonać to implementacja wersji językowych za pomocą zmiennych.

Nie wierzycie? Zobaczcie – a potem wyobraźcie sobie jak to możliwe, że to się w ogole indeksuje.

Te same wersje językowe w jednym podkatalogu i poza tym x-default też – normalnie nóź w kieszeni.

5. Treści – czyli chcesz content

Ważnym aspektem każdego serwisu są treści. To czego z reguły potrzebuje seowiec lub contentowiec to:

  • pole na wstawienie tekstu SEO na stronie głównej
  • możliowść wstawienia tekstów na kategorie i podkategorie w sklepie internetowym
  • blog, który najlepiej funkcjonuje w podkatalogu /blog/ a nie w poddomenie blog.zgred.pl – niby Googlersi mówią, że nie ma to znaczenia ale blog jednak lepiej pracuje w podkatalogu
  • opisy kategorii
  • linkowanie wewnętrzne na kartach produktu – są to elementy, które oprócz klikania i przenoszenia się do kategorii dają również SEO

Problemy, które czasem sie spotyka to:

  • ukrywanie treści przed robotami – czyli cloaking – warto zatem zajrzeć do cache bo można znaleźć tam ciekawe kwiatki
  • ucinanie nagłówków – bo dev stwierdził, że DIV mu się kończy i zamiast „złamać” napis to dał 3 kropeczki
  • tekst jest górze strony odsuwając produkty poniżej linii i ich nie widać, przez co użytkownik wychodzi ze sklepu

Inne rzeczy – krótkie wskazówki:

  • nie implementujcie infinity scroll – to jest zuo – zróbcie zwykłe stronicowanie. Poza tym spróbujcie dojechać do stopki, gdy są tam ważne dane jak telefon – skoro sie nie da to po co implementować
  • nie róbcie nagłówków Hx jako tytuły w sekcjach menu czy tytułach bloków z boku (sidebars) bo one nie muszą brać udziału w ustalaniu rankgingu strony
  • potrzebna możliwość wpisywania meta description dłuższego niż 160 znaków (w presta jest blokada a czasem warto pokusić się wstawić i 200 znaków)
  • w całym serwisie potrzeba wstawiać linkowanie wewnętrzne – więc warto wdrożyć edytor WYSIWYG umożliwiający dostęp do wszystkich b,u,i,a,href,h1..h6 itd.
  • dla obróbki i optymalizacji grafik też jest dobrze wdrożyć moduł jak np Imagify do WordPressa – optymalizacja grafik przekłada się na prędkość ładowania serwisu
  • hotlinkowanie – nie należy dopuszczać do pobierania obrazków (czy jakichkolwiek innych plików mediowych) z poza własnej domeny
  • nie robić nagłówka H1 pod logotypem – to zamierzchłe czasy i już tego sie nie robi
  • zapomina się o zdjęciu NOINDEX z wersji dev po przesunięciu na produkcję
  • nie używajcie comic sans 😉

I na koniec – właściwie dobierzcie framework skrypt oraz wykonanie i skonsultujcie go z seowcem, żeby na koniec w Google nie było o tak:

Developerzy! Seowcy Was kochają! Nauka dla obu stron jest bezcenna. Jeśli macie inne przypadki i uwagi to zapraszam do dzielenia się w komentarzach.

1 gwiazdka2 gwiazdki3 gwiazdki4 gwiazdki5 gwiazdek (8 głosów, średnia: 5,00 z 5)

Paweł Gontarek

Paweł Gontarek

Paweł Gontarek - Zgred - pasjonat SEO, staram się zrozumieć czym jest i jak działa SEM oraz UX.

Komentarze

    • Gdyby taki specjalista SEO miał tyle w głowie co programista. Oj, tylko pozazdrościć. To wszystko, co zostało tam opisane to blef. Żaden programista nie jest takim tępakiem, żeby takich rzeczy nie zauważyć. No chyba że chodzi o twórców tego bloga, bo to nie wygląda na bloga, tylko na jakąś ściemę pseudobiznesmenów, którzy dobrali się 10 lat temu do tego syfu i robią z tego wielki cyrk.

      • Jak sobie nie radzisz to może potrzeba zmienić sposób komunikacji i zarządzania. A jak nadal sobie nie radzisz to może czas zmienić pracę? Tak tylko sugeruję pewne rozwiązania 😉 Ale szanuję to, że wiesz ile lat ma ten blog. Zauważ, że tę ściemę uprawiają na zachodzie od bardzo dawna – zaczęli wiele lat przez Polakami. Linki, treści, optymalizacja… Nawet w reklamach jest SEO.

        A jakby tak poszperać w historii to już w prehistorii były piktogramy, malunki skalne oraz optymalizacja procesów grup żyjących stadnie 😉 Byli też i malkontenci, którym trudno było dostosować się do życia w grupach oraz do tego, że inni potrafią coś zrobić.

        Tak jak napisałem – nie pasuje Ci? Zmień pracę.

  1. Jakie to życiowe 🙂 Dodałbym jeszcze paragraf o indeksowaniu wyników wyszukiwania. Przy okazji dopytam co sądzisz o lazy loading na stronach?

  2. Zgodnie z semantyką HTML5, wszystkie sekcje muszą posiadać nagłówek, robiąc nawigacje trzeba nadać jej tytuł, tak samo sidebar też musi mieć nagłówek 😉 a w obecnych czasach brak błędów na stronie i zapewnienie dostępności wszystkim to bardzo ważny element

    • To wskaż proszę różnice albo podobieństwa. Rozumiem, że chodzi Ci o odróżnienie dewelopera (w IT) od programisty? Jak nie napiszesz to nikt sie nie dowie o co Ci dokładnie chodziło. Dla seowca to jedna i ta sama osoba – i zapewne Ci chodzi o to: kariera.comarch.pl/blog/praca-w-it/programista-czy-developer-mini-slownik-nazw-stanowisk-w-branzy/ – więc Ja tego nie rozróżniam 🙂

  3. Dlaczego? jako seowcy piszemy o optymalizacji i poprawie kodu, zatem warto wspominac o dobrych praktykach [?] Moze wspominac o tym ze masz brak name pod value w 35 linii kodu jest przesada.. ale w3c jakby nie patrzec zbiorem dobrych praktyk jest; A ze nie kazdy ma chrome na win10, to parsery roznie sobie radza ze stronami [szczegolnie jak mowa o stronie drobnego Janusza] – a same wskazowki minifikuj css z gpsi sa troche…. slabe prawda? 🙂

  4. Bardzo dużo przydatnych rad, zwłaszcza z meta description bo skoro Google i tak nie wyświetla całości to może się wydawać że nie ma sensu. A jednak ma to jakiś wpływ.

    Dzięki Paweł!

  5. O czym jest ten wpis? O tym, że programiści to debile? Może ci współpracujący z ludźmi, którzy zajmują się SEO faktycznie tacy są. Ale naprawdę, każdy programista frontend potrafi zauważyć takie głupoty. To nie jest rok 2001, gdzie nikt nie ogarnia czym jest paginacja i jakieś nagłówki. Nikt, kto siedzi przed komputerem, nie jest takim imbecylem, żeby coś takiego wyolbrzymić. Dlaczego ludzie nie zostają technicznymi SEOwcami, tylko programistami? Czemu SEO nikogo nie pociąga? Bo na technicznym SEO nikt porządnie nie zarobi, bo takie SEO to jest malutka część całej filozofii i taka osoba jest potrzebna tylko w miejscu, gdzie ktoś musi wykonywać „brudną robotę” (najczęściej firmę nie stać na ogarniętego programistę albo ktoś musi pomagać spamować na forum). Ludzie, którzy są nowi w pracy i wcześniej nie mieli o tym bladego pojęcia, już po 2 miesiącach to ogarniają i najczęściej się zwalniają, bo w tym po prostu nie da się wykazać. Czasem jak trafią na ludzką stawkę to zostają. Praca polegająca na formatowaniu tekstu i szukaniu błędów innych ludzi przyrównując ich działania do checklisty to chyba jakiś żart.

    • Twoje uwagi są bardzo cenne – wskazują na wiele istotnych elementów w relacjach wielu zespołów tworzących serwisy WWW.”Praca polegająca na formatowaniu tekstu i szukaniu błędów innych ludzi przyrównując ich działania do checklisty to chyba jakiś żart.” – ale widać dobrze płatna. W każdej branży istnieją checklisty i są audytorzy, których zadaniem jest wskazanie słabych elementów – mieszkasz gdzieś, nawet pod mostem, ale te budynki i budowlne przeszły przez audyt abyś mógł tam mieszkać czy używać mostu liub ścieżki rowerowej. Twoje audi czy inny szmercedes też przeszły przez kontrolę według określonej checklisty. No tylko boeing ostatnio ma z tym problem 😉 Więc to też jest praca, i do tego opłacana. A np w IT czy bezpieczeństwie wręcz doskonale płatna. Na resztę pytań odpowiesz sobie sam.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Kategorie

Najnowsze komentarze

Popularne artykuły