basic-openŻywy dashboard: każda podesłana treść → werdykt wg klucza. Weryfikacja w kodzie/audycie, nie „wg docs". Stan: 16.07.2026 · sesja 5
O co chodzi: Google renderuje JS, Bing prawie nie (110/126 wejść bez JS), boty AI wcale → treść krytyczna musi być w initial HTML. Boty AI to już 57,5% ruchu (więcej niż ludzie). llms.txt martwe (97% plików bez żądań).
WERDYKT: ✅ architektura zgodna punkt-w-punkt
| Wymóg z artykułu | Nasz stan |
|---|---|
| Treść krytyczna w initial HTML | ✅ OpenCart = SSR (PHP→HTML); audyt T1: cena w surowym HTML testem curl -A ClaudeBot |
| JSON-LD z serwera (nie useEffect) | ✅ moduł Argo SEO emituje w PHP (event), w HTML-u |
| Title / canonical z serwera | ✅ natywnie + D5.3 (title paginacji server-side) |
Linki <a href>, nie onClick/hash | ✅ nawigacja OC = <a href> (JS tylko sort/limit — i tak Disallow w robots) |
| Obrazy w HTML, nie JS-lazy | ✅ natywne loading=lazy (atrybut HTML) + srcset 2x |
| Boty AI: wpuszczać search/retrieval | ✅ robots prod świadomie wpuszcza boty AI (udokumentowana decyzja) |
| Limit Google 2 MB/URL | ✅ nasze strony ~55 KB raw / ~10 KB gzip — 40× zapasu |
| llms.txt | ✅ słusznie nie robimy (97% bez żądań — zgodne z P2-warunkowym księgi) |
O co chodzi: Discover = spersonalizowany feed Google (mobile; desktop w PL wciąż niedostępny). Treści przychodzą same, bez zapytania. Kanał głównie publisherski (newsy/lifestyle/poradniki); e-commerce wg samego artykułu = „zróżnicowany potencjał, niższa intencja zakupowa". Update 02/2026 karze clickbait/curiosity-gap.
WERDYKT: ⚠️ kanał warunkowy — przez blog (fala D16/17) + 1 quick-win do wzięcia
| Wymóg Discover | Nasz stan |
|---|---|
| CWV: LCP ≤2,5 s / INP / CLS | ✅ cały program perf — CLS ≤0.1 zweryfikowane, TBT 0 (zero-jQuery→INP), LCP czeka na pomiar prod |
| Obrazy: wydajność (WebP) | ✅ WebP transparentny + srcset 2x |
max-image-preview:large | ❌ NIE MAMY (zweryfikowane grep-em — brak w całym kodzie) → 💡 DO WDROŻENIA |
| Article/NewsArticle schema, daty, autor | ❌ n/d — nie mamy bloga (moduł w bibliotece work/moduły/blog = NIEKOMPLETNY, sam model) |
| RSS/feed treści | ❌ n/d — j.w. |
| E-E-A-T, nagłówki, świeżość | 🔵 fala treści D16/17 (celowo po technicznej) |
O co chodzi: Canonical-101 — rel=canonical konsoliduje duplikaty na jeden URL. Google traktuje go jako hint, nie dyrektywę (przy sprzecznych sygnałach może zignorować → „spójne sygnały" w całym serwisie). Lista błędów: łańcuchy A→B→C, canonical→301/404, noindex+canonical, względne URL-e, paginacja kanonizowana do strony 1. Bez danych/badań — poradnik podstawowy.
WERDYKT: ✅ mamy zabezpieczone w całości — nic do wdrożenia
| Zasada z artykułu | Nasz stan |
|---|---|
| Self-canonical, absolutny URL | ✅ audyt T6: 1×, absolutny, self, ładny URL (po D3/SEO URLs) |
| Paginacja: NIE kanonizować do str. 1 | ✅ audyt T7: self-canonical na ?page=N — słynny bug OC nieobecny; + D5.3 title „strona N" |
| Parametry sort/filter/sesja | ✅ Disallow parametrów w robots (wariant ①) + canonical konsoliduje surowe route= (D3.6: 200 + canonical — zweryfikowane w sesji 4) |
| Sitemap tylko canonicale | ✅ reguła księgi (rozdz. 4) wdrożona w module — sitemap z ładnych slugów, bez noindex/301/404; T3 PASS |
| Bez łańcuchów / canonical→301/404 | ✅ moduł Argo SEO: redirecty 301 z auto-wpisem przy zmianie sluga; canonical zawsze na bieżący slug (200) |
| Spójne sygnały (linkowanie wewn.) | ✅ FIX-2 (sesja 1): banery/linki na ładne URL-e; home 0× surowych route= |
| Canonical w HTML z serwera (nie JS) | ✅ SSR — spójne z werdyktem [JS26] |
| noindex + canonical razem = sprzeczność | ⚠️ niuans: w trybie testowym (maintenance ON) współistnieją — akceptowalne dla dev (robots i tak Disallow:/); na prodzie flaga OFF → nie występuje |
O co chodzi: Podstawy CWV — trzy metryki z progami (LCP ≤2,5 s · INP ≤200 ms · CLS ≤0,1), techniki optymalizacji (WebP, defer JS, critical CSS, width/height, third-party audit). Najważniejsza teza: Google rankuje po danych TERENOWYCH (CrUX/RUM), nie po Lighthouse — dobry wynik labu ≠ dobre UX realnych userów. +0,1 s ładowania = −8% konwersji.
WERDYKT: ✅ to dosłownie nasz program (fale 3+7, D9/D21) — jesteśmy DALEJ niż artykuł
| Rekomendacja z artykułu | Nasz stan |
|---|---|
| LCP: WebP, kompresja, bez blokującego JS, cache | ✅ WebP transparentny · 0 render-blocking (critical CSS + defer + PurgeCSS ~20 KB gzip) · gzip/brotli + cache statyków · + fetchpriority na LCP (artykuł tego nawet nie wspomina) |
| INP: mniej JS, podział zadań, mały DOM | ✅ zero-jQuery storefront (2 skrypty deferred), TBT 0 ms — realny INP potwierdzi RUM na prodzie |
| CLS: width/height, rezerwacja miejsca | ✅ nasza robota sesji 3–4: aspect-ratio w critical + width/height na hero — zweryfikowane Lighthouse: 0.09–0.093 wszędzie (≤0,1 „good") |
| Third-party: audyt skryptów | ✅ zero third-party w render-path (analityka = dataLayer bramkowany consentem) |
| Field data > lab data (CrUX/GSC decyduje) | ✅ nasza zasada „prod = pomiar" (lokalny HTTP/1.1 myli) — artykuł wzmacnia priorytet D11 RUM + D21.10 scoreboard (w backlogu, czeka na ruch prod) |
| Serwer <200 ms | 🔵 infra D22 (edge-cache TTFB ≤100 ms + OPcache/Redis) — decyzja PM, plan CDN rozpisany |
font-display: optional | ⚠️ niuans: my mamy swap (self-host, @font-face w inline critical) — CLS zweryfikowany good, więc bez zmiany; optional = agresywniejszy wariant, nie warto ruszać działającego |
O co chodzi: Podstawy sitemap XML — struktura, limity (50k URL / 50 MB), sitemap index, typy (obrazy/wideo/news). Najmocniejsze tezy: priority/changefreq = Google oficjalnie ignoruje („strata czasu"); lastmod tylko PRAWDZIWY (fałszowanie dat → Google „nauczy się go ignorować"); w sitemapie wyłącznie canonicale bez noindex/301/404. Bez e-commerce, bez hreflang, bez IndexNow.
WERDYKT: ✅ mamy w całości — zweryfikowane w kodzie generatora, nie „wg docs"
| Zasada z artykułu | Nasz stan (grep feed/argo_sitemap.php) |
|---|---|
Ignorować priority/changefreq | ✅ 0 wystąpień w kodzie — emitujemy tylko loc+lastmod (dokładnie reguła Aneksu C księgi) |
lastmod prawdziwy, nie fałszowany | ✅ z date_modified produktu/kategorii; suby indeksu z MAX(date_modified) — komentarz w kodzie wprost: „Real lastmod" |
| Sitemap index przy skali | ✅ sitemapindex + sub-sitemapy z paginacją (limit per plik) — architektura gotowa na 50k+ z założenia |
| Tylko canonicale, bez noindex/301/404 | ✅ URL-e z $this->url->link() (ładne slugi = canonicale), tylko status=1 + store-scoped; audyt T3 PASS |
Zgłoszenie: robots.txt Sitemap: + GSC | ✅ robots prod ma Sitemap: (wzorzec) · GSC/Bing = w kolejce na prod (kody weryfikacyjne w module gotowe) |
| Nie blokować sitemapy w robots | ✅ prod OK; dev Disallow:/ celowy (środowisko testowe) |
| Czego artykuł NIE zna | ✅ my mamy dalej: IndexNow w planie (P2, debounce — Bing), hreflang (moduł v0.6 na tej gałęzi), sitemap „news" n/d (brak bloga) |
O co chodzi: Hreflang-101 — rel=alternate hreflang kieruje usera do właściwej wersji językowej/regionalnej. Zasady: kody ISO 639-1 (+region ISO 3166-1), x-default, wzajemność (A→B wymaga B→A) + self-reference, wskazywać tylko istniejące canonicale, nie kłócić się z canonical. 3 metody: head / HTTP header / sitemap. Bez danych liczbowych.
WERDYKT: ✅ mamy — świeża implementacja v0.6 na TEJ gałęzi (commit 141aeac), zweryfikowana w kodzie
| Zasada z artykułu | Nasz stan (grep argo_seo.php §HREFLANG v0.6) |
|---|---|
Składnia <link rel=alternate hreflang> w head | ✅ emisja przez event do head, poprawny escaping; wpisy z tabeli oc_argo_seo_hreflang (admin: dropdown język + URL) |
x-default | ✅ emitowany, celowo na końcu listy (ORDER BY w zapytaniu) |
| Self-reference (wymóg Google) | ✅ komentarz w kodzie wprost: „własna domena też musi być wpisem (self-referencing hreflang — wymóg Google)" |
| Wzajemność / komplet odnośników | ✅ strażnik w kodzie: minimum 2 wpisy albo zero emisji („Google wymaga kompletu wzajemnych odnośników"); operacyjnie: ten sam zestaw wpisów na każdej domenie |
| Nie wskazywać złych odpowiedników | ✅ najlepszy detal implementacji: hreflang TYLKO na stronie głównej — sklepy mają RÓŻNE slugi na domenach językowych, więc mapowanie domena→domena jest prawdziwe tylko dla home; na podstronie wskazywałby zły URL (dokładnie błąd nr 3 z artykułu). Lepiej brak niż błędny. |
| Zgodność z canonical | ✅ hreflang → korzenie domen, canonical home = self — sygnały niesprzeczne |
| Flaga / kill-switch | ✅ argo_seo_hreflang_status — zgodnie z D1 (standard modułów) |
O co chodzi: UCP = standard komunikacji sklep↔agent AI (Google + 20 partnerów: Shopify, Walmart, Stripe, Visa…), ogłoszony 11.01.2026. Sklep publikuje manifest /.well-known/ucp (capabilities: checkout/discount/fulfillment), agent (np. Gemini) kupuje bez wchodzenia na stronę; płatności przez AP2. Timeline wg artykułu: 2026 integracja wielkich → 2027–28 masowa adopcja → 2030 „brak UCP = utrata głównego strumienia". Piloty: +15–25% konwersji; 46% konsumentów odda AI powtarzalne zakupy.
✅ przygotowani na dziś — „bilet wstępu" (feed+schema) mamy 🔵 protokół = P3 obserwować (słusznie)
| Co sklep ma przygotować (wg artykułu) | Nasz stan |
|---|---|
| Jakość danych produktowych (PIM) > design | ✅ dokładnie nasza strategia: PIM strażnikiem kompletności (EAN/wymiary/materiał, D14.1); księga: „kompletność atrybutów w PIM = pozycja w AI" |
| Ustrukturyzowane dane produktu | ✅ JSON-LD Product komplet (sku/gtin13/priceValidUntil/availability/brand) w SSR + GMC feed (Shopping Graph = zaplecze AI Mode) |
Manifest /.well-known/ucp | 🔵 księga już to zna: tabela PIM poz. 8 „(horyzont) manifest UCP per sklep" — czeka na stabilizację specu i ścieżkę PL/OpenCart |
| Płatności agentowe AP2 | 🔵 wymaga wsparcia dostawców płatności (u nas PayU/PragmaPay) — poza naszą kontrolą, obserwować |
| Checkout agentowy dostępny? | ❌ w PL nie — księga (nowsza niż artykuł, 07/2026): „checkouty USA-only — obserwować, dane przygotowywać" |
O co chodzi: 05.02.2026 Google ogłosiło pierwszy DEDYKOWANY update Discover (oddzielny od Core Updates). Trzy filary: lokalność (priorytet wydawców z kraju użytkownika — cios w zagraniczne agregatory), anty-clickbait (AI wykrywa „obietnice bez substancji"), granularny autorytet tematyczny (ocena sekcja-po-sekcji, nie globalnie — mały serwis branżowy może konkurować z dużym portalem). Bez danych liczbowych, bez e-commerce. Prognoza dotarcia do PL: Q2 2026.
WERDYKT: ❌ nic nowego technicznie — checklist z karty #2 bez zmian 💡 2 strategiczne wiatry w plecy dla fali treści
| Filar updatu | Znaczenie dla nas |
|---|---|
| Lokalność (priorytet kraju użytkownika) | 💡 przyszły blog PL dla userów PL dostaje przewagę nad zagranicznymi agregatorami — wiatr w plecy dla D16/17 |
| Granularny autorytet tematyczny | 💡 najważniejsze dla nas: niszowy blog sklepu (wąska specjalizacja = nasza kategoria produktowa) może konkurować z dużymi portalami — dokładnie model „treść, która pozycjonuje i karmi agentów" z księgi rozdz. 8 |
| Anty-clickbait | ✅ już w pakiecie „Discover-ready" (karta #2, akcja w tabie Do zrobienia): nagłówki konkretne, bez curiosity-gap |
O co chodzi: 24.03.2026 ruszył rutynowy spam update (ulepszenie SpamBrain, bez nowych kategorii naruszeń; wdrożenie „kilka dni" vs 27 dni w 08/2025). Rekomendacja: przy spadkach → GSC + przegląd zgodności z politykami; ponowna ocena po karze trwa miesiące. Zero danych, zero e-commerce.
WERDYKT: ✅ czyści z założenia — antywzorce anty-spamowe wpisane w księgę
| Powierzchnia spamowa | Nasz stan |
|---|---|
| PBN / katalogi / masowy szeptany | ✅ jawnie ZAKAZANE w antywzorcach księgi („po SpamBrain jawnie ryzykowne" — Aneks C) |
| Rating bez realnych opinii (kara ręczna) | ✅ AggregateRating emitowany warunkowo — tylko gdy realne recenzje (zweryfikowane w sesji 3) |
| Scaled content / site reputation / expired domain abuse | ✅ n/d — zero takich praktyk; przyszła fala treści = people-first (reguły księgi rozdz. 8) |
| Monitoring po updatach | ✅ dokładnie nasz plan D14: GSC od dnia 1 + oś czasu zmian nakładana na updaty Google — to jest rekomendacja z artykułu, mamy ją w procesie |
O co chodzi: Discover = 20+ niezależnych pipeline'ów selekcji (nazwy z dekompilacji SDK: content „autostrada" → moonstone „wzmacniacz" amplifikujący po sygnałach klików z pierwszych 4–6 h → mustntmiss/aura autorytet; osobno: breaking, lokalne, wideo, social/creatorcontent +33×). 58% URL-i żyje w wielu pipeline'ach; personalizacja statycznych profili umiera (−73%). Zastrzeżenie autora: dane obserwacyjne FR, interpretacje.
WERDYKT: 💡 najcenniejsza strategia treści z całej serii — prosto do teczki D16/17
| Ustalenie | Znaczenie dla nas |
|---|---|
shoppinginspiration = SILOS e-commerce (mediana świeżości 3,7 dnia, brak amplifikacji do szerokich pipeline'ów) | 💡 kluczowe: czysty ranking/recenzja produktu („TOP 10 X") utknie w silosie. Ucieczka: kąt redakcyjny (trend branżowy, kontekst rynkowy, stanowisko eksperta) → treść wchodzi do content/aura → szansa na moonstone |
| Amplifikacja moonstone = sygnały klików z pierwszych 4–6 h | 💡 tytuł + obraz główny muszą robić CTR OD RAZU (drugi impuls 6–12 h = jesteś w moonstone); wzorce godzinowe w GA4/GSC = diagnoza pipeline'u |
Pipeline lokalny (webkicklocalstories, 67% ekskluzywów) | 💡 spójne z #8: lokalność + nisza = ścieżki bez konkurencji gigantów |
| Personalizacja statycznych profili wygaszana (−73%) | ✅ nic nie robić — potwierdza, że nie ma sensu „optymalizować pod persony" |
creatorcontent +33× (75% z X) | 🔵 marginalne dla sklepu; ewent. sygnał na przyszłość dla działań social PM |
O co chodzi: Artykuł ma 5 niezależnych warstw tytułu: H1 (redakcyjny) · meta title (SERP, frazy na początku, ≤60–65 zn.) · schema headline (JSON-LD, Top Stories) · anchory promocyjne (linki wewn., +35% CTR) · og:title (social + to on steruje nagłówkiem w Google Discover; 3× kliknięć po przeróbce). Liczby z praktyki wydawcy, nie z badań. Wyłącznie prasa — zero e-commerce.
WERDYKT: ✅ warstwy strukturalne mamy 🔵 craft nagłówków = teczka D16/17
| Warstwa tytułu | Nasz stan |
|---|---|
| H1 + meta title | ✅ natywne OC (H1 = nazwa produktu/kategorii; meta_title per rekord) + szablony/fallbacki z PIM (księga rozdz. 5) + D5.3 title paginacji |
og:title niezależny od title | ✅ zweryfikowane w kodzie: moduł emituje og:title na produkcie (l. 647), kategorii (753), home (783) — pełen OG (audyt T10 PASS); dziś = nazwa produktu (dla sklepu OK) |
| Anchory linków wewnętrznych | ✅ księga rozdz. 8 pkt 7 ma regułę per typ strony: do produktu = pełna nazwa/SKU, do artykułu = tytuł/H2 |
Schema headline (Article) | 🔵 n/d do czasu bloga — w pakiecie Discover-ready (Article schema) już uwzględnione |
| Craft: dwuczęściowy title, cyfry, emocjonalny og:title | 🔵 warsztat pisania = fala treści D16/17 |
O co chodzi: Kompletna lista „co jest kluczowe w technicznym SEO dla e-commerce" od Gemini: architektura/3-klik, crawl budget, duplikacja/canonical, nawigacja fasetowa, CWV, mobile-first, dane strukturalne, HTTPS/URL/hreflang, obsługa wyprzedanych. Idealny audyt pokrycia całego programu — zweryfikowany w kodzie.
WERDYKT: ✅ ~95% pokryte (potwierdzone w kodzie) 💡 1 realna luka: return/shipping w schema
| Dział checklisty | Nasz stan |
|---|---|
| 1. Architektura / 3-klik / breadcrumbs / linki wewn. | ✅ hierarchia OC + BreadcrumbList (schema) + reguły linkowania (księga rozdz. 8) |
| 2. Crawl budget / robots / sitemap 200-only / 404→301 | ✅ robots prod (Disallow prywatne) + generator sitemap (200-only, index+suby, real lastmod) + moduł 301 auto |
| 3. Duplikacja / canonical / warianty / unikalne opisy | ✅ canonical (T6/T7) + ProductGroup dla wariantów (księga) + opisy = PIM/fala treści |
| 4. Nawigacja fasetowa (blokada filtrów) | ✅ wariant ①/②/③ z karty (Disallow parametrów) |
| 5. CWV + WebP/AVIF + lazy + CDN | ✅ cały program perf (CLS 0.09, 0 render-blocking, WebP+srcset, lazy); AVIF ⚠️ nie robimy (WebP wystarcza); CDN = D22 plan |
| 6. Mobile-first / RWD / brak intruzywnych popupów / tap targets | ✅ RWD theme; newsletter = blok inline, NIE modal/interstitial (zweryfikowane w szablonie → brak kary mobile) |
| 7. Schema: Product / AggregateRating / BreadcrumbList / MerchantReturnPolicy & ShippingDetails | ✅ Product komplet (sku/gtin13/brand/offers/priceValidUntil/itemCondition/availability) + AggregateRating warunkowo + BreadcrumbList · ❌ BRAK hasMerchantReturnPolicy + shippingDetails (grep potwierdził) → Do zrobienia |
| 8. HTTPS / przyjazne URL / hreflang | ✅ SEO URLs (T5) + hreflang v0.6; HTTPS = prod (T8, po deployu) |
| 9. Wyprzedane: temp (blok+notify) / trwałe (301 lub 404/410) | ✅ 301 przez moduł; stock status OC; ⚠️ „Powiadom o dostępności" = feature (fala UX), nie schema — do teczki |
| Monitoring: GSC / Screaming Frog / PageSpeed | ✅ wszystkie w tabie 🧰 Narzędzia |
O co chodzi: Praktyk z 20-letnim stażem o swoim stacku AI (ChatGPT=dyskusja · Codex=kod · Claude=analityka; ~900 mikronarzędzi w 3–4 mies., 22–25 serwerów MCP na Ubuntu za 30 €/mies.), metodyce (mikronarzędzia→mastery→orkiestratory, strojenie GLOBALNE scoringami, human-in-the-loop), patencie Google badającym kompletność atrybutów karty produktu, monitoringu promptów (GSC→prawdopodobny prompt→luka treści) i playbooku widoczności w LLM-ach (YouTube/shorts najszybsze, PR/wzmianki zewnętrzne, „LLM-y kochają liczby").
WERDYKT: ✅ walidacja naszych fundamentów (encje/cena/kompletność = nasz PIM+schema) 💡 metody do teczki: shorts, PR, prompt-gap, heurystyki analityczne
| Teza z podcastu | Nasz stan |
|---|---|
| Patent Google: kompletność atrybutów karty — parametr w katalogu (np. deska 12 cm), a brak w HTML+schema = sygnał in minus; Google „wie, czego brakuje" | ✅ walidacja wprost naszej strategii: PIM strażnikiem kompletności (D14.1), specyfikacja tabelą HTML (księga r.8 p.3), JSON-LD Product komplet — dokładnie ta obrona |
| Cena = encja / sygnał jakości — ukrywanie cen (deweloperka) → gorszy ranking | ✅ cena SSR w surowym HTML od baseline'u (audyt T1 — nasz pierwszy PASS) + JSON-LD price; antywzorzec „0,00 zł + AJAX" już w księdze |
| Segment ruchu AI w analityce (wejścia z ChatGPT/Perplexity/Gemini/Copilot) | ✅ już w planie D14.6 księgi + dataLayer GA4 (moduł v0.7 na tej gałęzi) |
| Bing/Copilot ważny (korporacje = tylko Copilot) | ✅ weryfikacja Bing w module (msvalidate) + SSR (Bing nie renderuje JS — #1); Bing w planie D15 |
| YouTube/shorts = najszybsza droga do AI Overviews (2–3 dni vs tygodnie dla tekstu); shorts ≤3 min, 1 problem, title+tagi+krótki opis „na tezę" | 🔵 nowy punkt ⑤ strategii treści (teczka D16/17) — kanał wymaga decyzji/zasobów PM |
| LLM-y cytują wzmianki na OBCYCH stronach → PR+SEO muszą współpracować; gościnne artykuły/podcasty budują widoczność w czatach | 🔵 nowy punkt ⑥ strategii treści; księga ma już „Off-site lite" (8-OFF) — to go wzmacnia |
| Monitoring promptów: z zapytań GSC (ślady AI Overviews/AI Mode) wnioskować prawdopodobny prompt → dopasowanie do treści; <30% = luka → nowy content | 💡 metoda do D15/D16 po wpięciu GSC na prodzie (dodane do P3) |
| GSC: rosnąca kolejka „Crawled – not indexed" = słaby content (polityki scaled/scraped 2025) | 💡 do checklisty monitoringu D14 (dodane do P3) |
| Heurystyki: sesja z LLM-referrera <15 s = scraper; konwersja = 100% człowiek; badanie promptów po API < web-scraper (Surfer SEO) | ℹ️ zapisane w Info — przyda się przy D11 RUM/analityce na prodzie |
| Skills vs mikronarzędzia: skille bez scoringów/warstw/kontekstu, vendor lock-in (Claude umiera = odcięty); narzędzia = trwałe dane + fallback multi-vendor | ℹ️ metodyka zapisana w Info — rama dla przyszłych narzędzi Argo (nasze moduły = „narzędzia", nie „skille": samoinstalujące, z danymi w DB) |
| LLM-y uczą się partiami (knowledge cutoff), Google/Bing na bieżąco; z LLM-ów nie da się „wykasować" | ℹ️ Info — kontekst do zarządzania oczekiwaniami (czas propagacji marki w czatach) |
O co chodzi: Ekspercka korekta naszego planu schema. Główne tezy: polityki zwrotów/wysyłki globalnie na OnlineStore (nie per-Offer; Offer tylko wyjątki — tak zaleca Google), sztuczne priceValidUntil +1 rok = semantycznie fałszywe (najpilniejsza korekta), SearchAction wyciąć, AggregateRating-nuans, reguła ProductGroup dla opcji, ItemList↓P3, FAQPage ≠ „optymalizacja AI", dedykowane właściwości przed additionalProperty, panel = jedno źródło dla JSON-LD i GMC (MC > markup w hierarchii Google).
OCENA: 9/10 — przyjęte niemal w całości, tezy zweryfikowane 💡 przebudowa akcji → pakiet „Schema v0.8"
| Teza opracowania | Nasza weryfikacja | Skutek |
|---|---|---|
priceValidUntil +1 rok = fałsz semantyczny | ✅ POTWIERDZONE W KODZIE: linia 700 strtotime('+1 year'); live render: 2027-07-16 (dziś+1 r). Upgrade zamiast gołego usunięcia: oc_product_special.date_end istnieje w DB (moduł go nie czyta) → emitować REALNĄ datę końca promocji, bez promocji pomijać | 🎯 v0.8 pkt 1 (najpilniejsze) |
OnlineStore + globalne hasMerchantReturnPolicy/hasShippingService; Offer = wyjątki | ✅ trafne — org-level preferowane przez Google (returns 2024, shipping 2025); OnlineStore to podtyp Organization = zmiana bezpieczna. Do dodania pola panelu (polityka zwrotów/wysyłki, sameAs, vatID) | 🎯 v0.8 pkt 2–3 (zastępuje starą akcję „per-Offer") |
| Panel = jedno źródło (JSON-LD + feed GMC); dane MC > markup | ✅ zgodne z hierarchią Google merchant-listings; nasz GMC feed już żyje w module — spinamy ustawienia | zasada architektury v0.8 |
| SearchAction wyciąć (sitelinks searchbox off 21.11.2024) | ✅ zgodne z naszym Aneksem C — wisiało jako osobna decyzja | 🎯 wchodzi do pakietu v0.8 (pkt 5) |
| „Rating bez opinii = kara ręczna" zbyt kategoryczne | ⚠️ słuszny niuans (kara = markup fikcyjny/niewidoczny/niezgodny; oceny liczbowe bez tekstu są OK). Nasz kod już zgodny (emisja przy realnych recenzjach widocznych na stronie); do poprawy tylko sformułowanie w księdze | korekta księgi przy konsolidacji po 3/3 |
| ProductGroup: opcja = wariant gdy zmienia SKU/GTIN/cenę/dostępność/zdjęcie/URL | ✅ dobra reguła operacyjna; na demo n/d (opcje OC bez per-wariant SKU/URL), ale reguła wchodzi do Info na przyszłe klony | ℹ️ Info |
| ItemList kategorii: P2→P3 (carousel tylko kursy/filmy/przepisy/restauracje) | ✅ zgodne z zakresem rich results Google | 🎯 P3 (przesunięte) |
| FAQPage ≠ „optymalizacja pod AI" (Google: brak specjalnej schemy dla AI) | ✅ oficjalna linia Google; FAQ wartościowe jako TREŚĆ, markup = semantyka widocznych pytań | reframe w księdze przy konsolidacji |
Dedykowane właściwości (color/material/size/wymiary/waga/gtin13) przed additionalProperty | ✅ zgodne z zaleceniem schema.org — doprecyzowuje nasz wcześniejszy pomysł P3 | 🎯 P3 (doprecyzowane) |
O co chodzi: Druga recenzja naszego stanu schema. Chwali core (SSR, zero microdata, warunkowy AggregateRating, breadcrumbs), potwierdza priorytety (P1 = zwroty/wysyłka; SearchAction = kosmetyka do wycięcia), ale rekomenduje wdrożenie return/shipping per-Offer w module — dokładnie odwrotnie niż opracowanie 1/3 (org-level OnlineStore).
OCENA: 6/10 — przyjęte częściowo; w konflikcie z 1/3 wygrywa 1/3 💡 1 dobre uzupełnienie: walidacja RRT + MC Diagnostics
| Teza 2/3 | Rozstrzygnięcie | Skutek |
|---|---|---|
| ⚔️ KONFLIKT z 1/3: return/shipping wdrożyć per-Offer w module (argumenty: niezależność od GMC, różnicowanie per produkt, szybkość crawl) | Wygrywa 1/3 (org-level): ① argument „niezależność" jest FAŁSZYWY — org-level markup to TAKŻE markup on-page (blok OnlineStore na stronie), niezależny od GMC dokładnie tak samo · ② „różnicowanie per produkt" = dokładnie do tego służą wyjątki na Offer w architekturze 1/3 · ③ Google w oficjalnych docs preferuje politykę organizacji przy wspólnych zasadach (mniej duplikacji — per-Offer pompuje identyczny blok w HTML każdego produktu) · ④ źródła 2/3 to blogi SEO, 1/3 cytuje developers.google.com | architektura v0.8 BEZ ZMIAN |
Chwali nasz Offer w komplecie, w tym priceValidUntil | ❌ 2/3 nie wyłapało sztucznej daty +1 rok (potwierdzonej w kodzie, l. 700) — chwali pole, które 1/3 słusznie zakwestionowało. Marker niższej rzetelności recenzji | korekta z 1/3 zostaje (pkt ① v0.8) |
| „Google w 2024–25 mocno karał «rating bez opinii»" | ⚠️ regres względem niuansu 1/3: kara = markup fikcyjny/niewidoczny/niezgodny; oceny liczbowe bez recenzji tekstowych są dozwolone | zasada z 1/3 zostaje (Info pkt ①) |
| FAQPage „P2, głównie pod AI/Overviews" | ❌ sprzeczne z oficjalną linią Google („no special schema for AI") potwierdzoną w 1/3 | reframe z 1/3 zostaje |
| ItemList „P2, wrócić przy większym ruchu" | ⚠️ zostaje P3 (1/3 miało lepsze źródło: carousel nie obejmuje kategorii e-commerce) | P3 bez zmian |
SearchAction wyciąć, WebSite z name/url zostawić (Site Names) | ✅ zgodne z 1/3 i Aneksem C — trzecie niezależne potwierdzenie | v0.8 pkt ⑤ potwierdzony |
| ProductGroup n/d na demo · additionalProperty dobry P3 · gtin13 = luka danych nie kodu | ✅ zgodne z naszą diagnozą i 1/3 | bez zmian |
| „Google coraz mocniej weryfikuje landing page vs MC" + spójny markup obok GMC | ✅ słuszne — wspiera zasadę „panel = jedno źródło dla markupu I feedu" (już w v0.8) | potwierdza pkt ③ v0.8 |
| Walidacja po wdrożeniu: Rich Results Test + Merchant Center Diagnostics | ✅ dobre uzupełnienie operacyjne — jedyny nowy wkład 2/3 | 🎯 dopisane do statusu pakietu v0.8 |
max-image-preview:large — meta robots emitowane globalnie przez moduł Argo SEO. ~10 min + test. Korzyść szersza niż Discover: duże podglądy obrazów w Search/Images (karta #2).priceValidUntil +1 rok (l. 700) → emitować REALNĄ datę końca promocji z oc_product_special.date_end, bez promocji pomijać pole · ② Organization → OnlineStore (podtyp — zmiana bezpieczna) · ③ globalne hasMerchantReturnPolicy + hasShippingService z pól panelu (panel = JEDNO źródło danych dla JSON-LD i feedu GMC; hierarchia Google: MC > markup) · ④ zwroty/wysyłka na poziomie Offer TYLKO dla wyjątków · ⑤ wyciąć martwy SearchAction (WebSite zostaje — wspiera nazwę witryny). Zastępuje wcześniejszą akcję „return/shipping per-Offer" z #12.shoppinginspiration bez amplifikacji (#10) · ③ tytuł+obraz pod CTR pierwszych 4–6 h (okno wzmacniacza moonstone; drugi impuls 6–12 h = diagnoza w GA4 godzinowym) (#10) · ④ dźwignią CTR w Discover jest og:title + obraz (to og:title steruje nagłówkiem w feedzie) → craftować osobno od title SEO, emocjonalnie ale bez clickbaitu (#11) · ⑤ YouTube shorts = najszybsza droga do AI Overviews (2–3 dni vs tygodnie dla tekstu): ≤3 min, 1 konkretny problem, zoptymalizowany title, tagi, krótki opis odpowiadający na tezę w 1. zdaniu; „LLM-y kochają liczby" — tabele/porównania/infografiki WŁASNE (#13) · ⑥ PR + wzmianki zewnętrzne — LLM-y cytują obce portale, nie tylko Twoją domenę: gościnne artykuły, podcasty, cytaty ekspertów; wzmianka + link do strony głównej (#13).<image:image> per produkt — wartość marginalna (JSON-LD image + og:image już karmią Google Images); przy module v0.3 (karta #5)./.well-known/ucp, wsparcie AP2 u PayU (karta #7).additionalProperty · ItemList kategorii zdegradowany P2→P3 (brak rich result dla kategorii e-commerce) · FAQPage = semantyczne oznaczenie widocznych pytań, nie „optymalizacja AI" · reguła ProductGroup — patrz Info.Zapisane 16.07.2026 (decyzja PM). Każde źródło do przeskanowania pod 2 kątami: ① technika SEO ② treść + AI search — wnioski wg klucza werdyktów jak karty #1–#11.
| Źródło | URL | Status skanu |
|---|---|---|
| Backlinko | backlinko.com/blog | ⏳ czeka |
| Ahrefs Blog | ahrefs.com/blog | ⏳ czeka |
| Moz Blog | moz.com/blog | ⏳ czeka |
| Search Engine Journal | searchenginejournal.com | ⏳ czeka |
| Search Engine Land | searchengineland.com | ⏳ czeka |
| Jakub Sawa (blog PL) | jakubsawa.pl | ⏳ monitoring nowych wpisów (11 dotychczasowych ✅ → #1–#11; źródło sprawdzone — najlepszy sygnał/szum z całej serii) |
Pojedyncze treści czekające na przegląd (dorzucane na bieżąco). Po analizie → karta w tabie „Zaliczone".
| Materiał | Źródło | Status |
|---|---|---|
| GONTAREK — podcast (transkrypt 1:24 h) | +SEO/GONTAREK -podcast.docx (lokalny, 62 KB) | ✅ przeanalizowane → karta #13 + Info + teczka D16/17 + P3 |
| Google sugestia (Gemini) — checklist tech SEO | +SEO/Google sugesita Geminni.docx (lokalny, 13 KB) | ✅ przeanalizowane → karta #12 + Info |
| Książka: Topical Authority / Search Retrieval Optimization (framework Koray) | Amazon (papier/ebook) — polecona w #13 jako „jedyna książka roku" Gontarka; cały framework semantyki/linkowania wewn./encji | 💡 kandydat — zakup = decyzja PM |
| Opracowania Schema — recenzje eksperckie (seria 3) | wklejki PM (chat) | SERIA KOMPLETNA ✅: 1/3 → #14 · 2/3+3/3 (razem) → #15 · konflikt rozstrzygnięty (org-level) · księga r.6 skonsolidowana [S1] · zostaje: wdrożenie Schema v0.8 (tab Do zrobienia) |
Rejestr wszystkich linków wklejonych w tej serii przeglądowej. Każdy → karta w „Zaliczonych".
| # | Link | Karta |
|---|---|---|
| 1 | jakubsawa.pl/javascript-seo-w-2026-google-bing-i-boty-ai-przewodnik-na-danych | #1 [JS26] |
| 2 | jakubsawa.pl/google-discover-przewodnik | #2 |
| 3 | jakubsawa.pl/co-to-jest-link-kanoniczny-i-jak-go-prawidlowo-stosowac | #3 |
| 4 | jakubsawa.pl/core-web-vitals-przewodnik-dla-seo | #4 |
| 5 | jakubsawa.pl/sitemapa-xml-kompletny-przewodnik-seo | #5 |
| 6 | jakubsawa.pl/co-to-jest-hreflang-i-jak-go-poprawnie-wdrozyc | #6 |
| 7 | jakubsawa.pl/universal-commerce-protocol-ucp… | #7 |
| 8 | jakubsawa.pl/pierwszy-oficjalny-google-discover-core-update… | #8 |
| 9 | jakubsawa.pl/google-spam-update-marzec-2026 | #9 |
| 10 | jakubsawa.pl/google-discover-to-nie-jeden-algorytm-to-20-oddzielnych-maszyn | #10 |
| 11 | jakubsawa.pl/5-typow-tytulow-ktore-sa-wazne-dla-google | #11 |
| 12 | +SEO/Google sugesita Geminni.docx (plik lokalny) | #12 |
| 13 | +SEO/GONTAREK -podcast.docx (plik lokalny, transkrypt 1:24 h) | #13 |
| 14–15 | Opracowania Schema 1/3 + 2/3+3/3 (wklejki chat) | #14–#15 |
Rejestr narzędzi z naszych sesji + z analizowanych treści. Dopisywane na bieżąco, gdy coś się przewija w robocie.
| Narzędzie | Do czego | Kontekst u nas |
|---|---|---|
Lighthouse (npx lighthouse) | autorytatywny pomiar CWV / CLS / audytów lab | zasada projektu: do CLS TYLKO Lighthouse (nie scroll+PerfObserver); pomiary sesji 3–4; wymaga CHROME_PATH |
| puppeteer-core + systemowy Chrome | headless testy E2E / skrypty pomiarowe | harness zero-jQuery, atrybucja CLS (LayoutShift.sources), test tabów makiety; instalacja w scratchpadzie (temp — znika między sesjami) |
| curl | testy SSR, botów, nagłówków, smoke po deployu | -A "ClaudeBot" (cena w HTML bez JS — audyt T1), --resolve (test proda przed DNS), -I (nagłówki/301) |
PHP CLI 8.3 (php -l, skrypty) | lint + jednorazowe zapytania DB (mysqli) | C:\laragon\bin\php\php-8.3.30...; diagnoza białej strony: php -d display_errors=1 index.php |
| mysqldump / mysql | backup i deploy bazy | paczka prod (153 tabele); pułapka: dump MySQL 8.4 → MariaDB wymaga sed na collation 0900 |
| penthouse | ekstrakcja critical CSS | D21.3 — 6 przebiegów (home/kat/produkt × mobile/desktop), sesja 2 |
| PurgeCSS 8 | usuwanie martwego CSS | bootstrap 121→65 KB, font-awesome 31→2,5 KB; safelista stanów JS-toggled (sesja 2) |
| clean-css | minifikacja CSS | critical.min.css 25 KB / ~5 KB gzip |
| Google Search Console | monitoring indeksacji, CWV (CrUX), sitemap, canonicale | D15 — na prod; kody weryfikacyjne emituje moduł Argo SEO (argo_seo_verify_google); „field data decyduje" (#4) |
| Bing Webmaster Tools | drugi silnik + wejście do Copilot | D15; weryfikacja msvalidate.01 z modułu; Bing w praktyce nie renderuje JS (#1) — nasz SSR ✓ |
| Rich Results Test | walidacja schema na żywym URL-u | księga rozdz. 6 — po każdej zmianie szablonu/schema (deploy gate D18) |
| Screaming Frog SEO Spider | crawl porównawczy raw vs rendered; audyt canonical/hreflang | rekomendowany w #1/#3/#6; u nas: do audytu klonów produkcyjnych |
| GA4 (raport godzinowy) | diagnoza pipeline'ów Discover po wzorcach czasowych | #10: drugi impuls ruchu 6–12 h = amplifikacja moonstone; segment ruchu AI (referrery chatgpt/perplexity) — księga D14.6 |
| Cloudflare | DNS · CDN/edge-cache · SSL · HTTP/3 | DNS argocore.ai już tam; plan D22.1: orange cloud + SSL Full = CDN i fix certu za jednym ruchem (rozpisane w rozmowie 16.07) |
GitHub Actions (deploy.yml) | deploy na prod (rsync/SSH), wyłącznie ręczny „Run workflow" | od 07/2026 — zastąpił paczkę ZIP; exclude: work/, db/, +SEO/, configi |
| IndexNow | natychmiastowe powiadamianie Bing o zmianach URL | plan P2 (debounce, flaga OFF) — księga rozdz. 4; artykuł #5 go nie znał |
| Serwery MCP (Model Context Protocol) | pośrednik LLM↔API: po jednym serwerze na źródło (GSC/GA4/Ads/PageSpeed/CrUX…); narzędzia w środku połączone, dane trwałe między wywołaniami | z #13: pełny przepis setupu w Info („Zaplecze MCP / API Google"); sami pracujemy na MCP w sesjach — kandydat na analitykę Argo po prodzie |
| GA4 → BigQuery (export + API/MCP) | odpytywanie danych GA4 SQL-em zamiast panelu (panel G4 „pochrzaniony") | z #13 (Gontarek + prowadzący): kandydat przy D11 RUM / analizach lejka AI na prodzie |
| Senuto / Semstorm / Ahrefs (API) | keyword research PL + dane widoczności; bazy wiedzy API jako fundament własnych narzędzi | z #13: wzorzec „wrzuć docs API do LLM → zbuduj narzędzie"; przyda się przy D16 (frazy) i skanie blogów |
| NotebookLM | trawienie długich źródeł (książki, dokumentacje) jako baza wiedzy | z #13: sposób pracy z ebookami/frameworkami (np. Koray) — kandydat przy fali treści |
Wszystko, co warte zapamiętania, a nie mieści się w Zaliczonych (karty przeglądów), Do zrobienia (akcje), Do analizy (kolejka) ani Narzędziach. Każdy wpis: data · skąd · treść. W pierwszej kolejności wyląduje tu wiedza z GONTAREK -podcast.docx (w kolejce analizy).
| Data | Skąd | Info |
|---|---|---|
| 16.07.2026 | Gemini (plik Google sugesita Geminni.docx) |
Checklist technicznego SEO e-commerce — szablon audytu (9 działów). Trzymamy jako gotowy template do audytu klonów/nowych wdrożeń. Skrót działów: ① architektura (3-klik, hierarchia SG→kat→podkat→produkt, breadcrumbs+schema, linki wewn.) · ② crawl budget (robots blokuje koszyk/konto/szukajkę/logowanie; sitemap TYLKO 200 OK, auto-update, dzielona; noindex na regulamin/filtry; 404→301, bez pętli) · ③ duplikacja (canonical przy sort/filtr/produkt-w-wielu-kategoriach; warianty: osobny URL+canonical LUB dynamicznie bez zmiany URL; unikalne opisy ≠ producenta) · ④ fasety (blokada filtrów; przyjazny URL tylko dla kombinacji z potencjałem — „czerwone sukienki wieczorowe") · ⑤ CWV (LCP<2,5s / INP<200ms / CLS<0,1; WebP/AVIF; lazy poniżej zgięcia; CDN) · ⑥ mobile-first (RWD, bez pełnoekranowych popupów = kara, tap-targety) · ⑦ schema (Product, AggregateRating, BreadcrumbList, MerchantReturnPolicy&ShippingDetails) · ⑧ bezpieczeństwo (HTTPS, przyjazne URL, hreflang) · ⑨ wyprzedane: chwilowo → zostaw stronę, wyłącz „Kup", dodaj „Powiadom o dostępności" + alternatywy; trwale → 301 do zamiennika/kategorii, albo 404/410 + usuń linki wewn. Monitoring: GSC · Screaming Frog/Sitebulb · PageSpeed Insights. → Audyt pokrycia u nas: karta #12 (~95% ✅, luka return/shipping = Do zrobienia). |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Patent Google: kompletność atrybutów karty produktu. Google weryfikuje encje/sygnały — czy WSZYSTKIE parametry produktu są na stronie: parametr w katalogu (deska 12 cm), a brak w HTML i danych strukturalnych = sygnał in minus; Google „wie, czego brakuje" (koszula bez „w kratę"). Cena = encja / sygnał jakości: ukrywanie cen (obserwacja z deweloperki) → gorszy ranking, bo UX/odbiór inny niż u konkurencji z cenami. → Twarde uzasadnienie naszej linii: PIM-kompletność (D14.1), specyfikacja tabelą HTML, JSON-LD komplet, cena SSR. |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Playbook widoczności w LLM-ach. ① Widoczność budują nie tylko Twoje strony, ale wzmianki na obcych (gościnne artykuły, podcasty, PR z linkiem do home) — LLM-y cytują portale zewnętrzne. ② YouTube/shorts najszybsze: dobra optymalizacja (title, tagi, opis „na tezę") = obecność w AI Overviews w 2–3 dni, szybciej niż treść pisana; shorts ≤3 min, 1 problem, bez hooków. ③ „LLM-y kochają liczby": tabele, scoringi, porównania, infografiki WŁASNE (nie AI), cytaty ekspertów, linki do źródeł — sygnały E-E-A-T się sprzęgają. ④ Google indeksuje social media (od ~07.2025) = sygnały jakościowe. ⑤ LLM-y uczą się PARTIAMI (knowledge cutoff) — Google/Bing na bieżąco; propagacja marki w czatach = tygodnie/miesiące. ⑥ Z LLM-ów nie da się „wykasować" (brak prawa do zapomnienia — ryzyko reputacyjne). ⑦ Black hat LLM istnieje: domena spalona w Google może rankować w czatach/Bingu. |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Heurystyki analityczne dla ruchu AI. Sesja z referrera LLM (ChatGPT/Perplexity/Gemini) <15 s = scraper (odrzucać z analiz); konwersja z wejścia LLM = 100% człowiek; zaangażowanie ~70% = realni użytkownicy. Pomysł prowadzącego: parametr user-level „prawdopodobieństwo bota 1–10" w GA4. Badanie Surfer SEO: testowanie promptów po API daje gorszą próbkę niż web-scraper zachowujący się jak realny user w aplikacji. Ruch z Copilota rośnie (korporacje = tylko Microsoft) → monitorować Bing. |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Metodyka narzędzi AI (rama dla narzędzi Argo). Mikronarzędzia (1 funkcja, skrypt) → mastery → orkiestratory (40 warstw, ~100–150 mikrotooli); dane jednego narzędzia = wejście następnego. Strojenie GLOBALNE scoringami/heurystykami — nie pod konkretnego klienta (LLM dryfuje do per-klient, trzeba przypominać). Human-in-the-loop: „próg bólu", confidence %, decyzja specjalisty na końcu. Podział ról: ChatGPT=dyskusja/briefy · Codex=kod · Claude=analityka/weryfikacja. Anty-vendor-lock: ta sama konfiguracja MCP w 2 klientach (Codex+Claude jako wzajemny fallback), backup na własnym sprzęcie (LibreChat+Qwen), git lokalny. Zespół chce WYNIKU, nie narzędzi — „jedna zakładka" zamiast 100 tooli (syndrom nadmiaru informacji). Skille: sprawdzaj background autora; bez scoringów/warstw nie ufać. |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Zaplecze MCP / API Google — przepis na setup (od zera do produkcji). Infra: zwykły VPS Ubuntu za ~30 €/mies. (16 GB RAM) — start możliwy nawet na laptopie 8 GB (Win z Node.js / macOS; Mac „grzał się jak patelnia" → przeniósł na Ubuntu). Wejście dla laika: opisz swoją maszynę w ChatGPT („mam Windows, chcę serwer MCP do GA/Ads") — prowadzi krok po kroku. Architektura: 22–25 serwerów MCP, po jednym na źródło danych: GSC (duży, osobny) · GA4 · Google Ads · PageSpeed Insights · CrUX · GTmetrix · GTM · Screaming Frog · Senuto ×2 (+ inne). „Serwer MCP = pośrednik do API" (cyt. za R. Rosenbergerem) — przewaga nad promptowaniem API wprost: narzędzia wewnątrz serwera są POŁĄCZONE, dane jednego narzędzia odkładają się jako wejście następnego (tego skille nie dają — brak trwałego kontekstu). Wykonanie: mikrotoole = skrypty Python/Node pisane przez Codex (nie LLM-y!), odpalane promptem, ~100 pracuje w tle; Codex spięty bezpośrednio z Ubuntu — testuje na serwerze testowym, potem produkcja; Claude agencyjny ma „podpięte wszystkie zabawki" do analiz. Odporność: ta sama konfiguracja MCP w Codex I Claude = wzajemny fallback przy awarii; DR: kopia całego serwera co 2–3 tyg. na Mac Studio (LibreChat + Qwen lokalnie — wolniej, ale działa), git lokalny + backupy na serwer; audyt bezpieczeństwa MCP zlecony Codexowi (znalazł dziury, poprawił logowanie/weryfikację); setup przenośny — „w 1 dzień postawię 1:1 w dowolnej agencji na ich Linuxie". Wzorzec „baza wiedzy API": dokumentację API dostawcy (Senuto/Semrush/Semstorm/Ahrefs) wrzucić do LLM → „jakie narzędzia można z tego zbudować?" → budować. GA4: panel „pochrzaniony" — nie widział go od 2–3 mies.; zamiast tego GA4 → BigQuery (BigQuery ma własny MCP) i odpytywanie SQL-em. Panele SaaS tylko do konfiguracji projektów — obróbka danych u siebie („najcenniejsze w obróbce są DANE"). Ograniczenie: część API tylko read-only (konfiguracji nie wyślesz). → U nas: gotowa rama pod analitykę Argo po wejściu na prod: GSC/GA4 przez MCP-pośredniki + mikronarzędzia z trwałymi danymi (D11 RUM, D14 monitoring, prompt-gap z P3). |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Komplementarność SEO — „trzeba być wszędzie" (Search Everywhere). ① „SEO jest SEO — nieważne, który engine optymalizujesz. Bebechy są cały czas te same" — search everywhere / search retrieval / search journey: akronim nie ma znaczenia, fundament się nie zmienił. ② Nie ma już tylko Google: Bing, YouTube (2. wyszukiwarka świata), TikTok, LLM-y — i będzie ich więcej; trzeba zaistnieć we wszystkich. ③ SEO stało się epicentrum wszystkiego: żeby istnieć we wszystkich wyszukiwarkach NARAZ, strona musi być dobra prędkościowo/wydajnościowo, mieć dobry UX i encje (cena!) — popup UX-owca przeszkadza, brak ceny przeszkadza, a „odpowiada" za to SEO-wiec. ④ Content marketing ≠ tylko treści pisane: webinary, podcasty, wideo, infografiki WŁASNE (nie AI), tabele, scoringi, porównania, cytaty, wywiady z ekspertami, linki do źródeł — sygnały E-E-A-T się sprzęgają: sam przyrost treści = wypozycjonujemy, ale ciężko; +YouTube = lepiej; +infografiki/tabele/cytaty = działa najlepiej. ⑤ Google indeksuje social media (od ~07.2025) = sygnały jakościowe dla domeny. ⑥ Kolejność kanałów: NIE zaczynaj od SEO — najpierw kanały, które najszybciej sprzedają (social/Ads), SEO odpowie za rok–dwa; ale docelowo marka musi żyć wszędzie, bo cytowania z każdego kanału karmią pozostałe. → U nas: spójne z księgą (cz. F „6 warstw widoczności" + r.8 formy treści) — podcast dodaje ekonomię sprzężeń: każdy format wzmacnia pozostałe, więc plan fali D16/17 powinien od startu być wieloformatowy (tekst+tabele+wideo), nie „najpierw sam blog". |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | YouTube i rolki (shorts) — playbook Gontarka w szczegółach. Dlaczego: hit roku wg gościa = filmy YouTube; YouTube'y (i shorts) są cytowane w AI Overviews i AI Mode; przy dobrej stronie + dobrym tytule + dobrej optymalizacji short potrafi wejść do AI Overviews w 2–3 dni — szybciej niż treść pisana; ~50 shortsów gościa „chodzi w karuzeli AI-owej", robią drugie tyle zasięgów co reszta kanału. Format: ≤3 min, JEDEN konkretny problem, wyjaśniony szybko; bez hooków, bez obróbki — statyw gdziekolwiek (nawet na spacerze), liczy się wiedza/flow, nie produkcja („Chińczycy sprzedają kampera w 30 s, a my kręcimy godzinę" — krótka forma wygrywa; pokazać JAK pakujesz karton, nie opisywać jego warstw). Optymalizacja: tytuł zoptymalizowany pod frazę · opis jak najkrótszy, odpowiadający na tezę w PIERWSZYM zdaniu („bluf") · używać pola tagów · opisy generowane ChatGPT robią robotę, ale trzeba je poprawić ręcznie. Publikacja: sam YouTube wystarczy (gość nie ma TikToka); długie filmy tylko gdy trzeba coś realnie wyjaśnić (~20 szt., rekord 41 min). Efekt biznesowy: klienci mówią „jest pan cytowany w ChatGPT"; dzięki shortsom klienci-Polacy z zagranicy (głównie USA) przychodzą po konsultacje SEO — shorts buduje markę ORAZ widoczność w LLM-ach jednocześnie. → U nas: rozszerzenie pkt ⑤ strategii treści (teczka D16/17): jak PM zdecyduje o wideo, ten wpis = gotowa instrukcja formatu i optymalizacji. |
| 16.07.2026 | Podcast Gontarek/Zgred (#13) | Biznes/rynek. SaaS-y AI: przeżyje ~1 na 100 (lub mniej). GSC: rosnąca kolejka „Crawled – not indexed" = słaby content (polityki scaled/scraped 2025) — Google dziś rzadko karze, częściej po prostu nie indeksuje. SEO nie dla każdego: test = Google Ads na próbę; jak Ads sprzedaje → organik ma sens. Hit: filmy YouTube · Mit: „AI zastąpi SEO-wca" · Najbardziej przereklamowane: ChatGPT · Metryka: sprzedaż. Rada końcowa: nie ufać AI ślepo — „jakie konsekwencje będą miały decyzje podjęte z AI". |
| 16.07.2026 | Opracowanie Schema 1/3 (#14) | Trwałe zasady schema (do konsolidacji księgi po serii 3/3). ① AggregateRating emitować tylko gdy: oceny od realnych użytkowników · ratingValue WIDOCZNY na stronie · ratingCount/reviewCount = rzeczywiste dane · ≥1 realna ocena. Kara ręczna dotyczy markupu fikcyjnego/niewidocznego/niezgodnego — oceny liczbowe bez recenzji tekstowych są OK. ② ProductGroup — opcja staje się wariantem, gdy zmienia: SKU/GTIN, cenę, dostępność, zdjęcie, albo ma własny URL/parametr → wtedy relacja ProductGroup→Product z unikalnymi ID; dodatki („pakowanie prezentowe", „montaż") ≠ warianty. ③ Hierarchia źródeł Google: dane Merchant Center > markup strony → panel sklepu = JEDNO źródło prawdy generujące i JSON-LD, i feed GMC (nie wybierać „schema albo MC"). ④ priceValidUntil = wyłącznie REALNA data końca ceny (promocja z terminem: validFrom+priceValidUntil); nie generować sztucznych dat „żeby pole było". ⑤ Dedykowane właściwości schema.org (color/material/size/wymiary/waga) PRZED additionalProperty — additionalProperty tylko dla cech bez dedykowanego pola. ⑥ AI features: Google oficjalnie — brak specjalnej schemy dla AI Overviews/AI Mode; liczy się indeksowalność, treść, linkowanie i zgodność markupu z widoczną zawartością. ⑦ Polityki zwrotów/wysyłki: preferowane org-level (OnlineStore.hasMerchantReturnPolicy/hasShippingService), Offer-level tylko nadpisywanie wyjątków. |