Techniczne SEO – 5 błędów, przez które możesz tracić przychody w swoim sklepie

#1 Sprawdzenie ustawionych tagów kanonicznych

Tagi kanoniczne to ważne zagadnienie z punktu widzenia SEO. Są sugestią dla robotów, który adres URL jest adresem docelowym. Pomimo jasnych deklaracji tagu kanonicznego, roboty mogą deklarację tę zignorować, ale o tym w dalszej części.

Część popularnych skryptów e-commerce czy systemów do zarządzania treścią w standardzie oferuje ustawienie tagów kanonicznych na podstronach. Są to tzw. self-referencing canonical tags, które wskazują na same siebie. Nawet jeśli posiadamy poprawnie wdrożone przekierowania (wersji z www lub bez czy https i https), to warto stosować self-referencing canonical tags, o czym informował John Mueller z Google – https://blog.seoprofiler.com/google-recommend-self-referencing-canonical-tags/

Warto sprawdzić poprawność wdrożenia tagów kanonicznych na najważniejszych podstronach w serwisie (strona główna, strony kategorii, strony produktowe). W przypadku podstron produktowych, należy sprawdzić je dla różnych „typów” produktu:

• Produkt dostępny
• Produkt niedostępny
• Produkt przeceniony
• Paczka produktów*

* Niektóre systemy sklepowe, np. Prestashop, pozwalają na tworzenie tzw. paczek. Jest to jeden produkt, który składa się z kilku innych, które można kupić w zestawie. To rozwiązanie możesz sprawdzić także pod kątem duplikacji treści, która w takich wypadkach może zachodzić.

Możesz się zastanawiać, dlaczego należy sprawdzić każdą z powyższych sytuacji. Przecież, jeśli tag kanoniczny jest poprawnie ustawiony na produktach dostępnych, to na niedostępnych także powinien być w porządku.

Teoretycznie tak powinno być, ale w praktyce audytowałem e-commerce, gdzie tagi kanoniczne produktów dostępnych były poprawne, natomiast w przypadku towarów niedostępnych, canonical był niepoprawnie zaimplementowany. Ale w czym tkwił problem?

Błędne tagi kanoniczne produktów niedostępnych

Kiedy produkt stawał się niedostępny, system sklepowy z automatu zmieniał mu tag kanoniczny z self-referencing, na inny adres, który zwracał błąd 404. Skutkiem tego adres URL produktu zostawał wyindeksowany, a indeksował się adres kanoniczny (w tym przypadku Google uznawał wybrany przez użytkownika adres kanoniczny 😉 ). Dodatkowo zwiększało to liczbę błędów 404 w serwisie.

Poniżej screen z Google Search Console, który obrazuje, jak błąd kanoniczny negatywnie wpływał na wyświetlenia i kliknięcia (pierwsza czerwona kreska oznaczony moment, kiedy produkt stał się niedostępny, druga czerwona kreska to moment poprawy błędu.

W trakcie, kiedy błąd występował, serwis nie pojawiał się na zapytania związane z danym produktem (lub pojawiała się inna, gorzej zoptymalizowana podstrona, a więc na niższych pozycjach).

W momencie, kiedy produkt znów stawał się dostępny, system przypisywał poprawny tag kanoniczny. Jednak w wielu przypadkach pozycję słów kluczowych, na które dany towar rankował, były niższe niż przed zmianą, co obrazuje poniższy przykład:

Jak taki błąd może przełożyć się na Twój biznes?

Taki błąd ma negatywny wpływ na przychody w Twoim sklepie. Co prawda, skoro produkt jest niedostępny, to teoretycznie i tak nie zostanie zakupiony (jeśli uniemożliwiasz zamawianie produktów, których nie masz na stanie), ale na karcie tego produktu możesz Klientowi zaproponować inne, podobne towary (być może nawet te same, ale w innej pojemności?).

A może Klient będzie też skłonny poczekać, aż produkt stanie się dostępny, lub wykona jakąś inną interakcję, która doprowadzi do konwersji?

Możliwości jest naprawdę wiele, ale wyżej opisany błąd techniczny je wszystkie „ucina”, a tym samym Twoje przychody z bezpłatnych źródeł wyszukiwania maleją.

2. Sprawdzenie podstron paginacji kategorii

Kolejnym ciekawym błędem technicznym SEO, z jakim się spotkałem, a który można wykryć bez dostępu do zewnętrznych narzędzi, był problem z duplikacją treści.

By ułatwić wyszukiwanie produktów, serwis posiadał zdublowane kategorie. Kategorie, które zawierały te same produkty, występowały w drzewku nawigacyjnym w dwóch różnych miejscach. Obie były zoptymalizowane pod kątem tych samych słów kluczowych, co powodowało kanibalizację słów kluczowych.

Jak uniknąć kanibalizacji słów kluczowych?

Aby tego uniknąć, jedna z kategorii w sekcji <head> posiadała wdrożony kod <meta name=”robots” content=”NOINDEX,FOLLOW”/>, który zabraniał jej indeksacji w wynikach wyszukiwania.

W teorii wszystko było w porządku, ale okazało się, że kolejne podstrony paginacji tych kategorii nie posiadają wyżej podanego kodu i zezwalane jest ich indeksowanie. Wobec tego pierwsze strony paginacji kategorii dublujących nie były indeksowane, natomiast kolejne strony paginacji już tak.

Wdrożenie na podstronach paginacji tagu robots z wartością NOINDEX pozwoliło uporać się z kanibalizacją słów kluczowych w tych przypadkach.

Dlaczego kanibalizcja słów kluczowych negatywnie wpłynie na Twoją stronę?

Kanibalizacja słów kluczowych powoduje wahania pozycji Twojego serwisu na zadane słowo kluczowe. Google nie wie, jaką podstronę ma wyświetlać na daną frazę i może w wynikach przedstawiać niekoniecznie tę, której Ty byś sobie życzył.

Co wtedy? Użytkownicy mogą „lądować” nie tam, gdzie trzeba. Np. po wpisaniu w wyszukiwarkę frazy sprzedażowej, trafią na podstronę, która nie prezentuje produktów.

#3 Sprawdzenie, czy roboty „widzą” content

Choć roboty Google coraz lepiej radzą sobie z JavaScript, to jednak nadal istnieje ryzyko, że mogą tych treści nie odczytywać. Co za tym idzie, mogą pomijać wartościowy content, i „nie widzieć” linków wewnętrznych w nim występujących.

Audytowałem serwis, w którym zawarta była podstrona (nazwijmy ją – podstrona A), spora tabela z odnośnikami do innych podstron w tym samym serwisie (podstron B). Ze względów UX-owych jej kolejne elementy doczytywane były dynamicznie po kliknięciu w odpowiedni button.

Na pierwszy rzut oka całość działała zgodnie z założeniem, jednak po dokładniejszej analizie okazało się, że roboty Google nie radzą sobie z doczytywaniem tej treści. Wobec czego roboty nie mogły z podstrony A (na której znajdowała się tabela), dostać się do podstron B, których adresy były dynamicznie doczytywane.

Taki stan rzeczy ma negatywny wpływ na linkowanie wewnętrzne. W przypadku, jeśli podstrona A to jedyne miejsce, z którego możesz dostać się do podstron B, to może się okazać, że robot Google nigdy do nich nie dotrze, a tym samym nie zostaną zaindeksowane (pomijam kwestie stosowania sitemap).

Jak bez zagłębiania się w techniczne aspekty zweryfikować, czy roboty „widzą” link z podstrony A do podstron B?

W tym celu wejdź do Google Search Console i wybierz zakładkę „Linki”, a następnie „Linki wewnętrzne”. Zobaczysz tabelę z adresami URL. Filtrując adresy na podstawie strony docelowej (niżej na screenie), możesz podać adres URL konkretnej podstrony.

Po jego wybraniu zobaczysz adresy URL (z analizowanej domeny), z których prowadzą linki wewnętrzne do wybranej (wyfiltrowanej) przez Ciebie podstrony.

Wracając do naszego przykładu. Możesz sprawdzić, czy do podstrony B prowadzi link z podstrony A (tej, która posiada tabelę z dynamicznie doczytywanymi linkami). Jeśli tak nie jest, to istnieje prawdopodobieństwo, że roboty Google mają problem z jej odczytem.

#4 Operator oraz site:domena.pl inurl:

Analizując, jakie podstrony Twojego serwisu są zaindeksowane w wyszukiwarce, możesz „wyłapać” te, które są w indeksie, a być nie powinny. Dla przykładu mogą to być strony filtrowania (oczywiście nie bierzemy pod uwagę zoptymalizowanych podstron z filtra kategorii), czy też sortowania kategorii.

Jak sprawdzić czy podstrony filtrowania wyników są zaindeksowane? Możesz to zrobić na dwa sposoby, jednak w obu przypadkach, powinieneś najpierw zweryfikować parametr, po jakim Twój skrypt e-commerce filtruje produkty.

Aby to zrobić przejdź do podstrony kategorii i wybierz któryś z filtrów (zależnie od Twojego asortymentu filtry będą różne, ale mogą nimi być np. kolor czy rozmiar). Po przefiltrowaniu kategorii zmieni się jej adres URL i właśnie z adresu URL jesteś w stanie wyłuskać parametr odpowiadający za filtrację.

Mając parametr możesz sprawdzić, czy zaindeksowane są adresy URL zawierające w sobie owy parametr.

Jak sprawdzić, czy podstrony filtrowania kategorii są zaindeksowane?

a) Google Search Console – przejdź do zakładki „Stan” i wybierz kwadrat „Prawidłowy”. Następnie filtrując adresy URL (z ustawieniem, że adres URL zawiera dany ciąg znaków), podaj parametr filtrowania. Jeżeli GSC zwróci Ci jakieś wyniki, oznacza to, że roboty Google indeksują podstrony filtrowania.

Niestety GSC posiada ograniczenia i nie wyświetla wszystkich zaindeksowanych adresów URL, dlatego też nawet jeśli nie znajdziesz żadnego adresu URL z parametrem, to wcale nie oznacza, że nie znajdują się one w indeksie Google.

b) Wyszukiwarka Google

Aby przekonać się, czy podstrony filtrowania są zaindeksowane, należy przejść do wyszukiwarki Google i wpisać poniższą komendę:

site:domena.pl inurl:[parametr]

Oczywiście w miejsce domena.pl podaj adres URL Twojej domeny, a parametr wpisz bez klamr.

Wyszukiwarka zwróci Ci zaindeksowane podstrony, które w adresie URL posiadają podany przez Ciebie parametr.

Jeśli w indeksie Google znajduje się wiele stron filtrowania czy sortowania wyników podstron kategorii, to, de facto, nie różnią się one wiele od ich oryginalnych odpowiedników.

5. Sprawdzenie blokowanych podstron

Google Search Console daje możliwość sprawdzenia, które zasoby Twojej strony są blokowane przed dostępem robotów, a które nie. Blokować je możesz w pliku robots.txt.

Dodając nowe dyrektywy do robots.txt musisz być bardzo ostrożny, bo nieumyślnie możesz zablokować dostęp do wartościowych podstron serwisu, co będzie mieć negatywny wpływ na widoczność w Google.

Aby przejść do testera, w narzędziu Google Search Console rozwiń zakładkę „Skanowanie”, a następnie wybierz „Tester pliku robots.txt”.

Oprócz sprawdzenia, czy nie blokujesz ważnych podstron w swoim serwisie, warto przekonać się, czy roboty Google mają dostęp do plików CSS i JavaScript. W celu poprawnego renderowania podstron roboty Google powinny mieć pełen dostęp do tych zasobów. Jeżeli przypadkowo zablokujesz im dostęp do jakiejś podstrony produktowej, to robot Google nie będzie jej mógł odwiedzić (pomijamy kwestie, jeśli produkt jest podlinkowany z zewnętrznego serwisu).

Przykładowo, nawet jeśli dodasz dla tego produktu nowy opis, który ma na celu m.in. wybicie go w wynikach wyszukiwania, to, jeśli chodzi o SEO, będzie to praca daremna.

Techniczne SEO – podsumowanie

Wymienione wyżej przypadki, to tylko kilka z wielu błędów w technicznym SEO, z jakimi na co dzień spotykam się podczas audytowania serwisów. Niestety wykrycie wielu z nich bez dostępu do narzędzi wspomagających, jak np. Screaming Frog, jest niemożliwe lub bardzo trudne.

Obawiasz się, że Twój serwis może zawierać błędy techniczne? Zdecyduj się na techniczny audyt SEO, który pozwoli na ich wykrycie i późniejszą poprawę.