Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Najbardziej kosztowne nieporozumienia, jakie widuję u klientów, nie dotyczą stawek ani linków. Dotyczą tego, że dwie osoby w tej samej firmie pracują nad tą samą frazą, nie wiedząc o sobie. Ktoś od SEO pisze obszerny poradnik, ktoś od kampanii buduje pod to samo zapytanie grupę reklam i stronę docelową, a potem oba zespoły dziwią się, dlaczego ruch rozjeżdża się między adresami, których nikt nie planował mieć obok siebie.
Wystarczy jeden wspólny dokument, żeby to zniknęło. Nie mówię o narzędziu za kilkaset złotych miesięcznie — mówię o kalendarzu publikacji, w którym każdy wiersz ma wpisane, po co powstaje dany tekst i kto go użyje. Prowadzę takie arkusze u kilku klientów i po kilkunastu miesiącach widzę, że główna wartość nie leży w planowaniu, a w tym, że nikt już nie pisze niczego „na wszelki wypadek”.
Poniżej opisuję, jak taki kalendarz układam: co musi być w wierszu, skąd biorę tematy, jak wpisuję do niego terminy narzucone przez Google i czego się na tym nauczyłem po drodze.
SEO i SEM planują w innych jednostkach czasu i to jest źródło całego problemu. Tekst pozycjonowany zaczyna pracować po tygodniach albo miesiącach, więc kalendarz SEO myśli kwartałami. Kampania płatna działa od godziny po zatwierdzeniu, więc kalendarz SEM myśli tygodniami, a w sezonie dniami. Kiedy każdy zespół prowadzi swój plik, po pół roku mają dwa niekompatybilne obrazy tego samego serwisu.
Widzę wtedy zawsze te same trzy skutki. Pierwszy: kanibalizacja fraz, czyli dwa albo trzy adresy w serwisie odpowiadające na to samo zapytanie, z których żaden nie jest wyraźnie mocniejszy. Drugi: strony docelowe kampanii budowane obok struktury serwisu, niepodlinkowane znikąd, niewidoczne dla robota i nieujęte w audytach. Trzeci, najbardziej irytujący: kampania startuje, a tekst, który miał ją wspierać, jest jeszcze u copywritera.
Wspólny kalendarz nie sprawia, że zespoły planują w tym samym tempie — to niemożliwe i niepotrzebne. Sprawia, że widzą cudze terminy zanim ustalą własne. To cała mechanika i to zwykle wystarcza.
Kalendarz zaczyna działać dopiero wtedy, gdy wiersz odpowiada na pytanie „po co”, a nie tylko „kiedy”. Minimalny zestaw kolumn, z którego nie schodzę:
Kolumny na wyniki dopisuję dopiero po publikacji i trzymam je z prawej strony, żeby nie mieszać planu z raportem. Kusi, żeby wrzucić wszystko do jednego widoku, ale wtedy nikt nie chce tego arkusza otwierać.
Research robię raz i dla obu kanałów naraz, bo dane po stronie kampanii są dla SEO bezcenne, a rzadko ktoś z nich korzysta.
Podstawą jest raport wyszukiwanych haseł z Google Ads. To jedyne miejsce, gdzie widzę realne zapytania z informacją o konwersjach — Search Console pokaże mi zapytania organiczne, ale nie powie, które z nich sprzedają. Frazy, które w kampanii dowożą konwersje przy wysokim koszcie kliknięcia, to pierwsi kandydaci na treść organiczną. Odwrotnie też to działa: zapytania z dużą liczbą wyświetleń i niskim CTR w Search Console podpowiadają, gdzie warto dokupić ruch, dopóki tekst nie dojdzie do formy.
Do tego dokładam Planer słów kluczowych po propozycje i sezonowość oraz Google Trends, gdy muszę porównać dynamikę dwóch określeń w czasie. Wszystko trafia do jednego arkusza roboczego, z którego dopiero potem przenoszę pozycje do kalendarza. Rozdzielenie tych dwóch plików jest ważne — kalendarz ma być listą zobowiązań, nie magazynem pomysłów.
Zasada, której pilnuję przy przenoszeniu: jedna intencja to jeden temat i jeden adres. Jeśli dwie pozycje z researchu mają tę samą intencję, łączę je w jeden mocniejszy tekst, zamiast planować dwa słabsze.
Część kalendarza wypełniają daty narzucone z zewnątrz i to one decydują o kolejności prac. W tym roku jest ich wyjątkowo dużo.
Od 30 czerwca w Google Ads nie można już tworzyć rozszerzonych reklam tekstowych — nowe teksty pisze się wyłącznie do elastycznych reklam w wyszukiwarce. Dla kalendarza treści to zmiana konkretna: brief na stronę docelową powinien od razu zawierać zestaw nagłówków i opisów w formacie, który da się swobodnie zestawiać, a nie dwa gotowe zdania reklamowe.
Druga data to 1 lipca 2023 roku, od którego Universal Analytics przestanie zbierać dane. Google ogłosił to w marcu i uważam, że migracja do Google Analytics 4 powinna siedzieć w kalendarzu jako projekt z własnymi terminami, a nie jako zadanie „do zrobienia kiedyś”. Bez działającego pomiaru wszystkie kolumny z wynikami po publikacji będą później nieporównywalne.
Trzecia rzecz dotyczy kampanii produktowych: trwa automatyczna migracja kampanii Smart Shopping do Performance Max i według zapowiedzi Google ma się zakończyć jeszcze w tym kwartale. W miesiącach, w których konto to przechodzi, nie planuję dużych premier treści — wyniki są wtedy trudne do zinterpretowania i lepiej nie nakładać na siebie dwóch zmian.
Warto też odnotować, że kilka dni temu Google ponownie przesunął wycofanie plików cookie firm trzecich, tym razem na 2024 rok. Daje to trochę powietrza, ale nie zmienia kierunku — planowanie treści zbierających dane własne, na przykład materiałów za zapisem, jest wciąż jednym z sensowniejszych punktów w rocznym kalendarzu.
Kalendarz, w którym wiersz kończy życie w dniu publikacji, jest tylko listą zadań. Dokładam do każdego wiersza dwie rzeczy.
Pierwsza to data przeglądu, zwykle trzy miesiące po publikacji. W tym dniu sprawdzam, czy tekst wszedł na pozycje, o które szło, i czy strona bywa używana jako docelowa w kampanii. Jeśli nie wszedł, wiersz wraca do kalendarza jako aktualizacja i tym razem dostaje konkretny brief naprawczy, a nie ogólne „rozbudować”.
Druga to informacja zwrotna do kampanii: czy po publikacji dało się wyłączyć albo ograniczyć płatny ruch na tę frazę. To najbardziej praktyczne uzasadnienie istnienia takiego arkusza — pokazuje pieniądze, a nie pozycje. Odwrotny wniosek jest równie użyteczny: jeśli po kwartale organik nie odbija, a fraza konwertuje, kampania na niej po prostu zostaje.
Aktualizacje traktuję w kalendarzu równorzędnie z nowymi tekstami. Na dojrzałym serwisie to zwykle one dają szybszy efekt, a mimo to prawie zawsze przegrywają walkę o miejsce w planie z czymś nowym.
Nie potrzebujesz dedykowanego systemu. Wszystkie kalendarze, które u mnie przetrwały dłużej niż rok, stoją na arkuszu w Arkuszach Google. Powód jest prozaiczny: wchodzą do niego ludzie z trzech różnych działów i nikt nie musi się niczego uczyć ani logować do kolejnego narzędzia.
Do arkusza dokładam jeden lekki raport w Google Data Studio, podłączony do Search Console i Google Ads, żeby przy przeglądzie nie trzeba było otwierać czterech paneli. Nie sklejam go z kalendarzem — plan i pomiar trzymam osobno, bo mają inny rytm aktualizacji i innych odbiorców.
Jeśli firma pracuje w systemie do zadań, przenoszę tam wyłącznie kolumnę zadaniową: właściciel, status, data gotowości. Cała warstwa merytoryczna, czyli frazy i intencje, zostaje w arkuszu. Próba wciśnięcia researchu do narzędzia projektowego kończyła się u mnie za każdym razem tym samym: dane były w dwóch miejscach i w żadnym aktualne.
Pierwszy i najkosztowniejszy: zbyt dużo kolumn. Mój pierwszy arkusz miał ich ponad dwadzieścia, łącznie z szacowaną trudnością frazy i planowaną liczbą znaków. Po dwóch miesiącach uzupełniałem go już tylko ja, bo dla pozostałych osób wypełnienie wiersza było zadaniem samym w sobie.
Drugi: planowanie na pół roku w przód z dokładnością do dnia. Realnie sztywno planuję najbliższy miesiąc, kolejne dwa mam rozpisane na tygodnie, a dalej trzymam tylko listę tematów bez dat. Kalendarz, który rozsypuje się przy pierwszej zmianie priorytetów, przestaje być otwierany.
Trzeci: brak jednej osoby odpowiedzialnej za sam arkusz. Nie za treści — za arkusz. Ktoś musi raz w tygodniu przejść po statusach i wyprosić z kalendarza pozycje, które od kwartału stoją w tym samym miejscu. Bez tego dokument zamienia się w archiwum dobrych intencji.
I ostatni, najbardziej banalny: pisanie tekstów bez wpisanego odbiorcy po stronie kampanii. Zdarzało mi się dowieźć porządny poradnik, który do niczego w kampaniach nie pasował, bo powstał z rozpędu w rytmie „dwa wpisy w miesiącu”. Jeśli w wierszu nie umiem uzasadnić, po co ta treść istnieje, to jej nie planuję — i to jedna z niewielu zasad, przy których nie idę na kompromis.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |