Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Na majowej konferencji Google zapowiedziało nowy model przetwarzania języka o nazwie MUM, czyli Multitask Unified Model. Od tego czasu w branży SEO zdążył on obrosnąć zestawem opinii, w których zaskakująco trudno odróżnić fakty od domysłów. Czytałem już porady, jak „optymalizować pod MUM”, i to jest dobry moment, żeby powiedzieć, że nikt takich porad rzetelnie sformułować dziś nie może.
Trzymam się więc tego, co Google powiedziało, i tego, co udało się zaobserwować przez ostatnie pół roku. To niewiele, ale wystarczy, żeby wyciągnąć kilka praktycznych wniosków — pod warunkiem, że nazwiemy rzecz po imieniu: mówimy o technologii zapowiedzianej i wdrażanej stopniowo, nie o działającym czynniku rankingowym.
Poniżej zbieram, co wiadomo, i staram się rozdzielić to od tego, co jest przewidywaniem.
Prezentacja z maja przedstawiła MUM jako model przeznaczony do rozumienia zapytań złożonych — takich, na które nie ma prostej odpowiedzi i które człowiek dziś rozbija na kilka kolejnych wyszukiwań.
Przykład, którym Google się posłużyło, dotyczył porównania doświadczenia z jednej wyprawy górskiej z przygotowaniem do kolejnej, trudniejszej. Żeby na to odpowiedzieć, trzeba rozumieć relację między dwiema rzeczami, a nie tylko dopasować słowa. Dziś użytkownik wykonuje w takiej sytuacji serię wyszukiwań i sam składa wnioski.
Dwie cechy modelu podkreślano najbardziej. Wielojęzyczność — model jest trenowany na wielu językach jednocześnie, co ma pozwolić na przenoszenie wiedzy między nimi. To znaczy, że informacja dostępna wyłącznie w języku japońskim mogłaby posłużyć do odpowiedzi na pytanie zadane po polsku. Wielomodalność — zdolność do pracy z tekstem, obrazem i innymi formatami w jednym modelu.
Google podało też, że model jest znacznie potężniejszy od wcześniejszego rozwiązania z tej rodziny, które wprowadzono kilka lat wcześniej i które również miało poprawić rozumienie języka naturalnego.
Zapowiedź to jedno, wdrożenie to drugie, a od maja pojawiło się kilka konkretów.
Pierwsze zastosowanie produkcyjne dotyczyło tematyki zdrowotnej: model posłużył do rozpoznania, że różne nazwy tego samego preparatu odnoszą się do tej samej rzeczy, co pozwoliło lepiej obsłużyć zapytania o niego. To zastosowanie wąskie i bardzo praktyczne — mówi więcej o kierunku niż o skali.
Wrześniowa prezentacja poświęcona wyszukiwaniu przyniosła zapowiedzi kolejnych funkcji opartych na tym modelu, w tym łączenia zapytania obrazkowego z tekstowym: robisz zdjęcie rzeczy i dopisujesz pytanie o nią. To rzecz naprawdę nowa, ale przedstawiona jako coś, co pojawi się w kolejnych miesiącach, nie jako funkcja dostępna dziś w Polsce.
Google wyraźnie zaznacza przy tym, że wdrożenie będzie ostrożne i rozłożone na lata, między innymi z powodu wymagań energetycznych i ryzyka związanego z jakością odpowiedzi. To zastrzeżenie jest w moim odczuciu najważniejszą informacją z całej tej historii, bo ustawia horyzont czasowy.
Warto to wypisać, bo w rozmowach branżowych mieszają się trzy różne rzeczy.
To nie jest aktualizacja algorytmu. Nie było wdrożenia z datą, po której widoczność stron mogłaby spaść albo wzrosnąć. Kto szuka w danych z ostatnich miesięcy śladu „aktualizacji MUM”, ten znajdzie skutki zupełnie innych zmian — a tych było tej jesieni kilka.
To nie jest czynnik rankingowy, pod który da się optymalizować. Nie ma parametru, wskaźnika ani zalecenia technicznego. Każda porada obiecująca dopasowanie strony do tego modelu jest dziś zgadywaniem.
To nie jest system generujący odpowiedzi zamiast wyników. Zapowiedziane funkcje dotyczą lepszego rozumienia zapytania i lepszego dopasowania istniejących treści, nie zastąpienia listy wyników czymś innym.
To nie jest coś, co dotyczy języka polskiego dzisiaj. Wdrożenia funkcji Google zwykle zaczynają się od rynku amerykańskiego i języka angielskiego, a do nas dochodzą z opóźnieniem liczonym w miesiącach albo latach.
Tu wchodzę w obszar przewidywań i chcę to jasno oznaczyć. Poniższe punkty to moje wnioski, nie zapowiedzi Google.
Jeśli wyszukiwarka będzie coraz lepiej obsługiwać zapytania złożone, to prawdopodobnie spadnie liczba wyszukiwań na jedną potrzebę informacyjną. Zamiast pięciu zapytań uściślających użytkownik zada jedno. Dla właścicieli stron oznacza to mniej okazji do pokazania się i większe znaczenie tego jednego wyniku.
Drugi wniosek: prawdopodobnie zyskają treści, które odpowiadają na pytanie w całości, wraz z kontekstem i zastrzeżeniami, a stracą treści zoptymalizowane pod pojedynczą frazę. To zresztą kierunek, w którym wyszukiwarka idzie konsekwentnie od kilku lat, więc nie jest to nowa wskazówka.
Trzeci, mniej oczywisty: rośnie znaczenie treści w innych językach. Jeśli model naprawdę przenosi wiedzę między językami, to polska strona może konkurować o widoczność z treścią, której autor nigdy nie pomyślał o polskim rynku. Nie wiem, jak szybko to nastąpi, ale kierunek jest niekorzystny dla treści, których jedyną zaletą jest to, że są po polsku.
Odpowiedź jest rozczarowująca i celowo taka pozostaje: dokładnie to samo, co warto było robić przed majem.
Czego nie robić: nie przebudowywać strategii treści w reakcji na zapowiedź, której wdrożenie ma potrwać lata i którego przebiegu nikt nie zna.
Zamykam praktyczną uwagą, bo takich zapowiedzi będzie więcej i warto mieć na nie metodę.
Czytam źródła pierwotne — komunikaty Google i wypowiedzi osób odpowiedzialnych za wyszukiwarkę — zanim przeczytam ich omówienia. Różnica między jednym a drugim bywa większa, niż się wydaje, bo omówienia zwykle wzmacniają ton i dopisują wnioski.
Rozdzielam trzy stany: zapowiedziane, testowane na wybranym rynku i wdrożone. To rozdzielenie oszczędza bardzo dużo niepotrzebnej pracy. Rzeczy zapowiedziane odnotowuję i wracam do nich, kiedy pojawi się informacja o wdrożeniu.
I ostatnia rzecz, może najważniejsza w tym roku: nowe modele językowe w wyszukiwarce są tematem świeżym i mało kto ma tu jeszcze doświadczenie z pierwszej ręki, ja też nie. Uczciwe powiedzenie „nie wiemy jeszcze, jak to zadziała” jest dziś lepszą podstawą decyzji niż pewne porady, których nikt nie ma na czym oprzeć.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |