SEO w PrestaShop: adresy URL, indeksowanie, treści i kontrola techniczna

Co byśmy zrobili

Zaczęlibyśmy od stron sprzedażowych, które klienci mają znajdować, i ustalili, czy problem dotyczy odkrywania, indeksowania, prezentacji w wyszukiwarce czy ścieżki zakupu. Właściwy sposób działania zależy od obecnej wersji PrestaShop, motywu, modułów, integracji, danych katalogowych, języków i rynków oraz od tego, kto w zespole może utrzymywać wynik. Przed zmianą ustawień lub zakupem kolejnego narzędzia SEO zapisz dokładne wersje PrestaShop, motywu i modułów wraz z generowanym wynikiem sklepu oraz sprawdź trasy, ścieżki szablonów i generowane reguły właściwe dla zainstalowanego wydania.

Zachowuj stabilność działających adresów URL i przydatnych zindeksowanych stron. Jeśli błąd dotyczy wspólnego szablonu lub reguły routingu, odtwórz go na zabezpieczonej kopii testowej z taką samą istotną konfiguracją i danymi. Przećwicz poprawkę, ścieżki klientów i kontrole robotów, zapisz sposób wycofania oraz uzgodnij termin wdrożenia z wyznaczoną osobą odpowiedzialną. Odizoluj kopię od rzeczywistych e-maili, płatności i integracji realizacji zamówień; publiczny sklep testowy sam może tworzyć duplikaty stron i ujawniać informacje klientów.

Wybierz punkt wyjścia

Przed otwarciem szczegółowych sekcji poniżej wybierz stronę z problemem i porównywalną stronę bez problemu. Zyskasz przydatne porównanie i drogę przez poradnik bez zmieniania wszystkich ustawień naraz.

Diagnozę konkretnego sklepu z priorytetami zapewnia PrestaShop SEO Audit & Action Plan, obejmujący ustalenia z analizy tylko do odczytu i proponowane poprawki; wdrożenie, pisanie treści, pozyskiwanie linków i bieżący monitoring są osobne.

Wybierz stabilne adresy URL i zachowaj wymagane pola tras

Zacznij w Parametry sklepu → Ruch i SEO → SEO i URL. W Konfiguracja adresów URL sprawdź ustawienie przyjaznych adresów URL i bieżące wzorce tras. W działającym sklepie wyeksportuj istniejące adresy przed ich zmianą.

Adres produktu taki jak index.php?id_product=42&controller=product może stać się czytelną ścieżką, np. /42-mens-leather-wallet.html. Liczbowe identyfikatory nie uniemożliwiają stronie zajmowania pozycji w wynikach. Zachowuj utrwalone adresy, chyba że zmiana ma jasny cel.

Zapisanie konfiguracji adresów URL wywołuje generowanie .htaccess dla Apache. Sprawdź działanie przepisywania i fizycznej ścieżki bazowej sklepu. Nginx nie odczytuje .htaccess, więc skonfiguruj równoważne reguły na serwerze. Jeśli przyjazne adresy zwracają 404, przed zmianą nazw produktów sprawdź konfigurację przepisywania, ścieżkę bazową i żądaną trasę.

Trasy rdzenia nadal wymagają identyfikatorów

Trasy produktów i kategorii w rdzeniu wymagają słów kluczowych identyfikatorów. Usunięcie {id} z pola trasy nie dodaje wyszukiwania encji po slugu. Domyślny wzorzec produktu w PrestaShop 9 pomija kategorię, ale nadal zawiera identyfikator produktu i opcjonalny identyfikator kombinacji.

# PrestaShop 9 core product route
{id}{-:id_product_attribute}-{rewrite}.html

# Core category route
{id}-{rewrite}

Trasy bez identyfikatorów wymagają implementacji, która je rozpoznaje oraz obsługuje kolizje i przekierowania. Jeśli tego potrzebujesz, zobacz pomoc Smart SEO Friendly URL Manager.

Sprawdź zakres kolizji przed zmianą tras

Użyj rzeczywistego prefiksu bazy. Poniższe zapytanie tylko do odczytu znajduje slugi współdzielone przez różne identyfikatory produktów w tym samym sklepie i języku. To wstępna kontrola dla tras opartych na slugach, a nie powód do zmiany działających adresów rdzenia.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS product_count
FROM ps_product_lang
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1;

Jeśli Twoja implementacja tras używa ścieżek kategorii, uwzględnij efektywną ścieżkę w kontroli kolizji. Sprawdź produkty, kategorie, strony CMS, marki i trasy modułów we wspólnej przestrzeni nazw. Nie licz tego samego produktu w kilku sklepach jako kilku kolidujących produktów.

• Używaj opisowych słów i łączników. Wybieraj czytelne slugi zamiast sztywnej reguły liczby słów.
• Wybierz spójną zasadę końcowego ukośnika i sufiksu dla każdego typu trasy. Kategorie rdzenia nie wymagają powszechnie końcowego ukośnika.
• Utrzymuj zgodność linków wewnętrznych, adresów kanonicznych, wpisów sitemapy i przekierowań z tą zasadą.
• Zaplanuj stałe przekierowanie, gdy istniejący adres faktycznie się przenosi.

Sprawdź HTTPS, normalizację domeny i przekierowania migracyjne

Najpierw zapewnij ważny certyfikat. Następnie włącz SSL i SSL na wszystkich stronach w Parametry sklepu → Ogólne. Sprawdź domenę sklepu i domenę SSL, generowane adresy zasobów oraz ostrzeżenia przeglądarki o mieszanej zawartości.

Kontroler frontowy PrestaShop realizuje przekierowania SSL. Odwrotne proxy musi prawidłowo przekazywać informacje o HTTPS, inaczej aplikacja może generować błędne adresy lub wpaść w pętlę przekierowań. Reguły serwera mogą uzupełniać przekierowania aplikacji i łączyć normalizację hosta oraz protokołu.

1. Wybierz preferowany host HTTPS, z www lub bez.
2. Przetestuj HTTP, alternatywny host, preferowany host i reprezentatywne ścieżki językowe.
3. Sprawdź każdy cel przekierowania i odpowiedź końcową. Dąż do bezpośredniego przekierowania do końcowego celu.
4. Po zmianach reguł serwera przetestuj produkty, kategorie, strony CMS, adresy modułów, składanie zamówienia i callbacki.

curl -I -L https://example.com/42-mens-leather-wallet.html
curl -I -L http://www.example.com/42-mens-leather-wallet.html

Trzy różne mechanizmy przekierowań

Wyeksportuj stare adresy i przypisz każdy zmieniony adres do równoważnego celu. Unikaj łańcuchów i zbiorczych przekierowań na stronę główną. Zmiana motywu wymaga przekierowań URL tylko wtedy, gdy adresy faktycznie się zmieniają. Osobno przetestuj jego adresy kanoniczne, schema, linki wewnętrzne i nagłówki.

Sprawdź warianty strony głównej, takie jak /, /index.php, /en/ i /en/index.php. Zachowaj celowe wersje językowe. Nie stosuj szerokiej reguły index.php, która obejmuje też funkcjonalne trasy z parametrami zapytania. Normalizuj ?page=1 tylko wtedy, gdy oznacza tę samą pierwszą stronę listy, i zachowuj niezwiązane parametry.

Wycofane produkty przekierowuj tylko do faktycznie równoważnego zamiennika. W przeciwnym razie zachowaj przydatne informacje o niedostępnym produkcie lub zwracaj odpowiednie 404/410. Przekierowanie do jedynie podobnego towaru może dezorientować kupujących i zostać uznane za pozorny błąd 404.

Pisz przydatne tytuły, opisy i treści stron

Edytuj metadane produktu w jego sekcji SEO, kategorii w edytorze kategorii, a CMS w edytorze strony. W Ruch i SEO przejrzyj wpis index dla strony głównej i inne wpisy stron statycznych, w tym kontaktu i sklepów.

Zastąp ps_ prefiksem swojej instalacji. Pusty meta title produktu może zostać zastąpiony nazwą produktu. Końcowy tytuł zależy też od zainstalowanego motywu i modułów SEO. Sprawdzaj wyrenderowany tytuł, zamiast zakładać konkretny sufiks.

Praktyczne wzorce tytułów i opisów

Product: Main product name - useful distinction | Shop name
Category: Category name - useful distinction | Shop name
CMS: Page topic | Shop name

Zaczynaj od tematu i odróżniaj poszczególne tytuły. Zwięzły tytuł o długości około 50 do 60 znaków może być celem redakcyjnym, ale Google nie ma stałego limitu znaków i może przepisać lub skrócić wyświetlany tytuł. Stosuj wskazówki Google dotyczące tytułów.

Napisz opis właściwy dla konkretnej strony, który dokładnie podsumowuje treść. Dodaj przydatną cechę, szczegół dostawy lub wezwanie do działania tylko wtedy, gdy są prawdziwe dla tej strony. Google może zamiast niego użyć tekstu strony, a długość opisu w wynikach zależy od urządzenia i zapytania. Opisy generowane programowo są odpowiednie, gdy pozostają czytelne i konkretne; puste pole nie jest zawsze lepsze od dobrego szablonu. Zobacz wskazówki Google dotyczące opisów w wynikach.

Zmiany zbiorcze

Przed aktualizacją wykonaj kopię bazy i podejrzyj zbiorcze zmiany metadanych jako SELECT. Łącz dane produktu, kategorii domyślnej i tłumaczeń we właściwym sklepie i języku. Zachowuj ręcznie napisane wartości, chyba że celowo je zastępujesz. Korzystaj z obsługiwanych importów lub API, gdy potrzebujesz walidacji, hooków i unieważniania pamięci podręcznej.

SELECT id_product, id_shop, id_lang, name, meta_title
FROM ps_product_lang
WHERE meta_title IS NULL OR TRIM(meta_title) = '';

Treść i nagłówki

Zapewnij stronom kategorii przydatne opisy wyjaśniające wybór i linkujące do odpowiednich podkategorii. PrestaShop 8 i 9 udostępniają dodatkowy opis kategorii, a jego położenie zależy od motywu. Dla starszego sklepu potrzebującego takiego obszaru treści zobacz pomoc Second Category Description.

Zastępuj skopiowane opisy dostawców dokładnymi informacjami właściwymi dla produktu. Zacznij od stron ważnych handlowo, a potem rozszerz zakres. Dodaj własne porady zakupowe, wymiary, materiały, kompatybilność i informacje o pielęgnacji tam, gdzie pomagają klientowi. Sprawdzaj automatycznie generowane teksty przed publikacją.

Zamień temat wyszukiwania w przydatne wytyczne treści

Przed utworzeniem kolejnej strony przypisz temat wyszukiwania do istniejącej kategorii, produktu lub poradnika i zweryfikuj wybór na podstawie zapytań Search Console oraz pytań klientów. Dla kategorii krzeseł biurowych zacznij od pytań decydujących o wyborze: regulacji siedziska, prześwitu pod biurkiem, materiałów i dopasowania do zastosowania. Umieść krótkie wyjaśnienie tam, gdzie pomaga wybrać, i dodaj linki do właściwego asortymentu lub poradnika dopasowania. Zdanie powtarzające „krzesła biurowe” bez pomocy w tej decyzji niewiele wnosi do siatki produktów.

Dla konkretnego krzesła zbierz przed pisaniem zweryfikowane wymiary, zakres regulacji i elementy zestawu. Jeśli dane pochodzą z importu, ustal miarodajne pola i osobę, która je poprawia. Tytuł obiecujący regulowane podłokietniki musi być zgodny zarówno ze szczegółami produktu, jak i opcją trafiającą do koszyka. Nie umieszczaj obietnic dostawy lub dostępności w tekstach wielokrotnego użytku, chyba że zespół może zapewniać ich aktualność na każdym objętym rynku.

Sprawdź wynik na rzeczywistej stronie mobilnej: czy klient widzi wybór produktów, znajduje porady zakupowe i dociera do podlinkowanego asortymentu? Zapisany opis kategorii, którego motyw nigdy nie pokazuje, nie odpowiada na pytanie kupującego. Zachowaj przydatne wytyczne przy danych produktu, aby późniejsze tłumaczenia i importy zachowały ich znaczenie.

Używaj jasnego głównego nagłówka i semantycznej hierarchii działającej z czytnikami ekranu. Google nie wymaga dokładnie jednego H1 ani magicznej liczby nagłówków. Dopasuj nagłówek do widocznego tematu i zachowuj dostępność ważnych treści na wąskich ekranach. Proces pracy z treścią opisuje poradnik treści SEO produktów.

Rozdziel adresy kanoniczne, skanowanie i indeksowanie

Link kanoniczny wskazuje preferowany adres dla zduplikowanej lub bardzo podobnej treści. Jest sygnałem i Google może wybrać inny adres. Przekierowanie przenosi żądanie. noindex zapobiega indeksowaniu, gdy robot może go odczytać. Reguła robots.txt kontroluje skanowanie.

<link rel="canonical" href="https://example.com/42-mens-leather-wallet.html">

Sprawdź końcową sekcję head dokumentu HTML i nagłówki odpowiedzi rzeczywistego motywu. Przetestuj zwykły produkt, kombinację, alternatywną ścieżkę kategorii, listę filtrowaną, listę sortowaną i adres śledzący. Przekierowanie kanoniczne rdzenia zasadniczo nie usuwa dowolnych parametrów zapytania: dodatkowy ciąg zapytania może zostać zaakceptowany bez przekierowania.

Kontroler list w PrestaShop 9 ustawia noindex po przesłaniu q lub order. Sprawdź wyrenderowany wynik, bo motywy i moduły mogą go zmienić. Nie zakładaj, że każdy własny filtr, starszy parametr lub trasa modułu otrzymuje taką samą obsługę.

W multistore weryfikuj host, ścieżkę, język i adres kanoniczny w kontekście każdego sklepu. Adresy kanoniczne między domenami są odpowiednie tylko wtedy, gdy świadomie chcesz skonsolidować zduplikowaną treść w innej domenie. Jawne wyjątki produktowe opisuje pomoc Product Canonical Manager.

Paginacja

Zachowuj możliwość skanowania przydatnej paginacji kategorii i nadaj każdej stronie własny adres kanoniczny. Druga strona listy zawiera inne produkty niż pierwsza. Nie kieruj wszystkich stron na pierwszą ani automatycznie nie ustawiaj noindex dla każdej strony po trzeciej. Google nie używa już rel="next" i rel="prev" jako sygnałów indeksowania. Stosuj wskazówki dotyczące paginacji.

Zapewnij zwykłe linki dostępne dla robotów do kolejnych stron i z powrotem do początku kategorii. Nieskończone przewijanie lub przycisk Wczytaj więcej nadal wymagają odkrywalnych adresów paginacji. Więcej produktów na stronie zmniejsza liczbę stron, ale zmienia też koszt renderowania, więc testuj użyteczność i wydajność. Użyj produktu występującego tylko na dalszej stronie: przejdź zwykłymi linkami z kategorii do tej strony, a potem do produktu, bez polegania na przewijaniu lub wyszukiwaniu wewnętrznym. To ujawnia lukę w odkrywaniu, którą może ukrywać prawidłowy adres kanoniczny pierwszej strony.

Kombinacje filtrów

Filtry mogą mnożyć warianty adresów. Na przykład wybór jednego z pięciu kolorów, jednego z ośmiu rozmiarów i jednego z czterech przedziałów cen daje 160 kombinacji przed uwzględnieniem innych opcji. Pozostaw indeksowalne tylko celowo wybrane strony docelowe. Nie łącz blokady robots z oczekiwaniem, że Google odczyta noindex lub znacznik kanoniczny strony. Jeśli niechciane warianty są już zindeksowane, przed blokadą skanowania ustal, jak robot otrzyma sygnał usunięcia; nie zakładaj, że nowo zapisana reguła robots usuwa je z indeksu.

Prawidłowo mapuj wersje językowe i regionalne

Używaj hreflang, aby pomóc Google wyświetlać odpowiednią wersję językową lub regionalną. Nie jest wymagany do odkrywania ani indeksowania przetłumaczonych stron przez Google. Każda wersja alternatywna powinna być osiągalnym adresem dopuszczającym indeksowanie i przedstawiającym równoważną treść.

<link rel="alternate" hreflang="en" href="https://example.com/en/42-wallet.html">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/42-portefeuille.html">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/42-wallet.html">

Uwzględnij samą stronę i pozostałe wersje alternatywne. Używaj pełnych adresów i linków zwrotnych. Brak linków zwrotnych wpływa na odpowiednie relacje, ale nie musi unieważniać każdej innej pary. Tagi HTML, nagłówki HTTP i sitemapy XML to równoważne metody przekazywania danych, więc wybierz tę, którą możesz spójnie utrzymywać.

W odpowiednich przypadkach używaj kodów samego języka, takich jak en lub fr. Dla wersji regionalnych dodaj region, na przykład en-GB lub en-US. en-UK jest nieprawidłowe. x-default to przydatna wersja zastępcza dla niedopasowanych odwiedzających, często selektor lub strona w języku domyślnym, ale sam jej brak nie unieważnia innych oznaczeń.

Sprawdź linki zwrotne, cele kanoniczne, indeksowalność i mapowanie równoważnych produktów w każdym sklepie. Osobne domeny są dozwolone. Przy mapowaniu między sklepami nie zakładaj, że przetłumaczony slug lub identyfikator produktu są wszędzie takie same. Zobacz wskazówki Google dotyczące wersji lokalnych i poradnik hreflang w PrestaShop.

Załóżmy, że produkt jest sprzedawany w sklepie angielskim, ale nie ma równoważnej francuskiej strony produktu. Nie podstawiaj francuskiej strony głównej tylko po to, by uzupełnić zestaw wersji alternatywnych. Zapisz brak odpowiednika, pomiń tę relację i ponów test po publikacji tłumaczenia. Oddziel tę decyzję o mapowaniu od chwilowego braku produktu w magazynie na istniejącym rynku.

Pomoc Hreflang Tags Manager wyjaśnia wersje alternatywne budowane z własnych adresów stron każdego sklepu; dla niezależnych sklepów z różnymi identyfikatorami produktów lub katalogami potwierdź sposób mapowania równoważnych stron przed wyborem implementacji.

Weryfikuj konkretny typ wyników rozszerzonych, którego potrzebujesz

Dane strukturalne mogą kwalifikować stronę do rozszerzonej prezentacji w wyszukiwarce. Poprawne znaczniki nie gwarantują wyświetlania ani wzrostu pozycji. Ich nazwa, cena, waluta, dostępność i opinie muszą być spójne z widoczną stroną.

Stosuj odpowiednie wymagania dla fragmentów produktu lub informacji o produktach sprzedawcy. Brak wymaganych właściwości może uniemożliwić kwalifikację. Ostrzeżenia o zalecanych właściwościach różnią się od błędów, a żadne z nich nie jest automatycznie ogólnym negatywnym sygnałem rankingowym. Spam w danych strukturalnych to osobna kwestia.

Przed edycją znajdź źródło danych

Przeszukaj zainstalowany motyw i moduły pod kątem application/ld+json oraz odpowiedniego typu schema. Wydania motywów różnią się. Szablon produktu Hummingbird dołącza _partials/microdata/product-jsonld.tpl. Nie zakładaj, że za schema odpowiada fragment szczegółów produktu.

Renderowanie ścieżki nawigacji i JSON-LD zależy od motywu lub modułów. Ustal komponent, który je generuje, zamiast szukać uniwersalnego wbudowanego modułu ścieżki nawigacji. Własny JSON-LD można zbudować jako tablicę PHP, bezpiecznie zakodować przez json_encode() i wyświetlić przez obsługiwany hook lub szablon. Zachowaj jedno źródło odpowiedzialne za każdą nakładającą się encję i właściwość. Dla produktu z kombinacjami wybierz inną opcję i porównaj widoczną cenę, komunikat o stanie oraz zawartość przekazaną do koszyka z danymi strukturalnymi testowanego adresu. Jeśli import zmienia dostępność, powtórz kontrolę po imporcie i po odświeżeniu odpowiedniej pamięci podręcznej; ręczna poprawka wartości w szablonie może ukryć nieaktualne źródło zamiast je naprawić.

Zarządzane dane Product, Offer, Breadcrumb i Organization opisuje pomoc Automatic SEO Schema Rich Snippets. Dane FAQ należą do osobnej implementacji, takiej jak SEO Revolution.

1. Przetestuj reprezentatywne produkty, kategorie, stronę główną i strony treści w teście wyników z elementami rozszerzonymi.
2. Sprawdź wyrenderowany HTML i potwierdź zgodność wartości ze stroną widoczną dla klienta.
3. Sprawdź ceny dla niezalogowanych, walutę, warianty, podatek i dostępność we właściwym kontekście sklepu.
4. Po wdrożeniu monitoruj odpowiednie raporty wyników rozszerzonych w Search Console.

Publikuj preferowane adresy w aktualnej sitemapie XML

Generowanie sitemap zapewnia zainstalowany moduł, a nie strona SEO i URL rdzenia. Zainstaluj gsitemap, jeśli go brakuje, albo użyj implementacji sitemap odpowiedniej dla sklepu. Moduł Google Sitemap obsługuje wpisy obrazów, daty modyfikacji i dzielenie plików. Te funkcje nie wymagają zastąpienia go po przekroczeniu arbitralnej liczby produktów.

Używaj adresu wskazanego przez zainstalowany moduł. Częsty indeks gsitemap to /1_index_sitemap.xml, z identyfikatorem sklepu w nazwie pliku, a nie uniwersalny /sitemap.xml. Korzystaj z wygenerowanego adresu zadania cyklicznego wraz z tokenem i identyfikatorem sklepu. Nie kopiuj starej nazwy głównego pliku PHP cron.

• Uwzględniaj kanoniczne produkty, kategorie i strony treści, które chcesz indeksować.
• Uwzględniaj strony dostawców lub marek, gdy mają przydatny cel dla klientów.
• Wykluczaj przekierowania, błędy, strony noindex, adresy konta i finalizacji zakupu oraz niewybrane warianty filtrów.
• Używaj dokładnych dat lastmod dla istotnych zmian.
• Generuj pliki dla właściwych domen sklepów i ścieżek językowych.
• Generuj ponownie z częstotliwością odpowiadającą rzeczywistym zmianom katalogu i sprawdzaj błędy zadań harmonogramu.

Sitemapę ogranicza 50 000 adresów lub 50 MB bez kompresji na plik. Dla wielu plików używaj indeksu. Zgłoś rzeczywisty adres indeksu w Search Console i wskaż go w robots.txt. Zgłoszenie pomaga w odkrywaniu, ale nie wymusza indeksowania. Zobacz wskazówki Google dotyczące sitemap.

Stary punkt końcowy Google do pingowania sitemap został wycofany. Używaj Search Console i robots.txt zamiast traktować udane powiadomienie modułu jako dowód przyjęcia sitemapy przez Google. Komunikat Google o wycofaniu wyjaśnia obecny sposób zgłaszania.

Jeśli potrzebujesz weryfikacji HTTP i dodatkowej kontroli wykluczeń, zobacz pomoc Advanced SEO Sitemap Builder.

Nagły spadek liczby opublikowanych adresów wymaga diagnozy. Zanim uznasz, że katalog zniknął z wyszukiwarki, sprawdź odpowiedzi inne niż 200, przekierowania, nagłówki lub metatagi noindex oraz rozbieżności adresów kanonicznych. Traktuj tymczasowe błędy serwera jako niepowodzenia do ponowienia, a nie prawidłowe strony do publikacji.

Generuj i testuj robots.txt dla rzeczywistego sklepu

Udostępniaj plik sterujący w katalogu głównym originu, na przykład https://example.com/robots.txt. Sklep zainstalowany w /shop/ nie może polegać na /shop/robots.txt do sterowania robotami. W regułach uwzględnij rzeczywisty prefiks ścieżki sklepu.

Robots.txt zarządza skanowaniem. Nie chroni katalogu administracyjnego ani danych prywatnych, a zablokowany adres nadal może pojawić się w wyszukiwarce bez pobranego opisu. Aby usunąć stronę z indeksu, pozwól robotowi odczytać dyrektywę noindex lub zwracaj właściwy status usunięcia. Prywatne zasoby chroń uwierzytelnianiem i kontrolą dostępu serwera. Zobacz wskazówki Google dotyczące robots.txt.

Zacznij od wygenerowanego pliku

Przed użyciem Parametry sklepu → Ruch i SEO → Generowanie pliku robots zrób kopię własnych reguł. Generowanie nadpisuje plik. Porównaj wynik przed wdrożeniem, a potem przywróć celowe modyfikacje.

Obecny generator PrestaShop 9 uwzględnia już parametry q i order, kontrolery transakcyjne, przyjazne trasy właściwe dla języka oraz fizyczne ścieżki sklepów. Blokuje też katalogi systemowe, dopuszczając pliki CSS, JavaScript i obrazy modułów. Zachowaj te wyjątki.

Poniżej znajduje się tylko fragment wzorców obecnego generatora. Nie jest to kompletny plik zastępczy.

User-agent: *
Allow: */modules/*.css
Allow: */modules/*.js
Allow: */modules/*.png
Allow: */modules/*.jpg
Allow: */modules/*.gif
Allow: */modules/*.svg
Allow: */modules/*.webp
Allow: */modules/*.avif
Allow: /js/jquery/*
Disallow: /*?order=
Disallow: /*&order=
Disallow: /*?q=
Disallow: /*&q=

Dodaj wiersz Sitemap: z rzeczywistym publicznym adresem indeksu sitemap, jeśli go brakuje. Nie blokuj wszystkich ciągów zapytań. Zachowaj możliwość skanowania adresów produktów i kategorii oraz zasobów potrzebnych do renderowania.

Przejrzyj każdą rodzinę adresów

Przetestuj dozwolone i zablokowane przykłady

1. Pobierz publiczny plik z katalogu głównego originu i zweryfikuj, że treść odpowiedzi jest zamierzonym tekstem.
2. Sprawdź reprezentatywne adresy produktów, zasobów, filtrów, kont i paginacji odpowiednim walidatorem reguł dla właściwego user agenta.
3. Użyj raportu robots.txt Search Console do sprawdzenia pobierania i parsowania, a następnie sprawdzenia adresu URL dla dotkniętej strony.
4. Przeglądaj żądania botów w logach serwera i monitoruj nieoczekiwane zmiany indeksowania stron.

W multistore każdy origin musi udostępniać odpowiednie reguły pod /robots.txt. Sklepy współdzielące jeden katalog główny serwera mogą udostępniać odpowiedni wspólny plik. Fizycznie osobne pliki są potrzebne tylko wtedy, gdy wymaga ich sposób obsługi żądań lub reguły.

Przeglądaj plik po zmianie wzorców tras, publicznych tras modułów, ścieżek zasobów motywu, języków, ścieżek sklepów lub konfiguracji multistore. Zachowaj kopię własnych reguł, by ponowne generowanie nie usunęło ich po cichu.

Oddziel uczenie AI, wyszukiwanie i pobieranie na żądanie użytkownika

Dobieraj preferencje robotów według celu. Blokowanie robota treningowego i robota wyszukiwarki ma różne skutki. Robots.txt opiera się na udokumentowanym zachowaniu usługi; nie jest systemem kontroli dostępu.

Dla polityki wykluczającej te dwa roboty rozwoju modeli dodatkowe grupy wyglądają tak:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Te grupy nie wyrażają osobnych preferencji dotyczących wyszukiwania. Cel każdego agenta opisują oficjalna dokumentacja OpenAI i dokumentacja robotów Anthropic.

Google-Extended to osobny mechanizm kontroli pewnych zastosowań uczenia Gemini i opierania odpowiedzi na źródłach. Nie określa obecności ani pozycji w wyszukiwarce Google. Przed wyborem tej polityki sprawdź dokumentację robotów Google.

Ustaw podpisy obrazów i mierz dostarczane obrazy

Edytuj podpis obrazu w edytorze produktu i podaj zwięzły opis tego, co przedstawia. Ustal konwencję przed importami. Rdzeń może użyć meta title lub nazwy produktu, gdy zapisany podpis jest pusty, więc puste pole w bazie nie musi oznaczać pustego atrybutu alt. Sprawdź końcowy wynik motywu.

W Ruch i SEO nie ma ogólnego ustawienia szablonu alt obrazów w rdzeniu. Przepisywanie adresów obrazów i fizyczne nazwy plików obrazów to też osobne kwestie. Sprawdzaj dostarczany adres, widoczny obraz i jego tekst alt, zamiast zakładać, że zmiana slugu zmienia każdy zapisany plik.

Gdy kilka fotografii pokazuje ten sam przedmiot, opisz istotny wyróżnik widoku, np. elementy regulacji krzesła lub mocowanie od spodu. Sprawdź stronę przetłumaczoną oraz język domyślny. Jeśli zapisany podpis jest prawidłowy, ale dostarczony alt błędny, przed przepisaniem całej biblioteki obrazów prześledź motyw lub moduł wybierający tę wartość zastępczą.

Jeśli potrzebujesz reguł tekstów alt dla całego katalogu, skorzystaj z pomocy Automatic SEO Images Alt Tags.

• Dobieraj wymiary obrazów do rozmiaru wyświetlania i udostępniaj rozmiary responsywne tam, gdzie obsługuje je motyw.
• Porównuj rzeczywiste rozmiary plików i widoczną jakość. Kodowanie w rdzeniu jest konfigurowalne, a jego wyniki nie są zawsze słabo skompresowane.
• Używaj obsługiwanych formatów WebP lub AVIF, gdy wspierają je wydanie PrestaShop, biblioteka obrazów PHP i motyw. Po zmianie ustawień wygeneruj ponownie odpowiednie formaty lub miniatury.
• Dobieraj jakość na podstawie zmierzonych wyników zamiast stosować jedną stałą wartość dla każdego formatu i katalogu.
• Ładuj leniwie obrazy poza ekranem. Zmierzony obraz LCP ładuj od razu i zapewnij jego łatwe wykrycie.
• Podawaj naturalne wymiary obrazów lub rezerwuj miejsce o odpowiednich proporcjach, by ograniczyć przesunięcia układu.
• Uwzględniaj odpowiednie obrazy w sitemapie, jeśli generator to obsługuje.

Jeśli zachowanie obrazów poza ekranem w motywie wymaga dodatkowej kontroli, skorzystaj z pomocy Automatic SEO Images Lazy Tags.

Mierz Core Web Vitals i testuj zmiany zasobów

Używaj danych rzeczywistych Core Web Vitals, aby zrozumieć doświadczenia klientów, a następnie odtwórz wolną stronę lub interakcję w narzędziach programistycznych. Dobry wynik nie gwarantuje określonej pozycji. Porównuj reprezentatywne trasy strony głównej, listy, produktu i finalizacji zakupu.

Oceniaj je na 75. percentylu wizyt. PageSpeed Insights może pokazać rzeczywiste dane CrUX, jeśli dostępna jest wystarczająca ilość danych. Zwykły test ładowania strony Lighthouse nie zapewnia równoważnego rzeczywistego pomiaru INP. Diagnozuj INP przez odtworzone interakcje i ślady wykonania. Total Blocking Time Lighthouse jest przydatnym wskaźnikiem diagnostycznym, ale nie samym INP. Zobacz wskazówki dotyczące INP.

Obrazy, fonty i układ

Przed optymalizacją zidentyfikuj rzeczywisty element LCP. Jeśli jest nim główny obraz, unikaj leniwego ładowania, dostarczaj odpowiedni format i rozmiar oraz rozważ wysoki priorytet pobierania lub ukierunkowane ładowanie wstępne. Sprawdź, czy ładowanie wstępne nie powiela pobrań lub nie konkuruje z ważniejszymi zasobami.

Rezerwuj miejsce na banery i treści pojawiające się później. Używaj odpowiednich fontów zastępczych i testuj wpływ font-display na przesunięcia. Własny hosting fontów może wyeliminować nawiązywanie połączenia z zewnętrznym dostawcą, ale nadal mierz wynik. Zachowaj tylko potrzebne grubości i zakresy znaków, w stosownych przypadkach używaj WOFF2 i wstępnie ładuj tylko fonty potrzebne na początku.

Ustawienia wydajności PrestaShop

W Zaawansowane → Wydajność sprawdź na kopii testowej pamięć podręczną Smarty i opcje CCC dla CSS/JavaScript. Zmierz działanie pamięci podręcznej i renderowanie przed włączeniem każdej optymalizacji w sklepie. Łączenie żądań może pomagać niektórym stronom, a innym dawać niewielką korzyść lub powodować problemy kolejności.

Sprawdź faktycznie zarejestrowane pliki i zależności wykonania. Moduł podpięty do displayHeader lub displayFooter nie musi generować JavaScript. Bezpośrednie znaczniki zasobów mogą omijać menedżera zasobów. JavaScript umieszczony na dole bez defer jest obsługiwanym zachowaniem, a nie automatycznie błędem.

Ładuj zasoby tylko na stronach, które ich potrzebują. Testuj defer i async względem zależności i kolejności inicjalizacji. Analizuj zewnętrzną analitykę, czat i skrypty reklamowe na podstawie zapisów interakcji zamiast zakładać, że wyjaśniają każde pogorszenie danych rzeczywistych.

Diagnozę pamięci podręcznej, bazy danych, serwera i frontendu opisuje poradnik wydajności PrestaShop.

Buduj przydatną nawigację i linki kontekstowe

Uporządkuj drzewo kategorii według sposobu szukania produktów przez klientów. Używaj sensownych grup, np. Buty, Męskie buty do biegania i Buty do biegania w terenie, jeśli katalog je uzasadnia. Unikaj pustych lub niemal identycznych kategorii tworzonych wyłącznie pod wariant słowa kluczowego.

Sprawdź nawigację okruszkową w używanych typach stron. W obecnym kodzie PrestaShop 9 PS_PRODUCT_BREADCRUMB_CATEGORY wybiera bieżącą kategorię wejścia lub kategorię domyślną. Ustaw odpowiednią domyślną i przetestuj obie ścieżki nawigacji, gdy produkt należy do kilku kategorii.

Połącz odpowiednie akcesoria i produkty powiązane w edytorze produktu, a następnie sprawdź, czy motyw wyświetla linki do produktów dostępne do skanowania. Linkuj poradniki rozmiarów, instrukcje montażu, zasady wysyłki i pielęgnacji z odpowiednich opisów oraz treści kategorii. Zachowaj dostępność przydatnych treści CMS i bloga przez zwykłą nawigację.

Używaj opisowego tekstu linków i prawidłowych końcowych adresów. Unikaj automatycznych linków zniekształcających zdania lub kierujących do niepowiązanych produktów. Blog może odpowiadać na pytania informacyjne i naturalnie linkować do przydatnych produktów. Dbaj, by każda strona była wystarczająco użyteczna, aby uzasadniała publikację.

Zarządzane linki kontekstowe w treściach opisuje pomoc Automatic Internal SEO Linker.

Diagnozuj stany indeksowania stron i ustal realistyczne oczekiwania

Otwórz raport Indeksowanie stron w Search Console i zbadaj adresy, które powinny być indeksowane. Duża liczba niezaindeksowanych stron nie jest automatycznie problemem: celowe duplikaty, przekierowania i strony noindex powinny pozostawać poza indeksem.

Dla ważnego adresu z problemem sprawdź zindeksowany zapis i wykonaj test wersji opublikowanej. Sprawdź status, uprawnienia robots, nagłówki lub metatagi noindex, adres kanoniczny, wyrenderowaną treść i linki wewnętrzne. Porównaj wersję bieżącą z ostatnią przetworzoną przez Google. Dla każdego statusu skorzystaj z dokumentacji raportu indeksowania stron. Prowadź niewielki rejestr adresów z zamierzoną rolą w wyszukiwaniu, bieżącą odpowiedzią, deklarowanym adresem kanonicznym, adresem wybranym przez Google, jeśli jest dostępny, ostatnim zaobserwowanym stanem i osobą odpowiedzialną. Grupuj adresy według wspólnego szablonu lub reguły, aby odróżnić pojedynczy błąd produktu od powtarzalnego błędu kategorii. Nie wyciągaj wniosków o stanie kanonicznego produktu z oczekiwanego wykluczenia adresu śledzącego.

Strony warte poprawy

Wzmacniaj przydatne strony dokładnymi informacjami i odpowiednimi linkami wewnętrznymi. Dla niemal identycznych wariantów ustal, które zasługują na osobne indeksowanie, i dopasuj treść oraz strategię kanoniczną. Zachowuj przydatną stronę produktu bez stanu z prawidłową dostępnością, jeśli klienci nadal jej potrzebują. Usuwaj faktycznie nieaktualne strony lub przekierowuj tylko do równoważnych zamienników.

Redagowana strona docelowa wyszukiwania może być przydatna, gdy ma stały temat, wybrane produkty, oryginalne porady i linki wewnętrzne. Surowe zapytanie z powtarzalnymi listami to inny typ strony. Zwykłe wyniki wyszukiwania pozostawiaj poza sitemapami, a redagowane strony publikuj świadomie.

Useful landing page: /search/walk-in-shower-trays with original advice and selected products.
Ordinary search: a raw ?s=shower result with repeated listings and no additional purpose.

Po naprawie

Utrzymuj aktualne sitemapy i linki wewnętrzne. W odpowiednich przypadkach poproś o indeksowanie ważnych zmienionych stron i o weryfikację rozwiązanego problemu w raporcie. Powtarzane zgłoszenia nie wymuszą na Google indeksowania zeskanowanej strony.

Nie ma stałego terminu poprawy SEO po zainstalowaniu modułu. Google musi ponownie przeskanować i przetworzyć zmiany, co dla różnych adresów może zajmować różny czas. Moduł nie może zagwarantować indeksowania, wyników rozszerzonych, pozycji ani odzyskania ruchu. Śledź dotknięte adresy i wyniki wyszukiwania w czasie, zamiast traktować datę instalacji jak termin realizacji.

Przypisz każdą funkcję SEO do konkretnego komponentu

Jeśli używasz więcej niż jednego narzędzia SEO, ustal komponent odpowiedzialny za linki kanoniczne, dyrektywy robots, hreflang, tagi Open Graph i każdą encję danych strukturalnych. Wiele bloków JSON-LD nie jest z założenia błędem, ale sprzeczne lub zduplikowane opisy tej samej encji wymagają uwagi.

Znana nazwa wtyczki WordPress nie potwierdza zgodności podobnie nazwanego produktu ani wtyczki innej platformy z PrestaShop. Sprawdź rzeczywisty moduł i wersję platformy, które chcesz połączyć.

1. Wypisz motyw i moduły generujące elementy SEO.
2. Wybierz jedno źródło każdej nakładającej się funkcji i wyłącz sprzeczne dane w pozostałych.
3. Sprawdź końcowy HTML i nagłówki we wszystkich ważnych typach stron, językach i domenach sklepów.
4. Ponawiaj testy po zmianach motywu, modułu SEO lub katalogu.

SEO Revolution zawiera czyszczenie sekcji head motywu, a Blog Revolution może przekazać generowanie danych strukturalnych bloga tej integracji.

Wybierz konfigurację, narzędzie, prace programistyczne lub audyt

Używaj narzędzia do powtarzalnego, jasno zdiagnozowanego wymagania. Jeden nieprawidłowy tytuł, przypadkowe noindex lub brakujące przekierowanie mogą wymagać jedynie poprawy konfiguracji lub treści. Pakiet narzędzi nie zastąpi decyzji, które adresy powinny istnieć i być indeksowane.

Sama liczba produktów w katalogu nie decyduje o drodze. Mały sklep wielojęzyczny może mieć skomplikowany błąd mapowania, a większy może już utrzymywać spójne wyniki. Przed zakupem narzędzia zapytaj, jakie powtarzalne zadanie wyeliminuje, kto utrzymuje reguły i po czym poznasz, że rozwiązało to zadanie.

Rozpoznaj, kiedy audyt SEO odpowie na konkretne pytanie

Zacznij od konkretnego objawu i dotkniętych stron. Spadek ruchu, kurczący się zbiór przydatnych zaindeksowanych stron, niedziałające przekierowania migracyjne lub utrata kwalifikacji do wyników rozszerzonych mogą uzasadniać dokładniejszą kontrolę. Korzystaj z kontroli poszczególnych adresów, by znaleźć przyczynę stojącą za daną liczbą lub oceną.

• Porównaj kliknięcia i wyświetlenia Search Console z analityką. Sprawdź zakresy dat, grupy zapytań, kraj, urządzenie i sezonowość.
• Porównaj datę zmiany z wdrożeniami, edycją adresów, zmianami robots, importami i potwierdzonymi aktualizacjami wyszukiwarki.
• Zbadaj zniknięcie przydatnej strony z indeksu. Nie uznawaj każdego oczekiwanego wykluczenia wersji alternatywnej za błąd.
• Po przebudowie wyglądu testuj linki kanoniczne, schema, nagłówki, treści i linki wewnętrzne nawet przy niezmienionych adresach.
• Sprawdzaj wolne odpowiedzi, powtarzające się błędy serwera i niedostępne zasoby obok problemów właściwych wyszukiwarce.

Niewyjaśniony spadek nie jest automatycznie usterką sklepu. Możliwe pozostają zmiany popytu w wyszukiwarce, konkurencji, pomiaru i rankingu. Potwierdzona aktualizacja wyszukiwarki też nie wyklucza równoczesnego problemu technicznego.

Używaj zweryfikowanej usługi Search Console obejmującej badane adresy sklepu. Jeśli brakuje Ci dostępu lub raport jest pusty, przed wyciągnięciem wniosków poproś właściciela o potwierdzenie usługi i jej zakresu. Brak danych w niewłaściwej usłudze nie dowodzi, że produkty nie otrzymują wizyt z wyszukiwarki.

Pierwsza samodzielna kontrola

1. Przejrzyj trendy indeksowania stron i skuteczności, a następnie sprawdź mały zestaw ważnych adresów objętych problemem.
2. Przeskanuj reprezentatywne strony i szukaj niedziałających linków, pętli, nieoczekiwanych celów kanonicznych i sprzecznych dyrektyw.
3. Sprawdź produkt, kategorię, drugą stronę listy, wariant filtra, alternatywną wersję językową i stronę główną.
4. Pobierz robots.txt i rzeczywisty indeks sitemap. Potwierdź poprawność treści i wymienionych adresów.
5. Użyj testu wyników z elementami rozszerzonymi i PageSpeed Insights dla typów stron, na których występuje objaw.

Wyszukiwanie site: może ujawnić niepożądane przykłady, ale jego liczba wyników nie jest wiarygodnym spisem indeksu. Własne ograniczenia robota skanującego też wpływają na wnioski z szybkiego skanowania.

# Read the canonical in the returned HTML
curl -sS https://example.com/42-mens-leather-wallet.html | grep -i canonical

# Check public files using their actual locations
curl -sS -o /dev/null -w '%{http_code}
' https://example.com/robots.txt
curl -sS -o /dev/null -w '%{http_code}
' https://example.com/1_index_sitemap.xml

Te polecenia działają tylko do odczytu. Tag kanoniczny może zajmować kilka wierszy lub mieć inną kolejność atrybutów, więc potwierdź pełny HTML, gdy prosta kontrola tekstowa go nie wykryje. Podążaj za nieoczekiwanym przekierowaniem i sprawdź je, zamiast traktować każdą pierwszą odpowiedź inną niż 200 jako tę samą usterkę.

Jeśli kontrola wskazuje jeden jasny problem, napraw go i zweryfikuj odpowiednie strony. Jeśli kilka systemów daje sprzeczne wyniki lub przyczyna pozostaje niejasna, audyt powinien dostarczyć adresy z problemem, odtwarzalne ustalenia, priorytety, proponowane poprawki i kroki walidacji. Uzgodnij z wykonawcą zakres, dostęp i rezultaty. Audyt diagnozuje; nie obiecuje odzyskania ruchu. Odróżniaj potwierdzony defekt od hipotezy i ograniczeń dowodów. Robot nie zgłosi strony, której nigdy nie odkrył, a jego czysty raport nie potwierdza, co Google zindeksował lub co klient otrzymuje w innym kontekście sklepu.

Prześledź kategorię tracącą wizyty z wyszukiwarki

Załóżmy, że kategoria butów do biegania w terenie traci kliknięcia z wyszukiwarki po wdrożeniu motywu, a porównywalna kategoria butów do biegania po asfalcie wydaje się stabilna. To hipotetyczna diagnoza, a nie twierdzenie, że wdrożenie zawsze wyjaśnia spadek. Zachowaj adresy z problemem i zapis wdrożenia oraz porównaj odpowiednie grupy zapytań, urządzenia i kraje w porównywalnych okresach przed wyborem poprawki.

1. Sprawdź obserwację. Potwierdź właściwą usługę Search Console i filtr strony docelowej. Porównaj wyświetlenia, kliknięcia i zapytania, a potem osobno sprawdź analitykę i rzeczywiste zamówienia. Zmiana konfiguracji zgód lub analityki może zmienić liczbę zapisanych sesji bez takiej samej zmiany kliknięć z wyszukiwarki.
2. Porównaj strony. Sprawdź kategorię z problemem i kategorię porównawczą w tym samym sklepie i języku. Sprawdź odpowiedź, nagłówki, dyrektywy robots, adres kanoniczny, widoczny nagłówek, siatkę produktów i linki z nawigacji.
3. Odtwórz błąd. Załóżmy, że kategoria z problemem zwraca normalną stronę, ale deklaruje stronę główną jako kanoniczną, podczas gdy sitemapa nadal zawiera kategorię. Zapisz ten wynik i sprawdź zindeksowany zapis; nie zakładaj, że Google już zastosował błędny sygnał.
4. Znajdź źródło. Porównaj zmianę motywu z komponentem generującym adres kanoniczny. Sprawdź ustawienia właściwe dla kategorii i nadpisania tego wyniku przez moduły. Jeśli winny jest wspólny szablon, napraw jego źródło zamiast dodawać obok kolejny znacznik kanoniczny.
5. Potwierdź poprawkę na kopii testowej. Zweryfikuj właściwy adres kanoniczny kategorii i przetestuj inne kategorie, paginację, filtry i wersje językowe korzystające z tego samego kodu. Potwierdź, że siatka produktów, linki i ścieżka zakupu nadal działają.
6. Wdróż i śledź adresy. Wdróż poprawkę w określonym zakresie, niezależnie sprawdź publiczny HTML i zachowaj czas wdrożenia przy dowodach. Zaktualizuj inne sprzeczne sygnały i śledź zapisy odpowiednich adresów w miarę ponownego skanowania przez Google.

Bezpośrednim dowodem odbioru jest poprawiony wynik i działający sklep. Późniejsze odzyskanie kliknięć to obserwacja do oceny względem popytu i innych zmian, a nie dowód wspólnej przyczyny każdej utraconej wizyty. Jeśli adres kanoniczny był już prawidłowy, zachowaj ten wynik i zbadaj kolejną prawdopodobną przyczynę zamiast mimo to stosować poprawkę z przykładu.

Uzgodnij rezultaty oceny

Poproś o ustalenia uporządkowane według wpływu biznesowego i nakładu pracy, z przykładowymi adresami, przyczyną, proponowaną poprawką i sposobem walidacji. Przegląd SEO z zewnątrz może opierać się na publicznych stronach; dostęp tylko do odczytu w Search Console dodaje dostępne dowody indeksowania i skuteczności. Każdy dodatkowy dostęp uzgodnij osobno zamiast zakładać, że audytor potrzebuje logowania do panelu administracyjnego.

Przydatny plan działania oddziela prace, które zespół może wykonać w edytorze, od konfiguracji modułów i prac programistycznych. Określ, kto wdraża, kto zatwierdza kontrole stron i kto później monitoruje wynik. Sama diagnoza nie obejmuje tych zadań, a ogólny eksport ostrzeżeń robota nie wyjaśnia, co sklep powinien zrobić najpierw.

O co zapytać programistę lub agencję

• Których ważnych handlowo adresów dotyczy problem i które porównywalne strony nadal działają?
• Jakie dowody łączą objaw z proponowaną przyczyną i co pozostaje niepewne?
• Który motyw, moduł, reguła serwera lub import generuje sporny wynik i czy zadanie harmonogramu może nadpisać poprawkę?
• Jakie sklepy, języki, waluty i konteksty klientów zostaną przetestowane, w tym strony, które mają pozostać bez zmian?
• Co dokładnie się zmieni, jak wycofamy zmianę i czy zostaną zmienione jakiekolwiek dane produktów lub zamówień?
• Kto wdroży, zachowa dowody sprzed zmiany i po niej oraz sprawdzi odpowiednie adresy po wdrożeniu?

Prowadź powtarzalny rejestr utrzymania technicznego i SEO

Zaplanuj krótki cykliczny przegląd i pełniejszą kontrolę po dużych zmianach. Półgodzinna sesja może objąć próbkę i wskazać dalsze prace, ale nie gwarantuje kompletnego audytu każdego sklepu.

Przed usunięciem podejrzyj kandydatów do czyszczenia, zachowuj odpowiednie okresy przechowywania i w razie potrzeby używaj ograniczonych partii. Stare koszyki powiązane z zamówieniami, aktywne odwołania i inne sklepy wymagają świadomej ochrony. Nie usuwaj danych zamówień lub klientów tylko dlatego, że tabela jest duża.

Proces czyszczenia z liczeniem na początku i kontrolę okresów przechowywania dla konkretnych zadań opisuje pomoc Database Cleanup.

Śledź skrypty OPcache, pamięć, trafienia i chybienia. Porównuj grupy wolnych zapytań według trasy lub kontrolera oraz zapisuj liczbę uwzględnionych i pominiętych adresów sitemapy i datę ostatniej udanej kopii. Używaj porównywalnych okresów, aby rejestr pokazywał trendy.

Diagnostykę warstw pamięci podręcznej modułów i wolnych zapytań opisuje pomoc Performance Revolution.

Najpierw usuwaj zagrożenia bezpieczeństwa i naprawiaj niedziałające funkcje zakupowe. Potem zajmij się błędami serwera i przypadkowymi blokadami indeksowania, nieprawidłowymi celami, problemami treści i danych strukturalnych oraz zmierzonymi problemami wydajności. Weryfikuj zmiany w środowisku testowym przed wdrożeniem i potem ponownie testuj ścieżki klientów i robotów objęte zmianami.

Przećwicz zmianę i zaplanuj wdrożenie

1. Zachowaj punkt odniesienia. Zapisz reprezentatywne adresy, przekierowania, HTML i nagłówki wraz ze sklepem, językiem i odpowiednią konfiguracją modułów. Uwzględnij niezmienianą stronę porównawczą i stare adresy, które nadal przyciągają klientów.
2. Przygotuj kopię. Zabezpiecz środowisko testowe kontrolą dostępu, zneutralizuj e-maile transakcyjne i rzeczywiste działania zewnętrzne oraz sprawdź zgodność istotnego motywu, modułów i stanu katalogu. Podczas testów używaj adresów kanonicznych i alternatywnych właściwych dla hosta zamiast pozostawiać adresy testowe do skopiowania do sklepu produkcyjnego.
3. Zapisz planowaną zmianę. Wymień zmieniane ustawienia, pliki, reguły lub dane o określonym zakresie oraz komponent odpowiedzialny za każdy wynik. Jeśli błąd powoduje import, przećwicz go zamiast testować tylko ręczny zapis w edytorze.
4. Przejdź ścieżki odbioru. Sprawdź odpowiednie rodziny stron i celowe wyjątki, a następnie przejdź od nawigacji do produktu, koszyka i finalizacji zakupu. Przy zmianach reguł przepisywania lub dostępu uwzględnij funkcjonalne trasy modułów i callbacki dostawców.
5. Przygotuj wycofanie. Zachowaj poprzednią odpowiednią konfigurację i pliki oraz określ objaw wyzwalający wycofanie. Przy edycji danych zachowaj wcześniejsze wartości w objętym zakresie i sprawdzoną procedurę przywracania; odtworzenie starej bazy całego sklepu może nadpisać nowe rzeczywiste zamówienia.
6. Uzgodnij wdrożenie. Wybierz termin, w którym zespół może zapewnić obsługę, wskaż osobę wdrażającą i sprawdzającą oraz uwzględnij importy, feedy i zadania pamięci podręcznej działające w tym czasie. Wdróż przetestowaną zmianę w aktualnym sklepie zamiast kopiować do niego nieaktualne dane testowe.
7. Niezależnie sprawdź środowisko produkcyjne. Po odświeżeniu pamięci podręcznych potwierdź publiczny host, przekierowania, nagłówki, adres kanoniczny, wersje językowe i objęte zmianą ścieżki klientów. Potwierdź brak przypadkowo skopiowanego testowego noindex lub blokady dostępu w sklepie, pozostawiając kopię testową zabezpieczoną.
8. Oddziel dalszą kontrolę techniczną od wyszukiwania. Natychmiast sprawdź generowany wynik i zakupy, a potem analizuj zapisy odpowiednich adresów i trendy wyszukiwania w miarę pojawiania się obserwacji. Zapisuj niezwiązane wdrożenia, aby późniejszych zmian nie przypisywać automatycznie temu jednemu.

Search Console, robot skanujący witrynę, PageSpeed Insights i Rich Results Test odpowiadają na różne pytania. Porównuj ich ustalenia z wyrenderowanymi stronami i zachowaniem serwera. Przed dalszymi zmianami SEO skorzystaj z poradnika rozwiązywania problemów przy pętlach przekierowań, błędach 404 i błędach aplikacji.

Pytania właścicieli sklepów

Czy mogę naprawić jasny problem bez płatnego audytu?

Tak. Jeśli potrafisz ustalić przyczynę i zweryfikować poprawkę, wybierz odpowiednią drogę konfiguracji, treści lub prac programistycznych. Diagnoza jest potrzebna przy niepewnej przyczynie lub zakresie, a nie tylko dlatego, że raport zawiera ostrzeżenia.

Czy więcej wykluczonych adresów oznacza pogorszenie SEO?

Sprawdź, jakie to adresy. Liczba oczekiwanych wersji alternatywnych i przekierowań może rosnąć, a przydatne strony nadal pozostawać w indeksie. Śledź strony sprzedażowe przeznaczone do indeksowania i badaj zmiany w tym zbiorze zamiast za wszelką cenę zwiększać łączną liczbę.

Czy mały sklep powinien kupić pakiet SEO, czy audyt?

Wybierz na podstawie problemu i możliwości zespołu w utrzymywaniu rozwiązania. Pojedynczy zrozumiany błąd wymaga poprawki; powtarzalne reguły mogą uzasadniać narzędzie; niewyjaśniona istotna strata może uzasadniać ocenę nawet małego katalogu.

Czy muszę usunąć identyfikatory produktów lub zmienić motyw, aby zdobywać pozycje?

Sam problem z pozycjami nie uzasadnia żadnego z tych działań. Identyfikatory nie przeszkadzają w zajmowaniu pozycji, a motyw należy oceniać po rzeczywistym wyniku i ścieżce klienta. Ustal, co nie działa, zanim zdecydujesz się na migrację adresów lub wymianę motywu.

Robot nie zgłasza błędów. Czy mogę zakończyć diagnozę?

Skanowanie ma zakres i ścieżkę odkrywania. Porównaj jego pokrycie z ważnymi stronami, Search Console i właściwym kontekstem klienta. Prawidłowa odpowiedź nie potwierdza przydatnej treści, prawidłowego indeksowania ani działającego zakupu.

Czy audyt obejmuje poprawki i bieżący monitoring?

Podlinkowana ocena dostarcza ustaleń i planu działania. Wdrożenie, pisanie treści, pozyskiwanie linków i bieżący monitoring wymagają osobnego zakresu i odpowiedzialności, więc uzgodnij przekazanie prac, zanim uznasz raport za ukończone działania naprawcze.

Skąd wiem, że poprawka zadziałała, zanim zmienią się pozycje?

Zachowaj pierwotny scenariusz odtworzenia i ponów jego kontrole odbioru w działającym sklepie. Poprawiona odpowiedź lub wygenerowany wynik to dowód dostępny bezpośrednio; widoczność w wyszukiwarce wymaga późniejszych obserwacji i nie ma gwarantowanej daty odbudowy.

Czy możemy bezpiecznie wycofać wdrożenie SEO?

Przygotuj wycofanie podczas prób. Przywróć objęte zmianą ustawienia, pliki lub wartości w określonym zakresie zgodnie z planem, chroniąc bieżące zamówienia, a następnie ponownie sprawdź sklep produkcyjny. Kopia zapasowa jest przydatna tylko wtedy, gdy wiesz, co zastąpi jej odtworzenie.