Blog

Lekcje SEO z naprawiania własnej strony

Przez kilka dni czytaliśmy własną stronę tak, jak robi to wyszukiwarka, i znaleźliśmy sześć rzeczy wartych naprawy. Każda strona deklarowała dwa bloki FAQ, Google jako miniaturę używało dekoracyjnej poświaty tła, kilka stron szablonów pozycjonowało się na frazy, na które nie odpowiadały, a nowa sekcja serwisu była blokowana przez nasz własny edge na stagingu. Nic z tego nie było dramatyczne. Wszystko po cichu kosztowało nas widoczność.

Strona w jednym akapicie

mythex.ai to aplikacja jednostronicowa, którą renderujemy wstępnie w czasie budowania: skrypt przechodzi przez wszystkie trasy, zapisuje dla każdej statyczny plik HTML i wstrzykuje tytuł strony, opis i dane strukturalne (blok JSON-LD, który mówi wyszukiwarkom, czym jest strona — zobacz czym są dane strukturalne). Większość tego, co poniżej, dzieje się w tym kroku renderowania, bo to właśnie ten HTML czyta crawler.

1. Każda strona podawała się za stronę FAQ

Objaw. Nasz szablon HTML zawierał w danych strukturalnych blok FAQPage obowiązujący w całym serwisie, z adresem URL wskazującym na /faq. Renderowanie wstępne dokładało potem własny FAQPage każdej strony. Efekt: każda strona miała dwa takie bloki, a nasza polityka prywatności mówiła Google, że jest stroną FAQ.

Dlaczego to ważne. Google oczekuje co najwyżej jednego FAQPage na stronę. Drugi, wskazujący gdzie indziej, to coś, co może obniżyć wartość znaczników strony, a nie tylko zostać zignorowane.

Naprawa. Globalny blok zniknął. Znaczniki FAQ każdej strony pochodzą teraz z jednego miejsca, łącznie z samą stroną /faq, która buduje je z pełnej listy pytań. Strony bez FAQ nie deklarują już żadnych, co jest uczciwą odpowiedzią. Renderowanie wstępne przerywa też budowanie, jeśli jakakolwiek strona znowu będzie miała więcej niż jeden FAQPage. Zasada, która żyje tylko w czyjejś pamięci, prędzej czy później zostaje złamana; zasada wymuszona przez build nie.

2. Google używało dla nas złego obrazka

Objaw. W wynikach wyszukiwania miniaturą Mythex była miękka, pulsująca poświata za hero na stronie głównej — dekoracyjny obraz tła — zamiast naszej karty udostępniania.

Dlaczego tak się stało. Nigdy nie powiedzieliśmy Google, który obrazek reprezentuje stronę, więc wybrało jeden, który znalazło.

Naprawa. Dwie strony tego samego problemu:

  • Wskaż obrazek strony. Strona główna ma teraz węzeł WebPage z primaryImageOfPage wskazującym na kartę udostępniania, a dane strukturalne każdej wstępnie wyrenderowanej strony zawierają jej własny obrazek (obrazek udostępniania strony lub domyślny).
  • Ukryj dekorację. Obrazki tła są teraz zabronione w robots.txt i serwowane z nagłówkiem noindex, noimageindex, więc nie trafiają do wyszukiwania grafik ani do miniatur.

3. Wyszukiwarki znały tylko nasze logo

Nasze znaczniki Organization zawierały nazwę, logo i kilka linków do mediów społecznościowych — samo branding, nic więcej. Wyszukiwarki budują panel wiedzy o firmie na podstawie faktów rejestrowych, więc dodaliśmy te z naszej licencji handlowej: nazwę prawną, datę założenia, założyciela i adres rejestrowy. Numer telefonu celowo pominęliśmy.

4. Strony szablonów odpowiadały na złe pytanie

Objaw. Search Console pokazywało, że trzy strony szablonów zbierają wyświetlenia i żadnych kliknięć. Jedna była wysoko na „content strategist portfolio” i jego warianty, druga na „best italian restaurant website design”, a jeszcze jedna na klaster wokół „agile board” — połowa tych zapytań zawierała słowo „free”. Pozycje mieściły się od połowy dwudziestki do pięćdziesiątek.

Dlaczego. Każda strona odpowiadała na inne pytanie niż to, które zadano. Ktoś, kto chciał zobaczyć, jak wygląda dobry projekt włoskiej restauracji, trafiał na stronę sprzedającą mu kreator.

Naprawa. Każda z trzech stron ma teraz sekcję napisaną pod wyszukiwanie, a nie pod produkt, tytuł i opis słowami, które ludzie faktycznie wpisują, oraz FAQ wartościowe dla znaczników, które już były emitowane.

Ten sam commit naprawił cichszy problem. Blok „powiązane szablony” brał pierwsze cztery szablony w kategorii, więc każdy szablon portfolio linkował do tych samych czterech portfolio, a reszta kategorii nie miała żadnych linków wewnętrznych. Zastąpiliśmy go pierścieniem uporządkowanym według podkategorii: każda strona szablonu ma dokładnie cztery linki przychodzące i cztery wychodzące. Wstępnie wyrenderowany HTML wypisuje teraz te linki — wcześniej istniały dopiero po uruchomieniu JavaScriptu, czego crawler może nigdy nie zrobić.

5. Informowanie Bing o nowych stronach zaraz po wdrożeniu

Google ignoruje IndexNow, protokół służący do powiadamiania wyszukiwarek o zmianie adresu URL. Bing, Yandex i Seznam z niego korzystają — a indeks Binga to to, z czego czyta wyszukiwarka ChatGPT. Aplikacja AI do budowania stron, której asystenci AI nie potrafią znaleźć, to szczególny rodzaj porażki.

Oczywiste podejście, czyli wysyłanie całej mapy witryny przy każdym wdrożeniu, prowadzi do ograniczenia limitu, a większość wdrożeń nie zmienia niczego, na czym zależy wyszukiwarkom. Dlatego skrypt porównuje mapę witryny, którą serwis podaje teraz, z tą właśnie zbudowaną, i wysyła tylko różnicę.

Dwa szczegóły sprawiły, że to zadziałało:

  • Zrób migawkę przed wdrożeniem. Punkt odniesienia trzeba zapisać, zanim nowy build trafi na produkcję. Potem „żywa” mapa witryny jest już nową i każda różnica wychodzi pusta.
  • Na razie tylko nowe strony. Nasza mapa witryny nie ma dat lastmod, więc skrypt ogłasza nowe strony, ale nie zmiany w istniejących. Nadanie każdemu adresowi daty builda oznaczałoby, że cała strona jest „zmieniona” przy każdym wdrożeniu — dokładnie ten spam, którego chcieliśmy uniknąć.

Uruchamia się tylko przy wdrożeniach produkcyjnych i nigdy nie przerywa builda: w chwili uruchomienia strona jest już żywa, a ping do wyszukiwarki nie jest warty czerwonego wdrożenia.

6. Nasz własny edge mówił „nie znaleziono”

Gdy uruchamialiśmy strony /ai (więcej o nich w landing page dla każdego rodzaju biznesu), staging pokazywał „Not found” dla wszystkich z nich, podczas gdy statyczny hosting serwował je bez problemu.

Usługa przed naszymi domenami marketingowymi przepuszcza tylko listę dozwolonych ścieżek; wszystko inne dostaje twardy błąd 404. /ai było nowe i nie znalazło się na liście. Dodaliśmy /ai i /ai/* oraz test, który sprawdza, że przechodzą. Mały błąd, ale dokładnie taki, który sprawia, że nowa sekcja jest niewidoczna dla crawlerów, a nikt tego nie zauważa.

Co z tego wynieśliśmy

  • Czytaj HTML, który czyta crawler. Większość z tych problemów była niewidoczna w przeglądarce, a oczywista w pliku wyrenderowanym wstępnie.
  • Zamieniaj zasady SEO w sprawdzenia w buildzie. „Jeden FAQPage na stronę” jest teraz wymuszany, a nie zapamiętywany.
  • Mów wyszukiwarkom, co masz na myśli. Jeśli nie powiesz, który obrazek lub które fakty cię reprezentują, zgadną.
  • Search Console pokazuje, jakie pytanie zadali ludzie. Wyświetlenia bez kliknięć zwykle oznaczają, że strona odpowiada na inne pytanie.
  • Wysyłaj różnice, a nie wszystko. Powiadamianie tylko o tym, co się zmieniło, pozwala trzymać się limitów.

Jeśli robisz to samo dla strony, którą zbudowałeś, nasze przewodniki SEO dla stron zbudowanych z AI i konfiguracja Google Search Console obejmują podstawy.

Mythex · Pricing · Zbuduj wszystko z AI · Szablony stron i aplikacji · Mythex w porównaniu · Słownik budowania aplikacji z AI · Darmowe narzędzia do budowania aplikacji z AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)