SEO techniczne po zmianie motywu sklepu: co sprawdzić przed publikacją

Zmiana motywu sklepu SEO wymaga kontroli nie tylko wyglądu strony, ale przede wszystkim tego, co nowy szablon wysyła do przeglądarki i robotów wyszukiwarek. Sklep może wyglądać lepiej, a jednocześnie po wdrożeniu mieć zmienione adresy, brakujące canonicale, inne nagłówki albo przypadkowe noindex.

Najbezpieczniej potraktować wdrożenie nowego motywu jak zmianę techniczną, którą trzeba odebrać przed publikacją. Porównujesz starą i nową wersję na tych samych adresach, sprawdzasz kod HTML, indeksowanie, linkowanie oraz wydajność. Dopiero kiedy różnice są znane i zaakceptowane, publikujesz motyw na produkcji.

Zmiana motywu sklepu SEO: zacznij od porównania starej i nowej wersji

Nie zaczynaj od testowania każdej podstrony po kolei. Najpierw wybierz reprezentatywny zestaw adresów: stronę główną, kategorię, produkt, stronę z paginacją, wyszukiwarkę wewnętrzną, wpis blogowy oraz, jeśli sklep ich używa, strony producentów, tagów lub filtrów.

Dla każdego adresu zapisz między innymi kod odpowiedzi HTTP, finalny URL, title, meta description, nagłówki H1 i H2, canonical, dyrektywy robots, liczbę linków wewnętrznych oraz obecność danych strukturalnych. Takie porównanie daje punkt odniesienia. Bez niego po wdrożeniu łatwo pomylić błąd nowego motywu ze zmianą, która istniała wcześniej.

Przy większym sklepie ręczne sprawdzanie wszystkich produktów nie ma sensu. Możesz pobrać listę adresów z mapy XML i sprawdzić próbkę według typów stron. Jeżeli sklep ma wiele kategorii, wariantów i filtrów, dobierz adresy z każdej istotnej grupy.

Dobrym materiałem pomocniczym jest też eksport najważniejszych adresów przed zmianą. Zapisz URL, title, H1, canonical i status HTTP. Po wdrożeniu uruchom ten sam test ponownie. Różnice od razu pokażą, gdzie nowy szablon zachował się inaczej.

Jeżeli sklep ma już problemy z adresami kanonicznymi, przed zmianą motywu dobrze oddzielić istniejące błędy od tych, które może wprowadzić nowy kod. Pomocna będzie wcześniejsza analiza błędów kanonicznych w sklepie, szczególnie gdy sklep korzysta z wielu wersji językowych.

Co porównać przed i po wdrożeniu

Element	Przed wdrożeniem	Po wdrożeniu	Co sprawdzić
URL	Lista działających adresów	Te same adresy	Czy nie zmieniły się ścieżki
Status HTTP	200, 3xx, 4xx	200, 3xx, 4xx	Czy ważne strony nadal odpowiadają prawidłowo
Title	Obecna wartość	Nowa wartość	Czy motyw nie zastąpił title nazwą sklepu
Meta description	Obecna wartość	Nowa wartość	Czy opisy nadal są generowane
H1	Jeden główny nagłówek	Nowa struktura	Czy H1 nie zniknął lub nie pojawił się wielokrotnie
H2	Istniejące sekcje	Nowe sekcje	Czy hierarchia nadal odpowiada treści
Canonical	Aktualny URL	Aktualny URL	Czy wskazuje właściwą wersję strony
Robots	Dotychczasowe dyrektywy	Nowe dyrektywy	Czy nie pojawił się przypadkowy noindex
Linkowanie	Menu, breadcrumbs, produkty	Nowy układ	Czy ważne strony nadal są osiągalne
Dane strukturalne	Obecne typy danych	Nowy kod	Czy Product, BreadcrumbList i inne dane nadal są dostępne
Obrazy	Obecne grafiki	Nowe grafiki	Czy obrazy mają właściwe adresy i atrybuty
JavaScript	Dotychczasowe skrypty	Nowy zestaw	Czy linki i treści są dostępne w HTML
Wydajność	Wyniki przed zmianą	Wyniki po zmianie	LCP, INP, CLS i ciężkie zasoby

Adresy URL i canonicale po zmianie szablonu

Sama podmiana motywu nie powinna wymagać zmiany adresów URL. Jeżeli jednak nowy szablon korzysta z innego mechanizmu generowania linków, problem może pojawić się niezauważenie. Sprawdź więc produkty, kategorie, warianty, strony paginacji oraz najważniejsze strony informacyjne.

Otwórz kilka starych adresów bezpośrednio w przeglądarce i sprawdź, czy nadal prowadzą do tej samej treści. Jeżeli pojawia się przekierowanie, ustal, czy jest ono zamierzone. Nie zakładaj, że każdy redirect jest problemem. Problemem jest redirect prowadzący do niewłaściwego miejsca albo taki, który powstał bez planu.

Następnie sprawdź element <link rel="canonical"> w kodzie źródłowym. Canonical powinien wskazywać adres odpowiadający stronie, którą chcesz traktować jako główną wersję treści. Nie wystarczy sprawdzić go tylko na stronie głównej. Przejdź przez produkt, kategorię, wpis, stronę paginacji i inne typy stron występujące w sklepie.

Zwróć uwagę na adres z protokołem HTTPS, wersję domeny, końcowy slash oraz parametry URL. Nowy motyw nie powinien nagle generować canonicali do wersji testowej, domeny technicznej albo innego języka.

Szczególnie dokładnie sprawdź sklepy wielojęzyczne. Jeżeli szablon modyfikuje sposób generowania nagłówka <head>, może zmienić również elementy związane z wersjami językowymi. W takiej sytuacji porównaj HTML starego i nowego motywu, zamiast zakładać, że wtyczka SEO nadal działa identycznie.

Title, meta description i nagłówki

Nowy motyw często ingeruje w sekcję <head>, nawet jeśli właściciel sklepu nie planował zmian SEO. Powodem może być własny system meta danych motywu, integracja z wtyczką SEO albo zmieniony sposób wyświetlania nazwy strony.

Na stronie produktu sprawdź, czy title nadal pochodzi z właściwego pola. Jeżeli wcześniej był tworzony według schematu nazwa produktu plus nazwa sklepu, porównaj wynik po wdrożeniu. To samo zrób dla kategorii i wpisów blogowych.

Meta description również trzeba porównać. Jeżeli nowy motyw usuwa fragment odpowiedzialny za wyświetlanie meta danych, część stron może zostać bez ręcznie ustawionych opisów. W kodzie strony sprawdź obecność meta name="description" oraz jego zawartość.

Potem przejdź do nagłówków. Na typowej stronie produktu sprawdź, czy nazwa produktu nadal jest głównym H1. Zobacz też, jakie elementy otrzymały H2. Nowy motyw może oznaczyć nazwę kategorii jako H1, a nazwę produktu jako H2 albo odwrotnie. Może też dodać nagłówki do elementów czysto wizualnych, takich jak boksy promocyjne.

Nie poprawiaj liczby nagłówków mechanicznie. Patrz na strukturę treści. Pytanie brzmi nie tylko, ile jest H1 i H2, ale czy hierarchia HTML opisuje rzeczywistą zawartość strony.

Linkowanie wewnętrzne, menu i breadcrumbs

Motyw odpowiada za znaczną część linków wewnętrznych. Menu główne, menu kategorii, stopka, breadcrumbs, linki do produktów powiązanych oraz elementy nawigacyjne mogą zostać całkowicie przebudowane.

Przed wdrożeniem sprawdź, jakie ważne strony są dostępne z poziomu nawigacji. Po wdrożeniu wykonaj ten sam test. Zwróć uwagę na produkty, które wcześniej były dostępne z kategorii, oraz kategorie znajdujące się w menu.

Nie patrz wyłącznie na to, czy link jest widoczny. Sprawdź jego rzeczywisty adres w HTML. Jeżeli link powstaje dopiero po kliknięciu przez JavaScript, przeanalizuj sposób jego generowania. Wątpliwości dotyczące takiej implementacji możesz zestawić z zasadami dotyczącymi linków generowanych przez JavaScript, szczególnie gdy nowy motyw mocno opiera na JavaScript nawigację lub filtry.

Sprawdź również breadcrumbs. Nowy motyw może je wizualnie wyświetlać, ale zmienić ich strukturę HTML albo dane strukturalne. Zobacz, czy ścieżka prowadzi logicznie od strony głównej przez kategorię do produktu i czy poszczególne elementy są faktycznymi linkami.

Warto porównać także linkowanie między produktami. Jeżeli stary motyw miał sekcję produktów powiązanych, a nowy ją usuwa, zmienia się sposób przechodzenia między stronami. Nie oznacza to automatycznie problemu, ale taka różnica powinna być świadoma.

Dane strukturalne po zmianie motywu

Dane strukturalne są częścią kodu strony, więc zmiana szablonu może je usunąć, zdublować albo zmienić ich wartości. Dotyczy to szczególnie sklepów, w których dane Product, Offer, Review lub BreadcrumbList były generowane przez motyw albo integrację z WooCommerce.

Na stronie produktu wyszukaj w kodzie application/ld+json. Sprawdź, jakie typy danych były obecne przed wdrożeniem i jakie są po wdrożeniu. Porównaj nazwę produktu, adres URL, cenę, dostępność, identyfikatory i dane dotyczące wariantów tam, gdzie są stosowane.

Nie zakładaj, że większa liczba bloków JSON-LD oznacza lepszą sytuację. Jeżeli stary motyw generował jeden poprawny zestaw danych, a nowy dodaje drugi zestaw z inną ceną lub adresem, trzeba ustalić źródło konfliktu.

W WooCommerce sprawdź również, czy nowy motyw nie nadpisuje szablonów WooCommerce w sposób, który zmienia strukturę strony produktu. Dokumentacja WooCommerce pokazuje, że pliki szablonów odpowiadają za markup i strukturę frontendowej części sklepu, dlatego ich modyfikacje mogą mieć bezpośrednie przełożenie na HTML.

Po wdrożeniu przetestuj dane strukturalne na kilku produktach, a nie tylko na jednym. W sklepie z wariantami wybierz produkty proste i wariantowe. Jeżeli dane różnią się w zależności od rodzaju produktu, jeden test nie wystarczy.

Indeksowanie i przypadkowe noindex

To jeden z testów, które wykonuję przed publikacją jako jeden z pierwszych. Nowy motyw może zostać przygotowany na środowisku testowym i zawierać zabezpieczenie przed indeksowaniem. Jeżeli takie ustawienie zostanie przeniesione na produkcję, ważne strony mogą otrzymać noindex.

Sprawdź kod HTML najważniejszych adresów i wyszukaj noindex. Zobacz stronę główną, kategorię, produkt, wpis blogowy oraz inne typy stron, które mają być widoczne w Google. Nie ograniczaj się do panelu administracyjnego. Ostatecznym punktem kontroli jest kod odpowiedzi wysyłany do przeglądarki.

Sprawdź także robots.txt. Sam motyw zwykle nie powinien go zmieniać, ale przy wdrożeniu często zmienia się konfiguracja całego środowiska. Jeżeli sklep był budowany na kopii produkcji, porównaj konfigurację testową i produkcyjną.

Przejrzyj mapę XML. Nowy motyw nie powinien usuwać produktów ani kategorii z mapy, ale zmiany w konfiguracji sklepu lub wtyczek mogą spowodować zmianę generowanych adresów. Porównaj liczbę i typy adresów, a przede wszystkim sprawdź, czy w mapie nie pojawiają się strony, które nie powinny być indeksowane.

Po publikacji użyj Google Search Console do kontroli wybranych URL-i. Sprawdź, jaki canonical widzi Google, czy adres może być indeksowany i czy Google otrzymuje tę samą wersję strony, którą widzi użytkownik.

HTML, obrazy i JavaScript

Nie oceniaj nowego motywu wyłącznie po tym, co widzisz w przeglądarce. Dwie strony mogą wyglądać niemal identycznie, a mieć zupełnie inną strukturę HTML.

Otwórz kod źródłowy kilku reprezentatywnych stron i porównaj główne elementy. Sprawdź <title>, meta description, robots, canonical, nagłówki, linki oraz dane strukturalne. Jeżeli sklep używa JavaScript do filtrów, menu, wyszukiwarki lub wariantów produktów, sprawdź także wersję strony po załadowaniu skryptów.

Obrazy również mogą zmienić sposób działania strony. Nowy motyw może korzystać z innych rozmiarów grafik, lazy loadingu, srcset albo nowych skryptów optymalizacyjnych. Sprawdź, czy najważniejsze zdjęcie produktu jest faktycznie ładowane, czy nie pojawiły się błędne adresy oraz czy zmiana nie powoduje dużego przesunięcia elementów podczas ładowania.

Przy okazji sprawdź atrybuty alt dla zdjęć produktów. Jeżeli wcześniej były pobierane z danych produktu, a nowy motyw generuje puste wartości, zauważysz to szybko na większej próbce.

Core Web Vitals po zmianie motywu

Nowy motyw może być cięższy od starego nawet wtedy, gdy liczba funkcji sklepu się nie zmieniła. Dochodzą fonty, biblioteki JavaScript, slidery, animacje, dodatkowe pliki CSS, skrypty analityczne i elementy wizualne.

Przed wdrożeniem zapisz wyniki dla najważniejszych typów stron. Nie testuj tylko strony głównej. W sklepie internetowym osobno sprawdź kategorię i produkt, ponieważ mają zupełnie inny zestaw zasobów.

Po wdrożeniu powtórz pomiary w podobnych warunkach. Interesują Cię przede wszystkim LCP, INP i CLS. LCP pokazuje, jak szybko pojawia się główny element strony, INP dotyczy reakcji strony na interakcje użytkownika, a CLS pokazuje stabilność układu podczas ładowania.

Jeżeli po zmianie motywu wynik jest gorszy, nie zaczynaj od usuwania przypadkowych elementów. Sprawdź waterfall zasobów i ustal, co pojawiło się w nowej wersji. Częstym źródłem problemu są dodatkowe fonty, duże obrazy, skrypty odpowiedzialne za animacje oraz biblioteki ładowane na każdej podstronie.

Jeżeli chcesz czytać wyniki PageSpeed bardziej technicznie, pomocne będzie zestawienie INP, LCP i CLS w sklepie, ponieważ pozwala rozdzielić problem ładowania od problemu interakcji i stabilności układu.

W WooCommerce warto dodatkowo sprawdzić, czy motyw nie ładuje zasobów związanych z funkcjami, które na danej stronie nie są używane. Na stronie produktu potrzebujesz innych elementów niż na koszyku czy checkout. Im więcej niepotrzebnego kodu trafia do każdej strony, tym więcej rzeczy trzeba później analizować.

Test przed publikacją i kontrola zaraz po wdrożeniu

Przed przełączeniem motywu przygotuj krótką listę adresów kontrolnych. Dla każdego adresu zapisz URL, status HTTP, title, H1, canonical, robots, dane strukturalne i podstawowe wyniki wydajności. To jest Twoja wersja referencyjna.

Następnie uruchom nowy motyw na środowisku testowym. Nie wystarczy sprawdzenie strony głównej. Przejdź przez pełną ścieżkę zakupową: kategoria, produkt, wariant, koszyk i checkout. Jeżeli sklep ma blog, producentów, filtry lub inne niestandardowe typy stron, dodaj je do testu.

Przed publikacją sprawdź też linki prowadzące do stron, które mają największe znaczenie biznesowe. Jeżeli zmieniła się nawigacja, upewnij się, że użytkownik i robot nadal mogą dojść do najważniejszych kategorii oraz produktów.

Po wdrożeniu nie kończ kontroli na komunikacie, że sklep działa. Ponownie wykonaj crawling najważniejszych adresów. Porównaj kod HTML ze stanem sprzed zmiany. Sprawdź błędy 404 i 500, przekierowania, canonicale, robots, mapę XML oraz Search Console.

Jeżeli po publikacji pojawią się błędy serwera, najpierw ustal ich źródło. Przydatna będzie analiza źródeł błędów 500 w sklepie, zwłaszcza gdy nowy motyw korzysta z dodatkowych funkcji PHP, integracji lub nadpisanych szablonów.

Na koniec wykonaj ręczny test kilku produktów na telefonie. Sprawdź menu, filtry, warianty, galerię, dodawanie do koszyka i przejście do checkoutu. SEO techniczne nie kończy się na kodzie, jeżeli zmiana motywu powoduje problemy z korzystaniem ze sklepu, trzeba je znaleźć przed zakończeniem wdrożenia.

Co sprawdzić po zmianie szablonu sklepu

Jeżeli zastanawiasz się, co sprawdzić po zmianie szablonu sklepu, zacznij od elementów, które mogły zmienić się bez świadomej decyzji. Najpierw adresy i statusy HTTP, następnie title, meta description, H1, canonical i robots. Później przejdź do linkowania, breadcrumbs, danych strukturalnych, obrazów i JavaScript.

Dopiero po tej kontroli zajmij się szerszą analizą wydajności. Dzięki temu wiesz, czy problem wynika z HTML, konfiguracji SEO, linkowania czy samego ciężaru nowego motywu.

Czy zmiana motywu wpływa na SEO?

Tak, może wpływać na SEO, ponieważ motyw kontroluje dużą część kodu HTML prezentowanego użytkownikowi. Nie oznacza to jednak, że każda zmiana motywu powoduje spadek widoczności. Efekt zależy od tego, co dokładnie zostało zmienione.

Jeżeli nowy motyw zachowuje adresy URL, meta dane, canonicale, strukturę nagłówków, linkowanie, dane strukturalne i dostępność treści, zakres zmian SEO może być niewielki. Jeżeli natomiast zmienia te elementy, trzeba je potraktować jako część wdrożenia technicznego.

Dlatego audyt po zmianie motywu powinien porównywać konkretne dane, a nie tylko wygląd sklepu. Szczególnie istotne są różnice w kodzie źródłowym, ponieważ część zmian może być niewidoczna dla osoby zarządzającej sklepem.

Jeżeli nie masz czasu na ręczne przejście przez HTML, canonicale, indeksowanie, linkowanie i wydajność, możesz zlecić audyt SEO sklepu po zmianie motywu. Zakres kontroli powinien objąć zarówno stronę główną, jak i reprezentatywne typy podstron sklepu.

Podsumowanie

Zmiana szablonu SEO nie powinna być traktowana wyłącznie jako projekt graficzny. Nowy motyw może zmienić strukturę HTML, sposób generowania meta danych, nagłówki, linki, breadcrumbs, dane strukturalne i sposób ładowania zasobów.

Przed publikacją przygotuj wersję referencyjną najważniejszych stron. Po wdrożeniu porównaj te same adresy i te same elementy. Sprawdź URL, status HTTP, title, meta description, H1, canonical, robots, linkowanie, dane strukturalne oraz Core Web Vitals. Jeżeli znajdziesz różnicę, ustal jej źródło i zdecyduj, czy jest zamierzona.

Taki audyt po zmianie motywu pozwala wykryć problemy wtedy, gdy można je jeszcze poprawić w kodzie szablonu, konfiguracji SEO albo wdrożeniu. Zamiast zgadywać, co mogło się zmienić, porównujesz konkretną wersję sklepu przed i po publikacji. Jeżeli nowy motyw pogorszył Core Web Vitals, poprawki można zlecić w ramach optymalizacji szybkości sklepu.