Przejdź do treści
megapromotingPorozmawiajmy

Ekspertyza · SEO

Optymalizacja dla klasycznych wyszukiwarek: przechodzimy każdy adres, umieszczamy wynik w tabeli i naprawiamy to, co da się zweryfikować.

SEO techniczne i strukturalne — indeksowalność, kanoniczne adresy, mapa witryny generowana z danych, przekierowania, tytuły i opisy, cienka treść, szybkość mierzona w bajtach. Bez obietnic pozycji.

Już zbudowaneDwa własne wdrożenia, oba otwarte na dysku. Pierwsze: audyt tej strony — 249 adresów przebytych z bezpośrednimi żądaniami, 23 kolumny na adres, wynik w wersjonowanym pliku tabelarycznym obok kodu, plus naprawy, które z tego wynikły (kanoniczny adres rozwiązany raz na zawsze dla wszystkich tras, adres udostępniania, mapa witryny wygenerowana z danych). Drugie: `mega-seo-analyzer`, własny analizator z 16 modułami analizy i ważonym wynikiem zapisanym wprost w kodzie. Czego nie możemy potwierdzić i nie napiszemy: uzyskanych pozycji ani procentów wzrostu. Nie mamy publikowalnych pomiarów dla takich rzeczy.

Klasyczne SEO to rzemiosło inwentaryzacji, a nie pomysłów. Wyszukiwarka musi móc dotrzeć do każdej strony, zrozumieć, która jest jej oficjalną wersją, otrzymać tytuł i opis, które się nie powtarzają, oraz znaleźć dość treści, by zasługiwała na miejsce na liście. Prawie wszystko, co się tu psuje, da się policzyć, a to, co da się policzyć, da się naprawić.

Dlatego zaczynamy od pełnego przejścia, a nie od próbki. Na tej stronie wyszło 249 adresów, każdy z 23 kolumnami: kod odpowiedzi, adres kanoniczny, tytuł, opis, hreflang, liczba bloków danych strukturalnych, objętość widocznego tekstu i reszta. Wynik to wersjonowany plik tabelaryczny obok kodu, więc każde stwierdzenie poniżej można odtworzyć za pomocą poleceń z aneksu raportu.

Co wyszło: 244 adresy odpowiadają 200, a pięć przekierowuje. 131 stron nie miało adresu kanonicznego. 219 z 244 deklarowało stronę główną jako adres udostępniania, więc każde udostępnienie pokazywało złą stronę. 100 tytułów przekraczało 60 znaków, najdłuższy miał 106. 65 stron dzieliło jeden opis wygenerowany z szablonu. 96 stron miało poniżej 2.000 znaków widocznego tekstu. Pierwsze dwie naprawiono po jednej linii w podstawowej konfiguracji, która stosuje się do każdej trasy; reszta jest na liście roboczej, z zapisaną priorytetyzacją.

Ta strona jest jedną z trzech. SEO zajmuje się wyszukiwarkami, które zwracają listę linków. Widoczność w odpowiedziach generowanych przez modele to coś innego i ma własną stronę, bo steruje się tym inaczej i — ważne — nie da się obiecać. Odpowiedzi bezpośrednie i dane strukturalne są trzecie. To, co wspólne dla wszystkich trzech: strona musi być dostępna, renderowana po stronie serwera i mieć jeden oficjalny adres. Tę część robi się raz i działa dla wszystkich.

Co obejmuje

Praca, komponent po komponencie

Przechodzimy każdy adres, a nie próbkę

Bezpośrednie żądania do każdego znanego adresu, bez śledzenia przekierowań, z maksymalnie sześcioma żądaniami jednocześnie, aby nie przeszkadzać serwerowi, oraz 23 kolumnami na adres: kod, adres kanoniczny, tytuł, opis, hreflang, liczba bloków danych strukturalnych, objętość widocznego tekstu. Wynik to plik tabelaryczny, który przekazujemy. Na tej stronie: 249 adresów, z czego 244 odpowiadają 200, a 5 przekierowuje.

Oficjalny adres strony, rozwiązany raz dla całej witryny

131 stron nie deklarowało żadnego adresu kanonicznego, a 219 z 244 deklarowało stronę główną jako adres udostępniania — więc każde udostępnienie w sieciach pokazywało inną stronę. Obie rzeczy naprawiono po jednej względnej deklaracji w podstawowej konfiguracji, która rozwiązuje się dla każdej trasy osobno. To jedna linia kodu zamiast konwencji, którą każda nowa strona musiałaby pamiętać sama.

Mapa witryny wygenerowana z danych, sprawdzona po publikacji

Mapa buduje się ze źródeł treści i przechodzi przez końcową deduplikację — na tej stronie, 147 adresów, ta sama liczba w kodzie i w pliku serwowanym na produkcji. Skrypt uruchamiany po publikacji zawodzi, jeśli mapa traci stronę albo jeśli pojawiają się warianty adresu, które się nie otwierają. Czego dziś brakuje, powiedziane jako brak: wpisy nie mają daty ostatniej modyfikacji, a 93 adresy możliwe do zindeksowania nie są jeszcze uwzględnione.

Stare adresy dostają każdy osobną decyzję

Przy restrukturyzacji każdy istniejący adres dostaje werdykt: zostaje, przekierowuje się trwale albo znika. Na tej stronie w konfiguracji wyszły 43 przekierowania. Osobno sprawdzono też rzeczy, których nikt nie testuje: przejście z domeny bez `www` na tę z `www` jest jedno; adres z końcowym ukośnikiem przekierowuje poprawnie; adres zapisany wielkimi literami zwraca 404, więc nie ma duplikatu zapisu.

Tytuły, opisy i cienka treść, policzone

100 tytułów z 244 przekracza 60 znaków, najdłuższy ma 106 — ryzykiem jest obcięcie w wynikach. 33 opisy przekraczają 160 znaków, ale zero ich brakuje. Poważniej: 65 stron dzieli jeden opis wygenerowany z szablonu, a 30 z nich różni się między sobą łącznie o 240 bajtów. Mediana widocznego tekstu: 2.328 znaków, z 96 stronami poniżej 2.000. To liczby, nie wrażenia, i każda ma w tle listę adresów.

Własny analizator, z modułami i wagami zapisanymi w kodzie

Nasz analizator ma 16 modułów — na stronie, wydajność, mapa witryny, bezpieczeństwo, dostępność, infrastruktura nazw, informacje o rejestracji domeny, linki zewnętrzne, sieci społecznościowe, stos techniczny, pozycje, badanie słów kluczowych, audyt ogólny — plus moduły porównawcze: znajdowanie konkurentów, różnica słów kluczowych, różnica treści, punkty odniesienia. Wynik ogólny jest jawnie ważony w kodzie: wydajność 0,20, SEO 0,20, na stronie 0,15, bezpieczeństwo 0,15, odpowiedzi bezpośrednie 0,10, dostępność 0,10, social 0,10. Moduły, które zawodzą, nie obniżają wyniku — wypadają z ważenia, aby padnięta usługa zewnętrzna nie wygenerowała fałszywego raportu.

Przekierowania, które nie kosztują całej strony

Przekierowanie wykonane wewnątrz aplikacji buduje stronę i dopiero potem wysyła odpowiedź o przekierowaniu. Na tej stronie są 11 takich przypadków, z których każdy generuje ponad 200 KB HTML, zanim powie „idź gdzie indziej”. Działa, ale to marnotrawstwo; przeniesienie ich do konfiguracji to niewielka praca z bezpośrednim wpływem na budżet indeksowania. Jest na liście napraw, wpisana jako brak.

To, co widzi crawler, sprawdzone crawlerem, a nie założone

Poprosiłyśmy o pięć adresów z 18 różnymi identyfikatorami agenta i porównałyśmy kod, rozmiar oraz odcisk normalizowanej treści. Wszystkie dostają 200 i dokładnie tę samą treść co przeglądarka; `robots.txt` jest identyczny, 129 bajtów, dla wszystkich; nie ma blokady, wyzwania ani ograniczenia dla crawlerów. Jedyna odtwarzalna różnica — 237 bajtów mniej na jednej dynamicznej stronie, dla trzech agentów — pochodzi z samego frameworka, który wysyła im pełny, niestreamowany HTML, a więc więcej gotowej do wyrenderowania treści, nie mniej.

Czego nie obiecujemy, zapisane przed umową

Nie obiecujemy pozycji, procentów wzrostu ani liczby wizyt. Nie mamy publikowalnych pomiarów dla takich rzeczy i nie wymyślamy ich. To, co dostarczamy, jest weryfikowalne inaczej: lista adresów ze stanem każdego z nich, wykonane naprawy, sprawdzenie uruchomione po publikacji i mierzalna różnica między stanem przed i po — w bajtach, kodach i liczbie stron, nie w obietnicach.

Jak to wygląda

Trasa, krok po kroku.

01

Pełne przejście i tabela stanu

Pierwszym rezultatem jest plik tabelaryczny z każdym adresem i jego stanem w 23 kolumnach, plus komendy, które go odtwarzają. Od tego momentu każda dyskusja ma z tyłu wiersz. To też moment, w którym wychodzą na jaw adresy, o których nikt nie wiedział, że istnieją.

02

Naprawy strukturalne, w kolejności wpływu

Najpierw rzeczy, które rozwiązuje się w jednym miejscu i stosuje wszędzie: adres kanoniczny, adres udostępniania, zachowanie strony błędu, reguły dla robotów. Potem te, które wymagają pracy na stronie: tytuły, opisy, cienka treść. Kolejność nie podlega negocjacji — odwrotnie, naprawiasz sto stron ręcznie dla czegoś, co rozwiązuje się jedną linią.

03

Mapa witryny i przekierowania

Mapa łączy się ze źródłami danych, aby nowa strona wchodziła sama. Stare adresy dostają przekierowania trwałe w konfiguracji, nie wewnątrz aplikacji. Dostarczamy pełną listę decyzji, adres po adresie.

04

Kontrola, która pozostaje po nas

Dostarczamy skrypt uruchamiany po każdej publikacji, który upada, jeśli zniknął adres kanoniczny, jeśli mapa witryny straciła stronę albo jeśli `robots.txt` zaczęło blokować zasoby renderowania. Bez niego naprawy erodują w ciągu kilku miesięcy i nikt tego nie zauważa aż do następnego audytu.

05

Pomiar, z Twoimi narzędziami

Jeśli masz Search Console i narzędzie analityczne, nakładamy raportowanie na nie i ustalamy, co śledzimy. Jeśli ich nie masz, pierwszym krokiem jest ich posiadanie — i mówimy to z góry, nie później. Czego nie robimy: nie raportujemy pozycji z narzędzia zewnętrznego tak, jakby były to dane ze źródła.

Strona jako terytorium, weryfikacje jako warstwy na niej1kod odpowiedzi2adres kanoniczny3tytuł i opis4date structurate5objętość tekstu249 adresów, 23 kolumny, jeden plik tabelaryczny.
Strona jako terytorium, weryfikacje jako warstwy na niej

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Co czytamy z Twojej strony
Tylko to, co publiczne: HTML stron, nagłówki odpowiedzi, `robots.txt`, mapa witryny. Bezpośrednie żądania, z ograniczonym tempem — najwyżej sześć równolegle, aby indeksowanie nie przypominało ataku. Nie potrzebujemy dostępu administracyjnego do części audytowej.
Czego potrzebujemy od Ciebie, jeśli chcesz też część pomiarową
Dostęp do odczytu w Konsoli wyszukiwania i w narzędziu analizy ruchu. Bez nich możemy powiedzieć, co jest technicznie nie tak, ale nie to, co dzieje się w wynikach. Audyt tej strony został wykonany celowo bez takiego dostępu, a ograniczenie jest wyraźnie opisane w dokumencie — aby nikt nie mylił pomiaru technicznego z pomiarem ruchu.
Gdzie są wyniki
Arkusz z przebiegiem i raport pisemny znajdują się w repozytorium projektu, wersjonowane obok kodu. Nie w prezentacji i nie w narzędziu abonamentowym, z którego nie da się ich już wyciągnąć. Gdy zmienia się liczba, w historii pliku widać, kto i kiedy ją zmienił.
Retencja raportów
Żyją tak długo, jak żyje repozytorium projektu. Przeglądane dane są z definicji publiczne — to Twoje strony, tak jak widzi je każdy. Jeśli audyt dotyka stref wymagających uwierzytelnienia, osobno ustala się, co jest zapisywane i na jak długo.

Przykład

249 adresów, 23 kolumny i dwie linie kodu, które naprawiły 350 stron

Sytuacja

Niedawno przebudowana strona z około 250 publicznymi adresami. Wszystkie odpowiadały 200 i nic nie wyglądało na nie tak. Pytanie wyjściowe nie brzmiało „jak zwiększyć ruch”, tylko „co każda strona deklaruje o sobie”.

Co zbudowaliśmy

Przeszliśmy przez każdy adres bezpośrednimi żądaniami, bez śledzenia przekierowań, z maksymalnie sześcioma żądaniami równocześnie, i zapisaliśmy dla każdego 23 kolumny w arkuszu wersjonowanym obok kodu. Na tym uruchomiliśmy osobne sprawdzenia: kto deklaruje jaki adres kanoniczny, kto deklaruje jaki adres do udostępniania, jakie długości mają tytuły i opisy, ile stron dzieli ten sam opis z szablonu, ile tekstu widocznego ma każda z nich, co serwer zwraca dla 18 różnych identyfikatorów agentów, co oferuje w kompresji i protokole. Każda liczba została odczytana z rzeczywistej odpowiedzi, a nie wywnioskowana z konfiguracji.

Co z tego wyszło

244 adresy odpowiadają 200, pięć przekierowuje. 131 stron nie deklarowało adresu kanonicznego; 219 z 244 deklarowało stronę główną jako adres do udostępniania. Oba problemy zostały naprawione jedną deklaracją względną w podstawowym układzie — dwiema liniami, które stosują się do każdej trasy, zamiast poprawki na każdej stronie. Pozostałe ustalenia trafiły do planu z jedenastoma krokami, w kolejności wpływu: 100 tytułów powyżej 60 znaków, 65 stron z opisem z szablonu, 96 stron z mniej niż 2 000 znaków tekstu, 93 brakujące indeksowalne adresy w mapie, 11 przekierowań wykonanych wewnątrz aplikacji.

Czego nie mówi ten przypadek

Audyt został wykonany bez dostępu do Konsoli wyszukiwania i bez danych o ruchu, celowo, a ograniczenie jest zapisane w raporcie: możemy powiedzieć, co jest technicznie nie tak, nie to, co dzieje się w wynikach. Z jedenastu kroków planu dwa są dziś zastosowane; pozostałe to otwarte prace, nie odhaczone pozycje. Raport, który deklaruje wszystkie kroki zakończone w dniu, w którym został napisany, nie jest raportem.

Pytania

O co pytają ludzie, zanim zadzwonią

Jaka jest różnica między SEO, GEO i AEO, w skrócie?

Odbiorca jest inny. SEO kieruje się do silników, które zwracają listę linków — Twoja strona się pojawia, osoba klika. GEO kieruje się do modeli generatywnych, które składają odpowiedź i mogą cytować źródło; tam nie ma pozycji i nie ma gwarancji, więc pracuje się nad tym, co da się kontrolować, a nie nad wynikiem. AEO kieruje się do odpowiedzi bezpośrednich — wycinka, panelu informacji, odpowiedzi głosowej — i opiera się na poprawnych danych strukturalnych. Baza jest wspólna: strona dostępna, renderowana po stronie serwera, z jednym oficjalnym adresem. Tę część robi się raz.

Co dokładnie dostarczacie w audycie SEO?

Arkusz z każdym adresem strony i jego stanem w 23 kolumnach — kod odpowiedzi, adres kanoniczny, tytuł, opis, hreflang, bloki danych strukturalnych, objętość tekstu — plus raport pisemny z ustaleniami w kolejności wpływu, każde z miejscem w kodzie, kryterium i poprawką. I komendy, które odtwarzają każdą liczbę. Na tej stronie wyszły 249 wierszy; są dokładnie w repozytorium, obok kodu.

Gwarantujecie pierwsze miejsce?

Nie, ani żadne konkretne miejsce. Nie mamy publicznie publikowalnych pomiarów dla takich wyników i niczego nie wymyślamy. To, co możemy pokazać, to weryfikowalna różnica: ile stron nie miało przedtem adresu kanonicznego i ile ma go teraz, ile błędnie deklarowało adres do udostępniania, ile starych adresów zostało bez przekierowania. Na tej stronie liczby wyniosły 131 oraz 219 z 244. To są fakty; obiecane miejsce nie jest.

Skąd wiadomo, że to, co naprawiacie, pozostaje naprawione?

Z poziomu skryptu uruchamianego po każdej publikacji, który sprawdza adresy kanoniczne, kotwice treści, mapę strony i `robots.txt`, i kończy się błędem, jeśli czegoś brakuje. Naprawy SEO erodują dokładnie tak jak każda inna niewypowiedziana konwencja: ktoś dodaje nową stronę, zapomina o deklaracji i nikt tego nie zauważa aż do następnego audytu. Skrypt zauważa od razu.

Czy macie własne narzędzia, czy korzystacie z subskrypcji?

Oba mają sens, ale analizę techniczną wykonujemy własnym analizatorem: 16 modułów — na stronie, wydajność, mapa witryny, bezpieczeństwo, dostępność, infrastruktura nazw, rejestracja domeny, linki zewnętrzne, sieci społecznościowe, stos techniczny, pozycje, słowa kluczowe — plus moduły porównania z konkurencją. Ogólny wynik ma wagi zapisane w kodzie, nie ukryte: wydajność i SEO po 0,20, na stronie i bezpieczeństwo po 0,15, reszta po 0,10. Moduł, który zawodzi, wypada z ważenia zamiast generować fałszywy wynik.

Co robicie ze stu prawie identycznymi stronami?

Oznaczamy je jako ryzyko, nie jako szansę. Na tej stronie 100 z 147 adresów w mapie to kombinacje usługa × domena, a 65 stron dzieli jeden opis z szablonu — 30 z nich różni się między sobą łącznie o 240 bajtów. Wyszukiwarka traktuje to jak treść produkowaną na skalę, a ryzykiem jest sankcja, nie wzrost widoczności. Rozwiązaniem jest prawdziwa treść na każdej stronie albo mniej stron. Nie zalecamy generowania stron jako strategii.

Czy szybkość ma znaczenie dla SEO?

Ma znaczenie, ale nie w formie, w jakiej zwykle się ją sprzedaje. Nie dajemy wyniku laboratoryjnego, bo łatwo nim manipulować i nie mówi on, jak żyje odwiedzająca osoba. Dajemy zmierzone bajty: ile waży skompresowany HTML, co jest przesyłane przy każdej nawigacji, co zawierają pakiety JavaScript, czy serwer oferuje nowoczesną kompresję i nowy protokół. Na tej stronie: nie oferuje ani Brotli, ani HTTP/2, katalog tłumaczeń kosztuje około 70 KB po kompresji przy każdej nawigacji, a pakiet 443 KB zawiera cztery katalogi językowe, z których używany jest tylko jeden. Wszystkie trzy są na liście napraw.

Blokujecie crawlery sztucznej inteligencji?

To decyzja po stronie właścicielskiej witryny, nie nasza, i wymaga oddzielenia trzech kategorii, które dziś na większości witryn są traktowane identycznie: crawlery wyszukiwarek, które odsyłają ludzi z powrotem, agenci uruchamiani przez osobę, która zażądała strony, oraz crawlery treningowe. Reguły dla nich są niezależne. Na tej witrynie istnieje w tej chwili jedna ogólna reguła, więc stanowisko jest domyślne — i mówimy to, zamiast udawać, że to strategia. Szczegóły należą do strony widoczności w odpowiedziach generowanych.

Czego nie robicie?

Nie kupujemy linków i nie budujemy sieci stron. Nie generujemy stron na skalę, żeby pokrywać kombinacje słów. Nie raportujemy pozycji pobranych z narzędzia zewnętrznego tak, jakby były danymi ze źródła. I nie ogłaszamy audytu zakończonego bez pliku tabelarycznego i poleceń, które go odtwarzają — raport, którego nie da się samodzielnie zweryfikować, nie jest audytem, tylko opinią.

Na czym opierają się powyższe stwierdzenia (14 źródeł)

14 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy