Techniczne SEO – audyt indeksacji, wydajności i architektury serwisu

Techniczne SEO to zestaw działań na stronie, dzięki którym Google może ją sprawnie crawlować, renderować i indeksować, a użytkownik może z niej wygodnie korzystać.

W audytach dzielę je na cztery obszary: indeksację, wydajność, architekturę serwisu i UX. Według Web Almanac 2024 tylko 43% stron mobilnych mieści się w progach Core Web Vitals, a mediana strony ładuje 22 skrypty, z czego 10 pochodzi od zewnętrznych dostawców.

Poprawki techniczne są najtrudniejsze do wdrożenia, bo większość z nich wykonuje programista, a specjalista SEO tylko wyznacza kierunek i sprawdza efekt. Pokażę Ci, co sprawdzam w każdym z czterech obszarów, jak dzielę pracę z programistami i dlaczego przy migracji strony specjalista SEO powinien pełnić rolę audytora między klientem a wykonawcą.

Najważniejsze informacje z wpisu:

• Techniczne SEO to część filaru on-page i obejmuje cztery obszary audytu: indeksację, wydajność, architekturę serwisu i UX.
• Indeks Google ma zawierać strony, na których zarabiasz; paginacje dostają self-canonical i linki w href, filtry bez popytu są zamykane przed robotem, a robots.txt nie usuwa stron z wyników.
• Poprawki techniczne wdraża programista, a specjalista SEO dostarcza wytyczne z uzasadnieniem i kryterium odbioru, po czym weryfikuje wdrożenie crawlem i raportami GSC.
• Przy migracji lub budowie nowej strony specjalista SEO pełni rolę trzeciej strony między klientem a wykonawcą, bo firma tworząca stronę nie odpowiada za zachowanie widoczności.

Co to jest SEO techniczne?

SEO techniczne to część optymalizacji on-page, obejmująca wszystko poza samą treścią: dostępność strony dla robotów, szybkość, strukturę adresów i nawigacji, dane strukturalne, bezpieczeństwo połączenia i działanie serwisu na telefonie.

W FEB dzielimy SEO na dwa filary. Pierwszy to on-page, czyli wszystko, co dzieje się na stronie i nad czym masz pełną kontrolę. Drugi to off-page, czyli linki i wzmianki poza stroną. Techniczne SEO mieści się w pierwszym filarze obok treści, a wydzielanie go jako trzeciego filaru wprowadza zamieszanie, bo w praktyce te same osoby pracują nad treścią i nad tym, czy Google tę treść zobaczy.

Cel jest prosty. Robot Google ma dotrzeć do każdej ważnej podstrony, poprawnie ją wyrenderować, zrozumieć jej kontekst i uznać za wartą pokazania w wynikach. Użytkownik ma otworzyć tę samą podstronę w ułamku sekundy, znaleźć to, po co przyszedł, i bez przeszkód dokończyć zakup. Jeżeli którykolwiek z tych warunków nie jest spełniony, treści i linki pracują na pół gwizdka, a często w ogóle.

W audytach technicznych rozkładam serwis na cztery obszary:

• indeksacja – które strony trafiają do indeksu Google i czy są to te właściwe,
• wydajność – Core Web Vitals, hosting, liczba wtyczek i skryptów oraz kolejność ich wykonywania,
• architektura serwisu – nawigacja, linkowanie wewnętrzne, dopasowanie stron do intencji, adresy URL,
• UX – czy projekt strony pozwala użytkownikowi zostać dłużej i dokończyć zamówienie.

Klasyczne listy elementów technicznego SEO wymieniają w tym miejscu mapę witryny, robots.txt, certyfikat SSL, meta tagi i przekierowania. Wszystkie te elementy mieszczą się w czterech obszarach powyżej, a taki podział jest wygodniejszy, bo odpowiada temu, jak faktycznie rozpisuje się zadania dla programisty. Jeżeli potrzebujesz podstaw, zajrzyj najpierw do wpisu o tym, czym jest SEO, a potem wróć tutaj.

Dlaczego techniczne SEO decyduje o sukcesie projektu?

Poprawki techniczne są najtrudniejsze do wdrożenia, ale to od nich najczęściej zależy, czy pozycjonowanie w ogóle ruszy.

Treść można napisać w tydzień, link można kupić w dzień, a zmiana sposobu generowania adresów filtrów w sklepie potrafi czekać w kolejce programistów przez kwartał. W tym czasie Google indeksuje tysiące bezwartościowych kombinacji parametrów zamiast nowych kategorii, a raport z pozycjonowania pokazuje wzrost widoczności na frazach, na których nikt nie zarabia.

Kolejność napraw, którą stosuję, wynika z wagi błędu. Łatwość wdrożenia nie ma tu znaczenia.

1. Najpierw wszystko, co blokuje indeksację wartościowych stron, bo bez tego reszta nie ma znaczenia.
2. Potem duplikacja, kanoniczne i architektura, bo one decydują, na którą podstronę trafi moc linków.
3. Na końcu wydajność i UX, które poprawiają wynik już widocznej strony.

Błąd w robots.txt odcinający połowę sklepu boli bardziej niż LCP za wolny o pół sekundy!

Ta kolejność ma też wymiar finansowy. Właściciel sklepu z segmentu, z którym pracujemy najczęściej, czyli resellera z budżetem mediowym kilku tysięcy złotych miesięcznie, nie ma pieniędzy na równoległe wdrażanie wszystkiego. Musi wybrać trzy poprawki na kwartał, więc lista z audytu ma być posortowana według wpływu na przychód. Więcej o tym, co powinien zawierać audyt SEO, piszę w osobnym wpisie.

Audyt indeksacji – które strony mają być w indeksie Google?

Celem audytu indeksacji jest doprowadzenie do sytuacji, w której indeks Google zawiera wszystkie strony, na których zarabiasz, i możliwie niewiele pozostałych.

Zaczynam od raportu „Strony” w Google Search Console. Porównuję liczbę zaindeksowanych adresów z liczbą stron, które według mnie powinny być w indeksie, czyli strony głównej, kategorii, podkategorii, kart produktów, stron usług i wpisów blogowych. Jeżeli sklep ma 3 000 produktów i 200 kategorii, a w indeksie siedzi 40 000 adresów, mam pierwszy problem do rozwiązania. Jeżeli zaindeksowanych jest 900, mam drugi.

Przy skupieniu na najważniejszych stronach pomaga prosta klasyfikacja. Każdy typ adresu w serwisie dostaje jedną z trzech decyzji:

Weryfikację robię crawlerem (Sitebulb albo Screaming Frog) skonfigurowanym tak, aby respektował robots.txt i raportował dyrektywy indeksowania. Lista adresów z crawla po zestawieniu z raportem GSC pokazuje, które strony robot widzi, ale ich nie indeksuje, i które indeksuje, choć nie powinien. Typowe przypadki opisałem we wpisie o najczęstszych problemach z indeksacją witryny.

Paginacje i filtry – gdzie sklepy tracą budżet crawlowania

Nawigacja fasetowa, czyli filtry w sklepie, to według dokumentacji Google najczęstsza przyczyna nadmiernego crawlowania.

Google tłumaczy to prosto. Adresy filtrów wyglądają dla robota jak nowe strony, a robot nie jest w stanie ocenić ich wartości bez wejścia, więc odwiedza ich bardzo dużo. Czas spędzony na bezużytecznych adresach to czas odebrany nowym produktom i kategoriom. Przy 500 produktach i pięciu filtrach po kilka wartości liczba kombinacji idzie w dziesiątki tysięcy adresów o niemal identycznej treści.

Z paginacjami trzeba postępować ostrożnie, bo błąd w drugą stronę odcina produkty od robota. Google w dokumentacji o paginacji podaje trzy zasady. Każda strona paginacji ma mieć własny canonical. Canonical wskazujący na pierwszą stronę jest błędem.

Kolejne strony mają być połączone zwykłymi linkami w atrybucie href, bo robot nie klika przycisków „załaduj więcej” ani nie przewija strony w nieskończoność. Znaczniki rel=”next” i rel=”prev” Google ignoruje od lat, podobnie jak numery stron umieszczone po znaku #. Jeżeli paginacja dostanie canonical na stronę pierwszą albo noindex, produkty z dalszych stron kategorii tracą jedyną ścieżkę linków wewnętrznych.

Filtry oceniam inaczej niż paginacje. Część z nich ma realny popyt w Google, na przykład kolor, marka albo rozmiar w konkretnej kategorii. Takie kombinacje traktuję jak podkategorie: dostają statyczny adres, własny tytuł i opis oraz link z bloku filtrów. Pozostałe kombinacje zamykam przed robotem w robots.txt albo przenoszę parametry za znak #, zgodnie z zaleceniami Google dla nawigacji fasetowej. Decyzję o tym, które filtry indeksować, podejmuję na podstawie wolumenów z Senuto i wyników w top 10 dla danej frazy. Sposób zarządzania tym zasobem opisałem we wpisie o tym, co to jest crawl budget i jak nim zarządzać.

Mapa witryny i robots.txt – co faktycznie robią?

Mapa witryny XML to lista adresów, które chcesz mieć w indeksie, a robots.txt to lista miejsc, których robot ma nie odwiedzać. Żaden z tych plików nie decyduje sam o indeksacji.

Google w dokumentacji o robots.txt pisze wprost, że strona zablokowana w tym pliku wciąż może trafić do indeksu, jeżeli prowadzą do niej linki z innych witryn. Pojawi się wtedy w wynikach bez opisu. Jeżeli strona ma zniknąć z Google, potrzebny jest noindex albo hasło, a robots.txt służy wyłącznie do zarządzania ruchem robota.

Trzy mechanizmy, które klienci najczęściej mylą, działają tak:

• robots.txt mówi „nie wchodź tutaj”,
• meta robots noindex mówi „wejdź, ale nie pokazuj tego w wynikach”,
• rel=”canonical” mówi „to jest kopia tamtej strony, sygnały przypisz tamtej”.

Połączenie noindex z blokadą w robots.txt jest błędem, bo robot nie wejdzie na stronę i nie przeczyta dyrektywy noindex. W mapie witryny sprawdzam zgodność z decyzjami z tabeli wyżej. Mapa ma zawierać wyłącznie adresy z kodem 200, self-canonical i bez noindex. Limity Google to 50 000 adresów i 50 MB na jeden plik, powyżej tego stosuje się indeks map. Google korzysta ze znacznika lastmod tylko wtedy, gdy jest konsekwentnie prawdziwy, a znaczniki priority i changefreq ignoruje całkowicie, więc generowanie ich przez wtyczkę nic nie daje. W sklepach dzielę mapę na osobne pliki dla kategorii, produktów i bloga, bo wtedy raport GSC pokazuje od razu, w którym typie stron indeksacja kuleje.

Audyt wydajności – Core Web Vitals w praktyce

Wydajność mierzę danymi z realnych użytkowników w raporcie Core Web Vitals w Google Search Console i w CrUX. Wynik laboratoryjny z PageSpeed Insights traktuję jako podpowiedź, co poprawić.

Skala problemu jest duża. Według Web Almanac 2024 (HTTP Archive) dobre wyniki wszystkich trzech wskaźników osiąga 43% stron na urządzeniach mobilnych i 54% na desktopie. Najsłabiej wypada LCP, czyli czas wyświetlenia największego elementu, z wynikiem dobrym na 59% stron mobilnych. Ten sam raport pokazuje, że strony główne wypadają gorzej niż podstrony: dobry LCP ma 53% stron głównych i 72% podstron, bo strony główne są przeładowane sliderami, wideo i bannerami.

Dlatego w audycie sprawdzam po jednym adresie z każdego typu: stronę główną, kategorię, kartę produktu, wpis blogowy i stronę informacyjną. Karta produktu z galerią w wysokiej rozdzielczości i kategoria z 60 miniaturami zachowują się zupełnie inaczej niż lekka strona główna. Tam, gdzie LCP jest zły, rozkładam go na części składowe. Web Almanac podaje, że na stronach ze złym LCP największą składową jest czas odpowiedzi serwera, a drugą opóźnienie w rozpoczęciu ładowania obrazu, które wynika najczęściej z lazy loadingu nałożonego na główną grafikę albo z obrazu wczytywanego przez CSS. 16% stron mobilnych stosuje lazy loading na obrazie LCP, co jest błędem, bo opóźnia ładowanie elementu, który ma się pojawić jako pierwszy.

Hosting jest tu ważny, ale ma ograniczony zakres. Serwer odpowiada za czas do pierwszego bajtu, dostępność i protokół HTTPS, natomiast nie naprawi za Ciebie ciężkiego frontendu. Zmianę hostingu traktuję jako narzędzie do usunięcia jednej konkretnej składowej LCP, a resztę pracy wykonuje się w kodzie strony. Kiedy serwer zaczyna ważyć na wynikach i co daje przejście na VPS, opisałem we wpisie o tym, jak hosting wpływa na pozycje w Google. O tym, jak wolne ładowanie przekłada się na sprzedaż, piszę we wpisie o tym, jak na sprzedaż e-commerce wpływa długie ładowanie strony.

Stabilność układu (CLS) psują najczęściej obrazy bez zadeklarowanych wymiarów. Według Web Almanac 66% stron mobilnych ma co najmniej jeden taki obraz, a mediana to dwa na stronę. Poprawka jest tania, bo wystarczy dopisać atrybuty width i height, ale wymaga zmiany w szablonie, więc trafia do programisty.

Wtyczki i skrypty – największy ukryty koszt wydajności

Liczba wtyczek i zewnętrznych skryptów jest w polskich sklepach i na stronach firmowych częstszą przyczyną słabych Core Web Vitals niż hosting.

Mediana strony mobilnej ładuje według Web Almanac 2024 558 KB JavaScriptu w 22 żądaniach, a z tego 10 żądań i 375 KB pochodzi od zewnętrznych dostawców, przy 168 KB kodu własnego. Około 44% pobranego JavaScriptu w ogóle nie jest używane podczas ładowania strony. Z zewnętrznych skryptów korzysta 92% stron, a pięć z dziesięciu najczęstszych domen zewnętrznych należy do Google (Tag Manager, Analytics, fonty, YouTube).

Na WordPressie, który według tego samego raportu napędza 36% stron w badanym zbiorze, problem ma dodatkowy wymiar. Każda wtyczka może doładować własny arkusz CSS i własny skrypt na każdej podstronie, nawet jeżeli jej funkcja jest potrzebna tylko w jednym miejscu. Efekt jest taki, że WordPress osiąga dobre Core Web Vitals na 40% stron mobilnych. Ta liczba poprawia się z roku na rok, bo rdzeń WordPressa wprowadził między innymi priorytet ładowania dla obrazu LCP, ale wciąż jest niższa niż średnia dla całej sieci.

Audyt wtyczek prowadzę według stałej procedury:

1. Eksportuję listę wtyczek z panelu i przy każdej wpisuję, jaką funkcję biznesową realizuje.
2. W zakładce Sieć w DevTools albo w raporcie PageSpeed Insights „Zmniejsz wpływ kodu firm zewnętrznych” spisuję skrypty ładowane na karcie produktu i wpisie blogowym.
3. Łączę obie listy. Wtyczka bez funkcji biznesowej idzie do usunięcia. Sama dezaktywacja nie wystarczy, bo nieaktywna wtyczka i tak wymaga aktualizacji bezpieczeństwa.
4. Dwie wtyczki realizujące tę samą funkcję (dwa cache, dwa formularze, dwa SEO) zostawiają jedną.
5. Skrypty potrzebne tylko na wybranych podstronach (kalkulator, mapa, galeria) ładują się warunkowo, wyłącznie tam.
6. Wynik zapisuję w tabeli: skrypt, źródło, rozmiar, gdzie potrzebny, decyzja.

Na naszej własnej stronie na Themify przechodzę ten proces po każdej większej zmianie szablonu i za każdym razem znajduję dwa lub trzy skrypty, które ktoś dodał „na chwilę” do testu. Zasada, którą przekazuję klientom, brzmi: jedna funkcja to jedna wtyczka, a każda nowa wtyczka wymaga sprawdzenia w PageSpeed Insights przed i po instalacji. Poradnik dla tej platformy znajdziesz w osobnym wpisie o pozycjonowaniu WordPressa.

Kolejność wykonywania skryptów

Kolejność ładowania i wykonywania skryptów decyduje o LCP i INP w równym stopniu jak ich liczba.

Skrypt umieszczony w sekcji head bez atrybutów async lub defer zatrzymuje parsowanie HTML do czasu pobrania i wykonania. Według Web Almanac 11% stron wciąż ładuje skrypty bez żadnego z tych atrybutów. Z kolei zadania w wątku głównym trwające powyżej 50 ms blokują reakcję strony na kliknięcie, a mediana strony mobilnej ma 14 takich długich zadań i łączny czas blokowania wątku głównego około 1,2 sekundy przy limicie 200 ms zalecanym przez Google w testach laboratoryjnych.

Kolejność, którą rekomenduję programistom, wygląda tak:

1. krytyczny CSS dla pierwszego ekranu inline w head, reszta stylów ładowana asynchronicznie,
2. obraz LCP z atrybutem fetchpriority=”high” i bez lazy loadingu,
3. własny JavaScript szablonu z atrybutem defer, aby wykonał się po zbudowaniu DOM,
4. Google Tag Manager z atrybutem async, a wewnątrz niego tagi marketingowe odpalane po zdarzeniu załadowania okna zamiast na starcie,
5. czat, popup newslettera, widget opinii i wideo ładowane dopiero po pierwszej interakcji użytkownika albo po przewinięciu strony.

Osobny wątek to baner zgody na cookies. Web Almanac wskazuje dostawców zgód jako jedną z kategorii skryptów najbardziej obniżających INP, bo baner pojawia się na starcie, blokuje wątek główny i wymusza pierwszą interakcję. W polskich sklepach widuję konfiguracje, w których baner ładuje wszystkie tagi marketingowe przed zgodą, a po zgodzie ładuje je drugi raz. Tę poprawkę wykonuje programista albo osoba zarządzająca GTM, a specjalista SEO dostarcza listę tagów i ich kolejność.

Mobile first – wersja mobilna jest jedyną ocenianą

Od 5 lipca 2024 roku Google crawluje i indeksuje strony wyłącznie robotem Googlebot Smartphone.

Google w komunikacie kończącym przejście na indeksowanie mobile-first zapowiedziało, że strona, której treść jest niedostępna na urządzeniu mobilnym, przestanie być indeksowana. W praktyce oznacza to, że audyt techniczny prowadzi się na wersji mobilnej, a wersja desktopowa jest dodatkiem. Sprawdzam, czy wersja mobilna ma tę samą treść, te same linki wewnętrzne i te same dane strukturalne co desktop. Częsty błąd to skrócony opis kategorii na telefonie albo menu, z którego wersja mobilna usuwa linki do podkategorii, przez co robot ich nie widzi.

Audyt architektury serwisu – nawigacja, linkowanie i intencje

Architektura serwisu ma spełniać jeden warunek: użytkownik i robot docierają do każdej ważnej strony w kilka kliknięć, a każda strona odpowiada na jedną konkretną intencję wyszukiwania.

Audyt zaczynam od crawla, który pokazuje głębokość kliknięć od strony głównej i liczbę linków wewnętrznych prowadzących do każdego adresu. Karta produktu na piątym poziomie, do której prowadzi jeden link z czwartej strony paginacji, jest dla Google niemal niewidoczna. Ta sama karta podlinkowana z kategorii, z bloku „podobne produkty” i z wpisu blogowego dostaje wielokrotnie więcej sygnałów.

Pięć elementów, które sprawdzam w każdym audycie architektury:

• logiczna i prosta nawigacja – menu odzwierciedla drzewo kategorii, a nazwy kategorii są frazami, których szukają klienci, a nie wewnętrznym żargonem firmy,
• linkowanie wewnętrzne wspierające klastry tematyczne – wpisy blogowe linkują do kategorii i produktów, kategorie linkują do powiązanych kategorii, a strona usługi linkuje do wpisów odpowiadających na pytania z tej usługi,
• strony dopasowane do intencji – na frazę komercyjną odpowiada kategoria lub usługa, na pytanie odpowiada wpis, a dwie strony nie walczą o tę samą frazę,
• brak treści niezwiązanych z tematem domeny – sklep z częściami samochodowymi nie prowadzi bloga o gotowaniu, bo rozmywa temat, w którym Google ma go uznać za autorytet,
• przyjazne adresy URL – małe litery, myślniki, fraza w adresie, bez parametrów, identyfikatorów i dat, ze strukturą stałą dla całego serwisu.

Klastry tematyczne wymagają dyscypliny przy linkowaniu. Każdy klaster ma stronę główną (kategorię lub usługę) i strony wspierające (wpisy, poradniki, porównania). Strony wspierające linkują do strony głównej klastra z anchorem zawierającym frazę główną, a strona główna linkuje z powrotem do najważniejszych stron wspierających. Bez tego blog rośnie obok sklepu zamiast pracować na sklep. Schemat wdrożenia opisałem we wpisie o linkowaniu wewnętrznym dla e-commerce, a mechanizm budowania autorytetu w wąskiej branży we wpisie o topical authority.

Dopasowanie stron do intencji sprawdzam na próbce 20 najważniejszych fraz klienta. Dla każdej frazy porównuję typ strony, którą Google pokazuje w top 10, z typem strony, którą klient chce pozycjonować. Jeżeli w wynikach są same kategorie sklepów, a klient celuje wpisem blogowym, strona nie ma szans niezależnie od jakości treści. Jeżeli dwie strony klienta pokazują się zamiennie na tę samą frazę, mam do czynienia z kanibalizacją słów kluczowych i jedna z nich wymaga zmiany tematu albo scalenia z drugą.

Treści niezwiązane z tematem domeny to problem, który narasta powoli. Zaczyna się od jednego wpisu okolicznościowego, a po dwóch latach blog ma 40 wpisów o wszystkim i o niczym, które rozwadniają fokus tematyczny całej domeny. W audycie eksportuję treść wszystkich wpisów i sprawdzam, które z nich są tematycznie odległe od oferty i jednocześnie nie generują ruchu ani linków. Takie wpisy przekierowuję na najbliższą tematycznie stronę albo usuwam.

UX jako część audytu technicznego

Dobry projekt strony sprawia, że użytkownik spędza na niej więcej czasu, a zły projekt przerywa zakup, nawet jeżeli strona jest szybka i poprawnie zaindeksowana.

Google nie mierzy estetyki, ale mierzy zachowania, a te zależą od projektu. Klient nie dokona zakupu w sklepie, który wygląda nieatrakcyjnie albo budzi wątpliwości co do bezpieczeństwa. Instytut Baymard w badaniu przyczyn porzucania koszyka podaje, że 19% kupujących zrezygnowało, bo nie zaufało stronie na tyle, aby podać dane karty, 17% odpadło przez zbyt długi lub skomplikowany proces zamówienia, a kolejne 17% przez błędy i awarie strony. Ten sam instytut szacuje, że duży sklep może zwiększyć współczynnik konwersji o 35,26% wyłącznie przez lepszy projekt procesu zamówienia.

W audycie technicznym UX sprawdzam elementy, które można zweryfikować bez badań z użytkownikami:

• czy ścieżka od karty produktu do potwierdzenia zamówienia działa na telefonie bez błędów w konsoli i bez przeskoków układu,
• czy formularze walidują dane na bieżąco i nie kasują wpisanych pól po błędzie,
• czy czcionki mają czytelny rozmiar, a przyciski wystarczający odstęp na ekranie dotykowym,
• czy koszty dostawy i czas realizacji są widoczne przed przejściem do koszyka,
• czy strona wygląda wiarygodnie: aktualne certyfikaty, dane firmy, opinie, spójna szata graficzna.

Te punkty przekładają się na sygnały behawioralne i na przychód, więc znajdują się w moim audycie obok Core Web Vitals. Pełne badanie ścieżki zakupowej to już osobna usługa, o której piszemy na stronie audytu UX.

Kto wdraża poprawki techniczne? Specjalista SEO a programista

Większość poprawek technicznych wykonuje programista, a specjalista SEO odpowiada za wytyczne, priorytety i weryfikację wdrożenia.

Specjalista SEO nie zawsze ma umiejętności programistyczne, a nawet jeżeli je ma, nie zawsze mieści się to w jego zakresie obowiązków i odpowiedzialności. Zmiana w szablonie sklepu, w konfiguracji serwera albo w logice generowania adresów wymaga dostępu do kodu, środowiska testowego i procedury wdrożeniowej, za które odpowiada zespół utrzymujący stronę. Dlatego w projektach SEO od początku ustalam, kto za co odpowiada, i rozpisuję to w prostej tabeli.

Każda poprawka trafia do programisty jako osobne zadanie z czterema elementami: co jest nie tak (z przykładowym adresem i zrzutem ekranu), dlaczego to ma znaczenie dla widoczności, jak ma wyglądać stan docelowy oraz jak sprawdzę, że zadanie jest zrobione. Bez czwartego punktu zadania wracają jako „zrobione”, choć wdrożenie objęło jeden szablon z pięciu. Przy większych projektach dokładam listę kontrolną z checklisty SEO, żeby obie strony pracowały na tym samym dokumencie.

Specjalista SEO przy migracji strony – trzecia strona między klientem a wykonawcą

Jeżeli dopiero planujesz nową stronę lub migrację, specjalista SEO jest najbardziej potrzebny przed startem prac.

Firma realizująca projekt strony internetowej nie ma w umowie obowiązku dbania o SEO ani o zachowanie widoczności wypracowanej przez poprzednie lata. Jej zadaniem jest dostarczenie działającej strony zgodnej z projektem graficznym i w terminie. Jeżeli klient nie jest osobą techniczną, nie wie, o co zapytać, a wykonawca nie wie, że powinien coś zaproponować. W tej luce znika ruch organiczny.

Specjalista SEO w takim projekcie pełni rolę tłumacza i audytora. Tłumaczy potrzeby klienta na język programistów: „chcemy utrzymać ruch z Google” zamienia na listę adresów do przekierowania, pola w szablonie i reguły indeksacji. Jako audytor sprawdza nowy szablon, zanim trafi na produkcję, i zwraca uwagę na to, czego w nim brakuje i czego nikt nie przewidział. Przykłady z projektów, które nadzorowałem:

• brak pola na opis kategorii pod listą produktów, przez co 200 opisów nie ma gdzie wrócić,
• nowe adresy URL generowane z identyfikatora zamiast z nazwy, bez planu przekierowań ze starych adresów,
• menu mobilne bez linków do podkategorii, które w wersji desktopowej są w megamenu,
• filtry generujące adresy z parametrami bez canonicala, czego stary sklep nie robił,
• galeria produktu na frameworku JavaScript, w której nazwy i opisy nie istnieją w kodzie HTML przed renderowaniem,
• noindex przeniesiony ze środowiska testowego na produkcję i wykryty po trzech tygodniach spadków.

Każdy z tych punktów wykryty przed wdrożeniem kosztuje godzinę pracy programisty. Ten sam punkt wykryty po wdrożeniu kosztuje tygodnie odbudowywania widoczności i często drugą rundę prac nad szablonem, za którą klient płaci ponownie.

Dlatego rekomenduję trzecią stronę w projekcie: niezależnego specjalistę SEO, który reprezentuje interes widoczności klienta wobec wykonawcy i odbiera prace pod tym kątem. Pełną checklistę przed wdrożeniem, na dzień wdrożenia i po nim znajdziesz we wpisie o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google. Jeżeli jesteś przed taką decyzją, skorzystaj z konsultacji marketingowych, zanim podpiszesz umowę z wykonawcą strony.

Jak robić SEO techniczne krok po kroku?

Audyt techniczny prowadzę w stałej kolejności, od dostępu do danych, przez crawl, po listę zadań z priorytetami, i powtarzam go po każdej większej zmianie na stronie.

Pełny cykl zajmuje od kilku dni w małym serwisie usługowym do kilku tygodni w sklepie z dziesiątkami tysięcy adresów, a jego efektem jest dokument, z którym programista może pracować bez dopytywania.

1. Dostępy i punkt odniesienia. Google Search Console, GA4, panel CMS i hosting. Eksport listy zaindeksowanych stron, ruchu organicznego per adres z ostatnich 12 miesięcy i pozycji z Senuto. Bez punktu odniesienia nie da się potem ocenić, czy poprawki zadziałały.
2. Crawl serwisu. Sitebulb lub Screaming Frog jako Googlebot Smartphone, z renderowaniem JavaScriptu. Wynik zestawiam z raportem „Strony” w GSC i z mapą witryny.
3. Audyt indeksacji. Klasyfikacja typów stron według tabeli z tego wpisu, kontrola robots.txt, dyrektyw noindex, canonicali, paginacji i filtrów.
4. Audyt wydajności. Dane CrUX i raport Core Web Vitals w GSC dla każdego typu strony, inwentaryzacja wtyczek i skryptów, kolejność ładowania, sprawdzenie wersji mobilnej.
5. Audyt architektury. Głębokość kliknięć, liczba linków wewnętrznych do stron zarabiających, dopasowanie do intencji dla 20 najważniejszych fraz, treści poza tematem domeny, wzorce adresów URL.
6. Audyt UX na ścieżce zakupowej. Przejście od kategorii do potwierdzenia zamówienia na telefonie, błędy formularzy, widoczność kosztów dostawy.
7. Lista zadań z priorytetem. Każde zadanie z opisem błędu, uzasadnieniem, stanem docelowym i kryterium odbioru. Kolejność: blokady indeksacji, duplikacja i kanoniczne, architektura, wydajność, UX.
8. Weryfikacja po wdrożeniu. Ponowny crawl, porównanie z punktem odniesienia, kontrola raportów GSC po 2–4 tygodniach.

Audyt techniczny nie jest zadaniem jednorazowym. Strony żyją: pojawiają się nowe funkcje, wtyczki, zmiany szablonu i aktualizacje platformy. Po każdym większym wdrożeniu powtarzam co najmniej crawl i kontrolę indeksacji, bo to właśnie po wdrożeniach pojawiają się błędy, które ujawniają się w widoczności dopiero po kilku miesiącach.

Jeżeli chcesz zlecić taki przegląd, zacznij od naszego audytu SEO, który obejmuje wszystkie cztery obszary opisane w tym wpisie, albo od darmowego audytu SEO, jeżeli chcesz najpierw sprawdzić skalę problemów.

Techniczne SEO to fundament

Techniczne SEO nie przynosi wzrostów samo z siebie. Naprawiona indeksacja, szybka strona i logiczna architektura sprawiają, że treści i linki zaczynają działać z pełną mocą, a sklep przestaje tracić klientów na ostatnim kroku zamówienia. W FEB traktujemy audyt techniczny jako pierwszy etap każdego projektu pozycjonowania e-commerce, a w projektach migracji jako obowiązkowy nadzór nad wykonawcą strony. Jeżeli chcesz sprawdzić, w którym z czterech obszarów Twoja strona traci najwięcej, napisz do nas. Przygotujemy listę poprawek z priorytetami, którą Twój programista będzie mógł wdrożyć bez dopytywania!

Źródła:

https://almanac.httparchive.org/en/2024/performance – Web Almanac 2024 (HTTP Archive): 43% stron mobilnych i 54% desktopowych z dobrymi Core Web Vitals, 59% z dobrym LCP, strony główne vs podstrony, 66% stron z obrazem bez wymiarów, 16% z lazy loadingiem na obrazie LCP, wpływ dostawców zgód na INP

https://almanac.httparchive.org/en/2024/javascript – Web Almanac 2024: mediana 558 KB JavaScriptu i 22 skryptów na stronę mobilną, 10 skryptów i 375 KB od dostawców zewnętrznych, 44% nieużywanego kodu, 11% skryptów bez async/defer, 14 długich zadań

https://almanac.httparchive.org/en/2024/cms – Web Almanac 2024: WordPress na 36% stron w zbiorze, 40% stron WordPress z dobrymi Core Web Vitals na urządzeniach mobilnych

https://developers.google.com/search/docs/crawling-indexing/crawling-managing-faceted-navigation – dokumentacja Google o nawigacji fasetowej jako przyczynie nadmiernego crawlowania i zalecanych rozwiązaniach (robots.txt, fragmenty URL, canonical)

https://developers.google.com/search/blog/2024/06/mobile-indexing-vlast-final-final – komunikat Google o zakończeniu przejścia na indeksowanie mobile-first i crawlowaniu wyłącznie robotem Googlebot Smartphone od 5 lipca 2024

https://baymard.com/lists/cart-abandonment-rate – Instytut Baymard: przyczyny porzucania koszyka (19% brak zaufania przy podawaniu danych karty, 17% zbyt długi proces zamówienia, 17% błędy strony) i potencjał wzrostu konwersji o 35,26% dzięki lepszemu projektowi checkoutu