Podział na techniczne SEO i contentowe w dużych organizacjach medialnych występuje odkąd pamiętam. Było tak, kiedy pojawiłem się w Onecie, podobnie działa to w szwajcarskim Blick czy niemieckim T-online. Zazwyczaj funkcjonują dwa zespoły SEO – jeden pracuje bliżej produktu, drugi bliżej redakcji.
Sam zaczynałem pracę jako Editorial SEO Specialist, gdzie moim głównym zadaniem było wsparcie redakcji. Do dzisiaj uśmiecham się, gdy wspominam, jak na cotygodniowych statusach raportowaliśmy przełożonemu tak zwane „bieżące wsparcie redakcji” (ukróciłem ten obyczaj, gdy sam zostałem szefem zespołu).
Co oznacza „bieżące wsparcie redakcji”?
Pod tym pojęciem kryje się oczywiście szereg różnych zadań, których przełożony oczekiwał od nas: od wyszukiwania trendów pod Google News, przez optymalizację tych trendów, raportowanie wyników do redakcji, prowadzenie statusów z redakcjami, szkolenia i monitoring ich efektywności, po analizy konkurencji oraz budowanie content planów.
Problem polegał na tym, że w rzeczywistości czasu wystarczało jedynie na wyszukiwanie trendów pod Google News i ich optymalizację. Gdy pojawiał się silny trend (najczęściej jakaś tragedia) i trzeba było utrzymać frazy „zamach”, „Bruksela” na jedynce w Google News, ruch na stronie wzrastał gwałtownie, a temu wszystkiemu towarzyszyły emocje. Jeśli ktoś miał dobre relacje z redakcją i wcześniej dobrze je zbudował, takie dni były kwintesencją pracy w Editorial SEO.
Były jednak dni – i była ich zdecydowana większość – kiedy „bieżące wsparcie redakcji” w rozumieniu: dobór słów kluczowych, wyszukiwanie trendów i tematów, optymalizacja, kolejny content plan sprawiały, że energia do działania znikała momentalnie, a mózg był wyjałowiony. Dla mnie osobiście to był moment, w którym organizm wołał o pomoc i ucieczkę z tego etapu SEO. To nie była łatwa decyzja, ale trafna. Zanim na dobre przeniosłem się do technicznego SEO, musiałem przede wszystkim się doszkolić. Zacząłem uczyć się języków programowania, pogłębiłem swoją wiedzę dotyczącą działania aplikacji. Czas nauki wykorzystałem do usprawnienia monotonnej i nudnej pracy przy redakcji.
Jakie umiejętności powinien posiadać Editorial SEO Specialist?
Najpierw pojawił się Google Discover, który zmienił zasady gry i sprawił, że stare, sprawdzone działania w Google News przestały mieć zastosowanie w tym produkcie (no może nie wszystkie). Potem przyszło AI, które znacząco obniżyło próg wejścia do realizacji zadań będących dla typowego specjalisty pracującego przy redakcji czarną magią.
Te dwie powyższe kwestie na nowo zdefiniowały moje podejście do tego, kim powinien być specjalista SEO pracujący przy redakcji. W dużym uproszczeniu, powinien to być ktoś podobny do mnie, gdy zaczynałem swoją przygodę z programowaniem – nie byłem wtedy technicznym specjalistą SEO, natomiast każdą nowo zdobytą wiedzę mogłem wykorzystać w codziennych, wcześniej nudnych zadaniach. To był jeden z lepszych okresów mojej pracy jako SEOwca. Dzisiaj wykorzystując API do GSC, KnowledgeGraph, Search API, Chat GPT oraz wiele innych narzędzi, można bardzo szybko dostarczyć redakcji niezbędnych insightów, które pomogą jej w codziennej pracy. Paradoksalnie nie trzeba znać się na kodowaniu, bo dostępne są narzędzia no-code typu dify.ai, które dobrze realizują proste i bardziej skomplikowane zadania (chociaż ja cały czas jestem fanem oldschoolowego podejścia).
Czy twoim głównym zadaniem w ciągu dnia jest szukanie trendów dla redakcji?
Jeżeli odpowiedź na to pytanie brzmi tak, to znaczy, że marnujesz czas. Nie oszukuj się – połowa znalezionych przez ciebie trendów nie wpadnie do Google Discover, a ty zmarnujesz czas redakcji (i stracisz jej zaufanie, to będzie twój koniec budowania relacji SEO – Redakcja). Co więcej, dobrze wyszkolona redakcja sama ogarnie wszystkie trendy. Jeżeli specjalista SEO przychodzi i twierdzi, że trzeba o czymś napisać, świadczy to o niskiej dojrzałości redakcji i wskazuje na kiepskiego specjalistę, który z tą redakcją pracuje. Proponuję w ramach prac rozwojowych napisać proste narzędzia, które dostarczą istotnej wiedzy na temat obsługiwanego serwisu i pozwolą ustabilizować ruch w Google Discover:
- Klasyfikator kategorii trendów w serwisie. Może być uruchamiany codziennie. Kategorie z Google trends znajdziesz tutaj: https://github.com/pat310/google-trends-api/wiki/Google-Trends-Categories. Potrzebujesz do tego:
- URL ze swojego serwisu z danego dnia lub innego badanego okresu
- Jina AI lub innego readera AI do pobrania zawartości treści z adresu URL
- API np. Open AI, które z odpowiednim promptem pomoże dobrać i powiązać treści z odpowiednimi kategoriami
- API z GSC, jeżeli chcesz dołożyć do tego dane trafficowe
- Punkty a-c możesz zastosować też wobec swojej konkurencji
- Narzędzie do odpytywania API Knowledge Graph. Po co? Jeżeli chcesz zweryfikować np. jakość swoich tagów, to jest to dobry początek. Takie narzędzie pomoże też przy wszelkiego rodzaju pracach związanych z Tag Clean Up.
- Narzędzie do budowania trójników semantycznych i Content Brief dla redakcji. To jest trochę bardziej skomplikowane i wymaga solidnych promptów. Może kiedyś się podzielę swoim własnym podejściem do tego tematu. Jeżeli ktoś chce spróbować swoich sił, to zachęcam do rozpoczęcia od tego: https://github.com/microsoft/graphrag/tree/main.
Zmiana, jaką od kilku lat przechodzi Editorial SEO, jest znacząca. Z nudnego pingowania redakcji i walki o pozycje w Google News, ten obszar pracy stał się dużo ciekawszy. Redakcja kiedyś zwykła mówić o nas „Ci magicy od SEO”. To stwierdzenie faktycznie nabiera magicznego charakteru dzięki dostępnym dziś narzędziom. Nie chodzi o to, że specjalista Editorial SEO w mediach ma się nagle przekształcić w specjalistę technicznego, ale powinien posiadać ten pierwiastek technicznego SEO i chęć rozwoju – w przeciwnym razie jego praca wkrótce może stać się zbędna.