Hreflang w PrestaShop: mapowania językowe i weryfikacja

Co byśmy zrobili

Przed wyborem modułu ustalilibyśmy przyczynę błędnej lub brakującej wersji alternatywnej. Podejście zależy od obecnego motywu, modułów SEO, integracji importujących tłumaczenia lub zmieniających adresy URL, mapowań katalogu, rynków i zespołu, który je utrzymuje. Zapisz, które strony powinny być równoważne i który komponent obecnie publikuje tę relację.

Wprowadź zmianę na kopii stagingowej tej konfiguracji. Zachowaj prywatność stagingu i wyklucz go z wyszukiwania, przećwicz kontrole mapowań i generowanych oznaczeń oraz zapisz poprzednie ustawienia i szablony. Uzgodnij okno przełączenia i kroki wycofania, a po wdrożeniu sprawdź strony publiczne. Kontrole stagingowe potwierdzają strukturę; docelowe hosty produkcyjne i możliwość indeksowania nadal trzeba sprawdzić na stronach produkcyjnych. Nigdy nie publikuj adresów stagingowych w produkcyjnych wersjach alternatywnych ani mapach witryny.

Jeśli wielojęzyczny routing, adresy kanoniczne i mapowania wersji alternatywnych są sprzeczne, PrestaShop SEO Audit & Action Plan zapewnia przegląd i uporządkowane według priorytetu poprawki dla programisty; wdrożenie jest osobną usługą.

Zrozum działanie hreflang

Hreflang wskazuje równoważne wersje językowe lub regionalne strony. Pomaga wyszukiwarkom wybrać odpowiednią wersję; nie tłumaczy treści, nie wymusza pozycji ani nie łączy przetłumaczonych stron w jedną stronę kanoniczną.

W pełni przetłumaczona treść główna nie jest duplikatem tylko dlatego, że została przetłumaczona. Skopiowany tekst języka źródłowego i regionalne powielenia w tym samym języku wymagają własnej analizy treści i adresów kanonicznych. Używaj osobnych adresów językowych i pozwól użytkownikom samodzielnie przełączać wersje. Zobacz wytyczne Google dotyczące witryn wielojęzycznych.

Hreflang jest zalecany, gdy potrzebujesz wyrazić tę relację, a nie obowiązkowy dla każdego sklepu wielojęzycznego. Google może odkrywać wersje językowe bez niego. Słaba treść, brakujące tłumaczenia, zablokowane adresy i mylący routing to odrębne problemy.

Najpierw sprawdź oznaczenia generowane przez PrestaShop

Współczesny PrestaShop buduje mapę alternatywnych adresów dla aktywnych języków bieżącego sklepu. W PrestaShop 9 mapa ma klucze language_code i korzysta z Link::getLanguageLink(). Motyw musi rzeczywiście wyrenderować ją w sekcji head. Nadpisany szablon częściowy head może ją usunąć lub powielić.

Classic i Hummingbird zapewniają nowoczesne integracje motywu, ale sprawdź zainstalowane wydania. Classic pozostawał domyślny w 9.0; Hummingbird stał się domyślny w 9.1. Nagłówek default-bootstrap PrestaShop 1.6 nie zapewnia tego samego nowoczesnego bloku alternatyw. Nie zakładaj identycznego wyniku między tymi generacjami.

Kod ISO języka uczestniczy w routingu URL, natomiast language_code dostarcza klucz wbudowanej mapy alternatyw. Locale jest osobnym polem. Popraw błędne wartości w ich rzeczywistej konfiguracji, a potem sprawdź wyrenderowany wynik; zmiana jednej nie gwarantuje poprawności drugiej.

Adresy sklepów należą do sklepów, a nie do poszczególnych języków. Podfoldery mogą korzystać z wbudowanego routingu wielojęzycznego. Osobne domeny lub subdomeny językowe wymagają odpowiedniego multistore lub własnego routingu. Wbudowane linki językowe jednego sklepu nie odkrywają automatycznie równoważnych produktów w niepowiązanych domenach sklepów.

W wydaniach używających tych etykiet menu sprawdź pola języka w Międzynarodowy → Lokalizacja → Języki, a ustawienia adresów URL w Parametry sklepu → Ruch i SEO → SEO i URL. Sekcja Ustaw adres URL sklepu dotyczy adresu sklepu. Przed edycją zapisz bieżący kontekst sklepu i wartości; zmiana utrwalonej ścieżki językowej wymaga również planu przekierowań i linków wewnętrznych.

Twórz wzajemnie powiązane zestawy stron

Używaj prawidłowych kodów językowych, opcjonalnie z obsługiwanym regionem: en-GB, a nie en-UK; dla czeskiego cs, a nie cz. Wskazuj rzeczywistą równoważną stronę pełnym adresem URL. Każda uczestnicząca wersja powinna wskazywać siebie i zawierać linki zwrotne do partnerów. Google może przetwarzać wzajemnie powiązane podzbiory; brak oznaczenia w innym miejscu nie unieważnia każdej działającej pary. Zobacz reguły Google dotyczące wersji alternatywnych.

Dla angielskiego, niemieckiego i francuskiego zestawu stron produktu ten sam zestaw uczestników powinien znajdować się w sekcji head każdej strony:

<link rel="alternate" hreflang="en" href="https://store.example/en/product">
<link rel="alternate" hreflang="de" href="https://store.example/de/produkt">
<link rel="alternate" hreflang="fr" href="https://store.example/fr/produit">

x-default jest opcjonalną wersją zastępczą, np. selektorem języka lub wybraną wersją ogólną. Jego brak nie unieważnia zestawu językowego. Jeśli go używasz, zadbaj o odpowiednie i dostępne miejsce docelowe. Zobacz wyjaśnienie x-default Google.

<link rel="alternate" hreflang="x-default" href="https://store.example/en/product">

Zachowaj zwykły adres kanoniczny każdej rzeczywiście przetłumaczonej wersji w jej języku. Rozwiąż nieoczekiwane przekierowania, noindex, błędy i sprzeczne adresy kanoniczne, zanim oprzesz się na zestawie. Hreflang nie umożliwia indeksowania strony, która się do niego nie kwalifikuje.

W sklepach regionalnych jawnie mapuj równoważne encje. Zgodne numeryczne ID między sklepami są bezpieczne tylko wtedy, gdy oznaczają ten sam produkt lub treść. Zdecyduj, które miejsce docelowe odpowiada za każdy kod języka lub regionu, gdy oferuje go kilka sklepów. Nigdy nie mapuj nieprzetłumaczonego produktu na stronę główną tylko po to, by wypełnić miejsce.

Relacje te można wyrazić tagami HTML w head i oznaczeniami w mapie witryny XML. Jeśli używasz obu, zachowuj spójne mapowania. Wpis mapy powinien zawierać bieżący URL i właściwe odwołania alternatywne z wymaganymi przestrzeniami nazw XML; sprawdzaj wszystkie uczestniczące wpisy, zamiast dodawać tylko jednokierunkowy link do innej wersji językowej.

Prześledź błąd mapowania regionalnego

Twoje sklepy brytyjski i amerykański sprzedają tę samą lampę po angielsku, ale importy katalogu utworzyły różne rekordy produktu. Mapowanie oparte na zgodnych numerycznych ID łączy brytyjską lampę z amerykańskim abażurem. Kody en-GB i en-US mogą być poprawne, mimo że relacja jest błędna.

Potwierdź równoważność na podstawie stałego indeksu katalogowego i faktycznej treści produktu, popraw mapowanie, a następnie sprawdź oba cele i ich linki zwrotne. Jeśli amerykańska lampa nie jest opublikowana, usuń jej wpis alternatywny z uczestniczących stron i włączonych oznaczeń mapy witryny, dopóki nie będzie gotowa. Dodaj ten przypadek do kontroli po importach katalogu: robot może wykrywać uszkodzone relacje, nie rozpoznając, że dwie prawidłowe strony sprzedają różne przedmioty.

Wybierz jedną implementację, a konfigurację sprawdzaj w pomocy modułu

Wybierz jeden komponent odpowiedzialny za zestaw wersji alternatywnych każdej strony i sprawdź jego integrację z rzeczywistym wynikiem motywu.

Automatyczne połączenia multistore, ręczne grupy Local/Shared, wiersze źródłowe i docelowe, wykluczenia, podglądy wersji roboczych, odpowiedzialność za wynik i wymagania licencyjne opisuje pomoc Hreflang Tags Manager.

Ustawienia hreflang, wzorce URL, podglądy, przekierowania historii URL i generowane językowe mapy witryny opisuje pomoc SEO Revolution.

Hreflang Tags Manager obejmuje obsługiwane strony encji i pomija generowane zestawy dla wyszukiwania, wyników filtrowanych i kolejnych stron list (od drugiej). Przy udanych odpowiedziach strony konta, zakupów i modułów zachowują alternatywy dostarczane przez własne kontrolery i motyw. Ręczne przypisania mają pierwszeństwo przed automatycznymi połączeniami. Własne docelowe URL i mapowania dynamiczne nadal wymagają kontroli linków zwrotnych. Obsługa adresów kanonicznych pozostaje osobną kwestią.

Gdy za oznaczenia hreflang odpowiada SEO Revolution, samodzielny menedżer ich nie generuje. Pakiet wymaga co najmniej dwóch kwalifikujących się wersji alternatywnych, w tym bieżącej strony; generowanie x-default zależy od tego, czy wybrany domyślny adres URL nadal się kwalifikuje. Kod preferuje language_code i może awaryjnie użyć locale. Funkcje nagłówka i mapy witryny mają własne ustawienia i kontrole kwalifikacji. Powtórz kontrole wyniku po zmianach motywu, ponieważ tagi generowane przez moduł nadal zależą od integracji z motywem.

Weryfikuj rzeczywiste strony po zmianach

1. Wybierz rzeczywisty produkt z ukończonymi tłumaczeniami. Pobierz odpowiedź HTML lub wyświetl źródło strony, a następnie sprawdź linki alternatywne w head. Ustal, który komponent je dostarcza.
2. Otwórz każdy adres docelowy. Potwierdź końcowy URL, widoczny język, status odpowiedzi, dyrektywę robots i adres kanoniczny. Porównaj rzeczywisty kod języka i regionu z docelowymi odbiorcami.
3. Porównaj zestawy. Sprawdź odwołania do siebie i linki zwrotne uczestniczących stron. Traktuj x-default jako opcjonalny, a gdy występuje, zweryfikuj jego cel.
4. Powtórz dla strony głównej, kategorii, CMS, marek i dostawców, jeśli uczestniczą. Celowo nieobsługiwane typy stron modułu nie wymagają wymyślonych mapowań.
5. Sprawdź wygenerowany XML, jeśli włączono oznaczenia w mapie witryny. Porównaj adresy z tagami head i celami selektora języka.
6. Użyj robota na docelowym zbiorze URL, aby znaleźć błędne kody, przekierowania, jednostronne pary, powielony wynik i niekwalifikujące się cele. Zapisuj wyjątki, zamiast zakładać udział każdej strony.
7. Powtórz po zmianie domen, ustawień języka, slugów, szablonów head motywu, komponentu odpowiedzialnego za SEO lub generowania map.

Brakujące lub bezużyteczne oznaczenia mogą zostać zignorowane lub nie ustanowić relacji. Sprawdź, których mapowań dotyczy problem, i popraw nieużyteczne oznaczenia.

Jeśli stary cel pozostaje po poprawce, porównaj odświeżoną odpowiedź z buforowanym HTML i ustal warstwę pamięci podręcznej przed edycją kolejnych mapowań. Wyczyszczenie pamięci przeglądarki nie usuwa HTML z serwera ani CDN. Jeśli brakuje tagów, porównaj ten sam typ strony w zainstalowanym motywie i jego nadpisaniu head, zanim uznasz, że brakuje danych języka.

Przygotowanie treści i walut stojących za tymi adresami opisuje poradnik tłumaczeń i sprzedaży międzynarodowej.

Zaplanuj przełączenie i przekazanie

1. Zachowaj HTML sprzed zmiany i po niej oraz ustawienia mapowań dla uzgodnionych stron testowych, w tym celowego wykluczenia. Przygotuj poprzednią konfigurację generowania oznaczeń do przywrócenia.
2. Wdróż zatwierdzone ustawienia i zmiany szablonów razem, odśwież odpowiednie pamięci podręczne i wygeneruj ponownie włączone mapy witryny. Przed zatwierdzeniem powtórz powyższą weryfikację na publicznych adresach URL.
3. Przekaż osobie utrzymującej sklep informacje o komponencie odpowiedzialnym za wynik, reguły mapowania, wykluczenia, testowe adresy URL i instrukcje wycofania. Powtarzaj odpowiednie kontrole po zmianie języka lub imporcie danych katalogowych przez tę osobę.

O co zapytać programistę lub agencję

• Jak dopasowywane są równoważne rekordy między sklepami i co się dzieje po wycofaniu publikacji tłumaczenia lub zastąpieniu rekordu przez import?
• Które nadpisanie motywu lub moduł kontroluje head i które ustawienia kontrolują oznaczenia w mapie witryny?
• Kto sprawdza dodawanie języków i zmiany domen oraz jakie dowody spowodują wycofanie zmian?

Pytania właścicieli sklepów

Czy naprawa hreflang wymaga osobnych domen?

Nie. Działająca konfiguracja z podfolderami może wskazywać wersje językowe. Wybieraj domeny pod kątem rynku i architektury sklepu; przenoszenie utrwalonych adresów URL dokłada pracę migracyjną, której poprawienie tagów może nie wymagać.

Czy hreflang zastąpi selektor języka lub przekieruje odwiedzających?

Nie. Zachowaj użyteczny selektor prowadzący do równoważnej strony. Automatyczne przekierowania według języka lub lokalizacji wymagają osobnej oceny: mogą uniemożliwić odwiedzającym i robotom dotarcie do żądanego adresu URL.

Kiedy Google pokaże poprawioną wersję?

Nie ma ustalonego terminu. Zachowaj poprawiony HTML i wyniki skanowania jako dowody techniczne; wyniki wyszukiwania zależą od ponownego odwiedzenia stron i wyboru Google. Sam brak zmiany pozycji nie wskazuje, czy oznaczenie jest poprawne.