Moduły SEO i marketing dla PrestaShop, FAQ

Schema PrestaShop, nazywana też structured data, to mała dodatkowa warstwa kodu, która mówi wyszukiwarkom, co reprezentuje każdy element treści na stronie: cenę, stan magazynowy, produkt, ocenę, breadcrumb trail albo wpis FAQ. Wyszukiwarki mogą użyć tych danych do kwalifikujących się funkcji rich results, takich jak snippet ceny i dostępności produktu, gwiazdki opinii tam, gdzie są wspierane, linki breadcrumb albo prezentacja w stylu FAQ tam, gdzie wyszukiwarka nadal ją obsługuje.

Rich results same w sobie nie przesuwają strony wyżej w rankingu, ale mogą sprawić, że wynik będzie bardziej użyteczny i łatwiejszy do zaufania. Dla sklepu typy schema, które zwykle mają znaczenie, to Product, Offer, AggregateRating/Review, BreadcrumbList, Organization, WebSite, CollectionPage, Article oraz, gdy ma to sens, FAQPage.

Nasz moduł Automatic SEO Schema Rich Snippets próbuje dodawać Product, Offer, rating/review, breadcrumb, Organization, WebSite, category i CMS-page markup bez edycji szablonów. Ta sama funkcjonalność schema jest też częścią Smart SEO Revolution Suite, jeśli chcesz mieć sitemaps, canonicals i automatyzację meta tagów w jednym miejscu.

Ważne zastrzeżenie obecnego kodu: moduł wypisuje JSON-LD z hookDisplayHeader, ale clean_existing_jsonld jest domyślnie włączone, a czyszczenie finalnego wyjścia zachowuje tylko skrypty JSON-LD zawierające marker . Hook header obecnie emituje nieoznaczone JSON-LD, więc przy aktywnym czyszczeniu JSON-LD finalny HTML może usunąć schema wygenerowane przez sam moduł. Dopóki renderer nie oznaczy swoich skryptów albo logika czyszczenia nie zostanie wyłączona/naprawiona, zweryfikuj finalne źródło strony, zanim uznasz JSON-LD za pewnie obecne.

Na stronach produktów schema Product może obejmować nazwę produktu, URL, opis, SKU, identyfikatory GTIN/UPC/ISBN/MPN, dane marki z producenta/dostawcy/cechy, obrazy, stan przedmiotu, dane oferty, wagę, kategorię i dane opinii, jeśli sklep je posiada. Generator marki używa skonfigurowanego źródła katalogowego, np. producenta, dostawcy albo cechy nazwanej jak Brand, z fallbackiem do producenta; deklarowane pole override-brand nie jest używane przez obecny generator. Dane oferty mogą zawierać cenę, walutę, dostępność, sprzedawcę, szczegóły dostawy i politykę zwrotów. Dla produktów z kombinacjami implementacja może zbudować zagregowane dane oferty zamiast udawać, że każdy wariant ma jedną identyczną ofertę.

Strony kategorii są obsługiwane inaczej: renderowane są jako dane CollectionPage z nazwą kategorii, URL, opisem, obrazem, liczbą produktów i próbką produktów ItemList. Strony CMS są renderowane jako Article schema z headline, URL, opisem, treścią artykułu, liczbą słów, datami, autorem, publisher, logo, językiem i main entity URL.

Praktyczna zasada dla sprzedawcy: uzupełniaj dane źródłowe, a nie tylko włączaj schema. Jeśli produkt nie ma identyfikatora, ma słabe zdjęcia, brak stanu magazynowego, brak opinii albo pusty opis, schema może opisać tylko te słabe dane. Structured data działa najlepiej, gdy dane katalogowe są już czyste, a w obecnym module trzeba też sprawdzić, czy ustawienia czyszczenia nie usuwają JSON-LD, które chcesz publikować.

Tak. Cookie Banner obsługuje sygnały Google Consent Mode v2 dla tagów Google. Ważne jest to, że Consent Mode komunikuje stan zgody do Google; nie zatrzymuje automatycznie ładowania każdego skryptu firm trzecich na stronie.

Panel administracyjny PrestaShop, konfiguracja modułu banera cookies z ustawieniami Google Consent Mode v2. — Obsługę Google Consent Mode v2 konfiguruje się w ustawieniach modułu banera cookies.

Przy bezpieczniejszej konfiguracji default-denied moduł wysyła denied consent dla advertising i analytics storage, dopóki odwiedzający nie zaakceptuje cookies. Functional i security storage pozostają granted w domyślnym wywołaniu Consent Mode. Gdy odwiedzający zaakceptuje, banner aktualizuje stan zgody Google na granted. Gdy odwiedzający odmówi lub zamknie banner, aktualizuje te same pola zgody advertising i analytics na denied.

gtag('consent','default',{ad_storage:'denied',ad_user_data:'denied',ad_personalization:'denied',analytics_storage:'denied',functionality_storage:'granted',personalization_storage:'granted',security_storage:'granted'});
// Accept button: gtag('consent','update',{ad_storage:'granted',ad_user_data:'granted',ad_personalization:'granted',analytics_storage:'granted'});
// Deny or close: gtag('consent','update',{ad_storage:'denied',ad_user_data:'denied',ad_personalization:'denied',analytics_storage:'denied'});

Moduł zapisuje wybór odwiedzającego we własnym first-party consent cookie i dispatchuje front-endowe zdarzenie zgody. Po włączeniu GCM v2 zweryfikuj w Google Tag Assistant, że stan domyślny odpala się przed tagami Google, a zdarzenie update odpala się po Accept/Deny.

Ustawienia stojące za tym zachowaniem to GCM_ENABLED i DEFAULT_CONSENT. Po instalacji moduł włącza GCM, ustawia DEFAULT_CONSENT na denied, włącza banner, ustawia 365-dniowy czas życia zgody, używa pozycji bottom-left i zapisuje wielojęzyczny tekst bannera, accept, deny oraz policy-link. Administrator może przełączyć domyślny stan na granted, ale własna kontrola integralności modułu oznacza to jako model opt-out i ostrzega, że rynki GDPR zwykle wymagają opt-in.

Domyślne wywołanie Consent Mode jest wstrzykiwane z displayHeader, a HTML bannera jest renderowany raz z hooków stopki, natomiast frontowy JavaScript jest rejestrowany na dole. Ta kolejność ma znaczenie: domyślny stan denied lub granted jest dostępny przed późniejszymi tagami Google, a potem skrypt po stronie przeglądarki aktualizuje stan po działaniu odwiedzającego. Jeśli odwiedzający ma już cookie mprcookie_consent, banner nie jest pokazywany, a zapisana wartość jest ponownie wysyłana do Google przy ładowaniu strony.

Zapisana wartość cookie to tylko granted albo denied. Jest zapisywana jako first-party cookie o nazwie mprcookie_consent z path=/, SameSite=Lax i Secure, gdy sklep działa przez HTTPS. Wygasanie pochodzi z COOKIE_EXPIRY; kontrola integralności traktuje puste lub niedodatnie wartości jako błąd i ostrzega powyżej 730 dni.

Accept wysyła granted dla ad_storage, ad_user_data, ad_personalization i analytics_storage.
Deny, przycisk zamknięcia i kliknięcie backdropu center-modal wysyłają denied dla tych samych czterech pól.
Moduł nie aktualizuje functionality_storage, personalization_storage ani security_storage po początkowym wywołaniu domyślnym; one są granted w wywołaniu domyślnym.
Niestandardowe zdarzenie mprcookie:consent odpala się, gdy odwiedzający dokonuje nowego wyboru, z event.detail.consent zawierającym nowy stan.

document.addEventListener('mprcookie:consent', function (event) {
  if (event.detail.consent === 'granted') {
    // load or unlock your optional non-Google script here
  }
});

Praktyczna pułapka: ponieważ moduł jest celowo lekki, sam nie skanuje strony, nie kategoryzuje cookies, nie przepisuje tagów skryptów ani nie blokuje skryptów innych niż Google. Jeśli Facebook pixel, widget chat albo skrypt analityczny ładuje się przed sprawdzeniem zgody, Consent Mode nie zatrzyma tego skryptu. Podłącz te skrypty do własnych kontroli zgody albo do zdarzenia mprcookie:consent i utrzymuj aktywny tylko jeden moduł zgody cookies, ponieważ instalacja blokuje uruchamianie tego modułu razem z mprcookiesrevolution.

Do testów wyczyść mprcookie_consent, przeładuj stronę, potwierdź, że domyślne wywołanie Consent Mode pojawia się w head, a następnie kliknij Accept i Deny w osobnych testach, aby potwierdzić, że wywołanie update zmienia cztery pola advertising i analytics. Przeładuj po utworzeniu cookie, aby potwierdzić, że banner pozostaje ukryty, ale zapisany stan nadal jest wypychany do Google.

Przeczytaj pełną odpowiedź

Tak. Z Product Canonical Manager ustawiasz reguły per encja dla produktów, kategorii, producentów, dostawców i stron CMS, a moduł wpisuje noindex i nofollow do meta tagu robots strony. Ten sam moduł regeneruje tagi hreflang z aktywnych języków sklepu i dodaje x-default dla języka domyślnego, dzięki czemu każda wersja językowa wskazuje właściwe alternatywy.

Panel Product Canonical Manager pokazujący reguły canonical, noindex/nofollow i hreflang per element dla produktów, kategorii, stron CMS, producentów i dostawców — Product Canonical Manager, reguły canonical, noindex i hreflang per element, z automatycznym hreflang i usuwaniem parametrów.

To trzyma cienkie albo zduplikowane strony (filtrowane listingi, wyszukiwanie wewnętrzne, strony konta) poza indeksem Google, podczas gdy realne produkty pozostają indeksowalne, i mówi Google, który język pokazać której grupie odbiorców. Częsty błąd to dodanie noindex i canonical wskazujących w różne strony na tym samym URL; zdecyduj per strona, czy chcesz ją indeksować z canonical, czy całkowicie noindex, a nie oba sygnały w konflikcie.

Smart SEO Revolution Suite współdzieli ten sam silnik canonical, hreflang i noindex, więc te same reguły per encja są dostępne również tam.

Reguły mają priorytet i zakres sklepu. Lookup akceptuje dokładne entity ID albo entity ID 0, a reguły dokładne lub globalne dla sklepu mogą być sortowane według priorytetu. To pozwala stworzyć szeroką regułę dla wszystkich produktów, a potem nadpisać jeden ważny produkt, kategorię albo stronę CMS bez dublowania każdego ustawienia.

Tag robots jest budowany tylko z dyrektyw, które wybierzesz. Jeśli zaznaczysz noindex, moduł dodaje noindex; jeśli zaznaczysz nofollow, dodaje nofollow; jeśli nie wybierzesz żadnej z nich, nie tworzy tagu robots tylko po to, żeby był widoczny. Istniejące tagi robots są zastępowane, gdy reguła ma zastosowanie, więc unikasz dwóch sprzecznych meta tagów robots w tym samym head.

Generowanie hreflang ma sens tylko w sklepach wielojęzycznych. Moduł sprawdza aktywne języki, generuje alternatywne URL dla każdego aktywnego języka i dodaje x-default dla skonfigurowanego języka domyślnego. Usuwa też istniejące tagi hreflang przed wstawieniem własnych, co pomaga uniknąć zduplikowanych klastrów alternates, gdy i motyw, i moduł próbują kontrolować ten sam sygnał.

Używaj noindex ostrożnie z sitemapami. URL z noindex nie powinien być promowany jako indeksowalny URL sitemap, a tabele polityk SEO Suite zawierają osobne override dla index, hreflang, sitemap i schema właśnie z tego powodu. Utrzymuj sygnały spójne: strony indeksowalne dostają canonical i hreflang; strony celowo ukryte dostają noindex i zwykle powinny pozostać poza XML sitemap.

Przeczytaj pełną odpowiedź

XML sitemap to plik czytelny maszynowo, napisany dla wyszukiwarek. Lista URL wraz z metadanymi (data ostatniej modyfikacji, alternatywy hreflang, referencje obrazów) jest przesyłana do Google Search Console albo Bing Webmaster Tools. Jej zadanie to discovery: pomaganie crawlerom w znajdowaniu i priorytetyzowaniu stron, które mogłyby pominąć.

HTML sitemap to zwykła strona w sklepie, przygotowana dla ludzi. Zawiera linki do kategorii, produktów, stron CMS i producentów w czytelnej strukturze. Jej zadanie to nawigacja i linkowanie wewnętrzne, daje odwiedzającym zapasowy indeks i daje crawlerom kolejny zestaw linków do głębszych stron.

Zwykle chcesz mieć oba: XML sitemap jest tą, którą wyszukiwarki faktycznie konsumują, a HTML sitemap jest opcjonalna, ale przydatna przy dużych katalogach. Nasz Advanced SEO Sitemap Builder generuje XML sitemaps z alternatywami hreflang i wpisami obrazów, automatycznie dzieli duże katalogi przy limicie wyszukiwarek 50 000 URL na plik na indeks sitemap, a także może opublikować stronę HTML sitemap.

Sitemap builder nie jest tylko zrzutem URL. Jego opis modułu i pipeline są zbudowane wokół zweryfikowanych XML sitemaps: URL mogą być crawlowane i sprawdzane pod kątem statusu HTTP, canonical i noindex przed zapisaniem. Zapisane wiersze URL zawierają typ encji, język, sklep, status, canonical oraz metadane image/hreflang, więc finalna sitemap może bazować na URL, które przeszły weryfikację, a nie na każdym możliwym URL katalogu.

Dla wyjścia XML writer zawiera standardową przestrzeń nazw sitemap i dodaje przestrzenie nazw image oraz XHTML, gdy włączone jest wyjście image lub hreflang. Każdy URL może dostać <loc>, <lastmod>, <changefreq>, <priority>, wpisy obrazów i linki alternatywnych języków. Duże wyjście jest dzielone według skonfigurowanego maksymalnego limitu URL i rozmiaru pliku, a indeks sitemap wskazuje crawlerom wygenerowane pliki.

HTML sitemap z założenia jest inna. Używa zweryfikowanych URL dla bieżącego sklepu i języka, grupuje je według typu, np. home, product, category, CMS, manufacturer, supplier, core, hook albo custom, i renderuje jako normalną stronę. W sprawdzonym kontrolerze frontowym strona HTML sitemap jest oznaczona noindex, więc traktuj ją głównie jako stronę nawigacji użytkownika i linkowania wewnętrznego, a nie jako kolejną stronę landingową, która ma rankować.

Praktyczna konfiguracja dla sprzedawcy: włącz typy encji, które faktycznie chcesz indeksować, zostaw output image i hreflang włączony dla katalogów wielojęzycznych/obrazowych, zgłoś indeks XML sitemap w Search Console i linkuj HTML sitemap tylko tam, gdzie pomaga odwiedzającym.

Tak. Blog Revolution daje każdemu wpisowi czysty, czytelny dla słów kluczowych URL oraz techniczny markup SEO, którego szukają wyszukiwarki, więc blog nie jest ślepą uliczką dla Twojego sklepu.

Co obsługuje za Ciebie:

Friendly URLs dla wpisów, kategorii i tagów, czytelne ścieżki zamiast query string.
Meta title, meta description i canonical per wpis, więc kontrolujesz, jak każda strona wygląda w wynikach i unikasz problemów z duplicate content.
Open Graph i JSON-LD blog schema dla uporządkowanych podglądów społecznościowych i structured data (oba można wyłączyć, jeśli inny moduł już je zapewnia).
hreflang na indeksowalnych stronach bloga oraz rel=prev/next na listach stronicowanych.
RSS autodiscovery i automatyczne włączenie opublikowanych wpisów do XML sitemap.

Częsty błąd: zostawienie pustego meta description, Blog Revolution użyje excerpt jako fallbacku, ale ręcznie napisany opis wygląda lepiej w wynikach. Jeśli Twój sklep używa też naszego Smart SEO Revolution Suite, pozwól jednemu modułowi być właścicielem blog schema, aby uniknąć duplikatów.

Moduł rejestruje trasy dla indeksu bloga, kategorii, tagów, autorów, archiwów, wyszukiwania, RSS, listy autorów i pojedynczych wpisów. URL wpisów są budowane z zapisanych slugów, a nie z surowych parametrów zapytania, a kontroler wpisu przekierowuje złe slugi, URL w złym języku albo dodatkowe warianty ścieżki z powrotem do formy canonical.

Każdy wpis przechowuje własny link_rewrite, meta title, meta description, meta keywords i opcjonalny canonical. Jeśli custom canonical jest pusty, kontroler używa bieżącego wygenerowanego URL. Strony preview są oznaczone noindex, a stronicowane listy bloga mogą być oznaczone noindex od drugiej strony wzwyż, nadal wystawiając linki rel prev/next.

Dla jakości treści kontroler wpisu może przetwarzać shortcodes, normalizować przypadkowe nagłówki H1 do H2, liczyć czas czytania i budować spis treści z nagłówków H2/H3. To nie tylko kosmetyka: utrzymuje wpisy blogowe spójne z szablonem sklepu produktowego, gdzie strona ma już jeden główny H1.

Dla feedów i discovery moduł może wystawić RSS z tytułem wpisu, linkiem, GUID, treścią, datą publikacji, autorem, kategorią i image enclosure. Hook sitemap dodaje listing bloga i opublikowane strony szczegółów wpisów, w tym dane featured image, gdy są dostępne. Drafty i nieopublikowane wpisy nie trafiają do sitemap.

Wyjście schema ma też zabezpieczenie: Blog Revolution sprawdza, czy SEO Revolution jest już skonfigurowany do dostarczania blog schema, i w razie potrzeby pomija własne natywne BlogPosting JSON-LD. To właściwy wzorzec dla structured data: jeden czysty właściciel per typ schema, a nie dwa moduły emitujące konkurencyjne bloki BlogPosting.

Tak, dokładnie tak działa. Automatic SEO Images Alt Tags nie zapisuje tekstu alt do bazy danych podczas instalacji. Ustawia alt (legend) w locie, za każdym razem, gdy renderowana jest strona produktu, listingu albo kategorii, przez podpięcie się do warstwy presenter PrestaShop. Dodasz nowy obraz produktu i jest on obsłużony automatycznie, bez ponownego uruchamiania, bez zadania batch.

Szablony łączą tokeny takie jak {product_name}, {category}, {category_name}, {manufacturer}, {image_position} oraz identyfikatory produktu ({reference}, {ean13}, {isbn}, {upc}, {mpn}), z osobnym szablonem per język sklepu, aby każdy front office dostał zlokalizowany tag alt.

Jedna zasada bezpieczeństwa: domyślnie moduł nigdy nie nadpisuje tekstu alt wpisanego ręcznie, uzupełnia tylko puste pola. Możesz włączyć override, jeśli chcesz, aby każdy obraz był sterowany szablonem. Domyślna maksymalna długość to 125 znaków.

Moduł rejestruje hooki presenter dla stron produktów, listingów produktów i stron kategorii. Na stronie produktu aktualizuje obraz cover, obraz domyślny i obrazy galerii. Na listingach aktualizuje prezentowany product cover/default image oraz listę obrazów. Na stronach kategorii aktualizuje legendę obrazu kategorii. Ponieważ dzieje się to w danych prezentowanych, pozostaje kompatybilne z cache i nie wymaga skanowania ani przepisywania wyrenderowanego HTML.

Domyślne szablony są proste i bezpieczne: strony produktów używają {product_name} - {manufacturer}, listingi używają {product_name} - {category}, a strony kategorii używają {category_name}. Możesz je zmienić, aby dodać referencje albo identyfikatory, ale utrzymuj wynik czytelny. Wyszukiwarki i screen readery wolą użyteczny tekst niż upchaną listę atrybutów.

Builder czyści wygenerowany tekst alt przed zwróceniem: podstawia zmienne, usuwa HTML, dekoduje encje, zwija powtarzające się spacje i przycina separatory pozostawione przez brakujące zmienne. Następnie ucina do skonfigurowanej maksymalnej długości, możliwie na granicy słowa. To znaczy, że brak producenta nie powinien zostawić brzydkiego wiszącego szablonu, a bardzo długa nazwa produktu nie powinna wygenerować zbyt dużego atrybutu alt.

Praktyczny workflow: ustaw raz szablon produktu, szablon listingu i szablon kategorii, zostaw override wyłączony, chyba że chcesz zastąpić ręcznie napisane legendy, a potem sprawdź stronę produktu i listing w źródle przeglądarki. Przyszłe obrazy będą automatycznie stosować te same reguły, bo hook uruchamia się za każdym razem, gdy strona jest prezentowana.

Tak. Facebook Pixel pozwala definiować własne zdarzenia Meta Pixel po stronie przeglądarki z konfiguracji modułu. Moduł obsługuje reguły oparte na kliknięciach, dopasowaniach URL, kontekście kontrolera/modułu PrestaShop albo zdarzeniu DOM.

Panel administracyjny PrestaShop, strona konfiguracji modułu Meta Pixel z ustawieniami zdarzeń niestandardowych. — Niestandardowe zdarzenia w sklepie są zarządzane z konfiguracji modułu Meta Pixel.

Używaj własnej nazwy zdarzenia tylko dla czegoś, co nie jest już standardowym zdarzeniem Meta. Moduł odrzuca standardowe/zarezerwowane nazwy, takie jak Purchase, AddToCart, Search, ViewContent i InitiateCheckout. Własne nazwy muszą zaczynać się literą i używać tylko liter, cyfr albo podkreśleń, z limitem 50 znaków.

Przykład: wyślij własne zdarzenie, gdy kupujący otwiera przewodnik rozmiarów na stronie produktu.

[{"event":"SizeGuideOpen","trigger":"click","selector":"#size-guide-link, .js-size-guide","once":true,"params":{"placement":"product_page","source":"faq_example"}}]

Ta reguła wysyła fbq('trackCustom', 'SizeGuideOpen', ...), gdy kliknięty element pasuje do selektora, i dołącza parametry z payloadu reguły. Po zapisaniu przetestuj zdarzenie w Meta Pixel Helper albo Events Manager, bo selektor, którego nie ma w aktywnym motywie, nigdy się nie uruchomi.

Moduł waliduje własne reguły przed zapisem. Akceptuje zwykłą tablicę events albo opakowany format obiektu, ignoruje wyłączone reguły, wymusza pola wymagane dla danego triggera i ogranicza liczbę unikalnych nazw własnych zdarzeń do 50. Reguły kliknięcia wymagają selektora, reguły URL wymagają wartości contains, reguły kontrolera wymagają kontekstu kontrolera, a reguły DOM-event wymagają nazwy zdarzenia do nasłuchiwania.

Obsługa parametrów jest celowo defensywna. Własne parametry są sanityzowane, nieprawidłowe klucze są odrzucane, zagnieżdżenie i łączna liczba parametrów są ograniczone, a pola wrażliwe albo zarezerwowane, takie jak email, phone, IP i event ID, nie są akceptowane z custom-event params. Dzięki temu własne zdarzenia są użyteczne do śledzenia zachowania, ale pole konfiguracji nie staje się miejscem wycieku danych osobowych.

Własne zdarzenia przeglądarkowe działają tylko wtedy, gdy tracking Pixel jest aktywny. Moduł sprawdza, czy tracking jest włączony, czy istnieje numeryczny Pixel ID oraz czy reguły wykluczenia pracowników i zgody marketingowej pozwalają na tracking. Skrypt header czeka na bramkę zgody, gdy jest skonfigurowana, inicjalizuje Pixel raz, wysyła PageView i standardowe zdarzenia specyficzne dla strony, a potem podpina listenery AddToCart, wishlist i custom-event.

Nie używaj własnych zdarzeń do duplikowania standardowych zdarzeń ecommerce. Moduł ma już standardowe zdarzenia po stronie przeglądarki oraz osobną kolejkę server-side CAPI purchase z event IDs do deduplikacji. Używaj własnych zdarzeń do interakcji specyficznych dla motywu, takich jak otwarcie przewodnika rozmiarów, użycie kalkulatora finansowania, kliknięcia przycisku oferty albo kroki konfiguratora, których Meta nie modeluje już jako standardowe zdarzenie.

Przeczytaj pełną odpowiedź

Tak. Internal Linker może automatycznie wstawiać linki podczas renderowania strony, na podstawie grup linków mapujących słowa kluczowe na docelowy URL. Nie wymaga ręcznej edycji każdego opisu produktu, kategorii, CMS albo bloga i nie przepisuje zapisanego tekstu w bazie danych.

Typowa grupa linków może wyglądać tak:

Group name: Shower screen SEO
Target URL: /en/shower-screens
Keywords: shower screen, walk-in screen, glass shower panel, shower enclosure|shower partition, shower*
Page types: product, category, cms
Content zones: product description, category description, CMS content
Max links from this group: 2
Link position: first

Słowa kluczowe mogą być rozdzielone przecinkami, specyficzne dla języka i mogą używać wariantów z |. Terminy wildcard-style, takie jak shower*, są obsługiwane przez konfigurację keyword modułu.

Moduł ma też zabezpieczenia, aby wynik wyglądał naturalnie: może pomijać bieżący URL, omijać nagłówki, unikać już zalinkowanego tekstu, zapobiegać duplikatom docelowych URL i ograniczać łączną liczbę linków na stronę albo per grupa. Dzięki temu przydaje się do wzorców linkowania SEO, np. linkowania powtarzanych terminów produktowych do ważnych kategorii albo poradników bez tworzenia nadmiaru linków wewnętrznych.

Moduł działa na actionOutputHTMLBefore, więc otrzymuje finalny HTML front office i modyfikuje tylko odpowiedź wysyłaną do odwiedzającego. Pomija output spoza front office, żądania AJAX, odpowiedzi inne niż HTML i treść, która nie wygląda jak HTML. Wspólny injector wyciąga potem <body> i pracuje wewnątrz skonfigurowanych regionów treści, zostawiając <head>, skrypty i JSON-LD bez zmian.

Ustawienia domyślne są konserwatywne: max_links_per_page to 5, max_links_per_group to 3, domyślne selektory obejmują opisy produktów, bloki opisów, treść stron i treść wpisów, a domyślne dozwolone tagi to p, div, span, blockquote, li i td. Domyślna klasa generowanych linków to mpr-autolink, cele bieżącej strony są pomijane, nagłówki są wyłączone, a wiele autolinków w tym samym elemencie jest blokowanych.

Content zones ułatwiają konfigurację bardziej niż ręczne pisanie selektorów. Resolver mapuje etykiety sprzedawcy, takie jak product description, category description, CMS content, blog content, manufacturer description i supplier description, na typowe selektory motywów oraz filtruje je według typu strony. Nadal możesz nadpisać selektory CSS i tagi HTML per grupa, jeśli motyw ma nietypowy markup.

Injector liczy istniejące linki w docelowych regionach treści i zmniejsza dostępny budżet grupy, gdy strona już linkuje do tego samego docelowego URL. Obsługuje też strategie rozmieszczenia linków: first, middle, last i spread. To przydatne, gdy słowo kluczowe pojawia się wiele razy w długim poradniku, a chcesz jeden naturalny link zamiast zamiany każdego wystąpienia w anchor.

Dla docelowych URL możesz wpisać URL ręcznie albo wybrać encję PrestaShop. Formularz admina obsługuje produkty, kategorie, strony CMS, producentów i dostawców oraz potrafi rozwiązać wybraną encję do jej URL front office. Dostępne są nadpisania słów kluczowych i docelowych URL per język, więc sklep wielojęzyczny może używać lokalnego anchor text zamiast wymuszać frazy jednego języka w każdym storefront.

Tagi hreflang dobrze rozwiązują jeden konkretny problem: mówią Google, którą wersję językową albo krajową strony pokazać danemu odwiedzającemu, dzięki czemu tłumaczone strony przestają konkurować ze sobą jako prawie zduplikowana treść. Dla wielojęzycznego sklepu PrestaShop nie są opcjonalne, ale są tylko częścią pracy, a nie całością.

Ustawienia MPR Hreflang: włączenie, tag x-default, język domyślny — Ustawienia Hreflang - warianty języka i kraju dla wielojęzycznego SEO.

Hreflang nie uratuje cienkich albo maszynowych tłumaczeń, nie uzupełni stron istniejących tylko w jednym języku i nie naprawi niespójnych struktur URL między sklepami. Pod tagami nadal potrzebujesz realnej treści i czystych URL. Nasz Smart SEO Revolution Suite generuje hreflang automatycznie dla każdego aktywnego języka, dodaje poprawny x-default, uwzględnia multishop i zawiera te same referencje w XML sitemap. Jeśli te sygnały są poprawne, Google może dopasować właściwą wersję do szukającego; jakość tłumaczeń nadal zależy od Ciebie.

W SEO Suite output hreflang jest częścią hooka header. Gdy HREFLANG_ENABLED jest włączone, moduł wywołuje swój Hreflang manager i renderuje tagi <link rel='alternate' hreflang='...'> dla alternatywnych URL, które może zbudować. Jeśli istnieje więcej niż jedna alternatywa, dodaje też URL x-default. Jeśli obecna decyzja robots zawiera noindex, suite nie zwraca hreflang dla tej strony, co zapobiega wysyłaniu sprzecznych sygnałów z noindexed pages.

<!-- MPR SEO Revolution - Hreflang Tags -->
<link rel="alternate" hreflang="en-US" href="https://example.com/en/product.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product.html" data-mpr-seo="1" />

<url>
  <loc>https://example.com/en/product.html</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" />
</url>

Strona sitemap jest osobna, ale spójna. Sitemap writer może emitować wpisy xhtml:link rel='alternate', gdy znajdzie pasujące URL dla tej samej encji w innych językach. Konfiguracja sitemap ma przełącznik INCLUDE_HREFLANG, więc hreflang w header i hreflang w XML sitemap mogą być świadomie kontrolowane.

Są nadal realne ograniczenia. Hreflang działa tylko wtedy, gdy istnieje prawdziwy alternatywny URL do wskazania. Jeśli produkt istnieje po angielsku, ale francuski produkt jest brakujący, wyłączony, noindexed albo ma słabe tłumaczenie, tag nie stworzy za Ciebie dobrej francuskiej strony landingowej. Podobnie hreflang nie zastępuje tagów canonical; każda strona językowa zwykle powinna canonicalizować do siebie i potem wskazywać swoje alternatywy.

Dobra checklista wielojęzycznego SEO: utrzymuj każdy językowy URL crawlowalny, używaj self-referencing canonicals, publikuj kompletne tłumaczenia ważnych produktów i kategorii, utrzymuj spójne URL przełącznika języka, dodawaj alternatywy do XML sitemap i unikaj noindex na stronach, które mają uczestniczyć w klastrze hreflang.

Przeczytaj pełną odpowiedź

Zwykle sprowadza się to do kilku rzeczy do naprawy, a najczęstsza to brakujący albo pusty tekst alt. Google mocno opiera się na atrybucie alt i otaczającym kontekście, aby zrozumieć, co pokazuje obraz, więc obrazy bez opisowego alt rzadko pojawiają się w Image search. Przejdź przez tę listę:

Pusty albo generyczny tekst alt, największy czynnik; napraw to najpierw.
robots.txt blokuje folder obrazów. Google nie zaindeksuje tego, czego nie może pobrać.
Obrazy ładowane tylko przez lazy-loading JavaScript, którego crawler nie uruchamia (dziś rzadsze przy natywnym lazy loading).
Brak wpisów obrazów w sitemap, więc discovery jest wolniejsze.
Bardzo małe albo niskiej jakości obrazy, których Google może nie wybrać do indeksowania.

Zacznij od tekstu alt. Automatic SEO Images Alt Tags generuje go z danych katalogowych, nazwy produktu, producenta, kategorii, referencji i więcej, i może uzupełniać tylko puste legendy albo zastępować istniejące. Pamiętaj, że daje Google czysty tekst alt do odczytania; nie gwarantuje indeksowania ani pozycji.

W module domyślny szablon produktu to {product_name} - {manufacturer}, listingi używają {product_name} - {category}, kategorie używają {category_name}, a domyślna maksymalna długość to 125 znaków. Możesz dodać placeholdery, takie jak {reference}, {ean13}, {mpn} i {image_position}, aby obrazy galerii były bardziej rozróżnialne. Builder usuwa puste separatory i ucina długi tekst na granicy słowa, więc szablon typu {product_name} - {manufacturer} - {reference} pozostaje czytelny nawet wtedy, gdy brakuje jednego pola.

Moduł uzupełnia wartość legend/alt obrazu podczas prezentacji dla obrazów cover produktu, galerii produktu, obrazów listingów i obsługiwanych obrazów kategorii. Domyślnie uzupełnia puste wartości bez nadpisywania ręcznie napisanych legend; włącz zastępowanie dopiero po sprawdzeniu, że ręczny tekst alt nie jest lepszy. Po zmianie szablonów wyczyść cache i sprawdź wyrenderowane atrybuty img alt na stronie produktu i kategorii. To nie jest generator image sitemap i nie może zmusić Google do indeksowania obrazu, ale usuwa jedną z głównych przeszkód po stronie katalogu.

Ostrzeżenie o brakującym markup oznacza, że narzędzie nie znalazło typu schema albo wymaganego pola na tym URL. W Schema Revolution najpierw sprawdź, czy typ schema jest włączony dla tego typu strony, potem porównaj preview modułu z finalnym źródłem strony po wyczyszczeniu cache, a na końcu przetestuj live URL w Google's Rich Results Test albo validatorze Schema.org.

Panel administracyjny PrestaShop, strona konfiguracji modułu SEO z ustawieniami danych strukturalnych. — Ostrzeżenia Schema należy sprawdzać względem ustawień danych strukturalnych modułu SEO.

Moduł buduje JSON-LD na podstawie wykrytego typu strony. Zależnie od konfiguracji może wystawiać Organization i WebSite na homepage, BreadcrumbList na stronach wewnętrznych, Product schema na stronach produktów, CollectionPage dla kategorii i Article dla stron CMS. Product schema może zawierać nazwę, URL, opis, SKU, GTIN, MPN, markę ze skonfigurowanego źródła katalogu, obrazy, stan, oferty, dostępność, szczegóły dostawy, politykę zwrotów, oceny, opinie, wagę i dane kategorii, gdy sklep ma te dane.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example product",
  "url": "https://example.com/product.html",
  "description": "Short product description",
  "sku": "REF-123",
  "gtin13": "1234567890123",
  "offers": {
    "@type": "Offer",
    "price": "29.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Jeśli Google zgłasza brakujące pola, porównaj trzy rzeczy: preview modułu, finalne źródło HTML po wyczyszczeniu cache PrestaShop i zewnętrznych cache oraz live URL pobrany przez narzędzie testowe. Pole może być nieobecne, bo typ schema jest wyłączony, detector strony nie rozpoznaje strony zgodnie z oczekiwaniami, produkt nie ma danych źródłowych takich jak marka albo GTIN, nadal serwowany jest cached HTML albo inny motyw/moduł zmienia finalny output.

Uważaj na opcje cleanup. Mają usuwać starsze microdata i duplikaty JSON-LD, ale obecne czyszczenie JSON-LD zachowuje tylko skrypty oznaczone , podczas gdy output header modułu jest nieoznaczony. Przy włączonym clean_existing_jsonld, w tym w stanie domyślnym, cleanup może usunąć własne schema modułu z finalnego HTML. Jeśli narzędzia pokazują brak schema, wyłącz/napraw czyszczenie JSON-LD albo dodaj oczekiwany marker, zanim uznasz, że winny jest inny moduł.

W konfiguracji modułu otwórz Schema Revolution > Configuration > Schema Types. Włącz tam brakujący typ: Product Schema, Organization Schema, WebSite Schema, Breadcrumb Schema, Category Schema lub CMS Article Schema, w zależności od testowanego URL.

Jeśli schema istnieje w podglądzie, ale znika z końcowego HTML, podczas testów wyłącz Remove Existing JSON-LD w tej samej zakładce Schema Types. Ta opcja usuwa ze strony nieoznaczone skrypty application/ld+json przed wyjściem, więc jest pierwszym ustawieniem do sprawdzenia, gdy walidatory zgłaszają brak całego JSON-LD.

Przeczytaj pełną odpowiedź

Czym jest robots.txt i dlaczego ma znaczenie dla PrestaShop

Plik robots.txt znajduje się w katalogu głównym instalacji PrestaShop i stanowi pierwszy punkt komunikacji między Twoim sklepem a robotami wyszukiwarek. Informuje boty takie jak Googlebot, Bingbot i inne, które części Twojej witryny mogą indeksować, a które powinny pominąć. Chociaż nie jest to mechanizm bezpieczeństwa (nie blokuje dostępu, a jedynie doradza robotom), jest jednym z najważniejszych narzędzi do zarządzania budżetem crawlowania, liczbą stron, które wyszukiwarka przejrzy na Twojej stronie w określonym czasie.

Dla sklepów PrestaShop ma to ogromne znaczenie. Typowa instalacja PrestaShop może generować tysiące wariantów URL poprzez filtry, opcje sortowania, paginację, przełączanie walut i zapytania wyszukiwania. Jeśli pozostanie to niekontrolowane, boty wyszukiwarek zmarnują swój budżet crawlowania na te bezwartościowe strony zamiast odkrywać i indeksować Twoje rzeczywiste strony produktów i kategorii.

Jak PrestaShop generuje swój plik robots.txt

PrestaShop zawiera wbudowany generator robots.txt dostępny z poziomu Back Office. Przejdź do Parametry sklepu > Ruch i SEO i przewiń na dół, gdzie znajdziesz sekcję "Generowanie pliku robots". Kliknięcie przycisku generowania tworzy plik robots.txt w katalogu głównym Twojego sklepu.

Domyślnie wygenerowany plik zawiera zazwyczaj takie reguły -

User-agent: *
Disallow: /classes/
Disallow: /config/
Disallow: /download/
Disallow: /mails/
Disallow: /modules/
Disallow: /translations/
Disallow: /tools/
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?tag=
Disallow: /*?id_currency=
Disallow: /*?search_query=
Disallow: /*?back=
Disallow: /*?n=
Sitemap: https://twojsklep.com/sitemap.xml

Choć jest to rozsądny punkt wyjścia, jest daleki od kompletności. Wiele krytycznych wzorców URL marnujących budżet crawlowania nie jest uwzględnionych.

Co musisz blokować w PrestaShop

1. Strony koszyka, zamówienia i konta

Te strony są specyficzne dla użytkownika i nie mają żadnej wartości SEO. Powinny być zawsze blokowane -

Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account
Disallow: /*?controller=identity
Disallow: /*?controller=addresses
Disallow: /*?controller=address
Disallow: /*?controller=history
Disallow: /*?controller=order-detail
Disallow: /*?controller=password
Disallow: /*?controller=discount
Disallow: /*?controller=order-return
Disallow: /*?controller=order-follow
Disallow: /*?controller=guest-tracking
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery

2. Nawigacja fasetowa i filtry warstwowe

Nawigacja fasetowa jest największym zabójcą budżetu crawlowania dla sklepów e-commerce. Gdy klient używa filtrów takich jak kolor, rozmiar czy zakres cenowy, PrestaShop generuje unikalne URL dla każdej kombinacji. Kategoria z 5 kolorami, 4 rozmiarami i 3 zakresami cenowymi może wygenerować setki kombinacji URL, z których żadna nie powinna znajdować się w indeksie Google.

# Blokuj parametry filtrów nawigacji warstwowej
Disallow: /*?q=
Disallow: /*&q=
Disallow: /*?selected_filters=
Disallow: /*&selected_filters=
Disallow: /module/ambjolisearch/jolisearch

# Blokuj kombinacje filtrów cenowych
Disallow: /*?price=
Disallow: /*&price=

# Blokuj filtry atrybutów i cech
Disallow: /*?id_attribute_group=
Disallow: /*&id_attribute_group=
Disallow: /*?id_feature=
Disallow: /*&id_feature=

3. Wewnętrzne wyniki wyszukiwania

Strony wewnętrznych wyników wyszukiwania to cienka treść i nigdy nie powinny być indeksowane. Często tworzą niemal zduplikowane strony i są znanym źródłem problemów z jakością -

Disallow: /*?controller=search
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search
Disallow: /*?search_query=
Disallow: /*&search_query=

4. Parametry paginacji

Podczas gdy strony kategorii same w sobie powinny być dostępne do crawlowania, parametry paginacji generujące warianty sortowania/stron powinny być kontrolowane -

Disallow: /*?page=
Disallow: /*&page=
Disallow: /*?p=
Disallow: /*&p=

Ważna uwaga - Bądź ostrożny z paginacją. Jeśli zablokujesz /*?page= całkowicie, możesz uniemożliwić robotom dotarcie do produktów, które pojawiają się tylko na głębszych stronach. Lepszym podejściem jest implementacja tagów rel="canonical" kierujących paginowane strony na pierwszą stronę lub użycie sygnałów paginacji rel="next" i rel="prev".

5. Strony porównania i listy życzeń

Disallow: /*?controller=comparison
Disallow: /comparison
Disallow: /*?controller=wishlist
Disallow: /module/blockwishlist/

6. Katalogi administracyjne i systemowe

Disallow: /admin*/
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

7. Parametry śledzenia URL

Parametry kampanii marketingowych tworzą zduplikowaną treść, gdy boty crawlują otagowane URL -

Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*&utm_source=
Disallow: /*&utm_medium=
Disallow: /*&utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=
Disallow: /*?ref=

Co musisz zezwalać w PrestaShop

1. Strony produktów i kategorii

To rdzeń Twojego sklepu i muszą zawsze pozostać dostępne do crawlowania. Nie blokuj swoich głównych katalogów z treścią.

2. Pliki CSS, JavaScript i obrazy

Google musi renderować Twoje strony, aby ocenić jakość treści. Blokowanie plików CSS lub JS uniemożliwia renderowanie i może zaszkodzić rankingom -

Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

3. Strony CMS

Twoje strony prawne, strony o nas i strony content marketingowe powinny być w pełni dostępne do crawlowania. Upewnij się, że nie zostały przypadkowo przechwycone przez zbyt szerokie reguły Disallow.

4. Strony producentów i dostawców (jeśli używane)

Jeśli utrzymujesz bogate strony producentów lub dostawców z unikalną treścią, pozostaw je dostępne do crawlowania. Jeśli są to cienkie, automatycznie generowane strony, rozważ ich zablokowanie.

Obsługa robotów AI

Rozwój usług AI wprowadził nową kategorię robotów, które zbierają treści do celów treningowych. Jeśli chcesz zapobiec wykorzystywaniu Twoich opisów produktów, zdjęć i innych treści przez modele AI, możesz dodać specyficzne reguły -

# Blokuj roboty treningowe AI
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Bytespider
Disallow: /

Zauważ, że zablokowanie Google-Extended uniemożliwia Google wykorzystanie Twoich treści do treningu AI (Gemini), jednocześnie pozwalając zwykłemu Googlebotowi normalnie crawlować i indeksować Twoje strony.

Kompletny zalecany plik robots.txt dla PrestaShop

Oto kompleksowy plik robots.txt, który możesz dostosować do swojego sklepu PrestaShop -

# Główne roboty wyszukiwarek
User-agent: *

# Zezwalaj na zasoby statyczne
Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

# Blokuj katalogi systemowe
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

# Blokuj koszyk, zamówienie, konto
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery
Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account

# Blokuj filtry i sortowanie
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?n=
Disallow: /*?q=
Disallow: /*?selected_filters=
Disallow: /*?id_currency=
Disallow: /*?tag=
Disallow: /*?back=

# Blokuj wyszukiwanie
Disallow: /*?controller=search
Disallow: /*?search_query=
Disallow: /*?s=
Disallow: /search

# Blokuj parametry śledzenia
Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=

# Blokuj porównanie i listę życzeń
Disallow: /*?controller=comparison
Disallow: /comparison

# Sitemap
Sitemap: https://twojsklep.com/1_index_sitemap.xml

# Blokuj roboty treningowe AI
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Częste błędy, których należy unikać

Całkowite blokowanie katalogu modules

Domyślny plik robots.txt PrestaShop blokuje /modules/. Chociaż nie chcesz, aby pliki PHP modułów były crawlowane, wiele modułów serwuje krytyczne pliki CSS i JavaScript z tego katalogu. Całkowite zablokowanie może uniemożliwić Google prawidłowe renderowanie Twoich stron. Zamiast tego zablokuj /modules/, ale wyraźnie zezwól na podkatalogi CSS i JS, jak pokazano powyżej.

Używanie robots.txt zamiast noindex

Krytyczne nieporozumienie - robots.txt informuje boty, aby nie crawlowały URL, ale nie zapobiega indeksowaniu. Jeśli inna strona linkuje do strony, którą zablokowałeś w robots.txt, Google może ją nadal zaindeksować (wyświetlając "Opis tego wyniku nie jest dostępny ze względu na plik robots.txt tej witryny"). Dla stron, które chcesz całkowicie usunąć z wyników wyszukiwania, użyj zamiast tego meta tagu noindex lub nagłówka HTTP X-Robots-Tag.

Zapominanie o referencji do sitemapy

Zawsze umieszczaj URL swojej sitemapy na końcu pliku robots.txt. Pomaga to robotom natychmiast znaleźć Twoją sitemapę. Jeśli używasz modułu generującego wiele sitemapów, odwołaj się do pliku indeksu sitemapy.

Używanie zbyt szerokich reguł

Reguła taka jak Disallow: /*? zablokowałaby każdy URL z dowolnym parametrem zapytania, co byłoby katastrofalne. Bądź precyzyjny ze swoimi regułami i testuj je za pomocą testera robots.txt w Google Search Console przed wdrożeniem.

Testowanie konfiguracji robots.txt

Google Search Console - Użyj narzędzia do testowania robots.txt (znajdującego się w narzędziach Legacy), aby sprawdzić konkretne URL względem Twoich reguł
Testowanie ręczne - Odwiedź twojsklep.com/robots.txt bezpośrednio w przeglądarce, aby sprawdzić, czy plik jest dostępny i poprawnie sformatowany
Raport pokrycia - Po wdrożeniu zmian monitoruj raport pokrycia w Google Search Console pod kątem nieoczekiwanych wzrostów stron "Wykluczone"
Analiza plików logów - Sprawdź logi serwera, aby potwierdzić, że boty rzeczywiście respektują Twoje reguły i nie marnują budżetu crawlowania na zablokowane URL

Kwestie multisklepu

Jeśli prowadzisz konfigurację multisklepu PrestaShop, każdy sklep (domena) potrzebuje własnego pliku robots.txt w swoim katalogu głównym. Generator PrestaShop tworzy reguły dla wszystkich sklepów w jednym pliku, ale jeśli Twoje sklepy znajdują się na różnych domenach, musisz je odpowiednio rozdzielić. Plik robots.txt każdego sklepu powinien odwoływać się do własnej sitemapy i mieć reguły odpowiednie dla jego struktury URL.

Kiedy regenerować robots.txt

Powinieneś regenerować lub aktualizować swój plik robots.txt zawsze, gdy -

Dodajesz nowe moduły tworzące publicznie dostępne URL (moduły wyszukiwania, moduły filtrów)
Zmieniasz strukturę URL lub włączasz/wyłączasz przyjazne URL
Zmieniasz szablon (różne szablony mogą serwować zasoby z różnych ścieżek)
Dodajesz lub usuwasz języki (co zmienia prefiksy URL)
Włączasz lub wyłączasz funkcję multisklepu
Zauważasz nietypowe wzorce crawlowania w logach serwera lub Google Search Console

Pamiętaj - zawsze rób kopię zapasową działającego pliku robots.txt przed regeneracją. Generator PrestaShop całkowicie nadpisuje plik, a wszystkie ręcznie dodane niestandardowe reguły zostaną utracone, chyba że dodasz je ponownie po wygenerowaniu.

Jeśli wolisz nie edytować reguł ręcznie przy każdej zmianie katalogu, Advanced SEO Sitemap Builder utrzymuje mapę witryny w synchronizacji i daje robotom czytelną mapę adresów URL, które chcesz zaindeksować.

"Crawled. Currently not indexed" oznacza, że Google pobrało stronę i zdecydowało jej nie indeksować. Prawie zawsze jest to ocena jakości albo priorytetu, a nie błąd techniczny. W sklepach PrestaShop typowe przyczyny to:

Cienka albo zduplikowana treść, strony produktów z samą kopią producenta albo prawie identyczne strony wariantów. To największa przyczyna; daj każdej stronie unikalny, użyteczny tekst.
Słabe linkowanie wewnętrzne, strony ukryte głęboko i z małą liczbą linków wyglądają na nieważne. Linkuj powiązane produkty i linkuj z treści CMS/blog.
Marnowany crawl budget na URL filtrów, wyszukiwania i parametrów sesji, zostawiający mało uwagi dla realnych stron.
Długotrwale niedostępne produkty, zostaw stronę live z OutOfStock schema albo przekieruj 301 produkty wycofane do najbliższej alternatywy.
Problemy canonical / response, złe canonicals, łańcuchy przekierowań albo soft 404. Zweryfikuj w URL Inspection tool.

Najpierw napraw treść i linkowanie, potem poproś o ponowne indeksowanie priorytetowych URL. Narzędzia takie jak nasz Smart SEO Revolution Suite pomagają z canonicals, structured data i sitemaps, aby Google widziało czyste sygnały.

Weryfikacja sitemap w SEO Revolution działa według tej samej idei, zanim URL trafią do XML. Pomija URL zwracające odpowiedzi non-200, przekierowujące do innego finalnego URL, zawierające noindex w nagłówkach albo meta tagach albo deklarujące canonical niepasujący do żądanego URL. Błędy serwera zostają pending do ponownej próby zamiast być publikowane jako zdrowe URL.

To ważne, bo wciskanie złych URL do sitemap może pogorszyć ten status w Search Console. Jeśli strona jest duplikatem filtrowanym, cienką stroną wyszukiwania wewnętrznego albo canonicalized duplicate, właściwą naprawą jest zwykle trzymanie jej poza sitemap i wzmocnienie canonical target zamiast wielokrotnego proszenia o indeksowanie.

Dla search-result landing pages Search Revolution jest domyślnie konserwatywny: zwykłe strony wyszukiwania wystawiają noindex, follow, a generowane SEO search pages startują jako inactive i non-indexable. Tylko curated search pages z unikalną treścią i realnym celem merchandisingowym powinny być indeksowalne i trafiać do sitemaps.

Good candidate: curated /search/walk-in-shower-trays with unique copy, products and internal links.
Poor candidate: raw ?s=shower query page with duplicate listings and no unique content.

Feed produktowy to ustrukturyzowany plik (XML, CSV lub JSON) z danymi każdego produktu, który platformy takie jak Google Shopping i Meta (Facebook/Instagram) wczytują, aby pokazać Twoje artykuły. Poprawny feed sprawia, że produkty są zatwierdzane, a nie odrzucane.

Panel administracyjny PrestaShop, strona konfiguracji modułu Product Feeds z widocznymi kanałami feedów. — Ustawienia feedów produktowych sterują eksportami do Google Shopping, Facebook Catalog i innych kanałów.

Czego wymagają platformy

Kluczowe atrybuty oczekiwane przez Google i Meta: id, title, description, link, image_link, price (z walutą), availability, brand oraz identyfikatory produktu, gtin (EAN-13/UPC) lub mpn, gdy GTIN istnieje. Dla Google przypisujesz każdą kategorię PrestaShop do google_product_category.

<item>
  <g:id>123-45</g:id>
  <g:item_group_id>123</g:item_group_id>
  <g:title>Example Product - Blue / M</g:title>
  <g:link>https://example.com/product.html</g:link>
  <g:image_link>https://example.com/img/p/1/2/3/123-large_default.jpg</g:image_link>
  <g:availability>in_stock</g:availability>
  <g:price>29.99 EUR</g:price>
  <g:brand>Example Brand</g:brand>
  <g:gtin>1234567890123</g:gtin>
  <g:mpn>REF-123-BLU-M</g:mpn>
</item>

Konfiguracja feedu Google Shopping w PrestaShop

Załóż konto Google Merchant Center i zweryfikuj/zgłoś domenę sklepu. Konto Google Ads jest potrzebne tylko do płatnych kampanii Shopping, nie do darmowych wizytówek.
Wygeneruj feed. Oficjalny moduł PrestaShop "Google & YouTube" łączy się z Merchant Center przez OAuth i mapuje atrybuty. Moduły feedów firm trzecich dodają własne mapowanie atrybutów, filtrowanie po kategorii/stanie i planowaną regenerację (cron). Dla pełnej kontroli możesz też generować własny feed XML i odświeżać go cronem.
Zmapuj atrybuty i wybierz produkty (wyklucz po kategorii, stanie lub cenie), a potem ustaw harmonogram regeneracji.

Katalog Facebook / Instagram

W Meta Commerce Manager utwórz katalog e-commerce, wybierz „Feed danych" i wskaż zaplanowany URL feedu na Twój feed PrestaShop. Pola wymagane przez Meta odpowiadają tym z Google. Dla reklam dynamicznych potrzebujesz też Meta Pixel wysyłającego ViewContent, AddToCart i Purchase.

Unikanie typowych odrzuceń

Brak identyfikatorów, uzupełnij EAN-13 i producenta przy każdym produkcie; bez realnego GTIN ustaw identifier_exists na false.
Rozbieżność cen, cena w feedzie (netto/brutto, zła waluta lub nieaktualna po promocji) musi zgadzać się ze stroną produktu; regeneruj odpowiednio często.
Odrzucenie zdjęć, bez znaków wodnych i tekstu promocyjnego, produkt wypełnia kadr, rozsądna rozdzielczość.

Warianty

Prześlij każdą kombinację PrestaShop jako osobny element z unikalnym id, zgrupowany wspólnym item_group_id, wraz z konkretnym color/size i ceną tego wariantu.

Zobacz Smart Google Merchant Feed Manager.

Przeczytaj pełną odpowiedź

Automatic SEO Schema Rich Snippets generuje JSON-LD per typ strony, używając danych, które PrestaShop faktycznie posiada, a każdy typ ma własny przełącznik on/off, więc decydujesz, co emituje dana strona:

Product na stronach produktów - nazwa, obraz, SKU/reference, marka, GTIN, plus Offer z ceną, walutą i dostępnością oraz rating/review, gdy dane istnieją.
Organization i WebSite na homepage.
BreadcrumbList na stronach wewnętrznych.
Category na stronach kategorii i markup CMS na stronach CMS.

Product schema jest najgłębszą częścią: może zawierać reference jako SKU, identyfikatory EAN/UPC/ISBN, supplier reference jako MPN, obrazy produktu do skonfigurowanego limitu, markę z producenta/dostawcy/cechy, item condition oraz offer availability jako InStock, BackOrder albo OutOfStock. Gdy kombinacje są włączone, warianty produktów mogą być reprezentowane jako offers, a pola shipping/return policy są dodawane, gdy te ustawienia są włączone.

Output homepage jest celowo ograniczony do Organization i WebSite schema, w tym WebSite search action. Strony kategorii są emitowane jako collection-style page z opisem, obrazem kategorii, liczbą produktów i krótką listą item list. Strony CMS są emitowane jako article-style content z headline, description/content, word count, dates, author/publisher organization i language.

Cleanup jest częścią pracy modułu. Przy domyślnie włączonych ustawieniach cleanup usuwa microdata motywu albo rdzenia oraz istniejące JSON-LD przed wstrzyknięciem własnego JSON-LD, aby narzędzia testowe widziały jedno spójne źródło zamiast zduplikowanego product albo breadcrumb markup. Wygenerowane skrypty są dodawane w head strony jako application/ld+json.

Jedno praktyczne ograniczenie: istnieje zapisany klucz konfiguracji enable_faq, ale obecny kod renderera nie wypisuje FAQ schema. Traktuj aktywny zestaw wyjścia jako product, organization, website, breadcrumb, category i CMS/article schema, chyba że kod modułu zostanie rozszerzony.

Ekran preview pozwala obejrzeć dokładne JSON-LD, zanim Google ponownie crawluje stronę, a krok cleanup usuwa duplikaty microdata albo JSON-LD pozostawione przez motyw, aby narzędzia widziały jedną czystą kopię. Poprawny markup kwalifikuje strony do rich results; Google nadal decyduje, czy je pokazać. Zobacz Automatic SEO Schema Rich Snippets.

Advanced SEO Sitemap Builder nie tylko listuje katalog - sprawdza każdy URL, zanim uzna go za gotowy do sitemap. Podczas generowania wysyła żądanie do każdego kandydującego URL i czyta trzy rzeczy: HTTP status, każdy sygnał noindex (robots meta albo X-Robots-Tag header) oraz cel canonical strony. URL zwracające non-200 (redirects, 404s), niosące noindex albo wskazujące canonical na inny adres są pomijane zamiast zgłaszane.

Flow weryfikacji jest ostrożniejszy niż prosty crawl. Najpierw używa HEAD, pomija URL, które już tam zawodzą, a potem wykonuje GET dla pozostałych odpowiedzi 200, aby sparsować head strony pod canonical i robots meta. Redirects są śledzone do skonfigurowanego limitu, request timeout ma minimalny bezpieczny próg, a concurrency jest ograniczone do trzech żądań, aby generowanie nie młóciło sklepu.

Każde pominięcie jest zapisywane do logu z powodem i kodem HTTP, więc widzisz, dlaczego URL został pominięty. Duże katalogi są dzielone na wiele plików z indeksem sitemap (do 50 000 URL na plik), a wpisy obrazów i alternatywy hreflang możesz włączyć, gdy sklep ich potrzebuje.

Moduł przechowuje stan kandydujących URL we własnej tabeli URL: pending, verified, skipped albo error, z polami skip reason, HTTP code, canonical URL, noindex flag, image URLs i verification date. Jeśli weryfikacja URL jest wyłączona, pending URLs mogą zostać oznaczone jako verified bezpośrednio; jeśli jest włączona, do sitemap trafiają tylko URL, które przejdą kontrole. Zmiany produktów, kategorii i CMS oznaczają pasujące URL jako pending ponownie, więc zmienione strony są sprawdzane przy następnym generowaniu.

Writer unika też częstego błędu operacyjnego: najpierw zapisuje do plików tymczasowych, a potem podmienia pliki live sitemap. Jeśli nie ma zweryfikowanych URL, nie nadpisuje istniejącej działającej sitemap pustą. Pliki sitemap są dzielone według liczby URL i rozmiaru, a plik indeksu jest używany, gdy istnieje wiele plików językowych albo split files.

Dlaczego to ważne: czysta sitemap oznacza, że wskazujesz Google tylko strony, które faktycznie chcesz indeksować, i łapiesz problemy URL tutaj, zamiast czekać tygodniami, aż Search Console je pokaże. Częsty błąd, któremu to zapobiega, to wysłanie sitemap pełnej przekierowanych albo noindexed URL, które po cichu marnują crawl budget.

Tak. Smart SEO Friendly URL Manager usuwa domyślne numeryczne ID z URL produktów, kategorii, CMS, producentów i dostawców oraz routuje stare ścieżki przez przekierowania 301, dzięki czemu istniejące linki przychodzące i zakładki nadal działają.

Bezpieczeństwo wynika z czterech wbudowanych mechanizmów. Collision handling zapobiega temu, aby dwie encje kończyły z tym samym finalnym URL, dodając suffix w razie potrzeby zamiast pozwolić duplikatowi nadpisać cache. Tabela historii URL zapisuje każdy stary URL z hit counter, więc widzisz, które legacy paths nadal dostają ruch, zanim je wycofasz. Manual override pozwala przypiąć konkretny URL poza wzorcem - przydatne dla ważnych stron, których nie chcesz auto-regenerować. A kod przekierowania jest konfigurowalny (301, 302, 307 albo 410 Gone), więc możesz wysłać właściwy sygnał per migracja.

System wzorców URL jest konfigurowalny per encja. URL produktów mogą używać placeholderów takich jak {name}, {category}, {categories}, {brand}, {reference}, {ean13}, {supplier} i {rewrite}. URL kategorii, CMS, producentów i dostawców mają własne zestawy placeholderów. Domyślny wzorzec jest konserwatywny: {rewrite}, lowercase enabled, accent removal enabled, special-character cleanup enabled i brak suffix.

Gdy wygenerowany URL koliduje z innym cached URL albo manual override, moduł może dodać suffix oparty na entity ID, reference/SKU, EAN13 albo liczbie inkrementowanej. To bezpieczniejsze niż blokowanie zapisu produktu, bo produkt nadal może być routowany, a duplikat jest widoczny w workflow regeneracji.

Historia przekierowań powstaje, gdy zmieniają się link rewrites, a akcje delete albo disable mogą przekierować do rodzica, homepage albo zwrócić 410 Gone, zależnie od ustawienia per encja. Router obsługuje też exact cache matches, manual overrides, history redirects, pattern matches i legacy ID-prefix redirects, zachowując query strings przy przekierowaniach.

Uruchom bulk regenerate najpierw z preview, przejrzyj proponowane zmiany i ponownie sprawdź topowe URL w Search Console przed zastosowaniem. Jeśli mprseorevolution jest zainstalowany i włączony, ten moduł jest zaprojektowany tak, aby domyślnie ustąpić mu miejsca, żeby dwa SEO URL routers nie walczyły o to samo żądanie.

Tak. Filter Revolution renderuje filtrowane strony kategorii z czystymi, czytelnymi URL, takimi jak /category/color:blue/size:l, zamiast surowych parametrów query-string, więc wybrane kombinacje filtrów mogą być wystawione jako crawlowalne, indeksowalne strony landingowe. Gdy włączony jest compact URL mode, a slug wartości jest globalnie unikalny, moduł może skrócić ścieżkę jeszcze bardziej, pomijając slug grupy.

Oddziela szybkie przeglądanie od indeksowalnego SEO. Kupujący dostają AJAX faceted navigation aktualizującą wyniki bez przeładowania strony - suwaki cen, swatche kolorów, chipsy rozmiarów, multi-select marek i hierarchiczne drzewa kategorii. Dla kombinacji wartych indeksowania przypinasz konkretny zestaw faceted, nadajesz mu czysty URL slug i piszesz własny title, meta description oraz H1, więc tylko strony wysokiej wartości trafiają do indeksu.

Tabela SEO page przechowuje controller, category ID, encoded facet path, normalized facet hash, active/indexable flags, meta title, meta description, URL segment, H1, top and bottom descriptions oraz opcjonalny image URL. Dopasowanie jest niezależne od kolejności, bo części facet są normalizowane przed porównaniem hasha, więc size:l/color:blue i color:blue/size:l rozwiązują się do tego samego celu SEO.

Dla zwykłych filtrowanych stron, które nie mają custom SEO page, ustawienia SEO decydują, czy są noindexed i czy canonical wskazuje z powrotem na niefiltrowany listing. Deep facet links mogą być oznaczone nofollow, a blokowanie ścieżek robots.txt jest dostępne, ale domyślnie wyłączone, aby wyszukiwarki nadal mogły crawlowac filtrowany URL i zobaczyć sygnał noindex/canonical.

Kombinacje facetów z zerową liczbą produktów mogą być ukryte albo wyszarzone, co trzyma cienkie i puste strony poza crawlem. Precomputed facet index utrzymuje stabilne czasy odpowiedzi na dużych katalogach, z tabelami product, category, attribute, feature i aggregate używanymi do szybkiego filtrowania. Moduł ogranicza też wartości products-per-page i obsługuje kontrolery listingów category, search, manufacturer, supplier, best-sales, new-products i prices-drop. Moduł działa na PrestaShop 1.7.6 i bieżących wersjach.

Tak. Moduł Facebook Pixel wstrzymuje tracking, dopóki odwiedzający nie udzieli zgody marketingowej, więc możesz uruchomić Pixel bez odpalania go przed zgodą.

Ustawienie Respect cookie consent w Facebook Pixel — Ustawienia Facebook Pixel - opcja Respect cookie consent.

Włącz ustawienie Respect cookie consent, a moduł sprawdzi baner zgody przed odpaleniem jakiegokolwiek zdarzenia. Czyta zgodę z naszych modułów Cookies Revolution albo Cookie Banner - zarówno browser pixel, jak i page-load events pozostają wstrzymane, dopóki kategoria marketingowa nie zostanie granted, a potem działają normalnie.

Skrypt przeglądarkowy używa client-side consent gate, gdy aktywny jest obsługiwany moduł zgody. Sprawdza window.MPRCR.isGranted('marketing'), gdy jest dostępne, wraca do cookie mprcr_consent dla Cookies Revolution, a potem do mprcookie_consent dla lightweight banner. Nasłuchuje też mprcr:consent i mprcookie:consent, więc odwiedzający, który zaakceptuje marketing cookies, może rozpocząć tracking bez pełnego przeładowania strony.

Uczciwe ograniczenie: ta bramka działa z obsługiwanym modułem zgody. Jeśli zgoda nie została udzielona (albo odmówiona) przez Cookies Revolution albo Cookie Banner, moduł wraca do domyślnego stanu zgody banera; a jeśli żaden obsługiwany moduł zgody nie jest aktywny, Pixel trackuje jak zwykle - nie tworzy własnej warstwy zgody. Połącz go więc z banerem, jeśli Twój sklep potrzebuje bramki zgody GDPR.

Ten sam consent check obejmuje server-side event Conversions API Purchase, więc wstrzymany odwiedzający nie jest śledzony tylnymi drzwiami. CAPI kolejkuje tylko wtedy, gdy Pixel ID, access token i purchase tracking są skonfigurowane, i używa tego samego wygenerowanego event ID co browser purchase, aby Meta mogła deduplikować zdarzenia przeglądarkowe i serwerowe.

Moduł ma też praktyczne zabezpieczenia: Pixel ID musi być numeryczny, pracownicy mogą być wykluczeni z front-office tracking, standardowe zdarzenia można przełączać pojedynczo, a własne zdarzenia przeglądarkowe są ograniczone i walidowane, aby nie duplikowały zarezerwowanych nazw zdarzeń Meta.

Przeczytaj pełną odpowiedź

Tak. Moduł GA4 śledzi standardowe zdarzenia ecommerce, w tym product views, add to cart, remove from cart, cart view, checkout start i purchase. Obsługuje też prostsze non-ecommerce events, takie jak search, login i sign up, plus custom browser events skonfigurowane regułami.

Zdarzenie purchase wysyłane do GA4 używa standardowego wzorca ecommerce payload:

window.dataLayer.push({ 'ecommerce': null });
gtag('event', 'purchase', {
  transaction_id: 'PS-100012',
  value: 129.90,
  currency: 'EUR',
  items: [{
    item_id: '42-5',
    item_name: 'Shower tray 120x90',
    item_category: 'Shower trays',
    price: 64.95,
    quantity: 2
  }]
});

Moduł buduje payload ecommerce server-side, przypisuje go do szablonu hooka, czyści poprzedni obiekt ecommerce w data layer, a potem odpala event GA4. Dla potwierdzeń zamówienia może też kolejkować fallback purchase przez Measurement Protocol, gdy Measurement ID i API Secret są skonfigurowane, co pomaga zachować tracking purchase, gdy zdarzenie przeglądarkowe zostanie zablokowane albo przerwane.

Dokładne hooki są podzielone według etapu ścieżki: strony produktów emitują view_item, strony koszyka emitują view_cart, zmiany ilości w koszyku mogą emitować add_to_cart albo remove_from_cart, kroki carrier/checkout emitują begin_checkout, a potwierdzenie zamówienia emituje purchase. Login i registration są zapisywane jako jednorazowe pending browser events, a potem konsumowane przy następnym ładowaniu strony.

Tracking działa tylko wtedy, gdy moduł jest włączony i istnieje poprawny GA4 Measurement ID, np. G-XXXXXXXXXX. Pomija non-front-office requests, znane boty, odwiedzających z cookie mpr_notrack=1 i zalogowanych pracowników, gdy employee exclusion jest włączone. Opcjonalny user ID tracking hashuje PrestaShop customer ID z solą per sklep przed wysłaniem do GA4.

Obsługa zgody też jest celowa. Jeśli Cookies Revolution jest zainstalowany, moduł ustawia swój hook header po CMP, aby domyślne Consent Mode istniało przed gtag('config'). Jeśli CMP nie ma, emituje fallbackowy blok domyślny Consent Mode z analytics i ad storage denied, więc strona nadal ma jasną bazę.

Dla najlepszych raportów upewnij się, że motyw nadal renderuje odpowiednie hooki product, cart, checkout i order-confirmation, oraz przetestuj zdarzenia w GA4 DebugView albo Tag Assistant po instalacji modułu. Jeśli włączysz Measurement Protocol purchases, dodaj poprawny API Secret i utrzymuj wspólnego workera cron, aby zakolejkowane zdarzenia mogły być ponawiane.

Moduł Google Tag Manager dla PrestaShop wypycha zdarzenia ecommerce w formacie GA4 do dataLayer, dzięki czemu tagi w Twoim kontenerze GTM mogą czytać ustrukturyzowane dane sklepu bez edycji szablonów motywu.

Panel administracyjny PrestaShop, strona konfiguracji modułu Google Tag Manager pokazująca ustawienia dataLayer. — Konfiguracja modułu GTM pokazuje, jakie informacje dataLayer są wysyłane ze sklepu.

Moduł emituje przeglądarkowe zdarzenia ecommerce, w tym view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout i purchase. Obsługuje też proste zdarzenia nie-ecommerce, takie jak wyszukiwanie, logowanie i rejestracja, plus konfigurowalne niestandardowe reguły dataLayer. Przed każdym zdarzeniem ecommerce wypycha {ecommerce: null}, czyli bezpieczny dla GA4 wzorzec resetu.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({'ecommerce': null});
window.dataLayer.push({
  'event': 'purchase',
  'ecommerce': {
    'transaction_id': 'ABCDXYZ',
    'affiliation': 'Example Shop',
    'value': 129.90,
    'tax': 21.65,
    'shipping': 4.90,
    'currency': 'EUR',
    'coupon': 'WELCOME10',
    'items': [{
      'item_id': '42',
      'item_name': 'Premium Shower Tray',
      'item_brand': 'Example Brand',
      'item_category': 'Bathroom',
      'item_variant': '90x90',
      'price': 125.00,
      'quantity': 1
    }]
  }
});

Skrypt kontenera GTM jest wstrzykiwany w nagłówku strony, a iframe noscript jest wstrzykiwany po otwierającym tagu body, gdy motyw udostępnia ten hook. Obsługa Consent Mode jest zaprojektowana do współpracy z mprcookiesrevolution: gdy ten CMP jest zainstalowany, moduł przesuwa swój hook header za CMP; gdy CMP nie ma, może wyemitować domyślny fallback Consent Mode v2 z odmową przed załadowaniem GTM.

Tracking jest pomijany dla żądań innych niż front, znanych botów, zalogowanych pracowników, gdy ta opcja jest włączona, oraz odwiedzających z cookie opt-out mpr_notrack=1. Opcjonalny fallback server-side Measurement Protocol wysyła dane zakupu przy actionValidateOrder, gdy skonfigurowane są poprawne GA4 Measurement ID i API Secret; GA4 deduplikuje po transaction_id.

Przeczytaj pełną odpowiedź

SEO i Marketing

SEO i Marketing

Pytania

Czym jest robots.txt i dlaczego ma znaczenie dla PrestaShop

Jak PrestaShop generuje swój plik robots.txt

Co musisz blokować w PrestaShop

1. Strony koszyka, zamówienia i konta

2. Nawigacja fasetowa i filtry warstwowe

3. Wewnętrzne wyniki wyszukiwania

4. Parametry paginacji

5. Strony porównania i listy życzeń

6. Katalogi administracyjne i systemowe

7. Parametry śledzenia URL

Co musisz zezwalać w PrestaShop

1. Strony produktów i kategorii

2. Pliki CSS, JavaScript i obrazy

3. Strony CMS

4. Strony producentów i dostawców (jeśli używane)

Obsługa robotów AI

Kompletny zalecany plik robots.txt dla PrestaShop

Częste błędy, których należy unikać

Całkowite blokowanie katalogu modules

Używanie robots.txt zamiast noindex

Zapominanie o referencji do sitemapy

Używanie zbyt szerokich reguł

Testowanie konfiguracji robots.txt

Kwestie multisklepu

Kiedy regenerować robots.txt

Co mówi każdy wynik

Dane laboratoryjne a terenowe

Szybkie zyski w PrestaShop

Czego wymagają platformy

Konfiguracja feedu Google Shopping w PrestaShop

Katalog Facebook / Instagram

Unikanie typowych odrzuceń

Warianty

Inne kategorie

Masz jeszcze pytania?

Cookie	Dostawca	Cel	Czas
PrestaShop-*	PrestaShop	Zarządzanie sesją i funkcjonalność koszyka	Sesja
PHPSESSID	PHP	Identyfikator sesji PHP	Sesja
mprcr_consent	MPR Cookies Revolution	Przechowuje preferencje zgody na pliki cookie	365 dzień/dni
mprcr_version	MPR Cookies Revolution	Śledzi wersję konfiguracji zgody	365 dzień/dni

Cookie	Dostawca	Cel	Czas
TawkConnectionTime	Tawk.to	Śledzi czas połączenia sesji czatu	Sesja
__tawkuuid	Tawk.to	Identyfikuje powracających odwiedzających czat	6 miesiąc/e

Cookie	Dostawca	Cel	Czas
_ga	Google Analytics	Rozróżnia unikalnych użytkowników za pomocą losowo wygenerowanego numeru	2 rok/lata
_ga_*	Google Analytics	Używany do utrzymania stanu sesji między żądaniami stron	2 rok/lata
_gid	Google Analytics	Rozróżnia unikalnych użytkowników przez 24 godziny	24 godzina/y