GSC Opportunity Finder: jak zamienić CSV z Search Console w plan SEO

Google Search Console daje świetne dane, ale w surowym eksporcie łatwo ugrzęznąć. Masz setki albo tysiące wierszy: query, page, kliknięcia, wyświetlenia, CTR, pozycja. Niby wszystko jest, ale brakuje odpowiedzi na najważniejsze pytanie: od czego zacząć?

GSC Opportunity Finder powstał jako małe narzędzie do priorytetyzacji. Wrzucasz CSV z Search Console, a ono układa dane w kategorie: quick wins, okazje CTR, topic expansion, intent mismatch i low priority.

Nie chodzi o to, żeby narzędzie podjęło decyzję za specjalistę. Chodzi o to, żeby szybciej oddzielić wiersze, które warto obejrzeć dziś, od wierszy, które mogą poczekać.

Otwórz GSC Opportunity Finder albo sprawdź repo: github.com/pokazmnie/gsc-opportunity-finder.

Dlaczego nie wystarczy sortowanie po CTR

Najprostsza pokusa: sortujesz eksport po wyświetleniach, potem patrzysz na niski CTR i mówisz „tu trzeba poprawić title i meta description”.

Czasem tak. Ale nie zawsze.

Jeśli zapytanie nie pasuje do intencji strony, niski CTR nie jest prostą okazją. Przykład: strona jest poradnikiem, a query wygląda jak zapytanie transakcyjne. Albo odwrotnie: landing sprzedażowy łapie informacyjne frazy z bardzo szerokim kontekstem. Możesz polerować snippet przez godzinę, a problemem nadal będzie niedopasowanie intencji.

Dlatego w tym narzędziu zasada jest taka: najpierw intent, potem CTR.

Jak działa obecna wersja

Aktualna wersja to v0.1 CSV MVP. Działa w przeglądarce i czyta plik lokalnie. Dane nie trafiają do API ani do bazy.

Narzędzie rozpoznaje kolumny z eksportu GSC po polsku i po angielsku, normalizuje liczby, liczy score 0-100 i przypisuje każdy wiersz do jednej z kategorii. Potem możesz filtrować wyniki i wyeksportować raport Markdown.

Najważniejsze reguły są proste:

• INTENT_MISMATCH ma pierwszeństwo, jeśli intencja zapytania nie pasuje do strony;
• QUICK_WIN to zwykle pozycje 5-15, dużo wyświetleń, niski CTR i sensowna intencja;
• CTR_OPPORTUNITY to wysokie pozycje z dużą liczbą wyświetleń, ale słabym klikaniem;
• TOPIC_EXPANSION to frazy dalej od topu, które mogą sugerować rozbudowę tematu.

Co daje wersja browser-only

Największy plus tej wersji to prywatność i prostota. Eksport z GSC może zawierać dane, których nie chcesz wysyłać do losowego narzędzia. Tutaj plik jest obrabiany lokalnie w przeglądarce.

Drugi plus: to działa jako nauka. Budując ten tool, łatwo zrozumieć, że średnia pozycja na poziomie strony potrafi mylić. Strona może rosnąć, ale średnia pozycja spada, bo dochodzą nowe zapytania na dalszych pozycjach. Dlatego analiza query + page jest praktyczniejsza niż patrzenie tylko na agregat.

Trzeci plus: raport Markdown. Można go wkleić do notatki, do briefu, do GitHub issue albo dać agentowi jako kontekst do dalszej pracy.

Czego ta wersja jeszcze nie robi

Nie łączy się jeszcze z GSC API. Nie trzyma historii. Nie robi automatycznego grupowania tematów. Nie patrzy na sezonowość, device, country ani typ wyniku w SERP. To wszystko są sensowne kolejne kroki, ale nie były potrzebne do pierwszej wersji.

MVP miało odpowiedzieć na jedno pytanie: czy da się szybko zamienić CSV z GSC w praktyczną kolejkę działań? Odpowiedź brzmi: tak, da się. Teraz można dopiero sensownie rozwijać warstwę bardziej analityczną.

Jak będę to rozwijał

Najbliższy krok to praca na prawdziwych eksportach. Chcę sprawdzić, gdzie reguły klasyfikacji są zbyt proste, gdzie trzeba dodać wyjątki i jak wygląda raport po kilku różnych typach stron.

Potem są trzy naturalne ścieżki:

• wersja SQL, która grupuje dane po query, page i temacie;
• wersja Python/pandas do analizy większych eksportów;
• integracja z GSC API, żeby raport można było generować cyklicznie.

Docelowo to może być część większego workflow: GSC export → klasyfikacja → brief zmian → aktualizacja treści → porównanie efektów po 28 dniach.

Gdzie śledzić stan projektu

Działające demo jest tutaj: GSC Opportunity Finder.
Żywa karta projektu, wersja i historia zmian są w Case studies.
Kod, CLI, przykładowe dane, SQL i wersja Python są w repozytorium GitHub.

Ten wpis jest krótkim opisem zamysłu. Case study będzie aktualizowane przy kolejnych wersjach, bo narzędzie ma rosnąć razem z realnym workflow pracy na danych z Search Console.