Wszystko, co warto wiedzieć, zanim zainstalujesz.
Szczegółowe spojrzenie na to, jak działa DataFirefly Indexing API: automatyczne zgłaszanie do Google Indexing API i IndexNow (Bing, Yandex, Naver) dla PrestaShop 8 i 9, dlaczego zbudowaliśmy go w ten sposób i jaka myśl stoi za powyższymi funkcjami.
Problem: Googlebot i Bingbot potrzebują czasu
To martwy punkt SEO każdego rosnącego sklepu. Publikujesz nowy produkt w poniedziałek rano, a Google indeksuje go dopiero w czwartek wieczorem. Poprawiasz literówkę w karcie, a Bing przez dwa tygodnie pokazuje starą wersję. Przez cały ten czas tracisz ruch organiczny, tracisz konwersje, a użytkownicy widzą nieaktualne informacje w wynikach wyszukiwania. Dla sklepu, który publikuje lub modyfikuje 20 produktów tygodniowo, to setki adresów z opóźnionym indeksowaniem w każdym momencie. Sitemapa XML pozostaje niezbędna: to oficjalny kanał odkrywania, musi być czysta i aktualna. Ale nie nadaje żadnego priorytetu, a klasyczny ping sitemapy nie ma już żadnego znaczenia, odkąd Google usunęło swój endpoint pingu w czerwcu 2023. Aby zasygnalizować zmianę w kilka minut zamiast w kilka dni, trzeba sięgnąć po bezpośrednie zgłaszanie.
Google Indexing API: co robi, a czego nie robi
Google udostępnia endpoint REST pod adresem indexing.googleapis.com, który przyjmuje powiadomienia o aktualizacji lub usunięciu adresu URL. Uwierzytelnianie odbywa się przez konto usługi Google Cloud: tworzysz Service Account, pobierasz jego klucz w formacie JSON i dodajesz go jako właściciela swojej usługi w Search Console. Moduł podpisuje JWT RS256 kluczem prywatnym, wymienia ten JWT na token dostępu OAuth2 na oauth2.googleapis.com, cache'uje token przez 55 minut i używa go do uwierzytelnienia każdego zgłoszenia. Rzecz do wiedzenia przed zakupem: dokumentacja Google oficjalnie ogranicza to API do stron z danymi strukturalnymi JobPosting albo BroadcastEvent osadzonym w VideoObject. Karta produktu ani strona kategorii nie mieszczą się w żadnym z tych przypadków. API mimo to przyjmuje zgłoszenie i odpowiada 200, ale ta odpowiedź oznacza tylko, że powiadomienie zostało odebrane: Google pozostaje jedynym sędzią crawlowania i indeksowania. Domyślny limit to 200 adresów dziennie na konto usługi, a zwiększenie limitu jest zarezerwowane dla witryn faktycznie używających JobPosting lub BroadcastEvent, więc sklep nie powinien na to liczyć. Moduł zgłasza, zapisuje kod zwrotny, a pulpit odzwierciedla odpowiedź API, a nie decyzję o indeksowaniu. Jeśli szukasz mierzalnego zysku indeksacyjnego na katalogu produktów, dostarcza go IndexNow.
IndexNow: Bing, Yandex, Naver, Seznam jednym wywołaniem
IndexNow to otwarty protokół forsowany przez Microsoft Bing i Yandex w 2021 roku, do którego dołączyły Naver (dominująca wyszukiwarka w Korei Południowej) i Seznam (historyczna wyszukiwarka w Czechach). W przeciwieństwie do API Google IndexNow nie narzuca żadnych ograniczeń co do typu strony: karty produktów, kategorie i strony CMS mieszczą się w jego normalnym zakresie. Zasada: generujesz klucz alfanumeryczny, publikujesz go w katalogu głównym domeny (plik klucz kropka txt) i wywołujesz endpoint api.indexnow.org z listą adresów. Wywołanie jest bezpłatne, bez limitu i automatycznie propagowane do wszystkich uczestniczących wyszukiwarek. Bez kwot, bez konta usługi, bez OAuth: tylko klucz i wywołanie HTTP. Moduł generuje klucz automatycznie przy instalacji, oferuje dwie metody udostępnienia go w katalogu głównym (przepisanie w pliku htaccess z generowanym snippetem albo plik fizyczny) i grupuje adresy po 100 na wywołanie, aby oszczędzać zapytania.
Nasłuchiwane hooki PrestaShop
Moduł podpina się do oficjalnych hooków cyklu życia obiektów PrestaShop. Dla produktów: actionProductSave jest wywoływany przy tworzeniu i każdej modyfikacji, a jeśli produkt jest aktywny, adres trafia do kolejki jako URL_UPDATED, w przeciwnym razie jako URL_DELETED. actionProductDelete jest wywoływany przy trwałym usunięciu, z zakolejkowaniem URL_DELETED. Dla stron CMS: actionObjectCmsAddAfter (utworzenie), actionObjectCmsUpdateAfter (modyfikacja), actionObjectCmsDeleteAfter (usunięcie). Dla kategorii: actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete, przy czym kategorie główne (ID 1 i 2) są pomijane dla bezpieczeństwa. Każdy hook buduje adres kanoniczny przez oficjalny obiekt Link PrestaShop, co gwarantuje poszanowanie ustawień przyjaznych adresów SEO, prefiksów językowych i reguł wielojęzycznych.
Kolejka: dlaczego i jak
Synchroniczne zgłaszanie przy każdym hooku byłoby podwójnie złym pomysłem: opóźnienie spowalniałoby panel administracyjny (wywołanie do Google może zająć 2 do 5 sekund), a błąd API uniemożliwiałby zapisanie produktu. Moduł kolejkuje więc każde zgłoszenie w trwałej tabeli kolejki (tabela df_indexapi_queue), a CRON przetwarza partie co kilka minut. Deduplikacja jest kluczowa: jeśli zmodyfikujesz produkt trzy razy w ciągu godziny, moduł rozpoznaje, że zadanie dla tej krotki (sklep, typ, ID, dostawca, akcja) już istnieje i po prostu aktualizuje jego adres i datę, nie tworzy trzech. Logiczna blokada pending na processing zapobiega podwójnemu przetwarzaniu, gdy dwa równoległe CRON-y pobierają z tej samej partii. Każde niepowodzenie inkrementuje licznik prób, wyzwalając automatyczne ponowienie przy kolejnym CRON-ie aż do konfigurowalnego maksimum (domyślnie 5). Powyżej tego zadanie przechodzi w błąd i pozostaje widoczne w ekranie Kolejka z dokładnym komunikatem zwróconym przez API.
Dziennik i pulpit
Każde zgłoszenie tworzy wpis w tabeli df_indexapi_log: dostawca Google lub IndexNow, typ i ID obiektu, dokładny zgłoszony adres URL, akcja URL_UPDATED lub URL_DELETED, zwrócony kod HTTP, wskaźnik zaakceptowane lub odrzucone, pełny komunikat odpowiedzi i data. Ekran Dziennik prezentuje te dane w standardowym HelperList PrestaShop z natywnymi filtrami (dostawca, kod HTTP, zaakceptowane), sortowaniem i eksportem CSV. Pulpit agreguje całość: pięć kart liczników per status kolejki, dwie karty diagnostyki dostawców (konto usługi Google skonfigurowane lub nie, klucz i host IndexNow skonfigurowane lub nie), tabela wskaźnika akceptacji z 30 dni per dostawca z kolorowaniem semantycznym (zielony powyżej 90, pomarańczowy między 60 a 90, czerwony poniżej) oraz wykres Chart.js dziennych zgłoszeń nakładający sumę zgłoszonych i sumę zaakceptowanych. Czytaj to jako wskaźnik technicznej kondycji wywołań API, a nie jako dowód indeksacji.
Bezpieczeństwo CRON-a i pliku klucza
Kontroler CRON jest wystawiony na froncie pod standardowym adresem PrestaShop, ale chroniony losowym 32-znakowym tokenem generowanym przy instalacji i regenerowalnym jednym kliknięciem z poziomu konfiguracji. Bez poprawnego tokenu kontroler zwraca 403. Obsługiwane są trzy akcje: process przetwarza partię z kolejki (wywołuj co 5 do 15 minut cronem hostingu), purge usuwa przetworzone zadania i logi powyżej skonfigurowanej retencji (wywołuj raz dziennie), a key serwuje zawartość pliku klucza IndexNow jako text/plain do przepisania w pliku htaccess (chronione przez wcześniejszą znajomość klucza w parametrze k). Dokładny snippet do pliku htaccess, który należy wkleić w katalogu głównym PrestaShop, jest generowany automatycznie na stronie Konfiguracja z bieżącym kluczem.
Typowe zastosowania
Rosnący sklep z 50 nowymi produktami tygodniowo: moduł kolejkuje każde utworzenie, CRON zgłasza w ciągu 10 minut, a Bing, Yandex, Naver i Seznam zwykle uwzględniają nowe adresy w ciągu kolejnych godzin. Po stronie Google zgłoszenie przyspiesza odkrycie bez gwarancji rezultatu. Sklep wielojęzyczny z katalogiem 5000 produktów: przy każdej modyfikacji karty adresy kanoniczne wszystkich języków są kolejkowane i zgłaszane, na wszystkich Twoich rynkach jednocześnie. Sklep B2B z katalogiem technicznym często aktualizowanym (ceny, stany, karty techniczne): deduplikacja chroni przed spamowaniem API przy seriach modyfikacji, jedno zadanie na produkt nawet jeśli zmodyfikujesz go dwadzieścia razy w ciągu dnia. Odbudowa SEO po migracji: przycisk Ponów wszystkie zadania w ekranie Kolejka pozwala masowo zgłosić ponownie po rozwiązaniu problemu konfiguracji lub limitu.
Znane ograniczenia i dobre praktyki
Google oficjalnie rezerwuje Indexing API dla stron JobPosting i BroadcastEvent, co czyni IndexNow głównym kanałem modułu dla katalogu produktów. Włącz IndexNow w pierwszej kolejności, a Google traktuj jako zapisywany w dzienniku bonus. IndexNow nie obsługuje akcji URL_DELETED: protokół zakłada, że 404 lub 410 na adresie jest właściwym sposobem zasygnalizowania usunięcia, więc moduł pomija te zadania (Google z kolei ten typ akcji obsługuje). Limit Google jest zamknięty na 200 adresach dziennie na konto usługi, a ponieważ zwiększenie limitu jest uwarunkowane obecnością znaczników JobPosting lub BroadcastEvent, sklep powinien traktować ten pułap jako ostateczny: ogranicz filtr Google do nowości albo utwórz drugie konto usługi z własnym limitem. Moduł nie zgłasza wariantów ani kombinacji produktów, ponieważ adres kanoniczny produktu głównego wystarcza, a Google naturalnie konsoliduje warianty. Kategorie główne (ID 1 i 2) są pomijane, aby nie zgłaszać nieistotnych adresów.
Na razie nie ma opinii o produkcie.