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ądkowane: https://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:
- https://support.google.com/webmasters/answer/1663744?hl=pl
- https://support.google.com/webmasters/answer/1663744?hl=pl
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.
Po co meta desc na więcej niż 160?
Bo więcej lepiej działa 🙂
I tak nie wyświetla 🙁
Nie musi. Wyświetla części. To wystarczy.
Testowaliście, że faktycznie ma to wpływ? To, że czyta to wiadomo ale ciekawi mnie czy ma wpływ na ranking.
Roboty Googlea czytają kod, a nie tylko to co jest wyświetlane 🙂 dlatego ważny też jest uporządkowany kod.
Tylko nie piszcie o W3C bo umrę 😉
Pełna zgoda. Generalnie kwestia współpracy dev’ów z marketingiem całościowo, to często wyzwanie.
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ę.
Jakie to życiowe 🙂 Dodałbym jeszcze paragraf o indeksowaniu wyników wyszukiwania. Przy okazji dopytam co sądzisz o lazy loading na stronach?
Wdrażać 🙂 Jestem za 🙂
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
Można zmniejszyć hierarchę nagłówków bocznych do h4 lub niżej
Zasugeruję zmianę fotki wpisu, bo naprawdę, czuć zażęnowanie z tych plakatów
A w czym masz problem?
polecam sprawdzić kto to jest „deweloper” i odróżniać pojęcia
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 🙂
Grunt, że nie informatyk 😉
Ten spadek na końcu wykresu na ostatniej grafice z czego wynika?
Złe wdrożony framework.
yyy czy ty wiesz o czym piszesz? jaki framework? SEO – ok, pewnie się na tym znasz ale śmieszy mnie jak robisz z siebie specjalistę z dziedzin o których nie masz pojęcia, a ciemny lud to łyka no bo przecież to mówi gontarek 🙂 wyjaśnij jaki framework, jak on wpłynął, bardzo jestem ciekaw
Dziękuję za zwrocenie uwagi. Masz słuszność. Zmieniłem, żeby Cię nie drażniło.
Już prawie myślałem, że to zrzut senuto z Rossmanna 🙂
Oj tam oj tam 🙂
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? 🙂
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ł!
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.