PrestaShop 9.2: zmiany danych strukturalnych i tras wielojęzycznych
Aktualizacja motywu i aktualizacja rdzenia mogą osobno tworzyć pozornie prawidłowe dane strukturalne, podczas gdy wynikowa strona opisuje ten sam produkt dwukrotnie, podając sprzeczne wartości. Właśnie takich problemów integracji warto szukać w PrestaShop 9.2.
Zmiany w wersji 9.2 obejmują prace nad danymi strukturalnymi po stronie rdzenia, późniejsze dopracowanie obsługi nieprawidłowych adresów URL produktów i kategorii oraz wielojęzyczną konfigurację tras encji. To konkretne zmiany renderowania i routingu. Nie dowodzą poprawy pozycji w wyszukiwarkach, a ten artykuł nie powiela ogólnej listy kontrolnej SEO. Zmiana danych strukturalnych w rdzeniu, późniejsze dopracowanie, trasy wielojęzyczne.
Wykonaj poniższe kontrole w wersji kandydującej 9.2 RC1 dostępnej według stanu na 26 września 2026 r., zapisując dokładne wersje motywu i modułów SEO.
W instalacji wielosklepowej połącz ten audyt renderowania z kontrolami wielosklepowości w PrestaShop 9.2 aby prawidłowy adres URL był również oceniany w kontekście właściwego sklepu.
Przenieś granicę audytu z fragmentów szablonów na wynik końcowy
Kierunek rozwoju danych strukturalnych po stronie rdzenia pozwala przygotowywać dane w kodzie aplikacji i renderować je przez motyw. Zmienia to miejsca, w których rozszerzenie może wnosić dane i w których może dojść do podwójnej odpowiedzialności. Oficjalny przykład demoseo jest przydatnym odniesieniem źródłowym dla nowego kierunku integracji. Oficjalny przykład danych strukturalnych.
Zacznij od spisania wszystkich komponentów mogących emitować dane produktu lub organizacji: rdzenia, motywu, nadpisań motywu potomnego i modułów. Ustal właściciela każdego pola lub reprezentacji encji. Nie zakładaj, że moduł przestał emitować znaczniki tylko dlatego, że rdzeń zyskał nową funkcję.
Następnie sprawdź wyrenderowaną stronę. Sam przegląd kodu źródłowego nie dowodzi końcowego wyniku, ponieważ może na niego wpływać wiele hooków i szablonów. Z kolei sam wynik walidatora może nie wyjaśnić, który komponent wyemitował nieprawidłową wartość.
Najpierw wybierz zwykły produkt testowy. Zarejestruj odpowiedź strony i przeanalizuj każdy blok JSON-LD. Porównaj identyfikatory, nazwy, adresy URL i wartości handlowe z widoczną stroną. Użyj wyrenderowanego wyniku jako dowodu akceptacji, a wykazu źródeł jako wyjaśnienia odpowiedzialności za dane.
Wykryj sprzeczne opisy, zanim dodasz więcej znaczników
Wiele bloków danych strukturalnych nie jest samo w sobie błędem. Problemem są sprzeczne lub niepowiązane opisy tej samej encji. Motyw i moduł mogą niezależnie emitować produkt z różnymi cenami, dostępnością lub identyfikatorami.
Dla każdej reprezentacji produktu ustal, czy odnosi się do tej samej encji i czy jej wartości są zgodne. Jeśli dwa komponenty odpowiadają za ten sam fakt, zdecyduj, który ma być wiążący. Nie usuwaj całego bloku tylko dlatego, że istnieje więcej niż jeden element script; może on opisywać inną prawidłową encję.
Zwróć uwagę na wartości dodawane przez moduły, takie jak recenzje czy zasady sklepu. Ich obecność powinna wynikać z faktycznej treści sklepu i zamierzonego kontraktu danych modułu. Nie wymyślaj ocen ani informacji o zasadach, aby raport walidacji wyglądał na pełniejszy.
W motywie potomnym porównaj dziedziczone szablony z lokalnymi nadpisaniami. Stare nadpisanie może zachować dawną postać wynikową, podczas gdy motyw nadrzędny przechodzi na ścieżkę po stronie rdzenia. Poprawka powinna rozwiązać konflikt odpowiedzialności zamiast stosować szeroką zamianę tekstu do każdego skryptu na stronie.
Oddzielaj wszelkie twierdzenia dotyczące zewnętrznych wyników wyszukiwania. Prawidłowe znaczniki są wynikiem implementacji. To, czy wyszukiwarka wyświetli określone rozszerzenie wyniku, jest osobną kwestią, której ta zmiana w wydaniu nie gwarantuje.
Używaj danych testowych ujawniających błędy przekształceń
Prosta nazwa produktu i krótki opis mogą ukrywać problemy z konwersją tekstu. Dodaj syntetyczny opis z sąsiadującymi akapitami, wyróżnieniami i znakami spoza ASCII. Sprawdź tekst danych strukturalnych i porównaj go z zamierzoną czytelną treścią.
Kolejny PR dla wersji 9.2 odnosi się do nowej ścieżki konwersji opisów z HTML na tekst i obsługi bezsensownych adresów URL produktów i kategorii. Te szczegóły uzasadniają ukierunkowane przypadki regresji bez sugerowania, że zmieniło się każde zachowanie SEO. Dopracowanie danych strukturalnych #42016.
Sprawdź produkt z kombinacjami, jeśli sklep ich używa. Wybierz inną kombinację przez obsługiwany interfejs i sprawdź, jaką reprezentację strukturalną emituje strona. Oczekiwana reprezentacja powinna odpowiadać kontraktowi motywu i rdzenia, a nie założeniu skopiowanemu z innego sklepu.
Przy brakujących danych opcjonalnych potwierdź, że wynik pozostaje spójny. Brak obrazu lub opisu nie powinien powodować błędu składni skryptu ani ponownego użycia wartości innego produktu. Korzystaj z danych testowych, które celowo pozostawiają opcjonalną treść nieustawioną.
Są to proponowane testy integracji. Nie stanowią stwierdzenia, że wersja kandydująca ma każdy z opisanych błędów.
Cechy produktu i dane kontaktowe sklepu mają konkretną zmianę w RC
Wydanie RC1 zawiera też zmianę dodającą cechy produktu przez additionalProperty oraz skonfigurowane dane kontaktowe sklepu do danych organizacji. Jest to konkretny dodatek do wyniku, odrębny od wcześniejszego przejścia w kierunku renderowania po stronie rdzenia. Zmiana cech produktu i danych kontaktowych #42571.
Nadaj produktowi testowemu dwie rozpoznawalne wartości cech i porównaj je z emitowanymi właściwościami. W motywie wielosklepowym sprawdź dane kontaktowe w kontekście każdego sklepu i potwierdź, że wynik opisuje wybrany sklep. Jeśli inny moduł emituje już te same informacje, przeanalizuj odpowiedzialność przed zachowaniem obu reprezentacji. Nie dodawaj wymyślonych danych kontaktowych tylko po to, aby wypełnić opcjonalne pole.
Sprawdź brakujące encje jako osobną klasę stron
Wywołaj kontrolowany adres URL nieistniejącego produktu lub kategorii w środowisku przedprodukcyjnym. Zarejestruj wynik HTTP, widoczną stronę i wszelkie dane strukturalne. Strona nie powinna myląco opisywać prawidłowej oferty produktu dla encji, która nie istnieje.
Nie testuj tego wyłącznie przez zmianę sluga przy istniejącym identyfikatorze. W zależności od udokumentowanego zachowania routera może to prowadzić lub przekierowywać do rzeczywistej encji. Użyj danych testowych o naprawdę nieistniejącej tożsamości i odróżnij je od nieaktywnego lub niedostępnego produktu.
Jeśli uczestniczy w tym własny moduł stron błędów lub nadpisanie motywu, uwzględnij go w wykazie odpowiedzialności. Poprawka rdzenia nie może potwierdzić poprawności znaczników dodanych później przez rozszerzenie.
Zachowaj odpowiedź przed zastosowaniem zmian po stronie przeglądarki. Jeśli skrypt zmienia stronę po załadowaniu, zapisz to osobno, aby zespół mógł odróżnić wynik serwera od zachowania klienta.
Przypadek brakującej strony należy do audytu tego wydania, ponieważ dotyczy go przytoczone dopracowanie wersji 9.2. Nie powinien rozrastać się w niezwiązany z tematem poradnik o wszystkich regułach przekierowań lub indeksowania w sklepie.
Wielojęzyczna konfiguracja tras to więcej niż przetłumaczone slugi
Zmiana tras wielojęzycznych pozwala różnicować wzorce tras encji według języka. PR podaje brzmienie ścieżki właściwe dla języka jako przykład uzasadniający zmianę. To coś innego niż tłumaczenie przepisanej nazwy pojedynczego produktu. Zmiana tras encji #41405.
W dwujęzycznym zestawie danych testowych zapisz wzorzec trasy i rzeczywiście wygenerowany adres URL encji w każdym języku. Otwórz te wygenerowane linki i sprawdź, czy prowadzą do oczekiwanej encji i języka. Unikaj ręcznego budowania adresu URL, którego aplikacja nigdy by nie wygenerowała.
Następnie przełącz język w sklepie i sprawdź miejsce docelowe. Sprawdź adres URL tworzony przez moduł odsyłający do tej samej encji. Moduł łączący stały segment ścieżki może ignorować nowy, konfigurowalny wzorzec językowy.
Osobna, zweryfikowana poprawka RC zachowuje paginację w adresach URL hreflang list produktów. Wcześniej alternatywy językowe mogły wskazywać pierwszą stronę, podczas gdy adres kanoniczny reprezentował dalszą stronę. Jest to wąska korekta paginacji, a nie twierdzenie, że rozwiązano każdy problem oznaczeń językowych. Poprawka paginacji hreflang #42725.
Użyj kategorii zawierającej dość produktów na kilka stron i sprawdź dalszą stronę w dwóch językach. Otwórz linki alternatywnego języka i potwierdź zachowanie zamierzonej pozycji strony. Uwzględnij pierwszą stronę jako osobny przypadek i sprawdź wzajemne alternatywy. Oddziel ten test od tłumaczenia wzorca trasy: jeden dotyczy stanu paginacji, a drugi wzorca ścieżki właściwego dla języka.
Sprawdź wartości domyślne przed zapisaniem formularza tras
Późniejsza poprawka dotyczy domyślnych wartości tras, które nie pojawiają się prawidłowo dla każdego języka w formularzu SEO i adresów URL, gdy konfiguracja nie istnieje lub nadal ma wcześniejszą postać. PR zawiera konkretną reprodukcję z nową konfiguracją. Poprawka wartości domyślnych dla poszczególnych języków #42241.
Przetestuj świeżą instalację wersji kandydującej przed dostosowaniem wzorców. Otwórz formularz i sprawdź, czy każdy odpowiedni język pokazuje prawidłową wartość domyślną. Zapisz bez celowych zmian, otwórz ponownie i potwierdź, że wartości pozostają prawidłowe.
Następnie skonfiguruj zamierzoną różnicę językową przez obsługiwany formularz i powtórz kontrole wygenerowanych linków. Pozwala to odróżnić wypełnianie wartości domyślnych od trwałego zapisu własnych wzorców.
Nie usuwaj wierszy konfiguracji w działającym sklepie, aby odtworzyć przypadek z projektu źródłowego. Świeża testowa baza danych zapewnia wymagany warunek bez ryzyka dla opublikowanych adresów URL. Jeśli istniejąca konfiguracja wymaga badania, użyj kontrolowanej kopii i zachowaj jej pierwotne wartości.
Porównaj świeży motyw z motywem dostosowanym
Gdy pojawiają się sprzeczne znaczniki, odtwórz dane testowe na obsługiwanej, niezmodyfikowanej wersji motywu w osobnej instancji testowej. Zachowaj równoważne wersje rdzenia i modułów. Następnie wprowadzaj kolejno nadpisania motywu potomnego i odpowiednie moduły SEO.
To porównanie może wskazać warstwę dodającą sprzeczną encję lub nieaktualną wartość. Nie dowodzi, że każda modyfikacja jest błędna; moduł może celowo dostarczać dane, których brak w motywie bazowym. Pytanie brzmi, czy łączna reprezentacja pozostaje spójna.
Zapisz przeanalizowane obiekty wraz z indeksem skryptu źródłowego i, jeśli badanie pozwala to ustalić, odpowiedzialnym komponentem. Unikaj usuwania wyniku wyłącznie na podstawie kolejności skryptów, ponieważ kolejność może się zmieniać bez zmiany odpowiedzialności.
Po ustaleniu odpowiedzialnej warstwy ponownie przetestuj zwykły produkt, brakującą encję i trasy w obu językach. Poprawka jednego szablonu może wpłynąć na więcej stron niż ta, na której po raz pierwszy zauważono rozbieżność.
Utrzymuj porównanie końcowego wyniku na tyle małe, aby opiekun motywu mógł je przejrzeć bez odtwarzania całego sklepu.
Zachowaj niewielkie, łatwe do przeglądu porównanie wyniku
Dla każdego zestawu danych testowych zapisz wybrany adres URL, język, status odpowiedzi, przeanalizowane obiekty danych strukturalnych i odpowiednie widoczne wartości. Poniższy fragment dla konsoli przeglądarki jedynie inwentaryzuje bloki JSON-LD na aktualnie otwartej stronie; nie potwierdza kwalifikowania się do wyników wyszukiwania:
const results = [...document.querySelectorAll('script[type="application/ld+json"]')]
.map((node, index) => {
try {
return { index, validJson: true, value: JSON.parse(node.textContent) };
} catch (error) {
return { index, validJson: false, error: String(error) };
}
});
console.table(results.map(({ index, validJson }) => ({ index, validJson })));
W kolejnym etapie użyj specjalistycznego walidatora i ręcznego przeglądu semantycznego. Prawidłowy JSON jest niezbędny w skrypcie JSON-LD, ale nie dowodzi, że zawarte w nim fakty poprawnie opisują stronę.
Audyt wersji 9.2 powinien zakończyć się jasną odpowiedzialnością za emitowane dane i zweryfikowanym zachowaniem tras językowych. Popraw sprzeczności i błędne wartości domyślne u źródła, a następnie zachowaj dane testowe, aby późniejszą aktualizację motywu lub modułu można było sprawdzić na podstawie tych samych dowodów.
Kontekst platformy bazowej znajdziesz w naszym poradniku SEO dla PrestaShop 9 i zastosuj powyższe kontrole właściwe dla wersji do ocenianej instalacji.