SEO News #99 – rozwój SGE, snippet linkowanych stron, uwaga na 304

Search Generative Experience stanie się dostępne dla kolejnych krajów. Google testuje funkcję wyników pokazującą linkujące strony. Odpowiedź serwera 304 (Not modified) może szkodzić SEO. Poza tym: Core Update dalej we wdrożeniu, eksperymentalne ładowanie JavaScript i Bing Chat w Chrome.

1. Search Generative Experience: kolejne kraje, dane o używaniu i ostateczna forma linków

Google ogłosiło, że Indie i Japonia dostaną dostęp do Search Generative Experience (SGE) – eksperymentalnej wyszukiwarki zintegrowanej z generatywnym AI. Nowa wyszukiwarka po raz pierwszy wyjdzie więc poza Stany Zjednoczone.

Przy okazji tego newsa firma podzieliła się także paroma wnioskami z danych o wykorzystaniu nowej wyszukiwarki. W skrócie:

• Najbardziej zadowolona grupa użytkowników SGE to osoby młode (w wieku 18-24 lata), którym podoba się możliwość zdobywania informacji poprzez zadawanie pytań uzupełniających w rozmowie z wyszukiwarką,
• Osoby testujące SGE zadają pytania o wiele dłuższe i bardziej konwersacyjne niż w klasycznej wyszukiwarce,
• Ogólnie rzecz biorąc, ludzie wyraźnie testują w SGE zapytania, które nigdy nie przyniosłyby oczekiwanego efektu w zwykłej wyszukiwarce,
• Mimo wszystko użytkownicy cenią sobie w SGE dostęp do klasycznych wyników (a nie tylko wygenerowanej odpowiedzi).

Google ostatecznie zdecydowało też, że linki do źródeł w odpowiedziach generowanych przez SGE będą prezentowane za pomocą rozwijanego menu.

Jak widać wyżej, odnośniki do źródeł będą dodawane przy konkretnych informacjach, w formie rozwijanego menu zawierającego karty ze stronami.

Czy to dobre rozwiązanie? Jak dla mnie o wiele lepiej prezentowało się linkowanie do źródła na zasadzie przypisu, które Google testowało wcześniej (SEO News #95). To jednak tylko moja opinia – w końcu to Google ma dane.

2. Funkcja wyników pokazująca stronę, która do nas linkuje

Google testuje nową funkcję, która pod klasycznym wynikiem wyszukiwania „dokleja” inne strony, wspominające o danym adresie.

Jak widać wyżej, nowa funkcja wyników „Mentioned in:” („Wspomniane w:”) to karuzela linków z fragmentami treści, która pojawia się pod wynikiem. Fragmenty te cytują zdania wspominające znaleziony adres; w tym wypadku: bazę zasobów edukacyjnych Moz.

Cel takiego snippetu zdaje się być bliski roli funkcji „O tym wyniku”, wprowadzonej globalnie w kwietniu tego roku (SEO News #77) – czyli uwiarygadnianiu źródeł. Wprowadzanie takiego rozszerzenia na dużą skalę mogłoby być jednak ryzykowne.

Mechanizm dobierania wspomnień do wyniku musiałby być naprawdę nieomylny lub mieć jakiś rodzaj „weryfikacji”. Inaczej znając jego działanie można by podpinać się pod strony konkurencji, a nawet robić im zły PR bezpośrednio w wynikach.

Na ten moment test tej funkcji jest bardzo ograniczony (wyłącznie do kilku/kilkunastu dużych serwisów). Na jego temat nie wypowiedział się też nikt z Google – pozostaje nam więc tylko obserwować.

3. Twoje strony zwracają 304: not modified? Uwaga na błędy!

Jak się okazuje, z kodem 304 jest trochę jak z patelnią na kuchence: samo w sobie mega przydatne, ale zostawione na chwilę samo może skończyć się tragedią. I to właśnie o tym, co może stać się w tej chwili nieuwagi napisał na LinkedIn’ie Garry Illyes.

Kod odpowiedzi HTTP 304 - Not modified (nie zmodyfikowano) informuje roboty internetowe, że treść odwiedzanego adresu nie zmieniła się od ostatniej wizyty. Taka informacja może zaszkodzić, gdy strona zwróci z jakiegoś powodu pusty adres z kodem 200 (OK).

Sytuacja wygląda tak:

1. Googlebot wysyła żądanie do serwera.
2. Serwer zwraca pustą stronę z kodem 200 (OK) – ze względu na jakiś błąd.
3. Googlebot uznaje to za tymczasowy problem – więc planuje ponowne skanowanie.
4. Jako że treść adresu (niezaładowana przy ostatniej wizycie) nie uległa zmianie, przy następnym skanowaniu serwer zwraca Googlebotowi kod 304 (Not modified).
5. Dla bota taka informacja oznacza jednak, że dany URL dalej zwraca pustą stronę (bo taka była ostatnia sytuacja, która wg. odpowiedzi serwera nie została zmodyfikowana).

W efekcie Googlebot uznaje więc, że napotkany wcześniej problem jest trwały i przestaje skanować URL – co kończy się wyindeksowaniem i wpływa negatywnie na pozycjonowanie całego serwisu.

Jak pisze Illyes: „Czy coś takiego się zdarza? Tak. Często? Nic z tych rzeczy. Ale i tak warto mieć to gdzieś z tyłu głowy, bo debugowanie tego to absolutny koszmar”.

4. August 2023 Core Update – wdrożenia ciąg dalszy

August 2023 Core Update trwa. W zeszłym tygodniu (SEO News #98) opisywałem jego efekty po pierwszym tygodniu wdrożenia. Teraz przyjrzymy się drugiemu.

Wykres zmienności wyników po tygodniu wygląda tak:

Jak widać, po szczycie 25 sierpnia wyniki wyraźnie się uspokoiły. W ostatnim tygodniu, pomiędzy 30 a 31 sierpnia, w Polsce widać było jeszcze skok zmienności. Nic nie wskazuje jednak na to gdzie miał on miejsce – najpewniej był mocno rozproszony.

W sieci dalej krąży pełno jednostkowych przypadków dużych zmian w ruchu/widoczności. Od 3 września wykresy globalnie skierowały się już jednak w dół – co wskazuje na końcówkę aktualizacji.

Po przeglądzie forów / wątków mogę wysunąć jeden wniosek: Google skupiło się w tej aktualizacji na kwestiach technicznych.

W rankingach spadają głównie strony, które mają jakieś zgrzyty w optymalizacji. Te, które mają mocne techniczne podstawy trzymają się bez zmian lub rosną.

Ogólnie trzeba przyznać, że ten Core Update nie miał aż tak intensywnego wpływu na wyniki, jaki zdawał się na początku zapowiadać.

5. Eksperymentalna funkcja Google Chrome przyśpiesza strony

Google ogłosiło nowy testowy sposób na uruchamianie JavaScript: scheduler.yield, który może znacznie poprawić responsywność serwisów. Szczególnie tych, które mają wysokie wyniki INP (Interaction to next Paint) – czyli nowego wskaźnika Core Web Vitals (SEO News #83).

Jedna z przyczyn kiepskiego INP to długo ładujące się skrypty JS (powyżej 50 ms).

Można powiedzieć, że są one trochę jak tiry hamujące osobówki na jednopasmowych drogach ekspresowych. Choć wszyscy z tyłu mogliby jechać szybciej, to one nie mogą przyśpieszyć.

Dotychczas problem ten obchodziło się przerzucając taki ładujący się zbyt długo skrypt na koniec kolejki. To jednak nie rozwiązywało problemu w kwestii responsywności, bo długi task często i tak był potrzebny do uzyskania odpowiedzi na akcję użytkownika.

Google próbuje więc podejść do sprawy inaczej.

Funkcja scheduler.yield też zatrzymuje zbyt długo wykonywany skrypt, ale tylko po to, by przetworzyć priorytetowo task dotyczący interakcji z użytkownikiem.

Wracając do przykładu z tirem: scheduler.yield sprawia, że taski dotyczące interakcji z użytkownikiem stają się taką „karetką na sygnale”.

Nasz tir (zbyt długo ładujący się skrypt) ustępuje im pierwszeństwa, ale nie przepuszcza wszystkich jak leci.

Dzięki temu, Ci którzy naprawdę muszą być szybko – są, a ważny (choć powolny) task jest wykonywany możliwie jak najszybciej. W efekcie strona zyskuje więc na responsywności.

API scheduler.yield jest dostępne eksperymentalnie w Chrome 115 (tutaj zapisy do testów). Można też testować lokalnie (offline). Jeśli chcesz wdrożyć na próbę i zobaczyć, jak zmieni to działanie Twojego serwisu, zapoznaj się ze wpisem na blogu Chrome.

Jeśli zajmujesz się techniczną stroną SEO, to warto mieć to rozwiązanie na oku. Po wyjściu z fazy eksperymentalnej i wdrożeniu INP na miejsce FID mechanizm ten może zyskać na znaczeniu.

6. Bing Chat działa już na Chrome!

Początkiem sierpnia (SEO News #95 – Bing Chat poza Edge) wspominałem o tym, że Bing Chat staje się powoli dostępny poza przeglądarką Microsoftu. Teraz, miesiąc później, donoszę, że działa już w 100% na Chrome. Niebawem pojawi się też wsparcie Safari.