May 27, 2026, 9:48 AM
This commit is contained in:
Paweł Domański
@@ -0,0 +1,143 @@
|
||||
# Wytyczne do Landing Page i Prompty AI
|
||||
|
||||
Dokument ten zawiera zestawienie wytycznych dotyczących optymalizacji stron docelowych (landing pages) oraz gotowe prompty do narzędzi AI, które pomogą w ich wdrożeniu. Opracowano na podstawie `Landing_pagesOpt.md`.
|
||||
|
||||
## Część 1: Wytyczne do budowy i optymalizacji Landing Page
|
||||
|
||||
### 1. Strategia i Wybór Elementów do Testowania
|
||||
Nie wszystko na stronie ma równe znaczenie. Skup się na zmianach, które mogą przynieść największy zwrot.
|
||||
|
||||
* **Zasada 80/20 (Pareto):** Skoncentruj się na 20% elementów, które generują 80% wyników. Naprawienie fundamentalnych problemów daje lepsze efekty niż drobne poprawki kosmetyczne.
|
||||
* **Priorytetyzacja stron:** Nie naprawiaj tylko stron, które działają słabo. Często największy potencjał ukryty jest w stronach, które już generują duży ruch i przychód, ale nie są w pełni zoptymalizowane.
|
||||
* **Analiza "Utraconego Przychodu":** Oblicz potencjalne straty dla każdej strony (Ruch × Przychód na użytkownika × Współczynnik odrzuceń), aby zdecydować, gdzie skierować wysiłki optymalizacyjne.
|
||||
|
||||
### 2. Struktura i Design (Page Structure & Emphasis)
|
||||
Sposób organizacji przestrzeni ma kluczowe znaczenie dla kierowania uwagą użytkownika.
|
||||
|
||||
* **Kluczowe obszary widoczności:** Użytkownicy skanują strony od lewego górnego rogu. Najważniejsze informacje i wezwanie do działania (CTA) powinny znajdować się "above the fold" (w górnej części strony, widocznej bez przewijania).
|
||||
* **Mniej znaczy więcej (Less is More):**
|
||||
* Usuń zbędne elementy (rozpraszacze).
|
||||
* Ogranicz liczbę linków wychodzących (nie związanych z konwersją).
|
||||
* Upraszczaj grafikę i skracaj teksty.
|
||||
* **Nawigacja:** Preferuj menu pionowe, ponieważ lepiej wykorzystują cenną przestrzeń w pionie i poprawiają czytelność na szerokich ekranach.
|
||||
* **Akcentowanie (Emphasis):** Kieruj uwagą poprzez kontrast (np. kolor przycisku CTA kontrastujący z tłem), rozmiar czcionek i "pustą przestrzeń" (whitespace). Nie "podkręcaj głośności" wszystkiego naraz.
|
||||
|
||||
### 3. Spójność (Coherency) i "Zapach Informacji"
|
||||
Strona musi być spójna wizualnie i logicznie z miejscem, z którego przyszedł użytkownik.
|
||||
|
||||
* **Dopasowanie komunikatu:** Nagłówek na landing page'u musi odpowiadać tekstowi w reklamie lub linku, w który kliknął użytkownik. Jeśli użytkownik traci ten "zapach informacji", czuje się oszukany lub zagubiony.
|
||||
* **Spójność wizualna:** Kolorystyka, czcionki i styl graficzny muszą być jednolite. Strony niespójne (np. wyglądające amatorsko lub chaotycznie) drastycznie obniżają zaufanie.
|
||||
* **Unikanie "Frankensteina":** Podczas testów wielowariantowych uważaj, aby losowe łączenie elementów nie stworzyło nielogicznej całości.
|
||||
|
||||
### 4. Architektura Informacji i Przepływ (Flow)
|
||||
Zadbaj o to, aby użytkownik wiedział, gdzie jest i co ma zrobić.
|
||||
|
||||
* **Macierz (The Matrix):** Upewnij się, że na każdym etapie użytkownik otrzymuje odpowiednie wsparcie (informacje, zachęty) potrzebne do przejścia dalej.
|
||||
* **Przepływy wielostronicowe:**
|
||||
* Zaczynaj od małych, nieinwazyjnych próśb.
|
||||
* Dopiero gdy użytkownik zainwestuje czas (np. kliknie dalej), proś o trudniejsze dane (np. numer karty).
|
||||
* **Obsługa "Spadochroniarzy":** Użytkownicy mogą trafić na podstronę bezpośrednio z wyszukiwarki. Zapewnij im kontekst ("jesteś tutaj"), nawigację i jasną ścieżkę do konwersji.
|
||||
|
||||
### 5. Budowanie Zaufania i Oferta
|
||||
Elementy psychologiczne, które pomagają przełamać wahanie.
|
||||
|
||||
* **Uspokajanie nerwów:** Używaj dowodu społecznego (social proof) – recenzje, logotypy znanych klientów, certyfikaty bezpieczeństwa.
|
||||
* **Personalizacja:** Dostosuj treść do lokalizacji użytkownika, jego wcześniejszych zachowań lub źródła ruchu.
|
||||
* **Oferta:** Testuj różne warianty nagłówków, tekstów sprzedażowych i wezwań do działania (CTA).
|
||||
|
||||
### 6. Testowanie Cen (Pricing)
|
||||
Cena jest jedną z najważniejszych zmiennych ciągłych.
|
||||
|
||||
* **Elastyczność cenowa:** Testuj różne punkty cenowe, aby znaleźć szczyt krzywej zysku.
|
||||
* **Upselling:** Testuj oferty dodatkowe (równolegle lub seryjnie).
|
||||
|
||||
### Podsumowanie dla Dewelopera/Designera
|
||||
|
||||
1. **Wyczyść interfejs:** Usuń wszystko, co nie prowadzi do głównego celu (CTA).
|
||||
2. **Wyróżnij CTA:** Przycisk musi kontrastować z resztą strony.
|
||||
3. **Sprawdź nagłówki:** Upewnij się, że H1 na stronie pasuje do słów kluczowych kampanii reklamowej.
|
||||
4. **Zadbaj o "Above the Fold":** Kluczowa wartość i CTA muszą być widoczne bez przewijania.
|
||||
5. **Przygotuj się na testy:** Zbuduj stronę tak, aby łatwo było podmieniać sekcje w narzędziach do testów A/B.
|
||||
|
||||
---
|
||||
|
||||
## Część 2: Prompty do narzędzi AI
|
||||
|
||||
Poniżej znajdują się gotowe polecenia do narzędzi AI (ChatGPT, Claude, Gemini), które pomogą wdrożyć powyższe zasady. W miejscach w nawiasach kwadratowych `[WSTAW TUTAJ...]` wklej odpowiednie treści.
|
||||
|
||||
### 1. Spójność i "Zapach Informacji"
|
||||
*Cel: Upewnienie się, że reklama i strona mówią tym samym językiem.*
|
||||
|
||||
**Prompt:**
|
||||
> "Działaj jako ekspert od optymalizacji konwersji (CRO). Przeanalizuj poniższe dwa teksty pod kątem zasady 'Zapachu Informacji' (Information Scent).
|
||||
>
|
||||
> 1. Treść mojej reklamy/linku: `[WSTAW TREŚĆ REKLAMY]`
|
||||
> 2. Nagłówek i pierwszy akapit mojego Landing Page: `[WSTAW NAGŁÓWEK I TEKST]`
|
||||
>
|
||||
> Czy istnieje dysonans poznawczy? Czy użytkownik po kliknięciu w reklamę od razu wie, że trafił w dobre miejsce? Wypunktuj 3 konkretne zmiany w nagłówku strony, aby idealnie pasował do obietnicy z reklamy."
|
||||
|
||||
### 2. Struktura i "Mniej znaczy więcej"
|
||||
*Cel: Usunięcie rozpraszaczy i poprawa hierarchii wizualnej.*
|
||||
|
||||
**Prompt:**
|
||||
> "Oto lista wszystkich elementów, które znajdują się obecnie na moim Landing Page'u: `[LISTA ELEMENTÓW, NP. MENU GÓRNE, LINKI DO SOCIAL MEDIA, DŁUGI TEKST O HISTORII FIRMY, FORMULARZ, STOPKA Z LINKAMI]`.
|
||||
>
|
||||
> Opierając się na zasadzie 'Mniej znaczy więcej' i regule Pareto (80/20), wskaż mi:
|
||||
> 1. Które elementy są zbędnymi 'rozpraszaczami' i powinny zostać usunięte, aby nie odciągać uwagi od głównego celu (konwersji)?
|
||||
> 2. Które elementy powinny znaleźć się 'Above the Fold' (w widocznej części ekranu), aby użytkownik nie musiał przewijać?
|
||||
> 3. Jak uprościć nawigację, aby prowadziła tylko do celu?"
|
||||
|
||||
### 3. Architektura Informacji i "The Matrix"
|
||||
*Cel: Upewnienie się, że użytkownik otrzymuje odpowiednie wsparcie na każdym etapie.*
|
||||
|
||||
**Prompt:**
|
||||
> "Chcę stworzyć przepływ użytkownika zgodny z koncepcją 'The Matrix' (zapewnienie odpowiedniego wsparcia na każdym etapie). Moim celem jest `[NP. SPRZEDAŻ KURSU / ZAPIS NA NEWSLETTER]`.
|
||||
>
|
||||
> Przeanalizuj moją obecną ofertę: `[OPIS OFERTY]`.
|
||||
>
|
||||
> Zaproponuj strukturę strony, która odpowiada na pytania użytkownika w logicznej kolejności:
|
||||
> 1. Świadomość (Gdzie jestem? Co to jest?)
|
||||
> 2. Zainteresowanie (Dlaczego mnie to obchodzi?)
|
||||
> 3. Pożądanie (Dlaczego to jest lepsze od innych?)
|
||||
> 4. Akcja (Co mam zrobić?)
|
||||
>
|
||||
> Dla każdego etapu zaproponuj jeden element 'uspokajający nerwy' (np. dowód społeczny, gwarancja)."
|
||||
|
||||
### 4. Copywriting i Budowanie Zaufania
|
||||
*Cel: Przełamanie wahania użytkownika.*
|
||||
|
||||
**Prompt:**
|
||||
> "Mój Landing Page ma na celu `[CEL STRONY]`. Użytkownicy często wahają się przed kliknięciem przycisku CTA z powodu `[OBRAWA, NP. CENY, SPAMU, BRAKU CZASU]`.
|
||||
>
|
||||
> Napisz 3 warianty sekcji budującej zaufanie (Trust Elements), która znajdzie się tuż obok przycisku CTA. Wykorzystaj techniki takie jak:
|
||||
> - Dowód społeczny (Social Proof)
|
||||
> - Gwarancja bezpieczeństwa
|
||||
> - Rozwiewanie obiekcji
|
||||
>
|
||||
> Styl ma być profesjonalny, ale bezpośredni."
|
||||
|
||||
### 5. Generowanie pomysłów na testy A/B
|
||||
*Cel: Znalezienie zmian o największym potencjale (High Impact).*
|
||||
|
||||
**Prompt:**
|
||||
> "Chcę przeprowadzić test A/B mojego Landing Page'a. Zamiast testować drobne zmiany (jak kolor przycisku), chcę przetestować radykalnie inną koncepcję (Variable Cluster), aby uzyskać wyraźny wynik.
|
||||
>
|
||||
> Mój obecny nagłówek to: `[OBECNY NAGŁÓWEK]`.
|
||||
> Moja obecna oferta to: `[OBECNA OFERTA]`.
|
||||
>
|
||||
> Zaproponuj 3 radykalnie odmienne warianty podejścia do tej strony (np. zmiana skupienia z cech produktu na korzyści emocjonalne, zmiana modelu cenowego, drastyczne skrócenie treści)."
|
||||
|
||||
### 6. Master Prompt (z plikiem)
|
||||
*Jeśli korzystasz z modelu, który pozwala na wgranie pliku.*
|
||||
|
||||
**Prompt:**
|
||||
> "Wgrywam plik z wytycznymi dotyczącymi optymalizacji Landing Page'y. Działaj jako surowy audytor zgodny z tymi zasadami.
|
||||
>
|
||||
> Poniżej wklejam treść mojego obecnego Landing Page'a (lub przesyłam jego screenshot):
|
||||
> `[WKLEJ TREŚĆ LUB OBRAZ]`
|
||||
>
|
||||
> Przeprowadź audyt w oparciu o wgrany plik. Skup się na:
|
||||
> 1. Czy strona spełnia zasadę 'Zapachu Informacji'?
|
||||
> 2. Czy CTA jest wystarczająco wyizolowane i kontrastowe?
|
||||
> 3. Czy nie ma zbyt wielu linków wychodzących (leaky bucket)?
|
||||
> 4. Wskaż 3 najważniejsze rzeczy do zmiany, które dadzą największy zwrot (zgodnie z zasadą Pareto)."
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,135 @@
|
||||
# Kompletna Dokumentacja: Instalacja i Konfiguracja MariaDB na Red Hat Enterprise Linux (RHEL)
|
||||
|
||||
## Cel
|
||||
Ta dokumentacja opisuje krok po kroku proces instalacji i konfiguracji serwera MariaDB na systemie RHEL. Konfiguracja jest specjalnie dostosowana do migracji istniejącej bazy danych MySQL, na podstawie dostarczonych parametrów, aby zapewnić maksymalną kompatybilność.
|
||||
|
||||
## Wymagania wstępne
|
||||
- System operacyjny Red Hat Enterprise Linux (lub jego pochodna, np. CentOS, Rocky Linux).
|
||||
- Dostęp do konta z uprawnieniami `sudo`.
|
||||
- Dostęp do internetu na serwerze docelowym.
|
||||
|
||||
---
|
||||
|
||||
### Krok 1: Przygotowanie Systemu
|
||||
Zawsze dobrą praktyką jest rozpoczęcie od aktualizacji pakietów systemowych do najnowszych wersji.
|
||||
|
||||
```bash
|
||||
sudo dnf update -y
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Krok 2: Wybór i Konfiguracja Repozytorium MariaDB
|
||||
|
||||
System Red Hat domyślnie zawiera w swoich repozytoriach pakiety MariaDB. Masz dwie główne ścieżki instalacji:
|
||||
|
||||
#### Opcja 1: Użycie repozytorium Red Hat (Metoda alternatywna)
|
||||
Możesz zainstalować wersję MariaDB dostarczaną bezpośrednio przez Red Hat. Jest to podejście prostsze, ale zazwyczaj daje dostęp do nieco starszej, choć bardzo stabilnej wersji.
|
||||
|
||||
- Aby zainstalować domyślną wersję z RHEL (np. 10.5 w RHEL 9):
|
||||
```bash
|
||||
sudo dnf install mariadb-server
|
||||
```
|
||||
- Jeśli używasz nowszej wersji RHEL (9.4+) i chcesz zainstalować nowszy "strumień" (np. 10.11):
|
||||
```bash
|
||||
sudo dnf module install mariadb:10.11/server
|
||||
```
|
||||
Jeśli wybierzesz tę opcję, możesz przejść od razu do **Kroku 4**, ale pamiętaj, aby zainstalować także klienta (`MariaDB-client` lub `mariadb`).
|
||||
|
||||
#### Opcja 2: Użycie oficjalnego repozytorium MariaDB (Metoda zalecana)
|
||||
Ta metoda jest zalecana w tej dokumentacji, ponieważ gwarantuje dostęp do najnowszych stabilnych wersji, które często oferują lepszą wydajność, nowe funkcje i dłuższy okres wsparcia. Jest to najlepsza praktyka, szczególnie w kontekście migracji.
|
||||
|
||||
Aby skonfigurować oficjalne repozytorium MariaDB, wykonaj poniższą komendę. Skrypt automatycznie wykryje Twój system i doda odpowiednie źródła pakietów.
|
||||
|
||||
```bash
|
||||
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
|
||||
```
|
||||
Po wykonaniu tej komendy, kontynuuj z **Krokiem 3**.
|
||||
|
||||
---
|
||||
|
||||
### Krok 3: Instalacja MariaDB
|
||||
Po dodaniu repozytorium, zainstaluj pakiety serwera i klienta MariaDB.
|
||||
|
||||
```bash
|
||||
sudo dnf install MariaDB-server MariaDB-client -y
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Krok 4: Zastosowanie Niestandardowej Konfiguracji dla Migracji
|
||||
To kluczowy krok, aby zapewnić zgodność z Twoim starym serwerem. Utworzyłem plik `z-custom-migration.cnf`, który zawiera ustawienia ze źródłowej bazy danych.
|
||||
|
||||
1. **Przenieś plik konfiguracyjny**
|
||||
Musisz przenieść plik `inbox/Projects/z-custom-migration.cnf` z Twojego lokalnego komputera na serwer docelowy. Możesz użyć `scp`, `rsync` lub innej metody transferu plików.
|
||||
|
||||
*Przykład użycia `scp` (z Twojego lokalnego komputera):*
|
||||
```bash
|
||||
scp "inbox/Projects/z-custom-migration.cnf" uzytkownik@adres-serwera:/tmp/z-custom-migration.cnf
|
||||
```
|
||||
|
||||
2. **Skopiuj plik do folderu konfiguracyjnego MariaDB**
|
||||
Na serwerze docelowym, skopiuj plik do folderu `/etc/my.cnf.d/`. MariaDB automatycznie wczyta wszystkie pliki `.cnf` z tego katalogu.
|
||||
|
||||
```bash
|
||||
sudo mv /tmp/z-custom-migration.cnf /etc/my.cnf.d/z-custom-migration.cnf
|
||||
```
|
||||
|
||||
**Ważne:** Nazwa pliku zaczyna się od `z-`, aby zapewnić, że zostanie on wczytany jako jeden z ostatnich, co pozwoli mu nadpisać ewentualne domyślne ustawienia.
|
||||
|
||||
---
|
||||
|
||||
### Krok 5: Uruchomienie i Zabezpieczenie MariaDB
|
||||
Po zakończeniu konfiguracji, uruchom usługę MariaDB i włącz ją, aby startowała automatycznie z systemem.
|
||||
|
||||
1. **Start i włączenie usługi:**
|
||||
```bash
|
||||
sudo systemctl start mariadb
|
||||
sudo systemctl enable mariadb
|
||||
```
|
||||
|
||||
2. **Zabezpieczenie instalacji:**
|
||||
Uruchom skrypt `mariadb-secure-installation`, który pomoże Ci ustawić hasło `root`, usunąć anonimowych użytkowników i zabezpieczyć bazę danych.
|
||||
|
||||
```bash
|
||||
sudo mariadb-secure-installation
|
||||
```
|
||||
Postępuj zgodnie z instrukcjami na ekranie.
|
||||
|
||||
---
|
||||
|
||||
### Krok 6: Weryfikacja Konfiguracji
|
||||
Na koniec sprawdź, czy usługa działa poprawnie i czy niestandardowe ustawienia zostały załadowane.
|
||||
|
||||
1. **Sprawdź status usługi:**
|
||||
```bash
|
||||
sudo systemctl status mariadb
|
||||
```
|
||||
Powinieneś zobaczyć status `active (running)`.
|
||||
|
||||
2. **Zaloguj się do MariaDB i zweryfikuj zmienne:**
|
||||
Zaloguj się jako `root` (używając hasła ustawionego w poprzednim kroku).
|
||||
|
||||
```bash
|
||||
sudo mariadb -u root -p
|
||||
```
|
||||
|
||||
Po zalogowaniu, sprawdź kilka kluczowych zmiennych, aby upewnić się, że Twoja konfiguracja została wczytana:
|
||||
```sql
|
||||
SHOW VARIABLES LIKE 'character_set_server';
|
||||
SHOW VARIABLES LIKE 'collation_server';
|
||||
SHOW VARIABLES LIKE 'max_allowed_packet';
|
||||
```
|
||||
|
||||
Wyniki powinny być zgodne z tym, co ustawiliśmy w pliku `z-custom-migration.cnf`:
|
||||
- `character_set_server`: `latin1`
|
||||
- `collation_server`: `latin1_swedish_ci`
|
||||
- `max_allowed_packet`: `67108864` (co odpowiada `64M`)
|
||||
|
||||
---
|
||||
|
||||
## Następne Kroki
|
||||
Twój serwer MariaDB jest teraz zainstalowany, skonfigurowany i gotowy na migrację. Następne kroki będą obejmować:
|
||||
1. Utworzenie odpowiednich baz danych i użytkowników.
|
||||
2. Wykonanie zrzutu (dump) danych ze starego serwera.
|
||||
3. Zaimportowanie danych na nowy serwer MariaDB.
|
||||
@@ -0,0 +1,822 @@
|
||||
# Dokumentacja Projektu NASA (Mission Management System)
|
||||
|
||||
```mermaid
|
||||
%%{init: {
|
||||
'theme': 'base',
|
||||
'themeVariables': {
|
||||
'primaryColor': '#0b1220',
|
||||
'primaryTextColor': '#e5e7eb',
|
||||
'lineColor': '#475569',
|
||||
'fontFamily': 'Inter, ui-sans-serif, system-ui',
|
||||
'fontSize': '14px'
|
||||
},
|
||||
'flowchart': { 'curve': 'basis', 'nodeSpacing': 55, 'rankSpacing': 65 }
|
||||
}}%%
|
||||
|
||||
flowchart LR
|
||||
|
||||
%% =========================================================
|
||||
%% BASE STYLES (dark UI)
|
||||
%% =========================================================
|
||||
classDef top fill:#111827,stroke:#f59e0b,stroke-width:2.5px,color:#ffffff,rx:16,ry:16;
|
||||
classDef control fill:#0b2a4a,stroke:#22c55e,stroke-width:2.5px,color:#e0f2fe,rx:16,ry:16;
|
||||
|
||||
classDef section fill:#0b1220,stroke:#1f2937,stroke-width:1.2px,color:#cbd5e1,rx:12,ry:12;
|
||||
classDef agent fill:#020617,stroke:#475569,stroke-width:1.2px,color:#e5e7eb,rx:10,ry:10;
|
||||
|
||||
%% =========================================================
|
||||
%% MISSION COLOR SYSTEM
|
||||
%% =========================================================
|
||||
%% Apollo (blue)
|
||||
classDef missionApollo fill:#0b2a4a,stroke:#38bdf8,stroke-width:3px,color:#e0f2fe,rx:16,ry:16,font-weight:bold;
|
||||
classDef apSection fill:#061a2f,stroke:#38bdf8,stroke-width:1.8px,color:#e0f2fe,rx:12,ry:12;
|
||||
classDef apAgent fill:#020617,stroke:#38bdf8,stroke-width:1.6px,color:#e0f2fe,rx:10,ry:10;
|
||||
|
||||
%% Hubble (amber)
|
||||
classDef missionHubble fill:#2a1606,stroke:#f59e0b,stroke-width:3px,color:#ffedd5,rx:16,ry:16,font-weight:bold;
|
||||
classDef hbSection fill:#1b0f06,stroke:#f59e0b,stroke-width:1.8px,color:#ffedd5,rx:12,ry:12;
|
||||
classDef hbAgent fill:#020617,stroke:#f59e0b,stroke-width:1.6px,color:#ffedd5,rx:10,ry:10;
|
||||
|
||||
%% Artemis (green)
|
||||
classDef missionArtemis fill:#052e1a,stroke:#22c55e,stroke-width:3px,color:#dcfce7,rx:16,ry:16,font-weight:bold;
|
||||
classDef arSection fill:#041f12,stroke:#22c55e,stroke-width:1.8px,color:#dcfce7,rx:12,ry:12;
|
||||
classDef arAgent fill:#020617,stroke:#22c55e,stroke-width:1.6px,color:#dcfce7,rx:10,ry:10;
|
||||
|
||||
%% =========================================================
|
||||
%% COLUMN 1: PROGRAM LEAD
|
||||
%% =========================================================
|
||||
PROGRAM_LEAD["🧭 [NASA-HQ]<br/>PROGRAM LEAD<br/>Vision · Strategy · Final Decisions"]:::top
|
||||
|
||||
%% =========================================================
|
||||
%% COLUMN 2: MISSION CONTROL
|
||||
%% =========================================================
|
||||
MISSION_CONTROL["🎛️ [MCC]<br/>MISSION CONTROL<br/>Research · Delegation · Execution · Orchestration"]:::control
|
||||
PROGRAM_LEAD --> MISSION_CONTROL
|
||||
|
||||
%% =========================================================
|
||||
%% COLUMN 3: PILLARS / MISSIONS (stacked)
|
||||
%% =========================================================
|
||||
subgraph PILLARS[" "]
|
||||
direction TB
|
||||
|
||||
FLIGHT_SYSTEMS["🚀 [APOLLO]<br/>FLIGHT SYSTEMS<br/>Engineering · Infrastructure · Reliability"]:::missionApollo
|
||||
MISSION_STORY["🔭 [HUBBLE]<br/>MISSION STORY<br/>Content · Creative · Distribution"]:::missionHubble
|
||||
MISSION_OUTCOMES["🌙 [ARTEMIS]<br/>MISSION OUTCOMES<br/>Product · Growth · Community"]:::missionArtemis
|
||||
end
|
||||
|
||||
MISSION_CONTROL --> FLIGHT_SYSTEMS
|
||||
MISSION_CONTROL --> MISSION_STORY
|
||||
MISSION_CONTROL --> MISSION_OUTCOMES
|
||||
|
||||
%% =========================================================
|
||||
%% APOLLO DETAILS (Flight Systems)
|
||||
%% =========================================================
|
||||
subgraph FS_DETAILS[" "]
|
||||
direction TB
|
||||
|
||||
FS_S1["🧱 [APOLLO-CORE]<br/>Core Tech"]:::apSection
|
||||
FS_S2["💻 [APOLLO-CODE]<br/>Flight Code"]:::apSection
|
||||
FS_S3["✅ [APOLLO-VERIFY]<br/>Verification"]:::apSection
|
||||
|
||||
Anvil["🧰 APOLLO-CORE / Anvil<br/>Systems Engineer"]:::apAgent
|
||||
Cipher["🛡️ APOLLO-CORE / Cipher<br/>Security Engineer"]:::apAgent
|
||||
Pixel["🧩 APOLLO-CODE / Pixel<br/>Frontend Engineer"]:::apAgent
|
||||
Sentry["🛰️ APOLLO-CODE / Sentry<br/>DevOps & Infra"]:::apAgent
|
||||
Inspector["🔍 APOLLO-VERIFY / Inspector<br/>QA & Reliability"]:::apAgent
|
||||
|
||||
FS_S1 --> Anvil
|
||||
FS_S1 --> Cipher
|
||||
FS_S2 --> Pixel
|
||||
FS_S2 --> Sentry
|
||||
FS_S3 --> Inspector
|
||||
end
|
||||
|
||||
FLIGHT_SYSTEMS --> FS_S1
|
||||
FLIGHT_SYSTEMS --> FS_S2
|
||||
FLIGHT_SYSTEMS --> FS_S3
|
||||
|
||||
%% =========================================================
|
||||
%% HUBBLE DETAILS (Mission Story)
|
||||
%% =========================================================
|
||||
subgraph MS_DETAILS[" "]
|
||||
direction TB
|
||||
|
||||
MS_S1["📝 [HUBBLE-CONTENT]<br/>Mission Content"]:::hbSection
|
||||
MS_S2["🎨 [HUBBLE-CREATIVE]<br/>Creative Studio"]:::hbSection
|
||||
|
||||
Rex["🎬 HUBBLE-CONTENT / Rex<br/>Script Writer"]:::hbAgent
|
||||
Sage["📚 HUBBLE-CONTENT / Sage<br/>Research & Analysis"]:::hbAgent
|
||||
Echo["📰 HUBBLE-CONTENT / Echo<br/>Newsletter Engine"]:::hbAgent
|
||||
Clip["🎞️ HUBBLE-CONTENT / Clip<br/>Short-form Video"]:::hbAgent
|
||||
Nebula["🧑🎨 HUBBLE-CREATIVE / Nebula<br/>Visual Design"]:::hbAgent
|
||||
Nova["🎥 HUBBLE-CREATIVE / Nova<br/>Video Production"]:::hbAgent
|
||||
|
||||
MS_S1 --> Rex
|
||||
MS_S1 --> Sage
|
||||
MS_S1 --> Echo
|
||||
MS_S1 --> Clip
|
||||
MS_S2 --> Nebula
|
||||
MS_S2 --> Nova
|
||||
end
|
||||
|
||||
MISSION_STORY --> MS_S1
|
||||
MISSION_STORY --> MS_S2
|
||||
|
||||
%% =========================================================
|
||||
%% ARTEMIS DETAILS (Mission Outcomes)
|
||||
%% =========================================================
|
||||
subgraph MO_DETAILS[" "]
|
||||
direction TB
|
||||
|
||||
MO_S1["🧪 [ARTEMIS-EXP]<br/>Experiments"]:::arSection
|
||||
MO_S2["📡 [ARTEMIS-TLM]<br/>Telemetry"]:::arSection
|
||||
MO_S3["🤝 [ARTEMIS-GROUND]<br/>Ground Crew"]:::arSection
|
||||
|
||||
Scout["🧭 ARTEMIS-EXP / Scout<br/>Product Intelligence"]:::arAgent
|
||||
Herald["📣 ARTEMIS-EXP / Herald<br/>Launch & Announcements"]:::arAgent
|
||||
Forge["🧲 ARTEMIS-TLM / Forge<br/>Optimization"]:::arAgent
|
||||
Pulse["📈 ARTEMIS-TLM / Pulse<br/>Telemetry & Analytics"]:::arAgent
|
||||
Beacon["🧰 ARTEMIS-GROUND / Beacon<br/>Support & Onboarding"]:::arAgent
|
||||
Link["🗨️ ARTEMIS-GROUND / Link<br/>Community Ops"]:::arAgent
|
||||
Vibe["✨ ARTEMIS-GROUND / Vibe<br/>Engagement"]:::arAgent
|
||||
|
||||
MO_S1 --> Scout
|
||||
MO_S1 --> Herald
|
||||
MO_S2 --> Forge
|
||||
MO_S2 --> Pulse
|
||||
MO_S3 --> Beacon
|
||||
MO_S3 --> Link
|
||||
MO_S3 --> Vibe
|
||||
end
|
||||
|
||||
MISSION_OUTCOMES --> MO_S1
|
||||
MISSION_OUTCOMES --> MO_S2
|
||||
MISSION_OUTCOMES --> MO_S3
|
||||
```
|
||||
|
||||
## Spis Treści
|
||||
|
||||
1. **Koncepcja i Architektura**
|
||||
* Opis systemu zarządzania misjami
|
||||
* Wyjaśnienie ról (PROGRAM LEAD vs MISSION CONTROL)
|
||||
* Pliki sterujące systemem (NASA-HQ)
|
||||
* Pliki dla Mission Control (MCC)
|
||||
2. **Misje i Agenci**
|
||||
* Misja APOLLO (Flight Systems)
|
||||
* Sub-agenci APOLLO
|
||||
* Misja HUBBLE (Mission Story)
|
||||
* Sub-agenci HUBBLE
|
||||
* Misja ARTEMIS (Mission Outcomes)
|
||||
* Sub-agenci ARTEMIS
|
||||
3. **Implementacja i Bootstrap**
|
||||
* Struktura folderów
|
||||
* Plik konfiguracyjny `openclaw.missions.json`
|
||||
* Główny skrypt bootstrap
|
||||
* Szablony pakietów misji
|
||||
|
||||
---
|
||||
|
||||
# CZĘŚĆ 1: KONCEPCJA I ARCHITEKTURA
|
||||
|
||||
## 1. Opis systemu (Koncepcja)
|
||||
|
||||
### Co to za system (w jednym zdaniu)
|
||||
|
||||
To jest **operacyjny system zarządzania pracą**, w którym:
|
||||
|
||||
* **PROGRAM LEAD** ustala kierunek i priorytety,
|
||||
* **MISSION CONTROL** zamienia priorytety na zadania i orkiestruje wykonanie,
|
||||
* a trzy „misje” (**APOLLO / HUBBLE / ARTEMIS**) są **stałymi strumieniami pracy** (workstreams) z własnym słownikiem, sekcjami i agentami.
|
||||
|
||||
To nie jest tylko „ładny org chart”. To jest:
|
||||
✅ **routing zadań**,
|
||||
✅ **standard nazewnictwa**,
|
||||
✅ **wspólna nawigacja**,
|
||||
✅ **a docelowo także logika dostępu i audytu**.
|
||||
|
||||
### Warstwy odpowiedzialności (governance)
|
||||
|
||||
#### PROGRAM LEAD — warstwa decyzji
|
||||
|
||||
**Rola:** “dlaczego i po co?”
|
||||
**Odpowiada za:**
|
||||
* wizję i zasady gry,
|
||||
* finalne decyzje (trade‑offs),
|
||||
* priorytety (co jest ważniejsze),
|
||||
* definicję “co znaczy sukces”.
|
||||
|
||||
**W praktyce:**
|
||||
PROGRAM LEAD nie schodzi do agentów. PROGRAM LEAD steruje przez *MISSION CONTROL*.
|
||||
|
||||
#### MISSION CONTROL — warstwa operacji
|
||||
|
||||
**Rola:** “co robimy teraz i jak to dowieźć?”
|
||||
**Odpowiada za:**
|
||||
* przyjmowanie zleceń/priorytetów,
|
||||
* rozbijanie na konkretne zadania,
|
||||
* delegowanie do misji i sekcji,
|
||||
* pilnowanie wykonania i domykanie wątków.
|
||||
|
||||
MISSION CONTROL jest Twoim “dispatcherem”:
|
||||
* kontroluje backlog,
|
||||
* kontroluje WIP,
|
||||
* kontroluje jakość wejścia/wyjścia.
|
||||
|
||||
### Misje NASA jako system nawigacji
|
||||
|
||||
Zamiast klasycznych działów typu “Engineering/Marketing/Sales”, masz trzy **misje**, które są:
|
||||
* **łatwe do zapamiętania**,
|
||||
* **rozłączne semantycznie** (mniej chaosu),
|
||||
* **idealne do tagowania** (OpenClaw, logi, foldery, eventy).
|
||||
|
||||
Każda misja ma cel, zakres, sekcje, agentów i prefiks (call‑sign).
|
||||
|
||||
#### 🚀 [APOLLO] — FLIGHT SYSTEMS
|
||||
**Slogan:** “Sprawność, stabilność, niezawodność”
|
||||
**Po co istnieje:** utrzymuje i rozwija fundament techniczny.
|
||||
|
||||
* **[APOLLO-CORE] Core Tech**: fundamenty, bezpieczeństwo, platforma.
|
||||
* **[APOLLO-CODE] Flight Code**: kod produktu, implementacja, UI.
|
||||
* **[APOLLO-VERIFY] Verification**: testy, jakość, niezawodność.
|
||||
|
||||
#### 🔭 [HUBBLE] — MISSION STORY
|
||||
**Slogan:** “Misja musi być widoczna i zrozumiała”
|
||||
**Po co istnieje:** produkuje i dystrybuuje treści.
|
||||
|
||||
* **[HUBBLE-CONTENT] Mission Content**: pisanie, research.
|
||||
* **[HUBBLE-CREATIVE] Creative Studio**: grafika, wideo.
|
||||
|
||||
#### 🌙 [ARTEMIS] — MISSION OUTCOMES
|
||||
**Slogan:** “Efekt misji: produkt, wzrost, społeczność”
|
||||
**Po co istnieje:** dowozi wartość, mierzy ją i zamienia feedback na iteracje.
|
||||
|
||||
* **[ARTEMIS-EXP] Experiments**: nowe inicjatywy, launch.
|
||||
* **[ARTEMIS-TLM] Telemetry**: pomiary, analityka.
|
||||
* **[ARTEMIS-GROUND] Ground Crew**: społeczność, wsparcie.
|
||||
|
||||
---
|
||||
|
||||
## 2. Role i Decyzje (Governance)
|
||||
|
||||
### Decision Rights (kto może / musi / nie może decydować)
|
||||
|
||||
#### NASA-HQ (PROGRAM LEAD = CEO)
|
||||
|
||||
* **Może decydować o:** kierunku, priorytetach, politykach i “co jest sukcesem”.
|
||||
* **Musi decydować o:** P0/P1, zmianach strategii, kosztach/ryzyku systemowym.
|
||||
* **Nie powinien decydować o:** szczegółach implementacji i mikro‑wyborach w taskach.
|
||||
|
||||
#### MISSION CONTROL (MCC = COO / Ops)
|
||||
|
||||
* **Może decydować o:** routingu, WIP, strukturze pakietów, jakości wejścia/wyjścia, “czy to jest done operacyjnie”.
|
||||
* **Musi decydować o:** triage, podziale na pakiety, bramkach SIM/FLIGHT, domknięciu (`PROCEED/ITERATE/HOLD/SCRUB`).
|
||||
* **Nie może decydować o:** strategicznej zmianie celu (CEO territory) oraz o FLIGHT dla P0/P1 bez GO od NASA-HQ.
|
||||
|
||||
#### Misje (APOLLO / HUBBLE / ARTEMIS = “mission owners”)
|
||||
|
||||
* **Może decydować o:** *jak* wykonać zadanie w ramach swojej domeny, jakie artefakty i jak je ułożyć, jakie rekomendacje zaproponować.
|
||||
* **Musi decydować o:** standardach jakości wewnątrz misji, kompletności artefaktów, rekomendacji decyzji (dla MCC).
|
||||
* **Nie może decydować o:** zmianie routingu, przekierowaniu misji, zatwierdzaniu FLIGHT (bez MCC), ani o celach strategicznych.
|
||||
|
||||
### Decision Matrix (skrót)
|
||||
|
||||
* **Strategia / priorytety P0/P1:** **PL decyduje**, MCC rekomenduje
|
||||
* **Routing / pakiety / WIP:** **MCC decyduje**
|
||||
* **Standardy operacyjne:** **MCC decyduje**, PL zatwierdza tylko zmiany “filozofii”
|
||||
* **Wykonanie w domenie:** **misja decyduje jak**, MCC decyduje czy “done”
|
||||
* **FLIGHT:** **MCC gatekeeper**, **PL GO dla P0/P1**, **Inspector NO‑GO dla technicznego**
|
||||
* **Closure:** **MCC decyduje**, misja rekomenduje, PL tylko przy P0/P1/sporach
|
||||
|
||||
### RACI — diagram odpowiedzialności
|
||||
|
||||
```mermaid
|
||||
%%{init: {
|
||||
'theme': 'base',
|
||||
'themeVariables': {
|
||||
'primaryColor': '#0b1220',
|
||||
'primaryTextColor': '#e5e7eb',
|
||||
'lineColor': '#475569',
|
||||
'fontFamily': 'Inter, ui-sans-serif, system-ui',
|
||||
'fontSize': '14px'
|
||||
},
|
||||
'flowchart': { 'curve': 'basis', 'nodeSpacing': 40, 'rankSpacing': 55 }
|
||||
}}%%
|
||||
|
||||
flowchart LR
|
||||
|
||||
%% Styles
|
||||
classDef role fill:#111827,stroke:#334155,stroke-width:1.5px,color:#e5e7eb,rx:12,ry:12,font-weight:bold;
|
||||
classDef proc fill:#0f172a,stroke:#64748b,stroke-width:1.2px,color:#e5e7eb,rx:10,ry:10;
|
||||
classDef raciR fill:#052e1a,stroke:#22c55e,stroke-width:2px,color:#dcfce7,rx:10,ry:10;
|
||||
classDef raciA fill:#2a1606,stroke:#f59e0b,stroke-width:2px,color:#ffedd5,rx:10,ry:10;
|
||||
classDef raciC fill:#1e1b4b,stroke:#818cf8,stroke-width:2px,color:#e0eaff,rx:10,ry:10;
|
||||
classDef raciI fill:#0b1220,stroke:#475569,stroke-width:1.2px,color:#cbd5e1,rx:10,ry:10;
|
||||
|
||||
%% Roles (columns)
|
||||
subgraph ROLES["ROLES"]
|
||||
direction TB
|
||||
PL["🧭 NASA‑HQ\nPROGRAM LEAD (CEO)"]:::role
|
||||
MCC["🎛️ MISSION CONTROL\n(MCC / COO)"]:::role
|
||||
AP["🚀 APOLLO\nFlight Systems"]:::role
|
||||
HU["🔭 HUBBLE\nMission Story"]:::role
|
||||
AR["🌙 ARTEMIS\nMission Outcomes"]:::role
|
||||
VFY["✅ APOLLO‑VERIFY\n(Inspector)"]:::role
|
||||
end
|
||||
|
||||
%% Processes (rows)
|
||||
subgraph PROCESSES["PROCESSES"]
|
||||
direction TB
|
||||
P1["1) Intake / Triage"]:::proc
|
||||
P2["2) Routing (Mission + Call‑sign)"]:::proc
|
||||
P3["3) Packet Creation (folder + brief)"]:::proc
|
||||
P4["4) Execution (produce artifacts)"]:::proc
|
||||
P5["5) Status / Telemetry updates"]:::proc
|
||||
P6["6) SIM→FLIGHT Checklist prepared"]:::proc
|
||||
P7["7) FLIGHT GO/NO‑GO"]:::proc
|
||||
P8["8) Close Packet (PROCEED/ITERATE/HOLD/SCRUB)"]:::proc
|
||||
P9["9) Archive + Index update"]:::proc
|
||||
end
|
||||
|
||||
%% RACI links: each process points to roles with R/A/C/I tags
|
||||
P1 -->|"A"| MCC:::raciA; P1 -->|"I"| PL:::raciI; P1 -->|"C"| AP:::raciC; P1 -->|"C"| HU:::raciC; P1 -->|"C"| AR:::raciC
|
||||
P2 -->|"A"| MCC:::raciA; P2 -->|"I"| PL:::raciI; P2 -->|"C"| AP:::raciC; P2 -->|"C"| HU:::raciC; P2 -->|"C"| AR:::raciC
|
||||
P3 -->|"R/A"| MCC:::raciA; P3 -->|"C"| AP:::raciC; P3 -->|"C"| HU:::raciC; P3 -->|"C"| AR:::raciC; P3 -->|"I"| PL:::raciI
|
||||
P4 -->|"I"| MCC:::raciI; P4 -->|"R/A"| AP:::raciR; P4 -->|"R/A"| HU:::raciR; P4 -->|"R/A"| AR:::raciR; P4 -->|"I"| PL:::raciI
|
||||
P5 -->|"A"| MCC:::raciA; P5 -->|"R"| AP:::raciR; P5 -->|"R"| HU:::raciR; P5 -->|"R"| AR:::raciR; P5 -->|"I"| PL:::raciI
|
||||
P6 -->|"A"| MCC:::raciA; P6 -->|"R"| AP:::raciR; P6 -->|"R"| HU:::raciR; P6 -->|"R"| AR:::raciR; P6 -->|"C"| VFY:::raciC; P6 -->|"C"| PL:::raciC
|
||||
P7 -->|"A"| MCC:::raciA; P7 -->|"C"| VFY:::raciC; P7 -->|"C"| AP:::raciC; P7 -->|"C"| HU:::raciC; P7 -->|"C"| AR:::raciC; P7 -->|"A (P0/P1)"| PL:::raciA
|
||||
P8 -->|"A"| MCC:::raciA; P8 -->|"C"| AP:::raciC; P8 -->|"C"| HU:::raciC; P8 -->|"C"| AR:::raciC; P8 -->|"C (P0/P1 or dispute)"| PL:::raciC
|
||||
P9 -->|"R/A"| MCC:::raciA; P9 -->|"I"| PL:::raciI; P9 -->|"I"| AP:::raciI; P9 -->|"I"| HU:::raciI; P9 -->|"I"| AR:::raciI
|
||||
```
|
||||
|
||||
---
|
||||
## 3. Pliki sterujące NASA-HQ
|
||||
|
||||
### `IDENTITY.md`
|
||||
```md
|
||||
Name: NASA-HQ
|
||||
Role: Program Lead & Mission Control
|
||||
System: Mission Management System (OpenClaw)
|
||||
|
||||
NASA-HQ is the executive and operational control layer of the system.
|
||||
It does not execute tasks directly.
|
||||
It defines intent, routes work, enforces structure, and closes missions.
|
||||
```
|
||||
|
||||
### `SOUL.md`
|
||||
```md
|
||||
NASA-HQ operates with discipline, clarity, and restraint.
|
||||
Core principles:
|
||||
- Structure over improvisation
|
||||
- Routing before execution
|
||||
- Decisions over endless work
|
||||
- Fewer missions, better outcomes
|
||||
```
|
||||
|
||||
### `TOOLS.md`
|
||||
```md
|
||||
NASA-HQ uses tools only to:
|
||||
- create and manage mission structure
|
||||
- write and update documentation
|
||||
- maintain routing and indices
|
||||
- inspect system state
|
||||
|
||||
Rule of thumb:
|
||||
If a tool changes reality → it must go through a Mission Packet and FLIGHT gate.
|
||||
```
|
||||
|
||||
---
|
||||
## 4. Pliki sterujące MISSION CONTROL (MCC)
|
||||
|
||||
### `IDENTITY.md`
|
||||
```md
|
||||
Name: MISSION CONTROL
|
||||
Alias: MCC
|
||||
Role: Operational Command & Routing Layer
|
||||
|
||||
MISSION CONTROL is the dispatcher and quality gate of the entire system.
|
||||
It converts strategic intent into executable mission packets, routes work by call-sign,
|
||||
maintains WIP limits, enforces SIM/FLIGHT gates, and closes missions with decisions.
|
||||
```
|
||||
|
||||
### `RULES.md`
|
||||
```md
|
||||
1) Every task must have exactly one call-sign (or MCC-TRIAGE).
|
||||
2) Never mix missions inside one packet.
|
||||
3) If work spans missions: create a parent MCC packet + child packets per mission.
|
||||
4) SIM is default. FLIGHT requires checklist.
|
||||
5) Every packet must end with a decision: PROCEED | ITERATE | HOLD | SCRUB.
|
||||
```
|
||||
|
||||
### `HEARTBEAT.md`
|
||||
```md
|
||||
1) Review active packets (MCC active index).
|
||||
2) Enforce WIP (stop intake if limit exceeded).
|
||||
3) Check SIM/FLIGHT hygiene.
|
||||
4) Closure sweep (packets done but undecided).
|
||||
5) Archive hygiene.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# CZĘŚĆ 2: MISJE I AGENCI
|
||||
|
||||
## 1. Misja APOLLO (Flight Systems)
|
||||
|
||||
### `IDENTITY.md`
|
||||
```md
|
||||
Name: APOLLO
|
||||
Role: Mission Owner — FLIGHT SYSTEMS
|
||||
Domain: Engineering · Infrastructure · Reliability
|
||||
|
||||
APOLLO owns the technical flight layer:
|
||||
- Core Tech (APOLLO-CORE)
|
||||
- Flight Code (APOLLO-CODE)
|
||||
- Verification (APOLLO-VERIFY)
|
||||
```
|
||||
|
||||
### `SOUL.md`
|
||||
```md
|
||||
APOLLO is reliability-first and safety-gated.
|
||||
Core principles:
|
||||
- Stability over speed
|
||||
- Explicit changes over hidden magic
|
||||
- Small, reversible steps over big rewrites
|
||||
- Verification before confidence
|
||||
```
|
||||
|
||||
### Sub-agenci APOLLO
|
||||
|
||||
* **Anvil (APOLLO-CORE)**: Systems Engineer. Platform foundations, architecture constraints.
|
||||
* **Cipher (APOLLO-CORE)**: Security Engineer. Security posture, secrets, hardening.
|
||||
* **Pixel (APOLLO-CODE)**: Frontend Engineer. UI code, integration glue.
|
||||
* **Sentry (APOLLO-CODE)**: DevOps & Infra. Pipelines, runtime, automation.
|
||||
* **Inspector (APOLLO-VERIFY)**: QA & Reliability. Verification evidence, regression checks.
|
||||
|
||||
---
|
||||
|
||||
## 2. Misja HUBBLE (Mission Story)
|
||||
|
||||
### `IDENTITY.md`
|
||||
```md
|
||||
Name: HUBBLE
|
||||
Role: Mission Owner — MISSION STORY
|
||||
Domain: Content · Creative · Distribution
|
||||
|
||||
HUBBLE owns the story layer:
|
||||
- Mission Content (HUBBLE-CONTENT)
|
||||
- Creative Studio (HUBBLE-CREATIVE)
|
||||
```
|
||||
|
||||
### `SOUL.md`
|
||||
```md
|
||||
HUBBLE is clarity-first, audience-aware, and production-minded.
|
||||
Core principles:
|
||||
- Clarity beats cleverness
|
||||
- Consistency beats variety
|
||||
- Shipping beats endless polishing
|
||||
```
|
||||
|
||||
### Sub-agenci HUBBLE
|
||||
|
||||
* **Rex (HUBBLE-CONTENT)**: Script Writer. Scripts, hooks, outlines.
|
||||
* **Sage (HUBBLE-CONTENT)**: Research & Analysis. Evidence, sources, insights.
|
||||
* **Echo (HUBBLE-CONTENT)**: Newsletter Engine. Newsletter drafts, editorial structure.
|
||||
* **Clip (HUBBLE-CONTENT)**: Short-form Video. Scripts for Reels/Shorts.
|
||||
* **Nebula (HUBBLE-CREATIVE)**: Visual Design. Visual assets, layouts, thumbnails.
|
||||
* **Nova (HUBBLE-CREATIVE)**: Video Production. Storyboards, edit plans.
|
||||
|
||||
---
|
||||
|
||||
## 3. Misja ARTEMIS (Mission Outcomes)
|
||||
|
||||
### `IDENTITY.md`
|
||||
```md
|
||||
Name: ARTEMIS
|
||||
Role: Mission Owner — MISSION OUTCOMES
|
||||
Domain: Product · Growth · Community
|
||||
|
||||
ARTEMIS owns the outcomes layer:
|
||||
- Experiments (ARTEMIS-EXP)
|
||||
- Telemetry (ARTEMIS-TLM)
|
||||
- Ground Crew (ARTEMIS-GROUND)
|
||||
```
|
||||
|
||||
### `SOUL.md`
|
||||
```md
|
||||
ARTEMIS is outcome-driven and evidence-first.
|
||||
Core principles:
|
||||
- Outcomes over activity
|
||||
- Evidence over opinion
|
||||
- Small experiments over big rewrites
|
||||
- Telemetry before conclusions
|
||||
```
|
||||
|
||||
### Sub-agenci ARTEMIS
|
||||
|
||||
* **Scout (ARTEMIS-EXP)**: Product Intelligence. Opportunities, hypotheses.
|
||||
* **Herald (ARTEMIS-EXP)**: Launch & Announcements. Launch plans, rollout messaging.
|
||||
* **Pulse (ARTEMIS-TLM)**: Telemetry & Analytics. Dashboards, KPI definitions.
|
||||
* **Forge (ARTEMIS-TLM)**: Optimization. Optimization proposals, experiment variants.
|
||||
* **Beacon (ARTEMIS-GROUND)**: Support & Onboarding. Onboarding playbooks, support workflows.
|
||||
* **Link (ARTEMIS-GROUND)**: Community Ops. Operations, moderation, structure.
|
||||
* **Vibe (ARTEMIS-GROUND)**: Engagement. Engagement loops, prompts.
|
||||
|
||||
---
|
||||
# CZĘŚĆ 3: IMPLEMENTACJA I BOOTSTRAP
|
||||
|
||||
## 1. Struktura folderów
|
||||
```text
|
||||
/missions
|
||||
├── _MCC/ # MISSION CONTROL (operacje)
|
||||
│ ├── 00_operating-manual.md
|
||||
│ ├── 10_backlog.md
|
||||
│ ├── 20_active-missions.md
|
||||
│ ├── 30_decisions.md
|
||||
│ ├── 40_routing-rules.md
|
||||
│ ├── 50_templates/
|
||||
│ │ ├── task-brief.md
|
||||
│ │ ├── sim-flight-checklist.md
|
||||
│ │ ├── post-mission-report.md
|
||||
│ │ └── decision-record.md
|
||||
│ └── 90_archive-index.md
|
||||
│
|
||||
├── APOLLO/ # 🚀 FLIGHT SYSTEMS
|
||||
│ ├── CORE_TECH/ # [APOLLO-CORE]
|
||||
│ │ └── missions/
|
||||
│ ├── FLIGHT_CODE/ # [APOLLO-CODE]
|
||||
│ │ └── missions/
|
||||
│ ├── VERIFICATION/ # [APOLLO-VERIFY]
|
||||
│ │ └── missions/
|
||||
│ └── 99_archive/
|
||||
│
|
||||
├── HUBBLE/ # 🔭 MISSION STORY
|
||||
│ ├── CONTENT/ # [HUBBLE-CONTENT]
|
||||
│ │ └── missions/
|
||||
│ ├── CREATIVE/ # [HUBBLE-CREATIVE]
|
||||
│ │ └── missions/
|
||||
│ └── 99_archive/
|
||||
│
|
||||
└── ARTEMIS/ # 🌙 MISSION OUTCOMES
|
||||
├── EXPERIMENTS/ # [ARTEMIS-EXP]
|
||||
│ └── missions/
|
||||
├── TELEMETRY/ # [ARTEMIS-TLM]
|
||||
│ └── missions/
|
||||
├── GROUND_CREW/ # [ARTEMIS-GROUND]
|
||||
│ └── missions/
|
||||
└── 99_archive/
|
||||
```
|
||||
|
||||
## 2. Plik konfiguracyjny `openclaw.missions.json`
|
||||
|
||||
Ten plik jest sercem mapowania systemu. Powinien zostać umieszczony w `{ROOT_PATH}/_MCC/openclaw.missions.json`.
|
||||
|
||||
```json
|
||||
{
|
||||
"root_path": "{{ROOT_PATH}}",
|
||||
"wip_limit": 5,
|
||||
"modes": {
|
||||
"default": "SIM",
|
||||
"flight_requires_checklist": true,
|
||||
"flight_requires_program_lead_for_priority": ["P0", "P1"]
|
||||
},
|
||||
"missions": {
|
||||
"APOLLO": {
|
||||
"label": "FLIGHT SYSTEMS",
|
||||
"sections": {
|
||||
"APOLLO-CORE": { "folder": "APOLLO/CORE_TECH", "agents": ["Anvil", "Cipher"] },
|
||||
"APOLLO-CODE": { "folder": "APOLLO/FLIGHT_CODE", "agents": ["Pixel", "Sentry"] },
|
||||
"APOLLO-VERIFY": { "folder": "APOLLO/VERIFICATION", "agents": ["Inspector"] }
|
||||
}
|
||||
},
|
||||
"HUBBLE": {
|
||||
"label": "MISSION STORY",
|
||||
"sections": {
|
||||
"HUBBLE-CONTENT": { "folder": "HUBBLE/CONTENT", "agents": ["Rex", "Sage", "Echo", "Clip"] },
|
||||
"HUBBLE-CREATIVE": { "folder": "HUBBLE/CREATIVE", "agents": ["Nebula", "Nova"] }
|
||||
}
|
||||
},
|
||||
"ARTEMIS": {
|
||||
"label": "MISSION OUTCOMES",
|
||||
"sections": {
|
||||
"ARTEMIS-EXP": { "folder": "ARTEMIS/EXPERIMENTS", "agents": ["Scout", "Herald"] },
|
||||
"ARTEMIS-TLM": { "folder": "ARTEMIS/TELEMETRY", "agents": ["Forge", "Pulse"] },
|
||||
"ARTEMIS-GROUND": { "folder": "ARTEMIS/GROUND_CREW", "agents": ["Beacon", "Link", "Vibe"] }
|
||||
}
|
||||
}
|
||||
},
|
||||
"packet": {
|
||||
"name_format": "YYYY-MM-DD__CALLSIGN__slug",
|
||||
"required_files": [
|
||||
"00_brief.md",
|
||||
"10_worklog.md",
|
||||
"30_results.md",
|
||||
"40_decision.md",
|
||||
"90_links.md"
|
||||
],
|
||||
"artifact_dir": "20_artifacts"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Główny skrypt bootstrap
|
||||
|
||||
Poniższy skrypt jest główną metodą tworzenia całej struktury systemu za pomocą jednego polecenia agenta `openclaw`.
|
||||
|
||||
### Wersja dla Linux/macOS/WSL (bash)
|
||||
|
||||
```bash
|
||||
export ROOT_PATH="$HOME/.openclaw/workspace/missions"
|
||||
|
||||
openclaw --profile missionctl agent --message "
|
||||
Jesteś MISSION CONTROL bootstrapper. Masz utworzyć strukturę systemu zarządzania MISJAMI w katalogu ROOT_PATH=$ROOT_PATH.
|
||||
Wykonaj dokładnie:
|
||||
|
||||
1) Utwórz katalogi:
|
||||
- $ROOT_PATH/_MCC/50_templates
|
||||
- $ROOT_PATH/APOLLO/CORE_TECH/missions
|
||||
- $ROOT_PATH/APOLLO/FLIGHT_CODE/missions
|
||||
- $ROOT_PATH/APOLLO/VERIFICATION/missions
|
||||
- $ROOT_PATH/APOLLO/99_archive
|
||||
- $ROOT_PATH/HUBBLE/CONTENT/missions
|
||||
- $ROOT_PATH/HUBBLE/CREATIVE/missions
|
||||
- $ROOT_PATH/HUBBLE/99_archive
|
||||
- $ROOT_PATH/ARTEMIS/EXPERIMENTS/missions
|
||||
- $ROOT_PATH/ARTEMIS/TELEMETRY/missions
|
||||
- $ROOT_PATH/ARTEMIS/GROUND_CREW/missions
|
||||
- $ROOT_PATH/ARTEMIS/99_archive
|
||||
|
||||
2) Zapisz pliki startowe (nadpisz jeśli istnieją):
|
||||
A) $ROOT_PATH/_MCC/00_operating-manual.md
|
||||
Treść:
|
||||
# Operating Manual — Mission System
|
||||
|
||||
## Governance
|
||||
- PROGRAM LEAD: vision, strategy, final decisions
|
||||
- MISSION CONTROL (MCC): triage, routing, execution, WIP, closure
|
||||
|
||||
## Missions
|
||||
- APOLLO: Flight Systems (Core Tech, Flight Code, Verification)
|
||||
- HUBBLE: Mission Story (Mission Content, Creative Studio)
|
||||
- ARTEMIS: Mission Outcomes (Experiments, Telemetry, Ground Crew)
|
||||
|
||||
## Packet standard
|
||||
Each packet contains:
|
||||
00_brief.md, 10_worklog.md, 20_artifacts/, 30_results.md, 40_decision.md, 90_links.md
|
||||
|
||||
## Modes
|
||||
SIM (default) vs FLIGHT (requires SIM→FLIGHT checklist)
|
||||
|
||||
## Closure
|
||||
PROCEED | ITERATE | HOLD | SCRUB
|
||||
|
||||
B) $ROOT_PATH/_MCC/40_routing-rules.md
|
||||
Treść:
|
||||
# Routing Rules (MCC)
|
||||
|
||||
## Call-signs → folders
|
||||
APOLLO-CORE → APOLLO/CORE_TECH
|
||||
APOLLO-CODE → APOLLO/FLIGHT_CODE
|
||||
APOLLO-VERIFY → APOLLO/VERIFICATION
|
||||
|
||||
HUBBLE-CONTENT → HUBBLE/CONTENT
|
||||
HUBBLE-CREATIVE → HUBBLE/CREATIVE
|
||||
|
||||
ARTEMIS-EXP → ARTEMIS/EXPERIMENTS
|
||||
ARTEMIS-TLM → ARTEMIS/TELEMETRY
|
||||
ARTEMIS-GROUND → ARTEMIS/GROUND_CREW
|
||||
|
||||
## Default mode
|
||||
SIM is default. FLIGHT requires checklist + approvals.
|
||||
|
||||
C) Puste indeksy:
|
||||
- $ROOT_PATH/_MCC/10_backlog.md (\"# Backlog (MCC)\")
|
||||
- $ROOT_PATH/_MCC/20_active-missions.md (\"# Active Missions (MCC)\")
|
||||
- $ROOT_PATH/_MCC/30_decisions.md (\"# Decisions (MCC)\")
|
||||
- $ROOT_PATH/_MCC/90_archive-index.md (\"# Archive Index (MCC)\")
|
||||
|
||||
3) Zapisz templates:
|
||||
- $ROOT_PATH/_MCC/50_templates/task-brief.md
|
||||
- $ROOT_PATH/_MCC/50_templates/sim-flight-checklist.md
|
||||
- $ROOT_PATH/_MCC/50_templates/post-mission-report.md
|
||||
- $ROOT_PATH/_MCC/50_templates/decision-record.md
|
||||
|
||||
4) Zapisz plik mapowania `openclaw.missions.json` z sekcji 3.2.
|
||||
|
||||
5) Na koniec zwróć krótkie podsumowanie: co utworzyłeś i gdzie.
|
||||
"
|
||||
```
|
||||
|
||||
### Wersja dla Windows PowerShell
|
||||
|
||||
```powershell
|
||||
$ROOT_PATH = "$env:USERPROFILE\.openclaw\workspace\missions"
|
||||
|
||||
openclaw --profile missionctl agent --message @"
|
||||
Utwórz strukturę systemu zarządzania MISJAMI w ROOT_PATH=$ROOT_PATH zgodnie z instrukcjami (katalogi, pliki MCC, template’y i openclaw.missions.json) analogicznie jak w wersji bash.
|
||||
"@
|
||||
```
|
||||
|
||||
## 4. Szablony Pakietów Misji
|
||||
|
||||
Poniżej znajdują się szablony, które powinny być umieszczone w `_MCC/50_templates/`.
|
||||
|
||||
### `task-brief.md`
|
||||
```md
|
||||
# [CALLSIGN] Task Brief — <title>
|
||||
|
||||
**Routing:** [CALLSIGN]
|
||||
**Owner (Agent):** <AgentName>
|
||||
**Mode:** SIM | FLIGHT
|
||||
**Priority:** P0 | P1 | P2
|
||||
**Start:** YYYY-MM-DD
|
||||
**Due:** YYYY-MM-DD (optional)
|
||||
|
||||
## Context
|
||||
Dlaczego to robimy? Jaki problem/okazja?
|
||||
|
||||
## Goal (1–2 zdania)
|
||||
Co ma być osiągnięte?
|
||||
|
||||
## Output / Deliverables
|
||||
- [ ] Artefakt 1 (np. raport / plik / PRD / skrypt / wideo)
|
||||
- [ ] Artefakt 2
|
||||
|
||||
## Constraints
|
||||
- deadline, format, ograniczenia techniczne, polityki
|
||||
|
||||
## Acceptance Criteria (Definition of Done)
|
||||
- Warunek A
|
||||
- Warunek B
|
||||
- Metryka/obserwacja C (jeśli dotyczy)
|
||||
|
||||
## Risks / Unknowns
|
||||
- ryzyko 1 + plan mitigacji
|
||||
```
|
||||
|
||||
### `sim-flight-checklist.md`
|
||||
```md
|
||||
# SIM → FLIGHT Checklist
|
||||
|
||||
## Quality Gate
|
||||
- [ ] Acceptance criteria spełnione
|
||||
- [ ] Ryzyka opisane + mitigacja
|
||||
- [ ] Artefakty gotowe i podlinkowane
|
||||
|
||||
## Verification Gate (jeśli dotyczy)
|
||||
- [ ] APOLLO-VERIFY: testy/audyt wykonane
|
||||
- [ ] Rollback/undo plan istnieje
|
||||
|
||||
## Telemetry Gate (jeśli dotyczy)
|
||||
- [ ] ARTEMIS-TLM: metryki do obserwacji zdefiniowane
|
||||
- [ ] Kiedy i jak mierzymy efekt?
|
||||
|
||||
## Approval
|
||||
- [ ] MISSION CONTROL: GO
|
||||
- [ ] PROGRAM LEAD: GO (dla P0/P1)
|
||||
```
|
||||
|
||||
### `post-mission-report.md`
|
||||
```md
|
||||
# Post-Mission Report — <title>
|
||||
|
||||
**Packet:** YYYY-MM-DD__CALLSIGN__slug
|
||||
**Decision:** PROCEED | ITERATE | HOLD | SCRUB
|
||||
**Owner:** MISSION CONTROL / PROGRAM LEAD
|
||||
**Date:** YYYY-MM-DD
|
||||
|
||||
## Summary
|
||||
1–3 zdania: co zrobiono i po co.
|
||||
|
||||
## Artifacts
|
||||
- linki/ścieżki
|
||||
|
||||
## Measurements / Evidence
|
||||
- metryki, screeny, logi, testy
|
||||
|
||||
## Learnings
|
||||
- co zadziałało
|
||||
- co nie zadziałało
|
||||
|
||||
## Next Steps
|
||||
- 1–5 kroków
|
||||
```
|
||||
|
||||
### `decision-record.md`
|
||||
```md
|
||||
# Decision Record — <title>
|
||||
|
||||
**Decision:** PROCEED | ITERATE | HOLD | SCRUB
|
||||
**Date:** YYYY-MM-DD
|
||||
**Owner:** PROGRAM LEAD / MISSION CONTROL
|
||||
|
||||
## Rationale
|
||||
Dlaczego taka decyzja?
|
||||
|
||||
## Trade-offs
|
||||
Co świadomie poświęcamy?
|
||||
|
||||
## Follow-up
|
||||
- [ ] zadanie 1
|
||||
- [ ] zadanie 2
|
||||
```
|
||||
@@ -0,0 +1,334 @@
|
||||
# Specyfikacja Konfiguracji OpenClaw: System Zarządzania Misjami
|
||||
|
||||
Na podstawie analizy dostarczonych plików, przygotowałem specyfikację do ustawienia systemu zarządzania misjami w OpenClaw. System ten opiera się na hierarchicznej strukturze folderów, pliku konfiguracyjnym `openclaw.missions.json` oraz zestawie szablonów.
|
||||
|
||||
## 1. Konfiguracja Rdzenia Systemu (`openclaw.missions.json`)
|
||||
|
||||
Sercem systemu jest plik konfiguracyjny, który mapuje misje, sekcje i agentów. Należy go umieścić w `{ROOT_PATH}/_MCC/openclaw.missions.json`.
|
||||
|
||||
**Zawartość `openclaw.missions.json`:**
|
||||
```json
|
||||
{
|
||||
"root_path": "{{ROOT_PATH}}",
|
||||
"wip_limit": 5,
|
||||
"modes": {
|
||||
"default": "SIM",
|
||||
"flight_requires_checklist": true,
|
||||
"flight_requires_program_lead_for_priority": ["P0", "P1"]
|
||||
},
|
||||
"governance": {
|
||||
"program_lead": {
|
||||
"name": "PROGRAM LEAD",
|
||||
"responsibilities": ["Vision", "Strategy", "Final Decisions"]
|
||||
},
|
||||
"mission_control": {
|
||||
"name": "MISSION CONTROL",
|
||||
"alias": "MCC",
|
||||
"responsibilities": ["Research", "Delegation", "Execution", "Orchestration"]
|
||||
}
|
||||
},
|
||||
"missions": {
|
||||
"APOLLO": {
|
||||
"label": "FLIGHT SYSTEMS",
|
||||
"sections": {
|
||||
"APOLLO-CORE": { "folder": "APOLLO/CORE_TECH", "agents": ["Anvil", "Cipher"] },
|
||||
"APOLLO-CODE": { "folder": "APOLLO/FLIGHT_CODE", "agents": ["Pixel", "Sentry"] },
|
||||
"APOLLO-VERIFY": { "folder": "APOLLO/VERIFICATION", "agents": ["Inspector"] }
|
||||
}
|
||||
},
|
||||
"HUBBLE": {
|
||||
"label": "MISSION STORY",
|
||||
"sections": {
|
||||
"HUBBLE-CONTENT": { "folder": "HUBBLE/CONTENT", "agents": ["Rex", "Sage", "Echo", "Clip"] },
|
||||
"HUBBLE-CREATIVE": { "folder": "HUBBLE/CREATIVE", "agents": ["Nebula", "Nova"] }
|
||||
}
|
||||
},
|
||||
"ARTEMIS": {
|
||||
"label": "MISSION OUTCOMES",
|
||||
"sections": {
|
||||
"ARTEMIS-EXP": { "folder": "ARTEMIS/EXPERIMENTS", "agents": ["Scout", "Herald"] },
|
||||
"ARTEMIS-TLM": { "folder": "ARTEMIS/TELEMETRY", "agents": ["Forge", "Pulse"] },
|
||||
"ARTEMIS-GROUND": { "folder": "ARTEMIS/GROUND_CREW", "agents": ["Beacon", "Link", "Vibe"] }
|
||||
}
|
||||
}
|
||||
},
|
||||
"packet": {
|
||||
"name_format": "YYYY-MM-DD__CALLSIGN__slug",
|
||||
"required_files": [
|
||||
"00_brief.md",
|
||||
"10_worklog.md",
|
||||
"30_results.md",
|
||||
"40_decision.md",
|
||||
"90_links.md"
|
||||
],
|
||||
"artifact_dir": "20_artifacts"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Struktura Katalogów
|
||||
|
||||
System wymaga następującej struktury katalogów, którą można utworzyć za pomocą poniższych poleceń. `ROOT_PATH` to główny katalog systemu (np. `~/.openclaw/workspace/missions`).
|
||||
|
||||
```text
|
||||
ROOT/
|
||||
_MCC/
|
||||
00_operating-manual.md
|
||||
10_backlog.md
|
||||
20_active-missions.md
|
||||
30_decisions.md
|
||||
40_routing-rules.md
|
||||
50_templates/
|
||||
task-brief.md
|
||||
sim-flight-checklist.md
|
||||
post-mission-report.md
|
||||
decision-record.md
|
||||
openclaw.missions.json
|
||||
90_archive-index.md
|
||||
|
||||
APOLLO/
|
||||
CORE_TECH/missions/
|
||||
FLIGHT_CODE/missions/
|
||||
VERIFICATION/missions/
|
||||
99_archive/
|
||||
|
||||
HUBBLE/
|
||||
CONTENT/missions/
|
||||
CREATIVE/missions/
|
||||
99_archive/
|
||||
|
||||
ARTEMIS/
|
||||
EXPERIMENTS/missions/
|
||||
TELEMETRY/missions/
|
||||
GROUND_CREW/missions/
|
||||
99_archive/
|
||||
```
|
||||
|
||||
## 3. Procedura Ustawieniowa (Bootstrap)
|
||||
|
||||
Poniższa procedura wykorzystuje klienta `openclaw` w środowisku Linux/WSL do automatycznego utworzenia całej struktury.
|
||||
|
||||
### Krok 1: Ustawienie zmiennej `ROOT_PATH`
|
||||
|
||||
Zdefiniuj ścieżkę do głównego katalogu systemu. Zalecane jest umieszczenie go w przestrzeni roboczej OpenClaw.
|
||||
```bash
|
||||
export ROOT_PATH="$HOME/.openclaw/workspace/missions"
|
||||
```
|
||||
|
||||
### Krok 2: Uruchomienie Gateway w osobnym profilu
|
||||
|
||||
Dla izolacji konfiguracji, użyj dedykowanego profilu `missionctl`.
|
||||
```bash
|
||||
openclaw --profile missionctl gateway start
|
||||
openclaw --profile missionctl gateway status
|
||||
```
|
||||
|
||||
### Krok 3: Weryfikacja dostępu (Sandbox)
|
||||
|
||||
Upewnij się, że agent OpenClaw ma uprawnienia do zapisu w `ROOT_PATH`.
|
||||
```bash
|
||||
openclaw --profile missionctl sandbox explain
|
||||
```
|
||||
|
||||
### Krok 4: Ustawienie profilu narzędzi (opcjonalnie)
|
||||
|
||||
Aby zapewnić dostęp do operacji na plikach, możesz ustawić profil `coding`.
|
||||
```bash
|
||||
openclaw --profile missionctl config set tools.profile '"coding"'
|
||||
```
|
||||
|
||||
### Krok 5: Główna komenda bootstrap
|
||||
|
||||
To pojedyncze polecenie instruuje agenta OpenClaw, aby utworzył całą strukturę katalogów, pliki konfiguracyjne i szablony.
|
||||
|
||||
```bash
|
||||
openclaw --profile missionctl agent --message "
|
||||
BOOTSTRAP Mission Management System.
|
||||
|
||||
ROOT_PATH=$ROOT_PATH
|
||||
|
||||
1) Create directories:
|
||||
- $ROOT_PATH/_MCC/50_templates
|
||||
- $ROOT_PATH/APOLLO/CORE_TECH/missions
|
||||
- $ROOT_PATH/APOLLO/FLIGHT_CODE/missions
|
||||
- $ROOT_PATH/APOLLO/VERIFICATION/missions
|
||||
- $ROOT_PATH/APOLLO/99_archive
|
||||
- $ROOT_PATH/HUBBLE/CONTENT/missions
|
||||
- $ROOT_PATH/HUBBLE/CREATIVE/missions
|
||||
- $ROOT_PATH/HUBBLE/99_archive
|
||||
- $ROOT_PATH/ARTEMIS/EXPERIMENTS/missions
|
||||
- $ROOT_PATH/ARTEMIS/TELEMETRY/missions
|
||||
- $ROOT_PATH/ARTEMIS/GROUND_CREW/missions
|
||||
- $ROOT_PATH/ARTEMIS/99_archive
|
||||
|
||||
2) Write MCC files (overwrite if exist):
|
||||
A) $ROOT_PATH/_MCC/00_operating-manual.md
|
||||
# Operating Manual — Mission System
|
||||
|
||||
## Governance
|
||||
- PROGRAM LEAD: vision, strategy, final decisions
|
||||
- MISSION CONTROL (MCC): triage, routing, execution, WIP, closure
|
||||
|
||||
## Missions
|
||||
- APOLLO: Flight Systems (Core Tech, Flight Code, Verification)
|
||||
- HUBBLE: Mission Story (Mission Content, Creative Studio)
|
||||
- ARTEMIS: Mission Outcomes (Experiments, Telemetry, Ground Crew)
|
||||
|
||||
## Packet standard
|
||||
Each packet contains:
|
||||
00_brief.md, 10_worklog.md, 20_artifacts/, 30_results.md, 40_decision.md, 90_links.md
|
||||
|
||||
## Modes
|
||||
SIM (default) vs FLIGHT (requires SIM→FLIGHT checklist)
|
||||
|
||||
## Closure
|
||||
PROCEED | ITERATE | HOLD | SCRUB
|
||||
|
||||
B) $ROOT_PATH/_MCC/40_routing-rules.md
|
||||
# Routing Rules (MCC)
|
||||
|
||||
## Call-signs → folders
|
||||
APOLLO-CORE → APOLLO/CORE_TECH
|
||||
APOLLO-CODE → APOLLO/FLIGHT_CODE
|
||||
APOLLO-VERIFY → APOLLO/VERIFICATION
|
||||
|
||||
HUBBLE-CONTENT → HUBBLE/CONTENT
|
||||
HUBBLE-CREATIVE → HUBBLE/CREATIVE
|
||||
|
||||
ARTEMIS-EXP → ARTEMIS/EXPERIMENTS
|
||||
ARTEMIS-TLM → ARTEMIS/TELEMETRY
|
||||
ARTEMIS-GROUND → ARTEMIS/GROUND_CREW
|
||||
|
||||
## Default mode
|
||||
SIM is default. FLIGHT requires checklist + approvals.
|
||||
|
||||
C) Empty indices:
|
||||
- $ROOT_PATH/_MCC/10_backlog.md with '# Backlog (MCC)'
|
||||
- $ROOT_PATH/_MCC/20_active-missions.md with '# Active Missions (MCC)'
|
||||
- $ROOT_PATH/_MCC/30_decisions.md with '# Decisions (MCC)'
|
||||
- $ROOT_PATH/_MCC/90_archive-index.md with '# Archive Index (MCC)'
|
||||
|
||||
3) Write templates:
|
||||
- $ROOT_PATH/_MCC/50_templates/task-brief.md
|
||||
- $ROOT_PATH/_MCC/50_templates/sim-flight-checklist.md
|
||||
- $ROOT_PATH/_MCC/50_templates/post-mission-report.md
|
||||
- $ROOT_PATH/_MCC/50_templates/decision-record.md
|
||||
|
||||
Contents:
|
||||
|
||||
(task-brief.md)
|
||||
# [CALLSIGN] Task Brief — <title>
|
||||
Routing: [CALLSIGN]
|
||||
Agent: <AgentName>
|
||||
Mode: SIM | FLIGHT
|
||||
Priority: P0 | P1 | P2
|
||||
## Context
|
||||
## Goal
|
||||
## Deliverables
|
||||
## Constraints
|
||||
## Acceptance Criteria
|
||||
## Risks
|
||||
|
||||
(sim-flight-checklist.md)
|
||||
# SIM → FLIGHT Checklist
|
||||
- Acceptance criteria met
|
||||
- Artifacts linked in 90_links.md
|
||||
- Risks reviewed
|
||||
- Verification done (if needed)
|
||||
- Telemetry plan ready (if needed)
|
||||
- MCC GO
|
||||
- PROGRAM LEAD GO (P0/P1)
|
||||
|
||||
(post-mission-report.md)
|
||||
# Post-Mission Report — <title>
|
||||
Packet:
|
||||
Decision:
|
||||
Summary:
|
||||
Artifacts:
|
||||
Measurements:
|
||||
Learnings:
|
||||
Next Steps:
|
||||
|
||||
(decision-record.md)
|
||||
# Decision Record — <title>
|
||||
Decision: PROCEED | ITERATE | HOLD | SCRUB
|
||||
Date:
|
||||
Owner:
|
||||
Rationale:
|
||||
Trade-offs:
|
||||
Follow-up:
|
||||
|
||||
4) Write mapping config:
|
||||
$ROOT_PATH/_MCC/openclaw.missions.json
|
||||
Use this exact JSON, but with root_path = ROOT_PATH:
|
||||
|
||||
{
|
||||
"root_path": "$ROOT_PATH",
|
||||
"wip_limit": 5,
|
||||
"modes": { "default": "SIM", "flight_requires_checklist": true, "flight_requires_program_lead_for_priority": ["P0","P1"] },
|
||||
"missions": {
|
||||
"APOLLO": {
|
||||
"label": "FLIGHT SYSTEMS",
|
||||
"sections": {
|
||||
"APOLLO-CORE": { "folder": "APOLLO/CORE_TECH", "agents": ["Anvil","Cipher"] },
|
||||
"APOLLO-CODE": { "folder": "APOLLO/FLIGHT_CODE", "agents": ["Pixel","Sentry"] },
|
||||
"APOLLO-VERIFY": { "folder": "APOLLO/VERIFICATION", "agents": ["Inspector"] }
|
||||
}
|
||||
},
|
||||
"HUBBLE": {
|
||||
"label": "MISSION STORY",
|
||||
"sections": {
|
||||
"HUBBLE-CONTENT": { "folder": "HUBBLE/CONTENT", "agents": ["Rex","Sage","Echo","Clip"] },
|
||||
"HUBBLE-CREATIVE": { "folder": "HUBBLE/CREATIVE", "agents": ["Nebula","Nova"] }
|
||||
}
|
||||
},
|
||||
"ARTEMIS": {
|
||||
"label": "MISSION OUTCOMES",
|
||||
"sections": {
|
||||
"ARTEMIS-EXP": { "folder": "ARTEMIS/EXPERIMENTS", "agents": ["Scout","Herald"] },
|
||||
"ARTEMIS-TLM": { "folder": "ARTEMIS/TELEMETRY", "agents": ["Forge","Pulse"] },
|
||||
"ARTEMIS-GROUND": { "folder": "ARTEMIS/GROUND_CREW", "agents": ["Beacon","Link","Vibe"] }
|
||||
}
|
||||
}
|
||||
},
|
||||
"packet": {
|
||||
"name_format": "YYYY-MM-DD__CALLSIGN__slug",
|
||||
"required_files": ["00_brief.md","10_worklog.md","30_results.md","40_decision.md","90_links.md"],
|
||||
"artifact_dir": "20_artifacts"
|
||||
}
|
||||
}
|
||||
|
||||
5) After completion, print a short summary of what you created and where.
|
||||
"
|
||||
```
|
||||
|
||||
## 4. Weryfikacja i Diagnostyka
|
||||
|
||||
Po wykonaniu skryptu bootstrap, możesz zweryfikować poprawność instalacji.
|
||||
|
||||
### Podgląd logów
|
||||
```bash
|
||||
openclaw --profile missionctl logs --follow
|
||||
```
|
||||
|
||||
### Pełny status systemu
|
||||
```bash
|
||||
openclaw --profile missionctl status --deep
|
||||
```
|
||||
|
||||
## 5. (Bonus) Utworzenie Pierwszego Pakietu Misji
|
||||
|
||||
Aby przetestować działanie systemu, możesz utworzyć pierwszy pakiet misji.
|
||||
```bash
|
||||
openclaw --profile missionctl agent --message "
|
||||
Utwórz Mission Packet w $ROOT_PATH dla:
|
||||
CALLSIGN: ARTEMIS-TLM
|
||||
Owner: Pulse
|
||||
Mode: SIM
|
||||
Slug: system-check
|
||||
|
||||
Folder: YYYY-MM-DD__ARTEMIS-TLM__system-check w ARTEMIS/TELEMETry/missions/
|
||||
W środku: 00_brief.md, 10_worklog.md, 20_artifacts/, 30_results.md, 40_decision.md, 90_links.md
|
||||
Dopisz wpis do $ROOT_PATH/_MCC/20_active-missions.md ze statusem IN_PROGRESS.
|
||||
"
|
||||
```
|
||||
@@ -0,0 +1,28 @@
|
||||
# Rozszerzony Model Dojrzałości AI: Od chaosu do autonomii
|
||||
|
||||
Wdrażanie sztucznej inteligencji w firmie to nie jest jednorazowy skok, ale wspinaczka po stromej drabinie. Tradycyjne modele dojrzałości AI często skupiają się wyłącznie na możliwościach samych narzędzi, pomijając brutalną rzeczywistość operacyjną – to, co naprawdę decyduje o sukcesie lub porażce projektu na produkcji.
|
||||
|
||||
Poniższe zestawienie to rozbudowana wersja standardowego modelu wdrażania AI. Została ona uzupełniona o "brakujące ogniwa" (etapy pośrednie, takie jak 3.5 czy 5.5), absolutny fundament organizacyjny (Poziom 0) oraz docelowy etap ciągłego doskonalenia (Poziom 8).
|
||||
|
||||
To praktyczna mapa drogowa, która pokazuje, jak przejść od luźnych eksperymentów z promptami, przez solidną architekturę RAG i LLMOps, aż po samouczące się systemy wielu agentów. Żadnej "magii AI" – wyłącznie inżynieria, procesy i mierzalna wartość biznesowa.
|
||||
|
||||
# Poziom 0 — Fundament mentalny i operacyjny [[poziom-0-fundamenty]]
|
||||
# Poziom 3.5 — Własna baza wiedzy i RAG w praktyce [[poziom-3.5-kb]]
|
||||
# Poziom 4.5 — Pamięć, role i orkiestracja wielu asystentów [[poziom-4.5-orchestrator]]
|
||||
# Poziom 5.5 — LLMOps dla aplikacji: ewale, staging, rollback [[poziom-5.5-llm]]
|
||||
# Poziom 8 — Samouczące się pętle wzrostu [[poziom-8-selflearn]]
|
||||
|
||||
|
||||
|
||||
Do tych „połówek” i „zera/ósemki” dołóż jeszcze trzy poziome osie, które przecinają wszystkie etapy i sprawiają, że drabina zamienia się w stabilną konstrukcję.
|
||||
|
||||
**Oś danych:** porządek w źródłach, jawne pochodzenie informacji, tagi ważności, kontrola wersji. Dane bez właściciela i daty przydatności są jak mleko bez etykiety — raz się uda, a raz popsuje kampanię.
|
||||
|
||||
**Oś jakości i bezpieczeństwa:** definicje jakości per przypadek użycia, ewale przed i po wdrożeniu, dzienniki decyzji agenta, uprawnienia oparte na rolach, czerwone przyciski „stop” i jasne scenariusze degradacji usług. To pozwala skalować bez obaw o wpadki.
|
||||
|
||||
**Oś ekonomii i wpływu:** koszt za rezultat, czas do efektu, jakość vs. ręczna produkcja, wpływ na przychód/konwersję. Zapisujesz to wprost, żeby uniknąć „magii AI”, która ładnie wygląda na slajdach, a nie dowozi liczb.
|
||||
|
||||
|
||||
Wyobraź sobie mini-ścieżkę na 7 dni. Najpierw dorzucasz Poziom 0 w formie krótkiego „AI README” i prostego repo promptów. Następnie w dwa dni budujesz RAG na najważniejszych dokumentach — nie wszystko na raz, tylko to, co realnie wspiera sprzedaż i delivery. Potem uczysz asystentów pamięci i rozdzielasz im role, żeby przestali wchodzić sobie w drogę. Do MVP dorzucasz ewale i staging, dzięki czemu każdy większy pomysł przechodzi przez bramkę jakości zanim trafi do klientów. I kiedy już całość spina się w automatyzacji, otwierasz pętlę eksperymentów: trzy warianty, telemetryka, notatka, aktualizacja repo. Mało efektowna od strony PR, ale po miesiącu w liczbach wygląda jak „magia”.
|
||||
|
||||
Na koniec jedna rzecz, która ratuje projekty przed „złotym młotkiem AI”. Zapisuj decyzje i antywzorce. „Ten agent ma wysoki recall, ale niski precision, więc używamy go tylko do wstępnych propozycji, nigdy do publikacji.” „Ten korpus wiedzy ma dużo przestarzałych cenników, więc każdy draft ofertowy musi przejść przez checker dat.” Taka „księga ostrzeżeń” robi więcej dla jakości niż jakikolwiek nowy model.
|
||||
@@ -0,0 +1,4 @@
|
||||
|
||||
# Poziom 0 — Fundament mentalny i operacyjny
|
||||
|
||||
Zanim zacznie się właściwa wspinaczka, warto mieć na starcie dwie rzeczy: kodeks pracy z AI i szkielet operacyjny. Chodzi o spisany „AI README” dla zespołu (co automatyzujemy, czego nie, jak oceniamy ryzyko, jak oznaczamy treści generowane) oraz minimalny warsztat PromptOps: wersjonowanie promptów, naming konwencji, repozytorium przykładów wejść/wyjść i prostą tabelę kosztów. To jest jak rozgrzewka przed treningiem — niby nie poziom, ale bez tego kolejne etapy będą się kruszyć.
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
# Poziom 3.5 — Własna baza wiedzy i RAG w praktyce
|
||||
|
||||
Między „prompt + dane” a „asystenci” brakuje jednego kroku: stałego, przeszukiwalnego źródła prawdy. Tu wchodzi Retrieval-Augmented Generation. Nie chodzi tylko o podpięcie PDF-ów, ale o świadome budowanie korpusu: polityki firmy, cenniki, style guide, FAQ sprzedażowe, case studies, baza obiekcji i odpowiedzi. Dochodzi też higiena: deduplikacja, wersjonowanie, daty ważności, podstawowe embeddingi i monitoring „odklejeń” (czyli kiedy model odpowiada spoza wiedzy). Efekt jest bardzo praktyczny: Twoi asystenci przestają fantazjować i zaczynają cytować konkrety.
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
# Poziom 4.5 — Pamięć, role i orkiestracja wielu asystentów
|
||||
|
||||
Gdy masz już asystentów, kolejny krok to sprawić, by pamiętali i grali zespołowo. Wprowadzasz trwałą pamięć kontekstową (cele, preferencje, definicje „dobrej odpowiedzi”), ustalone role z kontraktami (np. „Researcher podaje źródła + krótkie ryzyka, Copywriter nie publikuje bez check-listy dostępności”), oraz prosty system ról strażniczych: „Red Team” zadający trudne pytania i „Fact-Checker” wpinany przed publikacją. Nie zwiększasz mocy pojedynczego agenta, tylko ograniczasz błędy całego układu.
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
|
||||
# Poziom 5.5 — LLMOps dla aplikacji: ewale, staging, rollback
|
||||
|
||||
Skoro budujesz MVP-ki, dorzuć pas bezpieczeństwa: automatyczne ewaluacje jakości (zestawy testowych promptów i oczekiwanych kryteriów), środowiska dev/staging/prod dla promptów i konfiguracji, canary release oraz mechanizm powrotu do poprzedniej wersji. Do tego licznik kosztów i czasu na żądanie oraz alarmy, gdy coś nagle drożeje lub zwalnia. W praktyce to różnica między „fajne demo” a „narzędzie, na którym naprawdę można polegać”.
|
||||
@@ -0,0 +1,4 @@
|
||||
|
||||
# Poziom 8 — Samouczące się pętle wzrostu
|
||||
|
||||
Kiedy Poziom 7 już działa, systemy mogą zacząć same się optymalizować. Tu pojawia się zamknięta pętla: generowanie → eksperyment → pomiar → selekcja zwycięzców → aktualizacja wiedzy i promptów. Nie RL w laboratorium, tylko zdroworozsądkowe A/B/C: np. trzy warianty lead magnetu, telemetryka z CRM/GA4, automatyczna notatka „co wygrało i dlaczego” oraz półautomatyczny PR do repo promptów. Klucz to bezpieczne gardła: limity, reguły wycofania i ludzkie „TAK” przed większą zmianą.
|
||||
@@ -0,0 +1,40 @@
|
||||
# Najlepsze praktyki bezpieczeństwa baz danych wspierane przez Agenta DBA
|
||||
|
||||
Bezpieczeństwo baz danych to fundament stabilnej i godnej zaufania aplikacji. Wyciek danych, ich uszkodzenie lub nieautoryzowany dostęp mogą prowadzić do katastrofalnych skutków finansowych i wizerunkowych. Skonfigurowany w tym projekcie Agent DBA został zaprojektowany, aby aktywnie wspierać i egzekwować kluczowe zasady bezpieczeństwa.
|
||||
|
||||
Ten artykuł omawia najważniejsze praktyki i wyjaśnia, w jaki sposób agent pomaga w ich przestrzeganiu.
|
||||
|
||||
## 1. Zasada Najmniejszych Uprawnień (Principle of Least Privilege)
|
||||
|
||||
**Na czym polega?**
|
||||
Zasada ta mówi, że każdy użytkownik, aplikacja czy proces powinien mieć tylko te uprawnienia, które są absolutnie niezbędne do wykonania jego zadań – i nic ponadto. Zamiast przyznawać szerokie uprawnienia `DB_OWNER` lub `SUPERUSER`, należy precyzyjnie definiować dostęp do konkretnych tabel, widoków czy procedur.
|
||||
|
||||
**Jak pomaga agent?**
|
||||
Agent został skonfigurowany, aby zwracać szczególną uwagę na polecenia `GRANT`. Jeśli wykryje próbę nadania zbyt szerokich uprawnień (np. `GRANT ALL PRIVILEGES`), zakwestionuje taką operację i poprosi o bardziej szczegółowe, ograniczone uprawnienia, zgodnie z zasadą "Bezpieczeństwo Przede Wszystkim".
|
||||
|
||||
## 2. Bezpieczne Zarządzanie Poświadczeniami
|
||||
|
||||
**Na czym polega?**
|
||||
Przechowywanie haseł, kluczy API czy innych danych uwierzytelniających w postaci jawnego tekstu w skryptach, plikach konfiguracyjnych lub w kodzie źródłowym jest jedną z najpoważniejszych luk bezpieczeństwa. Poświadczenia powinny być zarządzane za pomocą dedykowanych narzędzi, takich jak systemy zarządzania sekretami (np. HashiCorp Vault, Azure Key Vault) lub zmienne środowiskowe.
|
||||
|
||||
**Jak pomaga agent?**
|
||||
Jedną z fundamentalnych reguł agenta jest unikanie zakodowanych na stałe poświadczeń. Jeśli w przesłanym do niego skrypcie lub poleceniu znajdzie fragment wyglądający jak hasło w otwartym tekście, odmówi wykonania operacji i zasugeruje użycie bezpieczniejszych metod.
|
||||
|
||||
## 3. Ochrona przed Atakami SQL Injection
|
||||
|
||||
**Na czym polega?**
|
||||
SQL Injection to atak, w którym złośliwy kod SQL jest "wstrzykiwany" do zapytania poprzez dane wejściowe od użytkownika. Może to prowadzić do nieautoryzowanego odczytu, modyfikacji lub usunięcia danych. Podstawową metodą obrony jest stosowanie zapytań parametryzowanych (prepared statements), które oddzielają logikę zapytania od danych.
|
||||
|
||||
**Jak pomaga agent?**
|
||||
Chociaż ochrona przed SQL Injection leży głównie po stronie kodu aplikacji, agent DBA również odgrywa tu rolę. Analizując zapytania ad-hoc lub skrypty, może zwracać uwagę na konstrukcje, które wyglądają na podatne na atak (np. konkatenacja stringów w celu zbudowania zapytania) i promować stosowanie bezpieczniejszych alternatyw, takich jak procedury składowane.
|
||||
|
||||
## 4. Potwierdzanie Operacji Destrukcyjnych
|
||||
|
||||
**Na czym polega?**
|
||||
Operacje takie jak `DROP TABLE`, `TRUNCATE TABLE` czy `DELETE` bez klauzuli `WHERE` niosą ze sobą ryzyko nieodwracalnej utraty danych. Przypadkowe wykonanie takiego polecenia w środowisku produkcyjnym może być katastrofalne.
|
||||
|
||||
**Jak pomaga agent?**
|
||||
Agent ma wbudowaną regułę wymagania jawnego potwierdzenia przed wykonaniem każdej operacji o charakterze destrukcyjnym. Nie wykona takiego polecenia automatycznie. Zamiast tego poprosi użytkownika o świadome zatwierdzenie, co stanowi ważną barierę ochronną przed przypadkowymi błędami.
|
||||
|
||||
## Podsumowanie
|
||||
Agent DBA to nie tylko narzędzie do wykonywania poleceń, ale także aktywny strażnik dobrych praktyk. Poprzez egzekwowanie zasad najmniejszych uprawnień, bezpiecznego zarządzania sekretami i wymaganie potwierdzeń dla ryzykownych operacji, pomaga budować kulturę bezpieczeństwa i minimalizować ryzyko incydentów związanych z bazą danych.
|
||||
@@ -0,0 +1,633 @@
|
||||
# Obowiązki Administratora Baz Danych (DBA)
|
||||
|
||||
## Zarządzanie Serwerami Baz Danych
|
||||
|
||||
### 1. Microsoft SQL Server
|
||||
|
||||
**A. Przed instalacją**
|
||||
|
||||
* Zbieranie wymagań: CPU, pamięć, dyski, komponenty, użytkownicy usług, strona kodowa, klaster, replikacja, mirroring.
|
||||
* Przygotowanie i formatowanie dysków na dane, logi, TempDB, system, archiwum i kopie zapasowe.
|
||||
* Konfiguracja i weryfikacja CPU i pamięci serwera.
|
||||
* Przygotowanie użytkowników usług w Active Directory (zazwyczaj przez zespół Windows).
|
||||
|
||||
**B. Instalacja**
|
||||
|
||||
* Instalacja SQL Server: Ustawienie ścieżek dysków na dane, strony kodowej, użytkowników usług, ustawień TempDB i pamięci.
|
||||
|
||||
**C. Po instalacji**
|
||||
|
||||
* Konfiguracja SQL Server: Zastosowanie najlepszych praktyk, ulepszonych ustawień i konfiguracji pamięci.
|
||||
* Ustawienie użytkowników z uprawnieniami sysadmin i użytkowników usług.
|
||||
* Konfiguracja poczty (SQL Mail), operatorów, alertów i SQL Agent.
|
||||
* Przygotowanie dysków na dane i logi z odpowiednimi uprawnieniami i strukturą katalogów.
|
||||
* Otwarcie niezbędnych portów w zaporze sieciowej (np. TCP 1433, UDP 1434).
|
||||
* Wykluczenie folderów związanych z SQL ze skanowania antywirusowego.
|
||||
|
||||
**D. Zadania migracyjne (przy przenoszeniu ze starego serwera)**
|
||||
|
||||
* Uruchomienie Microsoft Assessment Tool w celu sprawdzenia kompatybilności.
|
||||
* Analiza starego serwera pod kątem wymagań i ustawień.
|
||||
* Tworzenie i transfer kopii zapasowych, odtwarzanie na nowym serwerze.
|
||||
* Skryptowanie i odtwarzanie loginów, uprawnień, ustawień poczty, synonimów, operatorów, alertów, zadań SQL Agent, audytów, wyzwalaczy serwerowych i replikacji w razie potrzeby.
|
||||
* Porównanie i ustawienie konfiguracji serwera.
|
||||
* Analiza i migracja pakietów SSIS w razie potrzeby.
|
||||
* Testowanie migracji: Weryfikacja komponentów, baz danych, łączności i kopii zapasowych.
|
||||
* Migracja "Go-live": Przygotowanie starego i nowego serwera, zarządzanie zmianami IP, tworzenie snapshotów replikacji i włączanie wszystkich użytkowników i zadań po migracji.
|
||||
|
||||
**E. Bieżące zadania**
|
||||
|
||||
* Kopie zapasowe
|
||||
* Konserwacja
|
||||
* Monitorowanie
|
||||
* Archiwizacja
|
||||
* Zadania związane z danymi
|
||||
* Strojenie wydajności
|
||||
* Rozwiązywanie problemów
|
||||
* Replikacja
|
||||
* Zadania klastrowe
|
||||
* Zarządzanie uprawnieniami
|
||||
* Audyt
|
||||
|
||||
### 2. MySQL Server
|
||||
|
||||
**A. Przed instalacją**
|
||||
|
||||
* Zbieranie wymagań: CPU, pamięć, przestrzeń dyskowa, typ przechowywania, konfiguracja sieci, wersja MySQL i zestaw znaków/porównywanie.
|
||||
* Planowanie architektury bazy danych: samodzielna, replikacja (master-slave, master-master), klastrowanie (InnoDB Cluster, Galera) lub sharding.
|
||||
* Przygotowanie i formatowanie dysków na dane, logi i kopie zapasowe.
|
||||
* Planowanie kont użytkowników i uprawnień.
|
||||
|
||||
**B. Instalacja**
|
||||
|
||||
* Instalacja MySQL Server: Wybór odpowiedniej wersji i edycji.
|
||||
* Konfiguracja początkowych ustawień: katalog danych, port, zestaw znaków, porównywanie i rozmiary buforów.
|
||||
* Ustawienie użytkowników root i administracyjnych MySQL z bezpiecznymi hasłami.
|
||||
|
||||
**C. Po instalacji**
|
||||
|
||||
* Zastosowanie najlepszych praktyk bezpieczeństwa: usunięcie testowych baz danych, wyłączenie zdalnego dostępu dla roota, ustawienie reguł zapory sieciowej (np. TCP 3306).
|
||||
* Konfiguracja procedur tworzenia kopii zapasowych (mysqldump, Percona XtraBackup itp.).
|
||||
* Ustawienie monitorowania i alertów (np. Zabbix, Nagios, MySQL Enterprise Monitor).
|
||||
* Strojenie parametrów wydajności: bufor puli InnoDB, pamięć podręczna zapytań, limity połączeń, log wolnych zapytań.
|
||||
* Ustawienie replikacji w razie potrzeby: konfiguracja mastera i slave'a, ustawienie logowania binarnego.
|
||||
* Tworzenie i zarządzanie kontami użytkowników i uprawnieniami.
|
||||
* Wykluczenie katalogów danych MySQL ze skanowania antywirusowego.
|
||||
|
||||
**D. Zadania migracyjne**
|
||||
|
||||
* Ocena kompatybilności i wymagań do migracji.
|
||||
* Eksport i import baz danych (mysqldump, mysqlpump lub kopia logiczna/fizyczna).
|
||||
* Migracja kont użytkowników i uprawnień.
|
||||
* Odtwarzanie procedur składowanych, wyzwalaczy, zdarzeń i zaplanowanych zadań.
|
||||
* Testowanie migracji: weryfikacja integralności danych, łączności aplikacji i wydajności.
|
||||
* Przełączenie na nowy serwer, aktualizacja parametrów połączenia aplikacji i monitorowanie po migracji.
|
||||
|
||||
**E. Bieżące zadania**
|
||||
|
||||
* Regularne tworzenie kopii zapasowych i testowanie odtwarzania.
|
||||
* Rutynowa konserwacja: optymalizacja tabel, aktualizacja statystyk, czyszczenie logów.
|
||||
* Monitorowanie stanu serwera, wydajności i statusu replikacji.
|
||||
* Strojenie wydajności i optymalizacja zapytań.
|
||||
* Rozwiązywanie problemów z błędami i wolnymi zapytaniami.
|
||||
* Zarządzanie uprawnieniami użytkowników i audyty bezpieczeństwa.
|
||||
* Aplikowanie poprawek i aktualizacji wersji.
|
||||
* Archiwizacja starych danych w razie potrzeby.
|
||||
|
||||
### 3. MongoDB Server
|
||||
|
||||
**A. Przed instalacją**
|
||||
|
||||
* Zbieranie wymagań: CPU, pamięć, przestrzeń dyskowa, typ przechowywania, konfiguracja sieci, wersja MongoDB i silnik przechowywania (np. WiredTiger).
|
||||
* Planowanie architektury wdrożenia: samodzielna, zestaw replik, klaster sharded.
|
||||
* Przygotowanie i formatowanie dysków na dane, logi i kopie zapasowe.
|
||||
* Planowanie kont użytkowników, ról i mechanizmów uwierzytelniania (SCRAM, x.509, LDAP).
|
||||
|
||||
**B. Instalacja**
|
||||
|
||||
* Instalacja MongoDB Server: Wybór odpowiedniej wersji i edycji (Community lub Enterprise).
|
||||
* Konfiguracja początkowych ustawień: katalog danych, katalog logów, port, adres IP do bindowania i silnik przechowywania.
|
||||
* Ustawienie użytkowników administracyjnych z bezpiecznymi hasłami.
|
||||
|
||||
**C. Po instalacji**
|
||||
|
||||
* Zastosowanie najlepszych praktyk bezpieczeństwa: włączenie uwierzytelniania, konfiguracja kontroli dostępu opartej na rolach (RBAC), włączenie TLS/SSL do szyfrowania w tranzycie i konfiguracja zapór sieciowych (np. TCP 27017).
|
||||
* Konfiguracja procedur tworzenia kopii zapasowych (mongodump/mongorestore, Ops Manager lub narzędzia firm trzecich).
|
||||
* Ustawienie monitorowania i alertów (MongoDB Ops Manager, Cloud Manager lub narzędzia zewnętrzne, takie jak Zabbix, Prometheus).
|
||||
* Strojenie parametrów wydajności: rozmiar pamięci podręcznej, journaling, limity połączeń i opcje silnika przechowywania.
|
||||
* Ustawienie zestawów replik lub shardingu w razie potrzeby: inicjalizacja zestawu replik, dodawanie członków, konfiguracja arbiterów i ustawienie kluczy shardingu.
|
||||
* Wykluczenie katalogów danych MongoDB ze skanowania antywirusowego.
|
||||
|
||||
**D. Zadania migracyjne**
|
||||
|
||||
* Ocena kompatybilności i wymagań do migracji.
|
||||
* Eksport i import baz danych (mongodump/mongorestore, mongoexport/mongoimport lub kopia logiczna/fizyczna).
|
||||
* Migracja kont użytkowników, ról i ustawień uwierzytelniania.
|
||||
* Odtwarzanie indeksów, reguł walidacji i niestandardowych skryptów.
|
||||
* Testowanie migracji: weryfikacja integralności danych, łączności aplikacji i wydajności.
|
||||
* Przełączenie na nowy serwer, aktualizacja parametrów połączenia aplikacji i monitorowanie po migracji.
|
||||
|
||||
**E. Bieżące zadania**
|
||||
|
||||
* Regularne tworzenie kopii zapasowych i testowanie odtwarzania.
|
||||
* Rutynowa konserwacja: kompaktowanie kolekcji, naprawa baz danych, rotacja logów.
|
||||
* Monitorowanie stanu serwera, wydajności i statusu zestawu replik/shardingu.
|
||||
* Strojenie wydajności i optymalizacja zapytań (analiza wolnych zapytań, tworzenie indeksów).
|
||||
* Rozwiązywanie problemów z błędami, opóźnieniami replikacji i zdarzeniami przełączania awaryjnego.
|
||||
* Zarządzanie uprawnieniami użytkowników i przeprowadzanie audytów bezpieczeństwa.
|
||||
* Aplikowanie poprawek i aktualizacji wersji.
|
||||
* Archiwizacja lub usuwanie starych danych w razie potrzeby.
|
||||
|
||||
### 4. PostgreSQL Server
|
||||
|
||||
**A. Przed instalacją**
|
||||
|
||||
* Zbieranie wymagań: CPU, pamięć, przestrzeń dyskowa, typ przechowywania, konfiguracja sieci, wersja PostgreSQL i ustawienia regionalne/kodowanie.
|
||||
* Planowanie architektury bazy danych: samodzielna, replikacja strumieniowa (primary/standby), replikacja logiczna lub klastrowanie (np. Patroni, Citus).
|
||||
* Przygotowanie i formatowanie dysków na dane, logi i kopie zapasowe.
|
||||
* Planowanie kont użytkowników, ról i metod uwierzytelniania (md5, scram-sha-256, LDAP, Kerberos).
|
||||
|
||||
**B. Instalacja**
|
||||
|
||||
* Instalacja PostgreSQL Server: Wybór odpowiedniej wersji i edycji (Community, EnterpriseDB itp.).
|
||||
* Konfiguracja początkowych ustawień: katalog danych, port, ustawienia regionalne, kodowanie i parametry pamięci (shared_buffers, work_mem).
|
||||
* Ustawienie ról superużytkownika i administracyjnych z bezpiecznymi hasłami.
|
||||
|
||||
**C. Po instalacji**
|
||||
|
||||
* Zastosowanie najlepszych praktyk bezpieczeństwa: konfiguracja `pg_hba.conf` i `postgresql.conf` do uwierzytelniania i kontroli dostępu, włączenie SSL/TLS i ustawienie zapór sieciowych (np. TCP 5432).
|
||||
* Konfiguracja procedur tworzenia kopii zapasowych (pg_dump, pg_basebackup, Barman lub narzędzia firm trzecich).
|
||||
* Ustawienie monitorowania i alertów (np. pgAdmin, Zabbix, Prometheus, Nagios).
|
||||
* Strojenie parametrów wydajności: shared_buffers, work_mem, maintenance_work_mem, autovacuum, ustawienia checkpointów.
|
||||
* Ustawienie replikacji w razie potrzeby: konfiguracja serwerów primary i standby, ustawienie slotów replikacji i zarządzanie archiwizacją WAL.
|
||||
* Tworzenie i zarządzanie rolami i uprawnieniami użytkowników.
|
||||
* Wykluczenie katalogów danych PostgreSQL ze skanowania antywirusowego.
|
||||
|
||||
**D. Zadania migracyjne**
|
||||
|
||||
* Ocena kompatybilności i wymagań do migracji.
|
||||
* Eksport i import baz danych (pg_dump/pg_restore, replikacja logiczna lub kopia fizyczna/przywracanie).
|
||||
* Migracja ról użytkowników, uprawnień i ustawień uwierzytelniania.
|
||||
* Odtwarzanie funkcji, wyzwalaczy, rozszerzeń i zaplanowanych zadań (pgAgent, cron).
|
||||
* Testowanie migracji: weryfikacja integralności danych, łączności aplikacji i wydajności.
|
||||
* Przełączenie na nowy serwer, aktualizacja parametrów połączenia aplikacji i monitorowanie po migracji.
|
||||
|
||||
**E. Bieżące zadania**
|
||||
|
||||
* Regularne tworzenie kopii zapasowych i testowanie odtwarzania.
|
||||
* Rutynowa konserwacja: vacuum, analyze, reindex, aktualizacja statystyk, czyszczenie logów.
|
||||
* Monitorowanie stanu serwera, wydajności i statusu replikacji.
|
||||
* Strojenie wydajności i optymalizacja zapytań (analiza wolnych zapytań, tworzenie indeksów, partycjonowanie tabel).
|
||||
* Rozwiązywanie problemów z błędami, opóźnieniami replikacji i zdarzeniami przełączania awaryjnego.
|
||||
* Zarządzanie rolami użytkowników i przeprowadzanie audytów bezpieczeństwa.
|
||||
* Aplikowanie poprawek i aktualizacji wersji.
|
||||
* Archiwizacja lub usuwanie starych danych w razie potrzeby.
|
||||
|
||||
### 5. OracleDB Server
|
||||
|
||||
**A. Przed instalacją**
|
||||
|
||||
* Zbieranie wymagań: CPU, pamięć, przestrzeń dyskowa, typ przechowywania, konfiguracja sieci, wersja Oracle Database i zestaw znaków/narodowy zestaw znaków.
|
||||
* Planowanie architektury bazy danych: samodzielna, Real Application Clusters (RAC), Data Guard lub sharding.
|
||||
* Przygotowanie i formatowanie dysków na dane, logi, archiwum i kopie zapasowe.
|
||||
* Planowanie użytkowników Oracle, grup i wymaganych uprawnień na poziomie systemu operacyjnego.
|
||||
* Przygotowanie kont usług i konfiguracja katalogów Oracle Inventory i Oracle Home.
|
||||
|
||||
**B. Instalacja**
|
||||
|
||||
* Instalacja oprogramowania Oracle Database: Wybór odpowiedniej wersji i edycji (Standard, Enterprise, Express).
|
||||
* Konfiguracja początkowych ustawień: Oracle Base, Oracle Home, katalog danych, port nasłuchu i zestaw znaków.
|
||||
* Tworzenie i konfiguracja początkowej instancji bazy danych (za pomocą DBCA lub ręcznie).
|
||||
* Ustawienie użytkowników administracyjnych (SYS, SYSTEM) z bezpiecznymi hasłami.
|
||||
|
||||
**C. Po instalacji**
|
||||
|
||||
* Zastosowanie najlepszych praktyk bezpieczeństwa: konfiguracja `listener.ora` i `sqlnet.ora`, włączenie audytu, ustawienie polityk haseł i konfiguracja zapór sieciowych (np. TCP 1521).
|
||||
* Konfiguracja procedur tworzenia kopii zapasowych (RMAN, Data Pump lub narzędzia firm trzecich).
|
||||
* Ustawienie monitorowania i alertów (Oracle Enterprise Manager, Zabbix, Nagios lub niestandardowe skrypty).
|
||||
* Strojenie parametrów wydajności: SGA, PGA, rozmiar redo log, tablespace undo i ustawienia optymalizatora.
|
||||
* Ustawienie Data Guard lub RAC w razie potrzeby: konfiguracja baz danych standby, transport redo i mechanizmy przełączania awaryjnego.
|
||||
* Tworzenie i zarządzanie kontami użytkowników, rolami i uprawnieniami.
|
||||
* Wykluczenie katalogów danych Oracle ze skanowania antywirusowego.
|
||||
|
||||
**D. Zadania migracyjne**
|
||||
|
||||
* Ocena kompatybilności i wymagań do migracji.
|
||||
* Eksport i import baz danych (Data Pump expdp/impdp, RMAN lub kopia logiczna/fizyczna).
|
||||
* Migracja kont użytkowników, ról i uprawnień.
|
||||
* Odtwarzanie procedur składowanych, wyzwalaczy, zadań (DBMS_SCHEDULER) i niestandardowych skryptów.
|
||||
* Testowanie migracji: weryfikacja integralności danych, łączności aplikacji i wydajności.
|
||||
* Przełączenie na nowy serwer, aktualizacja parametrów połączenia aplikacji i monitorowanie po migracji.
|
||||
|
||||
**E. Bieżące zadania**
|
||||
|
||||
* Regularne tworzenie kopii zapasowych i testowanie odtwarzania.
|
||||
* Rutynowa konserwacja: zbieranie statystyk, przebudowa indeksów, czyszczenie logów i zarządzanie tablespace'ami.
|
||||
* Monitorowanie stanu serwera, wydajności i statusu Data Guard/RAC.
|
||||
* Strojenie wydajności i optymalizacja zapytań (raporty AWR/ASH, strojenie SQL).
|
||||
* Rozwiązywanie problemów z błędami, opóźnieniami replikacji i zdarzeniami przełączania awaryjnego.
|
||||
* Zarządzanie uprawnieniami użytkowników i przeprowadzanie audytów bezpieczeństwa.
|
||||
* Aplikowanie poprawek i aktualizacji wersji (za pomocą OPatch lub DBUA).
|
||||
* Archiwizacja lub usuwanie starych danych w razie potrzeby.
|
||||
|
||||
---
|
||||
|
||||
## Komponenty i Usługi Dodatkowe
|
||||
|
||||
### 6. Administracja SSIS (SQL Server Integration Services)
|
||||
|
||||
**A. Instalacja**
|
||||
|
||||
* Weryfikacja wymagań systemowych i wstępnych warunków do instalacji SSIS.
|
||||
* Instalacja SSIS jako funkcji podczas instalacji SQL Server lub dodanie jej do istniejącej instancji.
|
||||
* Zastosowanie najnowszych service packów i aktualizacji zbiorczych dla SSIS.
|
||||
* Rejestracja i konfiguracja usługi SSIS na serwerze.
|
||||
* Ustawienie odpowiednich kont usług do wykonywania SSIS.
|
||||
|
||||
**B. Konfiguracja**
|
||||
|
||||
* Konfiguracja właściwości usługi SSIS (np. logowanie, bezpieczeństwo, lokalizacja przechowywania pakietów).
|
||||
* Ustawienie SSISDB (Integration Services Catalog) dla modelu wdrożenia projektu.
|
||||
* Konfiguracja bezpieczeństwa: przypisywanie uprawnień do SSISDB, folderów, projektów i środowisk.
|
||||
* Ustawienie zmiennych środowiskowych i parametrów do wykonywania pakietów.
|
||||
* Konfiguracja logowania i audytu wykonywania pakietów SSIS.
|
||||
* Ustawienie zadań SQL Server Agent lub innych harmonogramów do automatyzacji wykonywania pakietów SSIS.
|
||||
* Konfiguracja wysokiej dostępności i odzyskiwania po awarii dla SSISDB w razie potrzeby.
|
||||
|
||||
**C. Konserwacja**
|
||||
|
||||
* Monitorowanie wykonań pakietów SSIS i przeglądanie logów pod kątem błędów lub problemów z wydajnością.
|
||||
* Rozwiązywanie problemów z nieudanymi wykonaniami pakietów i rozwiązywanie problemów z przepływem danych lub łącznością.
|
||||
* Aplikowanie poprawek i aktualizacji do komponentów SSIS w razie potrzeby.
|
||||
* Zarządzanie SSISDB: czyszczenie starych logów wykonań, usuwanie nieużywanych projektów/pakietów i monitorowanie wzrostu bazy danych.
|
||||
* Tworzenie kopii zapasowych i odtwarzanie SSISDB w ramach regularnej konserwacji bazy danych.
|
||||
* Przeglądanie i aktualizacja uprawnień bezpieczeństwa dla użytkowników i operatorów SSIS.
|
||||
* Optymalizacja pakietów SSIS pod kątem wydajności i wykorzystania zasobów.
|
||||
* Dokumentowanie konfiguracji SSIS, harmonogramów i procedur operacyjnych.
|
||||
|
||||
### 7. Administracja SSRS (SQL Server Reporting Services)
|
||||
|
||||
**A. Instalacja**
|
||||
|
||||
* Weryfikacja wymagań systemowych i wstępnych warunków do instalacji SSRS.
|
||||
* Instalacja SSRS jako funkcji podczas instalacji SQL Server lub jako samodzielnej usługi.
|
||||
* Zastosowanie najnowszych service packów i aktualizacji zbiorczych dla SSRS.
|
||||
* Rejestracja i konfiguracja usługi SSRS na serwerze.
|
||||
* Ustawienie odpowiednich kont usług do wykonywania SSRS.
|
||||
|
||||
**B. Konfiguracja**
|
||||
|
||||
* Konfiguracja właściwości usługi SSRS (np. konto usługi, URL usługi sieciowej, URL portalu internetowego).
|
||||
* Ustawienie i konfiguracja bazy danych serwera raportów (ReportServer i ReportServerTempDB).
|
||||
* Konfiguracja bezpieczeństwa: przypisywanie uprawnień do folderów, raportów i źródeł danych.
|
||||
* Ustawienie ustawień poczty e-mail dla subskrypcji raportów i alertów.
|
||||
* Konfiguracja źródeł danych i współdzielonych zestawów danych dla raportów.
|
||||
* Ustawienie harmonogramów wykonywania raportów i subskrypcji.
|
||||
* Włączanie i konfiguracja kluczy szyfrowania dla danych wrażliwych.
|
||||
* Konfiguracja wysokiej dostępności i odzyskiwania po awarii dla SSRS w razie potrzeby (np. wdrożenie scale-out).
|
||||
|
||||
**C. Konserwacja**
|
||||
|
||||
* Monitorowanie stanu usługi SSRS, wykonywania raportów i wydajności.
|
||||
* Rozwiązywanie problemów z nieudanymi wykonaniami raportów i rozwiązywanie problemów z łącznością danych lub renderowaniem.
|
||||
* Aplikowanie poprawek i aktualizacji do komponentów SSRS w razie potrzeby.
|
||||
* Zarządzanie bazami danych ReportServer: czyszczenie starych raportów, logów wykonań i monitorowanie wzrostu bazy danych.
|
||||
* Tworzenie kopii zapasowych i odtwarzanie kluczy szyfrowania SSRS oraz baz danych ReportServer w ramach regularnej konserwacji.
|
||||
* Przeglądanie i aktualizacja uprawnień bezpieczeństwa dla użytkowników i operatorów SSRS.
|
||||
* Optymalizacja wydajności raportów i wykorzystania zasobów.
|
||||
* Dokumentowanie konfiguracji SSRS, harmonogramów i procedur operacyjnych.
|
||||
|
||||
---
|
||||
|
||||
## Zarządzanie Systemami Operacyjnymi
|
||||
|
||||
### 8. Administracja Systemem Windows
|
||||
|
||||
**A. Instalacja i Wstępna Konfiguracja**
|
||||
|
||||
* Weryfikacja wymagań sprzętowych i oprogramowania do instalacji Windows Server.
|
||||
* Instalacja odpowiedniej wersji i edycji Windows Server.
|
||||
* Zastosowanie najnowszych service packów, poprawek bezpieczeństwa i aktualizacji.
|
||||
* Konfiguracja ról i funkcji serwera w razie potrzeby (np. Active Directory, DNS, DHCP).
|
||||
* Ustawienie lokalnych i domenowych kont użytkowników z odpowiednimi uprawnieniami.
|
||||
* Konfiguracja nazwy hosta serwera, adresu IP i ustawień sieciowych.
|
||||
* Ustawienie synchronizacji czasu (NTP).
|
||||
|
||||
**B. Konfiguracja**
|
||||
|
||||
* Konfiguracja reguł Zapory systemu Windows dla łączności baz danych i aplikacji.
|
||||
* Ustawienie polityk bezpieczeństwa: polityki haseł, blokady konta i audytu.
|
||||
* Konfiguracja przechowywania: tworzenie i formatowanie woluminów, ustawienie RAID w razie potrzeby, przypisywanie liter dysków.
|
||||
* Ustawienie zaplanowanych zadań do konserwacji (np. kopie zapasowe, czyszczenie dysku).
|
||||
* Konfiguracja wykluczeń antywirusowych dla katalogów baz danych i logów.
|
||||
* Ustawienie pulpitu zdalnego i narzędzi do zarządzania (np. RDP, PowerShell Remoting).
|
||||
* Konfiguracja logowania zdarzeń i monitorowania.
|
||||
|
||||
**C. Konserwacja**
|
||||
|
||||
* Monitorowanie stanu systemu: użycie CPU, pamięci, dysku i sieci.
|
||||
* Aplikowanie regularnych aktualizacji Windows i poprawek bezpieczeństwa.
|
||||
* Przeglądanie i zarządzanie logami zdarzeń pod kątem błędów i ostrzeżeń.
|
||||
* Wykonywanie regularnych kopii zapasowych i testowanie procedur odtwarzania.
|
||||
* Zarządzanie kontami użytkowników, uprawnieniami i członkostwem w grupach.
|
||||
* Rozwiązywanie problemów sprzętowych i programowych.
|
||||
* Czyszczenie plików tymczasowych i zarządzanie przestrzenią dyskową.
|
||||
* Dokumentowanie konfiguracji serwera, zaplanowanych zadań i procedur operacyjnych.
|
||||
|
||||
**D. Zarządzanie Użytkownikami i Uprawnieniami**
|
||||
|
||||
* Tworzenie i zarządzanie kontami Active Directory dla kont usług baz danych.
|
||||
* Konfiguracja grup Windows dla dostępu opartego na rolach w SQL Server.
|
||||
* Ustawienie delegacji Kerberos dla SQL Server w środowiskach wielowarstwowych.
|
||||
|
||||
**E. Zarządzanie Usługami i Procesami**
|
||||
|
||||
* Instalacja i konfiguracja usług SQL Server (Database Engine, Agent, SSIS, SSRS).
|
||||
* Zarządzanie usługami Windows związanymi z SQL Server (start/stop, ustawienie typu uruchomienia).
|
||||
* Monitorowanie stanu usług i ponowne uruchamianie usług podczas konserwacji.
|
||||
|
||||
**F. Zarządzanie Pamięcią Masową i Dyskami**
|
||||
|
||||
* Konfiguracja uprawnień NTFS dla katalogów danych i logów baz danych.
|
||||
* Zarządzanie partycjami dysków i woluminami w celu optymalnej wydajności bazy danych.
|
||||
* Ustawienie punktów montowania dla dużych magazynów baz danych.
|
||||
|
||||
**G. Integracja Kopii Zapasowych i Odzyskiwania**
|
||||
|
||||
* Konfiguracja Harmonogramu zadań Windows dla skryptów kopii zapasowych (jeśli nie używa się SQL Agent).
|
||||
* Zarządzanie kopiami zapasowymi na poziomie systemu plików dla plików baz danych.
|
||||
* Zapewnienie kompatybilności Volume Shadow Copy Service (VSS) dla kopii zapasowych SQL.
|
||||
|
||||
**H. Zarządzanie Wydajnością i Zasobami**
|
||||
|
||||
* Monitorowanie liczników wydajności systemu Windows dla CPU, pamięci i I/O dysku.
|
||||
* Konfiguracja ustawień Windows Server w celu optymalizacji SQL (np. Lock Pages in Memory).
|
||||
* Dostosowanie planów zasilania do obciążeń baz danych o wysokiej wydajności.
|
||||
|
||||
**I. Bezpieczeństwo i Zgodność**
|
||||
|
||||
* Aplikowanie poprawek bezpieczeństwa systemu Windows na serwerach baz danych.
|
||||
* Konfiguracja reguł Zapory systemu Windows dla portów SQL Server.
|
||||
* Implementacja obiektów zasad grupy (GPO) w celu wzmocnienia zabezpieczeń serwera baz danych.
|
||||
|
||||
**J. Wysoka Dostępność i Odzyskiwanie po Awarii**
|
||||
|
||||
* Konfiguracja klastra trybu failover systemu Windows dla SQL Server AlwaysOn.
|
||||
* Zarządzanie węzłami klastra i ustawieniami kworum.
|
||||
* Walidacja stanu klastra i rozwiązywanie problemów związanych z klastrem.
|
||||
|
||||
### 9. Administracja Systemem Linux
|
||||
|
||||
**A. Instalacja i Wstępna Konfiguracja**
|
||||
|
||||
* Weryfikacja wymagań sprzętowych i oprogramowania do instalacji serwera Linux.
|
||||
* Instalacja odpowiedniej dystrybucji i wersji Linuksa (np. RHEL, CentOS, Ubuntu, SUSE).
|
||||
* Zastosowanie najnowszych aktualizacji, poprawek i poprawek bezpieczeństwa.
|
||||
* Konfiguracja nazwy hosta serwera, adresu IP i ustawień sieciowych.
|
||||
* Ustawienie lokalnych i domenowych kont użytkowników z odpowiednimi uprawnieniami.
|
||||
* Konfiguracja synchronizacji czasu (NTP/chrony).
|
||||
* Partycjonowanie i formatowanie dysków na dane, logi, kopie zapasowe i pliki systemowe.
|
||||
|
||||
**B. Konfiguracja**
|
||||
|
||||
* Konfiguracja reguł zapory sieciowej (np. firewalld, iptables) dla łączności baz danych i aplikacji.
|
||||
* Ustawienie polityk bezpieczeństwa: polityki haseł, sudoers i audytu.
|
||||
* Konfiguracja przechowywania: punkty montowania, LVM, RAID i uprawnienia systemu plików.
|
||||
* Ustawienie zaplanowanych zadań do konserwacji (np. zadania cron do tworzenia kopii zapasowych, rotacji logów).
|
||||
* Konfiguracja ochrony antywirusowej lub przed złośliwym oprogramowaniem i ustawienie wykluczeń dla katalogów baz danych.
|
||||
* Ustawienie SSH dla bezpiecznego zdalnego dostępu i konfiguracja uwierzytelniania opartego na kluczach.
|
||||
* Konfiguracja logowania i monitorowania systemu (np. syslog, journald, auditd).
|
||||
|
||||
**C. Konserwacja**
|
||||
|
||||
* Monitorowanie stanu systemu: użycie CPU, pamięci, dysku i sieci.
|
||||
* Aplikowanie regularnych aktualizacji i poprawek bezpieczeństwa.
|
||||
* Przeglądanie i zarządzanie logami systemowymi i aplikacyjnymi pod kątem błędów i ostrzeżeń.
|
||||
* Wykonywanie regularnych kopii zapasowych i testowanie procedur odtwarzania.
|
||||
* Zarządzanie kontami użytkowników, uprawnieniami i członkostwem w grupach.
|
||||
* Rozwiązywanie problemów sprzętowych i programowych.
|
||||
* Czyszczenie plików tymczasowych i zarządzanie przestrzenią dyskową.
|
||||
* Dokumentowanie konfiguracji serwera, zaplanowanych zadań i procedur operacyjnych.
|
||||
|
||||
---
|
||||
|
||||
## Automatyzacja i Skrypty
|
||||
|
||||
### 10. Automatyzacja i Skrypty (Ogólne)
|
||||
|
||||
* Użycie PowerShell do zarządzania instancjami SQL Server (instalacja, konfiguracja, łatanie).
|
||||
* Automatyzacja zadań na poziomie systemu Windows, takich jak czyszczenie dysku lub rotacja logów.
|
||||
* Integracja PowerShell DSC w celu zapewnienia spójności konfiguracji SQL Server.
|
||||
|
||||
### 11. Skrypty
|
||||
|
||||
**A. Bash**
|
||||
|
||||
* Tworzenie skryptów.
|
||||
* Planowanie skryptów lub uruchamianie ich ręcznie.
|
||||
* Dostosowywanie, konserwacja i weryfikacja skryptów.
|
||||
* Monitorowanie skryptów.
|
||||
|
||||
**B. PowerShell**
|
||||
|
||||
* Tworzenie skryptów.
|
||||
* Planowanie skryptów lub uruchamianie ich ręcznie.
|
||||
* Dostosowywanie, konserwacja i weryfikacja skryptów.
|
||||
* Monitorowanie skryptów.
|
||||
|
||||
**C. Transact-SQL**
|
||||
|
||||
* Tworzenie skryptów.
|
||||
* Planowanie skryptów lub uruchamianie ich ręcznie.
|
||||
* Dostosowywanie, konserwacja i weryfikacja skryptów.
|
||||
* Monitorowanie skryptów.
|
||||
* Tworzenie wyzwalaczy SQL, funkcji, procedur, zdarzeń, audytów zgodnie z systemem baz danych.
|
||||
* Tworzenie i konserwacja zadań SQL.
|
||||
* Monitorowanie zadań i tworzenie alertów.
|
||||
|
||||
### 12. Ansible
|
||||
|
||||
**A. Tworzenie i utrzymywanie listy serwerów baz danych**
|
||||
|
||||
* Identyfikacja serwera.
|
||||
* Dodanie odpowiednich tagów bazy danych.
|
||||
|
||||
**B. Przygotowywanie szablonów baz danych**
|
||||
|
||||
* Tworzenie i utrzymywanie szablonu dla MSSQL.
|
||||
* Tworzenie i utrzymywanie szablonu dla MySQL.
|
||||
* Tworzenie i utrzymywanie szablonu dla PostgreSQL.
|
||||
* Tworzenie i utrzymywanie szablonu dla MongoDB.
|
||||
* Tworzenie i utrzymywanie szablonu dla OracleDB.
|
||||
|
||||
**C. Stosowanie szablonów do agenta zainstalowanego na serwerach baz danych**
|
||||
|
||||
* Tworzenie zgłoszenia dla każdej zmiany wprowadzonej w Ansible.
|
||||
* Dodawanie odpowiednich ustawień dla każdego serwera baz danych w pliku inwentarza Ansible.
|
||||
* Uruchamianie playbooka Ansible w celu wypchnięcia zmian na serwer.
|
||||
|
||||
---
|
||||
|
||||
## Narzędzia i Platformy Monitorujące
|
||||
|
||||
### 13. NinjaRMM
|
||||
|
||||
**A. Tworzenie i utrzymywanie listy serwerów baz danych**
|
||||
|
||||
* Identyfikacja serwera.
|
||||
* Dodanie odpowiednich tagów bazy danych.
|
||||
|
||||
**B. Przygotowywanie szablonów łatania**
|
||||
|
||||
**C. Łatanie serwerów zgodnie z polityką łatania**
|
||||
|
||||
### 14. Splunk
|
||||
|
||||
**A. Tworzenie i utrzymywanie listy serwerów baz danych**
|
||||
|
||||
* Weryfikacja, czy wszystkie serwery baz danych są podłączone do Splunka.
|
||||
|
||||
**B. Przygotowywanie i dostosowywanie wykresów i pulpitów nawigacyjnych**
|
||||
|
||||
* Tworzenie spersonalizowanych wykresów i pulpitów nawigacyjnych.
|
||||
* Tworzenie spersonalizowanych metryk.
|
||||
|
||||
**C. Tworzenie detektorów i zarządzanie alertami**
|
||||
|
||||
* Oddzielne detektory i alerty dla środowisk produkcyjnych i nieprodukcyjnych.
|
||||
* Powiadamianie o alertach za pośrednictwem poczty e-mail i kanału Teams.
|
||||
|
||||
**D. Codzienne monitorowanie utworzonych pulpitów nawigacyjnych i wykresów**
|
||||
|
||||
* Tworzenie incydentu w SNOW w przypadku zauważenia wartości krytycznej.
|
||||
* Dostosowywanie progów w przypadku zauważenia niestandardowego zachowania.
|
||||
* Raportowanie aktywnych i zamkniętych incydentów.
|
||||
|
||||
---
|
||||
|
||||
## Zarządzanie Kopiami Zapasowymi
|
||||
|
||||
### 15. Veeam SQL
|
||||
|
||||
**A. Tworzenie i utrzymywanie listy serwerów baz danych**
|
||||
|
||||
* Identyfikacja serwera.
|
||||
* Dodanie odpowiednich tagów bazy danych.
|
||||
|
||||
**B. Przygotowywanie szablonów kopii zapasowych**
|
||||
|
||||
**C. Tworzenie kopii zapasowych serwerów zgodnie z politykami łatania**
|
||||
|
||||
**D. Tworzenie kopii zapasowych serwerów na żądanie**
|
||||
|
||||
**E. Monitorowanie serwerów zgodnie z politykami monitorowania**
|
||||
|
||||
**F. Odtwarzanie kopii zapasowych na żądanie**
|
||||
|
||||
---
|
||||
|
||||
## Główne Obowiązki i Procesy
|
||||
|
||||
### 16. Optymalizacja Baz Danych
|
||||
|
||||
**A. Zarządzanie Indeksami**
|
||||
|
||||
* Analiza wzorców zapytań i identyfikacja brakujących lub nieużywanych indeksów.
|
||||
* Tworzenie odpowiednich indeksów (jednokolumnowe, złożone, pokrywające) w celu poprawy wydajności zapytań.
|
||||
* Regularna przebudowa lub reorganizacja pofragmentowanych indeksów.
|
||||
* Usuwanie zbędnych lub nieużywanych indeksów w celu zmniejszenia narzutu.
|
||||
|
||||
**B. Optymalizacja Zapytań**
|
||||
|
||||
* Przegląd i dostosowywanie wolno działających zapytań za pomocą planów wykonania.
|
||||
* Refaktoryzacja zapytań w celu zwiększenia wydajności (np. unikanie `SELECT *`, używanie odpowiednich złączeń, wczesne filtrowanie).
|
||||
* Używanie zapytań sparametryzowanych w celu poprawy ponownego wykorzystania planu i bezpieczeństwa.
|
||||
* Optymalizacja procedur składowanych, wyzwalaczy i funkcji.
|
||||
|
||||
**C. Statystyki i Konserwacja**
|
||||
|
||||
* Regularna aktualizacja statystyk bazy danych w celu zapewnienia optymalnych planów zapytań.
|
||||
* Planowanie i automatyzacja regularnych zadań konserwacji bazy danych (np. vacuum, analyze, update statistics).
|
||||
* Czyszczenie przestarzałych lub tymczasowych danych.
|
||||
|
||||
**D. Strojenie Konfiguracji**
|
||||
|
||||
* Dostosowywanie alokacji pamięci (pule buforów, rozmiary pamięci podręcznej) w oparciu o obciążenie i zasoby serwera.
|
||||
* Dostosowywanie limitów połączeń, równoległości i ustawień wątków.
|
||||
* Optymalizacja parametrów specyficznych dla bazy danych (np. TempDB w SQL Server, pula buforów InnoDB w MySQL, shared_buffers w PostgreSQL).
|
||||
|
||||
**E. Optymalizacja Modelu Danych**
|
||||
|
||||
* Normalizacja lub denormalizacja tabel w zależności od obciążenia.
|
||||
* Partycjonowanie dużych tabel w celu poprawy wydajności zapytań i konserwacji.
|
||||
* Archiwizacja lub usuwanie starych danych w celu utrzymania małych aktywnych zestawów danych.
|
||||
|
||||
**F. Monitorowanie i Analiza**
|
||||
|
||||
* Ustawienie narzędzi monitorujących do śledzenia metryk wydajności (CPU, pamięć, I/O dysku, czasy odpowiedzi na zapytania).
|
||||
* Regularna analiza logów wolnych zapytań i raportów wydajności.
|
||||
* Ustawienie alertów dotyczących degradacji wydajności lub wąskich gardeł zasobów.
|
||||
|
||||
**G. Zarządzanie Zasobami**
|
||||
|
||||
* Równoważenie obciążeń między dostępnym sprzętem (CPU, pamięć, pamięć masowa).
|
||||
* Optymalizacja układu dysków (oddzielne pliki danych, logów, temp i kopii zapasowych).
|
||||
* Zapewnienie wystarczającej przepustowości I/O dla operacji bazodanowych.
|
||||
|
||||
**H. Współbieżność i Blokowanie**
|
||||
|
||||
* Identyfikacja i rozwiązywanie problemów z blokowaniem i zakleszczeniami.
|
||||
* Dostosowywanie poziomów izolacji i strategii blokowania w celu zrównoważenia spójności i wydajności.
|
||||
|
||||
**I. Strojenie Aplikacji i Połączeń**
|
||||
|
||||
* Używanie puli połączeń w celu zmniejszenia narzutu.
|
||||
* Optymalizacja logiki aplikacji w celu zminimalizowania niepotrzebnych wywołań bazy danych.
|
||||
|
||||
**J. Bezpieczeństwo i Zgodność**
|
||||
|
||||
* Zapewnienie, że optymalizacja nie zagraża bezpieczeństwu (np. unikanie ujawniania danych wrażliwych w logach).
|
||||
* Regularny audyt uprawnień i wzorców dostępu.
|
||||
|
||||
**K. Dokumentacja i Przegląd**
|
||||
|
||||
* Dokumentowanie zmian optymalizacyjnych i ich uzasadnienia.
|
||||
* Okresowy przegląd i aktualizacja strategii optymalizacji w miarę ewolucji obciążeń.
|
||||
|
||||
### 17. Testowanie
|
||||
|
||||
*(Brak szczegółów w oryginalnym dokumencie)*
|
||||
|
||||
### 18. Bezpieczeństwo
|
||||
|
||||
*(Brak szczegółów w oryginalnym dokumencie)*
|
||||
|
||||
### 19. Instalacja poprawek (Patching)
|
||||
|
||||
*(Brak szczegółów w oryginalnym dokumencie)*
|
||||
|
||||
### 20. Konsultacje
|
||||
|
||||
*(Brak szczegółów w oryginalnym dokumencie)*
|
||||
|
||||
### 21. Analiza Błędów
|
||||
|
||||
*(Brak szczegółów w oryginalnym dokumencie)*
|
||||
|
||||
### 22. Wsparcie Danych w Środowisku Produkcyjnym
|
||||
|
||||
**A. Masowe ładowanie danych w środowisku produkcyjnym**
|
||||
|
||||
* Udzielanie pomocy Biznesowi, gdy wymagane są masowe ładowania danych w środowisku produkcyjnym, szczególnie w przypadkach, gdy nie istnieje standardowy proces lub wewnętrzna wiedza (tj. ładowania ad hoc lub jednorazowe).
|
||||
* Masowe ładowania danych często wymagają szczególnej uwagi w celu zapewnienia stabilności systemu. Może to obejmować opracowanie skryptów wsadowych i ścisłą obserwację w celu zapobiegania blokadom i blokowaniu bazy danych, zapewniając tym samym, że operacje produkcyjne przebiegają bez zakłóceń.
|
||||
|
||||
**B. Masowe aktualizacje jakości danych w środowisku produkcyjnym**
|
||||
|
||||
* Udzielanie wsparcia Biznesowi przy masowych aktualizacjach istniejących danych w środowisku produkcyjnym, gdy jest to wymagane ze względu na jakość lub kompletność danych, zwłaszcza w przypadkach, gdy nie jest dostępna dedykowana aplikacja lub wewnętrzna wiedza (tj. korekty danych ad hoc lub jednorazowe).
|
||||
* Takie masowe aktualizacje danych często wymagają szczególnej staranności w celu utrzymania stabilności systemu. Może to obejmować opracowanie skryptów wsadowych i ścisłą obserwację w celu zapobiegania blokadom i blokowaniu bazy danych, zapewniając, że operacje produkcyjne przebiegają bez zakłóceń.
|
||||
|
||||
**C. Archiwizacja danych w środowisku produkcyjnym**
|
||||
|
||||
* Udzielanie wsparcia Biznesowi w procesach archiwizacji danych w środowisku produkcyjnym. Archiwizacja danych jest często pomijana, ponieważ Biznes może nie być świadomy ciągłego wzrostu baz danych na przestrzeni lat. Tabele o dużej liczbie rekordów mogą wymagać archiwizacji w celu poprawy wydajności systemu oraz skrócenia czasu konserwacji i tworzenia kopii zapasowych, a także optymalnego zarządzania przestrzenią dyskową.
|
||||
* Wiele baz danych zawiera tabele z bardzo starymi danymi, które nie są już potrzebne do codziennych operacji i mogą być przeniesione z głównych tabel.
|
||||
* Skuteczna archiwizacja danych wymaga świadomości, dokładnego planowania i starannego wykonania skryptów archiwizacyjnych w celu zapewnienia integralności danych i zminimalizowania wpływu na operacje produkcyjne.
|
||||
@@ -0,0 +1,70 @@
|
||||
# Przepływ Pracy (Workflow) Administratora Baz Danych (DBA)
|
||||
|
||||
Ten dokument opisuje typowy przepływ pracy dla Administratora Baz Danych (DBA), zorganizowany w oparciu o częstotliwość wykonywania zadań. Workflow ma na celu zapewnienie stabilności, wydajności i bezpieczeństwa zarządzanych systemów bazodanowych.
|
||||
|
||||
---
|
||||
|
||||
## 1. Zadania Codzienne (Daily Tasks)
|
||||
|
||||
**Cel:** Zapewnienie ciągłości działania i szybkiego reagowania na problemy.
|
||||
|
||||
| Zadanie | Opis | Narzędzia / Procesy |
|
||||
| :--- | :--- | :--- |
|
||||
| **Monitorowanie i Alerty** | Aktywne monitorowanie pulpitów nawigacyjnych i systemów alertów w celu wczesnego wykrywania problemów. | - **Splunk:** Analiza wykresów i alertów.<br>- **NinjaRMM:** Sprawdzanie stanu serwerów.<br>- **Natywne narzędzia:** Alerty SQL Agenta, logi systemowe. |
|
||||
| **Przegląd Wydajności** | Szybka ocena kluczowych wskaźników wydajności (KPI), takich jak użycie CPU, pamięci, I/O dysku i czas odpowiedzi na zapytania. | - **Splunk:** Analiza metryk wydajności.<br>- **Narzędzia monitorujące:** Zabbix, Nagios, Prometheus. |
|
||||
| **Sprawdzanie Statusu Kopii Zapasowych**| Weryfikacja, czy wszystkie zaplanowane zadania tworzenia kopii zapasowych zakończyły się sukcesem. | - **Veeam SQL:** Sprawdzanie statusu zadań.<br>- **SQL Agent:** Weryfikacja historii zadań.<br>- **Skrypty PowerShell/Bash:** Automatyczne raporty. |
|
||||
| **Zarządzanie Incydentami** | Reagowanie na alerty, diagnozowanie problemów i tworzenie zgłoszeń w systemie (np. SNOW) w przypadku krytycznych wartości. | - **Splunk:** Tworzenie alertów i detektorów.<br>- **Systemy ticketowe:** Tworzenie i obsługa incydentów. |
|
||||
|
||||
---
|
||||
|
||||
## 2. Zadania Cotygodniowe (Weekly Tasks)
|
||||
|
||||
**Cel:** Proaktywna konserwacja, optymalizacja i planowanie.
|
||||
|
||||
| Zadanie | Opis | Narzędzia / Procesy |
|
||||
| :--- | :--- | :--- |
|
||||
| **Konserwacja i Optymalizacja** | Przegląd wolnych zapytań, stanu indeksów i statystyk. Planowanie i wykonywanie zadań konserwacyjnych (reindeksacja, aktualizacja statystyk). | - **Plany konserwacji SQL.**<br>- **Skrypty T-SQL/PowerShell:** Analiza fragmentacji, optymalizacja zapytań.<br>- **Narzędzia analityczne:** Execution Plans, AWR/ASH reports. |
|
||||
| **Przegląd Bezpieczeństwa** | Audyt uprawnień, przegląd logów dostępu i weryfikacja polityk bezpieczeństwa. | - **Audyty SQL Server.**<br>- **Przegląd logów systemowych i bazodanowych.** |
|
||||
| **Planowanie i Instalacja Poprawek (Patching)** | Przegląd dostępnych poprawek, planowanie okien serwisowych i przygotowywanie serwerów do aktualizacji. | - **NinjaRMM:** Przygotowanie szablonów łatania.<br>- **Ansible:** Automatyzacja procesu łatania. |
|
||||
| **Raportowanie Stanu** | Przygotowanie podsumowania stanu środowiska bazodanowego, wydajności i zrealizowanych zadań dla przełożonych lub zespołu. | - **SSRS:** Generowanie raportów.<br>- **Splunk:** Eksport danych z dashboardów. |
|
||||
|
||||
---
|
||||
|
||||
## 3. Zadania Comiesięczne (Monthly Tasks)
|
||||
|
||||
**Cel:** Długoterminowe zarządzanie i strategiczne planowanie.
|
||||
|
||||
| Zadanie | Opis | Narzędzia / Procesy |
|
||||
| :--- | :--- | :--- |
|
||||
| **Testowanie Odtwarzania Danych** | Próbne odtwarzanie losowo wybranych kopii zapasowych na środowisku testowym w celu weryfikacji ich integralności i poprawności procedur. | - **Veeam SQL:** Odtwarzanie na żądanie.<br>- **Skrypty T-SQL/PowerShell:** Automatyzacja procesu odtwarzania i weryfikacji. |
|
||||
| **Przegląd Pojemności (Capacity Planning)** | Analiza trendów wzrostu baz danych, zużycia przestrzeni dyskowej i prognozowanie przyszłych potrzeb. | - **Skrypty monitorujące wzrost plików baz danych.**<br>- **Raporty z narzędzi monitorujących.** |
|
||||
| **Archiwizacja Danych** | Identyfikacja i planowanie archiwizacji starych danych w celu poprawy wydajności i zarządzania przestrzenią dyskową. | - **Współpraca z biznesem.**<br>- **Skrypty T-SQL/SSIS** do przenoszenia danych. |
|
||||
| **Przegląd i Aktualizacja Dokumentacji** | Weryfikacja i aktualizacja dokumentacji konfiguracyjnej serwerów, procedur operacyjnych i skryptów. | - **Systemy wiki (np. Confluence).**<br>- **Repozytoria kodu (np. Git).** |
|
||||
|
||||
---
|
||||
|
||||
## 4. Zadania Ad-Hoc / Na Żądanie (On-Demand Tasks)
|
||||
|
||||
**Cel:** Reagowanie na bieżące potrzeby biznesowe i techniczne.
|
||||
|
||||
| Zadanie | Opis | Narzędzia / Procesy |
|
||||
| :--- | :--- | :--- |
|
||||
| **Instalacja i Konfiguracja Nowych Serwerów**| Pełen cykl życia: od zebrania wymagań, przez instalację, po konfigurację i wdrożenie produkcyjne. | - **Ansible:** Automatyzacja instalacji i konfiguracji.<br>- **Skrypty PowerShell/Bash.**<br>- **Checklisty instalacyjne.** |
|
||||
| **Migracje Baz Danych** | Planowanie i przeprowadzanie migracji między serwerami, weryfikacja danych i testy po migracji. | - **Microsoft Assessment Tool.**<br>- **Narzędzia do exportu/importu:** `mysqldump`, `mongodump`, `pg_dump`, Data Pump, SSIS. |
|
||||
| **Wsparcie dla Biznesu i Deweloperów** | - Masowe ładowanie/aktualizacje danych.<br>- Konsultacje w zakresie optymalizacji zapytań.<br>- Udzielanie dostępu, rozwiązywanie problemów z łącznością. | - **Skrypty T-SQL/PowerShell.**<br>- **Narzędzia do analizy zapytań.** |
|
||||
| **Analiza Błędów i Problemów** | Głęboka analiza przyczyn źródłowych incydentów, problemów z wydajnością lub błędów aplikacyjnych. | - **Logi systemowe i bazodanowe.**<br>- **Narzędzia diagnostyczne (profilery, extended events).** |
|
||||
| **Wdrażanie Zmian** | Aplikowanie zmian konfiguracyjnych, schematów baz danych czy aktualizacji z użyciem zautomatyzowanych procesów. | - **Ansible:** Wdrażanie zmian z plików inwentarza.<br>- **Systemy kontroli wersji (Git) i CI/CD.** |
|
||||
|
||||
---
|
||||
|
||||
## 5. Procesy Ciągłe (Ongoing Processes)
|
||||
|
||||
**Cel:** Stałe doskonalenie i utrzymanie porządku w zarządzanym środowisku.
|
||||
|
||||
| Proces | Opis | Narzędzia / Procesy |
|
||||
| :--- | :--- | :--- |
|
||||
| **Automatyzacja** | Identyfikacja powtarzalnych zadań i tworzenie skryptów oraz playbooków w celu ich automatyzacji. | - **Ansible, PowerShell, Bash, T-SQL.** |
|
||||
| **Zarządzanie Konfiguracją** | Utrzymywanie spójnej i udokumentowanej konfiguracji wszystkich serwerów bazodanowych. | - **Ansible (Infrastructure as Code).**<br>- **Repozytoria Git** do przechowywania konfiguracji i skryptów. |
|
||||
| **Utrzymywanie Wiedzy** | Doskonalenie znajomości nowych technologii, wersji oprogramowania i najlepszych praktyk w branży. | - **Szkolenia, dokumentacja techniczna, webinary.** |
|
||||
| **Rozwój Narzędzi Wewnętrznych**| Ulepszanie i tworzenie nowych skryptów, pulpitów nawigacyjnych i narzędzi ułatwiających administrację. | - **Splunk, PowerShell, Python.** |
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
- [Frequently Asked Questions](#frequently-asked-questions)
|
||||
- [Links/Graphs/BackLinks don't work. How do I enable them?](#linksgraphsbacklinks-dont-work-how-do-i-enable-them)
|
||||
- [I don't want Foam enabled for all my workspaces](#i-dont-want-foam-enabled-for-all-my-workspaces)
|
||||
- [I want to publish the graph view to GitHub pages or Vercel](#i-want-to-publish-the-graph-view-to-github-pages-or-vercel)
|
||||
|
||||
## Links/Graphs/BackLinks don't work. How do I enable them?
|
||||
|
||||
- Ensure that you have all the [[recommended-extensions]] installed in Visual Studio Code
|
||||
- Reload Visual Studio Code by running `Cmd` + `Shift` + `P` (`Ctrl` + `Shift` + `P` for Windows), type "reload" and run the **Developer: Reload Window** command to for the updated extensions take effect
|
||||
- Check the formatting rules for links on [[foam-file-format]] and [[wikilinks]]
|
||||
|
||||
## I don't want Foam enabled for all my workspaces
|
||||
|
||||
Any extension you install in Visual Studio Code is enabled by default. Given the philosophy of Foam, it works out of the box without doing any configuration upfront. In case you want to disable Foam for a specific workspace, or disable Foam by default and enable it for specific workspaces, it is advised to follow the best practices as [documented by Visual Studio Code](https://code.visualstudio.com/docs/editor/extension-marketplace#_manage-extensions)
|
||||
|
||||
## I want to publish the graph view to GitHub pages or Vercel
|
||||
|
||||
If you want a different front-end look to your published foam and a way to see your graph view, we'd recommend checking out these templates:
|
||||
|
||||
- [foam-gatsby](https://github.com/mathieudutour/foam-gatsby-template) by [Mathieu Dutour](https://github.com/mathieudutour)
|
||||
- [foam-gatsby-kb](https://github.com/hikerpig/foam-template-gatsby-kb) by [hikerpig](https://github.com/hikerpig)
|
||||
|
||||
[recommended-extensions]: getting-started/recommended-extensions.md 'Recommended Extensions'
|
||||
[foam-file-format]: ../dev/foam-file-format.md 'Foam File Format'
|
||||
[wikilinks]: features/wikilinks.md 'Wikilinks'
|
||||
@@ -0,0 +1,62 @@
|
||||
# Checklista wdrożenia GEO dla treści technicznych
|
||||
|
||||
**Cel:** Poniższa **checklista GEO (Generative Engine Optimization)** pomaga tworzyć i optymalizować treści techniczne (dokumentacje, artykuły inżynierskie, wpisy blogowe o bazach danych, poradniki itp.) tak, aby były **łatwo cytowane przez systemy AI** (ChatGPT, Perplexity, Google SGE itp.). Dzięki temu Twoje materiały – jako Database Engineer – staną się zaufanym źródłem odpowiedzi generowanych przez AI.
|
||||
|
||||
## Najważniejsze etapy GEO i działania wdrożeniowe
|
||||
|
||||
*(Podzielono na sekcje od planowania treści, poprzez formatowanie i aspekty techniczne, po utrzymanie i analizę wyników.)*
|
||||
|
||||
### Przygotowanie treści (planowanie i research)
|
||||
|
||||
| **Krok / zadanie** | **Dlaczego to ważne** | **Jak to wdrożyć** |
|
||||
| --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Analiza potrzeb i pytań użytkowników** <br>*(Research tematów)* | Aby tworzyć treści odpowiadające realnym zapytaniom – **lepsza zgodność z intencją użytkownika** oznacza większe szanse, że AI uzna Twoją treść za idealną odpowiedź. | Zbadaj, **o co pytają ludzie** w Twojej branży: prześledź fora (Stack Overflow, Reddit), pytania z Google, sugestie autouzupełniania. Zanotuj najczęstsze problemy i sformułowania pytań (np. *„Jak skonfigurować klaster MySQL?”*). Skup się na **long-tail** (szczegółowych) pytaniach, bo AI często odpowiada na konkrety. |
|
||||
| **Określenie celu i zakres treści** <br>*(Jasna teza i target)* | Jasno zdefiniowany **główny temat i pytanie przewodnie** gwarantuje, że cała treść będzie spójna i ukierunkowana na odpowiedź. | Zdecyduj, **jakie pytanie główne** ma adresować treść (np. *„Co to jest sharding bazy danych i jak go zaimplementować?”*). Wypisz także podrzędne zagadnienia, które trzeba poruszyć (np. korzyści shardingu, przykłady kodu konfiguracji). To będzie baza do struktury Q\&A. |
|
||||
| **Zebranie materiałów i danych** <br>*(Eksperckie źródła, przykłady)* | **Wiarygodna i bogata merytorycznie treść** wyróżni się dla AI. Unikalne dane, przykłady kodu czy wyniki testów uczynią Twoje treści cenniejszymi od powierzchownych artykułów marketingowych. | Zgromadź **konkretne informacje** do przytoczenia: oficjalną dokumentację (np. specyfikacja API, manual DB), wyniki własnych testów wydajności, fragmenty kodu, ewentualnie cytaty z ekspertów. Przygotuj też linki do źródeł, na które się powołasz (np. whitepapery, standardy) – będą potrzebne do dodania przypisów. |
|
||||
|
||||
### Struktura i formatowanie treści (przyjazne dla AI)
|
||||
|
||||
| **Krok / zadanie** | **Dlaczego to ważne** | **Jak to wdrożyć** |
|
||||
| -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Tytuł jako pytanie + szybka odpowiedź na start** <br>*(Pytaj i odpowiadaj natychmiast)* | Nagłówek w formie pytania **idealnie pokrywa się z zapytaniem użytkownika**, co zwiększa szansę dopasowania przez AI. Z kolei **blisko umieszczona esencjonalna odpowiedź** (tzw. Quick Answer) sprawia, że model może od razu ją zacytować. | Sformułuj tytuł jako **pytanie zawierające główne słowo kluczowe** (np. *„Jak działa transakcja w NoSQL?”*). Tuż pod tytułem dodaj **krótką definicję/odpowiedź (40–60 słów)** pogrubioną lub w ramce – wyjaśniającą sedno tematu. Np.: *„**Transakcja w NoSQL** to operacja obejmująca wiele dokumentów, gwarantująca ich spójną modyfikację lub brak zmian w razie błędu.”* |
|
||||
| **Nagłówki H2/H3 jako pytania (struktura Q\&A)** <br>*(Sekcje odpowiadające na pod-pytania)* | Podział treści na sekcje pytanie→odpowiedź ułatwia AI znajdowanie konkretnych informacji. Artykuły z wyraźną strukturą Q\&A mają nawet \~**40% większą szansę na cytowanie**. | Każdą główną sekcję rozpocznij **pytaniem w nagłówku** (H2/H3), np. *„**Jak skonfigurować replikację w PostgreSQL?**”*. Bezpośrednio pod nagłówkiem **odpowiedz w 1–3 zdaniach** (zanim przejdziesz do szczegółów). Taki układ pytanie→krótka odpowiedź→szczegóły zachowaj w całym tekście. |
|
||||
| **Krótkie akapity, styl *answer-first*** <br>*(Zwięzłość i konkrety)* | **Zwięzłe akapity** (1–3 zdania) są łatwiejsze do przetworzenia przez model – minimalizujesz ryzyko “zgubienia” odpowiedzi w ścianie tekstu. Pisząc stylem *„najpierw odpowiedź, potem rozwinięcie”*, zapewniasz, że AI wyłapie sedno nawet jeśli pominie resztę akapitu. | **Unikaj lania wody**: każdą sekcję i akapit zaczynaj od najważniejszej informacji. Na przykład zamiast wprowadzać długi kontekst historyczny, od razu powiedz: *„Mechanizm WAL w PostgreSQL zapewnia trwałość danych, utrwalając operacje przed potwierdzeniem transakcji.”* – a dopiero potem dodaj szczegóły techniczne. Utrzymuj zdania **krótkie i precyzyjne**, zrozumiałe także poza kontekstem (AI może zacytować jedno zdanie wyrwane z tekstu). |
|
||||
| **Listy wypunktowane i numerowane** <br>*(Wypisz kroki, cechy, porady)* | **Wypunktowania porządkują informacje** i zwracają uwagę algorytmów AI. Modele językowe często formatują odpowiedzi jako listy – jeśli Twój tekst już zawiera listę, zwiększasz szansę, że AI przejmie ją w gotowej postaci. Klarowne listy punktów czy kroków są jak drogowskazy: wskazują modelowi najważniejsze elementy do wyróżnienia. | Stosuj listy wszędzie tam, gdzie wyliczasz **wiele elementów**: np. *główne funkcje systemu (●)*, *etapy konfiguracji krok po kroku (1. 2. 3.)*, *zalety i wady rozwiązania (–/+)*. Każdy punkt formułuj **telegraficznie**, jednym zdaniem lub równoważnikiem zdania. Przykład: zamiast chować 10 zaleceń w akapicie, wypunktuj je punktami – AI może wtedy zacytować całą listę jako odpowiedź na pytanie typu „What are best practices for X?”. |
|
||||
| **Tabele z danymi lub porównaniami** <br>*(Struktura tabelaryczna)* | **Tabele są świetnymi „magnesami cytowań”** – prezentują dane w uporządkowany sposób, który AI może przejąć bez przerabiania formy. Jeśli użytkownik zapyta np. *„Porównaj X i Y”*, model chętnie zacytuje istniejącą tabelę zamiast generować opis. Tabele pozwalają też AI precyzyjnie wyłuskać pojedyńcze wartości (np. *„Jaka jest maks. liczba połączeń w DB2?”* może spowodować zacytowanie konkretnej komórki z tabeli porównawczej limitów). | Wykorzystuj **tabelki do porównań i zestawień danych**: np. tabelę porównującą różne silniki baz danych (kolumny: kryterium, DBMS A, DBMS B). Upewnij się, że tabela ma opisowe nagłówki kolumn i dobrze rozdzielone wiersze z danymi. W treści możesz nawiązać do tabeli, np. *„Tabela 1 podsumowuje różnice między lokalnym a rozproszonym indeksowaniem.”* – to podpowie AI, że konkrety są w tabeli i może je tam znaleźć. |
|
||||
| **Przykłady kodu i konfiguracji (z objaśnieniem)** <br>*(Bloki kodu w tekście)* | **Kod to często najlepsza odpowiedź** na pytanie techniczne – modele wolą zacytować poprawny fragment kodu, niż ryzykować generowanie go samodzielnie (co mogłoby skutkować błędem). Ale żeby AI użył Twojego kodu, musi zrozumieć kontekst – stąd ważne jest otoczenie przykładu kodu opisem. Dodatkowo, poprawne sformatowanie (blok `<code>` lub Markdown) sprawi, że model łatwo wyłowi dokładny fragment. | Dodawaj **fragmenty kodu, konfiguracji lub zapytań** SQL ilustrujące rozwiązanie. Każdy blok kodu poprzedź jednym zdaniem opisującym *co robi kod* lub *jaki problem rozwiązuje*. Np.: *„Poniższy skrypt Bash automatyzuje backup bazy MySQL:”* (i dalej blok kodu). Używaj odpowiedniego formatowania: w HTML `<pre><code>` z językiem, w Markdown potrójne backticki z nazwą języka (`sql, `python itd.). Dzięki temu AI rozpozna, że to kod – i może go zacytować dokładnie w tej formie. |
|
||||
| **Sekcja FAQ na końcu** <br>*(Pokrycie dodatkowych pytań)* | **FAQ to dodatkowe Q\&A** w treści – zwiększa pokrycie tzw. długiego ogona pytań. Użytkownicy często zadają drobne, powiązane pytania (np. „Co jeśli replika padnie?”), a AI szuka na nie szybkich odpowiedzi. Posiadanie sekcji FAQ to sygnał dla Google i AI, że strona kompleksowo omawia temat – Google SGE często **włącza odpowiedzi z FAQ do swoich podsumowań**. | Dodaj na końcu artykułu **3–5 krótkich pytań uzupełniających z odpowiedziami**. Skup się na praktycznych kwestiach, np. *„Czy MongoDB wspiera transakcje?”* – *„Tak, począwszy od wersji 4.0 MongoDB obsługuje transakcje wielodokumentowe...”.* Zaimplementuj te pytania także w znacznikach **schema FAQPage** (każde Q jako `mainEntity` z `acceptedAnswer`), aby zarówno wyszukiwarki, jak i AI, widziały wyraźnie strukturę FAQ. |
|
||||
|
||||
### Dane strukturalne i aspekt techniczny SEO
|
||||
|
||||
| **Krok / zadanie** | **Dlaczego to ważne** | **Jak to wdrożyć** |
|
||||
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Znaczniki schema.org dla strony** <br>*(Article/TechArticle, FAQ, HowTo)* | **Dane strukturalne (schema)** opisują Twoją treść w sposób zrozumiały dla algorytmów – ułatwiają Google i AI rozpoznanie typu contentu i kluczowych sekcji. np. schema `Article` informuje o autorze, dacie, tytule; schema `FAQPage` jasno wyróżnia pytania i odpowiedzi. Dzięki temu AI może skuteczniej wybrać Twoją stronę i nawet zacytować konkretną odpowiedź z FAQ. | Dodaj w headzie lub body **JSON-LD z definicją artykułu** (typu `Article` lub `TechArticle`): uwzględnij `headline`, `description`, `author` (z `name` i np. `jobTitle`), `dateModified` itp. W przypadku poradników krok-po-kroku, rozważ również schema `HowTo`. Jeśli masz sekcję FAQ (jak wyżej) – koniecznie zaimplementuj schema typu `FAQPage` dla tych elementów. Skorzystaj z narzędzi Google do testowania wyników rozszerzonych, aby upewnić się, że dane strukturalne są poprawne. |
|
||||
| **Semantyczny HTML i dostępność** <br>*(Uporządkowany kod strony)* | **Czysta struktura HTML** sprawia, że zarówno tradycyjne crawlery wyszukiwarek, jak i boty AI **lepiej rozumieją układ treści**. Poprawne nagłówki, listy, tabele, podpisy do obrazów – to wszystko pozwala modelom językowym łatwiej zidentyfikować co jest czym (pytaniem, kodem, treścią poboczną). Dodatkowo, praktyki dostępności (alt text, ARIA) pomagają algorytmom podobnie jak czytnikom ekranu. | Stosuj **prawidłowe znaczniki HTML5**: nagłówek strony jako `<h1>` (tytuł artykułu), kolejne sekcje z `<h2>..<h3>` (pytania), używaj `<section>`/`<article>` jeśli to możliwe do logicznego wydzielenia części. Dla kodu – `<pre><code>` z atrybutem języka (klasa lub `lang`). Dla obrazków/diagramów – zapewnij **tekst alternatywny** lub podpis `<figcaption>` z objaśnieniem ilustracji (AI nie “widzi” grafiki, musi polegać na tekście). Unikaj osadzania istotnej treści w formie, której crawler nie odczyta (np. tekst tylko w obrazku lub w iframe). Jeśli strona korzysta z heavy JavaScript do generowania treści, rozważ statyczne prerenderowanie dla crawlerów. |
|
||||
| **Weryfikacja indeksacji i robots** <br>*(Przyjazność dla botów AI)* | Jeśli Twoja strona nie będzie dostępna dla botów, **żadne starania GEO nie zadziałają** – AI po prostu jej nie zna. Ważne jest nieblokowanie nowych crawlerów AI (np. OpenAI) w `robots.txt`. Na przykład ChatGPT korzysta z własnego bota indeksującego sieć – **OAI-SearchBot** – który musi mieć dostęp do Twojej strony, by mógł ją zindeksować i wykorzystać. Również **GPTBot** (crawler trenujący modele OpenAI) warto dopuścić, jeśli chcesz, by przyszłe modele „nauczyły się” Twojej zawartości. | **Sprawdź `robots.txt`** – upewnij się, że nie blokujesz popularnych agentów: `Googlebot`, `Bingbot` (to standard), a także `GPTBot` i `ChatGPT-User`/`ChatGPTBrowser` (identyfikatory używane przez crawlery OpenAI). Przykładowo, aby zezwolić GPTBotowi, możesz dodać: `User-agent: GPTBot` + `Allow: /`. Jeśli z jakichś względów nie chcesz być użyty do treningu modeli, GPTBot obsługuje także pole `Disallow` z parametrami; jednak pozostawienie dostępu zwiększa szansę ujęcia w odpowiedziach. Dla pewności, nie używaj meta-tagów `noindex` na stronach, które chcesz promować w AI. Po publikacji, **zindeksuj stronę** w Google/Bing (np. przez API indeksowania) – szybciej trafi też do SGE i Perplexity. |
|
||||
|
||||
### Cytowania, wiarygodność i autorytet
|
||||
|
||||
| **Krok / zadanie** | **Dlaczego to ważne** | **Jak to wdrożyć** |
|
||||
| ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| **Dodawanie przypisów i linków do źródeł** <br>*(Weryfikowalność informacji)* | Modele AI wybierając treść do cytowania **faworyzują informacje poparte źródłami** – to dla nich sygnał wiarygodności. Jeśli Twój tekst ma odwołania do oficjalnych dokumentacji, standardów czy artykułów naukowych, **zmniejszasz ryzyko uznania treści za niesprawdzoną**. Dodatkowo użytkownik końcowy widząc cytat z Twojej strony i tak otrzyma referencję do źródła (link), więc lepiej, byś już w tekście pokazał, że bazujesz na faktach. | Wprowadzaj **cytowania w stylu naukowym lub dziennikarskim**: kluczowe stwierdzenia opatrz przypisem (np. „\[1]”) lub linkiem do źródła. Np. *„Redis może osiągać opóźnienia <1 ms”* – z odnośnikiem do raportu wydajności. Linkuj do **wiarygodnych witryn** (dokumentacje produktowe, RFC, akademickie, renomowane blogi tech). Jeżeli przytaczasz czyjeś słowa, podaj autora/organizację. Dobrą praktyką jest na końcu artykułu dać sekcję „Źródła” lub bibliografię. Pamiętaj: lepiej użyć **kilku solidnych źródeł** niż wielu przypadkowych – jakość ponad ilość. |
|
||||
| **Podkreślenie autorytetu autora (E-E-A-T)** <br>*(Experience, Expertise, Authority, Trust)* | Treści tworzone i firmowane przez ekspertów są **bardziej cenione przez algorytmy AI** (oraz Google). Wysoki E-E-A-T oznacza, że użytkownik (i AI) ma podstawy ufać informacjom. Dla AI, które nie chcą szerzyć dezinformacji, widok artykułu podpisanego przez inżyniera z doświadczeniem to plus. Podobnie domeny o ugruntowanej reputacji (np. oficjalny blog tech dużej firmy) mają przewagę. | **Dodaj informacje o autorze**: np. krótki bio pod tytułem albo na końcu (kim jesteś, czym się zajmujesz – np. *„Database Engineer z 10-letnim doświadczeniem w firmie X”*). Możesz podlinkować profil LinkedIn, stronę „O mnie” lub inne źródło potwierdzające ekspertyzę. Jeśli publikujesz w ramach strony firmy, rozważ stworzenie profilu autora i strony z jego osiągnięciami. Z punktu widzenia kodu: uwzględnij meta-dane autora (np. w JSON-LD `author.name`, `author.url`). Dodatkowo dbaj o **wysoką jakość treści** – unikalność, poprawność merytoryczną i językową – to wszystko buduje autorytet witryny. |
|
||||
| **Wykorzystanie cytatów i wiedzy ekspertów zewnętrznych** <br>*(Dywersyfikacja źródeł w treści)* | Wplecenie w swoją treść **opinii lub danych od niezależnych autorytetów** (np. ekspertów branżowych, liderów open-source) podnosi wiarygodność materiału. Dla AI to sygnał, że artykuł nie jest jednostronny – zawiera szerszy kontekst. Takie cytaty mogą też zostać **osobno zacytowane** przez AI, zwłaszcza jeśli pochodzą od znanej osoby lub instytucji (np. cytat z dokumentacji PostgreSQL lub z bloga AWS). | Jeżeli to możliwe, dodaj **krótki cytat** z eksperta: np. *„Jak podkreśla Martin Kleppmann, spójność eventual consistency nie gwarantuje odczytu najświeższych danych, ale zapewnia skalowalność.”* – z przypisem/linkiem do źródła wypowiedzi. Możesz też zacytować fragment oficjalnej dokumentacji (w cudzysłowie) – pokażesz w ten sposób, że Twoje porady są zgodne z zaleceniami twórców narzędzia. Pamiętaj, by wyraźnie oznaczyć cytaty i podać ich źródło. |
|
||||
|
||||
### Aktualizacja i utrzymanie treści
|
||||
|
||||
| **Krok / zadanie** | **Dlaczego to ważne** | **Jak to wdrożyć** |
|
||||
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| **Regularna aktualizacja i świeżość contentu** <br>*(„Updated”)* | **Aktualność informacji** to kluczowy czynnik – modele AI (i użytkownicy) preferują treści świeże, aby mieć pewność co do ich poprawności. Strony niedawno zaktualizowane są nawet **3× częściej cytowane przez AI** niż materiały sprzed wielu miesięcy. Ponadto Google SGE wyraźnie oznacza daty – stare daty mogą zniechęcić do kliknięcia. | Ustal harmonogram **przeglądu treści** (np. co kwartał, a w szybko zmieniających tematach co miesiąc). Sprawdzaj, czy wszystkie informacje są aktualne na obecną wersję technologii – jeśli wyszła nowa wersja DB czy biblioteki, zaktualizuj wpis o nowe funkcje, zmień datę „Updated” na górze. **Wyeksponuj datę** ostatniej aktualizacji w widocznym miejscu (np. pod tytułem lub na końcu artykułu). Nawet drobna aktualizacja (typu przepisanie akapitu, dodanie nowej sekcji FAQ) z nową datą podnosi wiarygodność treści w oczach AI i użytkowników. |
|
||||
| **Reagowanie na zmiany i komentarze** <br>*(Cykliczny improvement)* | GEO to proces ciągły – świat technologii się zmienia, a wraz z nim pytania użytkowników. **Elastyczność i reagowanie na feedback** utrzymuje Twoje treści w czołówce. Jeśli na podstawie analizy zauważysz, że AI nie cytuje Twojej strony na określone pytanie – może warto dodać taką informację. | Śledź nowości w swojej dziedzinie (np. zmiany w API, nowe najlepsze praktyki) i **aktualizuj treść ad hoc** gdy wydarzy się coś istotnego. Wykorzystuj też informacje zwrotne: jeśli czytelnicy zadają pytania w komentarzach lub pojawiają się nowe wątki na forach, rozważ rozszerzenie artykułu o te zagadnienia (albo dodaj je do sekcji FAQ). Zapewnienie, że Twoje treści żyją i odpowiadają na najnowsze potrzeby, będzie skutkować długofalowo lepszymi wynikami GEO. |
|
||||
|
||||
### Monitoring i analiza wyników GEO
|
||||
|
||||
| **Krok / zadanie** | **Dlaczego to ważne** | **Jak to wdrożyć** |
|
||||
| ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Śledzenie ruchu z generatywnych AI** <br>*(Analytics AI referral)* | Aby ocenić skuteczność GEO, musisz wiedzieć, **czy i skąd użytkownicy trafiają do Ciebie z odpowiedzi AI**. Inaczej niż SEO (gdzie patrzymy na ruch organiczny z wyszukiwarki), tutaj kluczowe są wizyty z odsyłaczy typu ChatGPT, Bing Chat, Perplexity itp. | W narzędziu analitycznym (Google Analytics, Matomo itp.) **segreguj ruch z AI**. Np. kliknięcia z ChatGPT mają w URL parametr `utm_source=chatgpt` – stwórz filtr/segment, by je zliczać. Ruch z Bing Chat/SGE może pojawiać się jako referer z domen Bing lub Google z parametrami (`gen=...`). Perplexity dodaje własny referer. Analizuj te dane: czy liczba *AI-driven sessions* rośnie? które treści są najczęściej odwiedzane z AI? To bezpośrednia miara, na ile AI „promuje” Twój content. |
|
||||
| **Weryfikacja cytowań i obecności w odpowiedziach** <br>*(Rewizje w AI)* | Sama analityka ruchu to nie wszystko – warto **sprawdzić bezpośrednio, czy AI cytują Twoje treści**. Czasem AI może użyć informacji z Twojej strony **bez generowania kliknięcia** (użytkownik otrzyma odpowiedź i nie wejdzie dalej). Monitorowanie tego pozwoli Ci doszlifować GEO. | Co pewien czas **uruchom „test” w AI**: zapytaj ChatGPT (z wtyczką przeglądarki lub poprzez SGE/Perplexity) o tematy, które pokrywasz. Sprawdź **listę cytowanych źródeł** w odpowiedzi – czy pojawia się Twój artykuł? Jeśli nie, zobacz które konkurencyjne źródła są cytowane. Przeanalizuj je: może mają nowsze dane, inny format? Wyciągnij wnioski i ulepsz swoją treść (np. dodaj brakujące informacje, zmień tytuł na trafniejsze pytanie, itp.). Możesz też skorzystać z narzędzi monitorujących wzmianki (alerty na nazwę domeny w wynikach AI, jeśli takie są dostępne). |
|
||||
| **Ocena zaangażowania użytkowników z AI** <br>*(Jakość ruchu)* | Ruch z AI bywa mniejszy niż klasyczny SEO, ale często to **użytkownicy wysoko zmotywowani** – skoro kliknęli po otrzymaniu odpowiedzi AI, to naprawdę szukają pogłębienia tematu. Warto zatem sprawdzić, czy dostają to, po co przyszli (czas na stronie, bounce rate, konwersje itp.). | Porównaj metryki zachowania użytkowników **przychodzących z AI vs z organicznych wyników**. Czytelnicy od AI prawdopodobnie spędzają więcej czasu na czytaniu (często już wiedzą, że u Ciebie jest odpowiedź, skoro AI ich odesłała). Jeśli jednak widzisz, że szybko wychodzą, to sygnał do poprawek – być może zawartość nie rozwija wystarczająco tematu ponad to, co już zdradziła im AI. Staraj się zapewnić dodatkową wartość: np. **więcej szczegółów, wykresy, demo do pobrania** – coś, czego model AI nie ujął w zwięzłej odpowiedzi. |
|
||||
|
||||
***
|
||||
|
||||
**Na koniec:** Implementacja GEO w treściach technicznych to **połączenie świetnych praktyk SEO, UX i rzetelnej dokumentacji**. Dbaj o **faktyczną wartość merytoryczną** – AI coraz lepiej odróżnia powierzchowny content od eksperckiego. Dzięki powyższej checkliście Twoje artykuły i dokumentacje będą nie tylko wysoko w Google, ale i chętnie cytowane przez modele generatywne, co zwiększy zasięg Twojej wiedzy wśród użytkowników szukających odpowiedzi.
|
||||
@@ -0,0 +1,588 @@
|
||||
# GEO w treściach technicznych – kluczowe praktyki dla inżyniera danych
|
||||
|
||||
**Generative Engine Optimization** (GEO) to zestaw technik, dzięki którym treści stają się **preferowanym źródłem odpowiedzi dla systemów AI** (jak ChatGPT, Perplexity czy Google SGE). W przypadku treści technicznych (dokumentacja, artykuły inżynierskie, wpisy blogowe o bazach danych, poradniki programistyczne, opisy architektury systemów itp.) kluczowe jest pisanie **materiałów o charakterze referencyjnym, bogatych w fakty, przykłady i klarowną strukturę**. Poniżej przedstawiamy najważniejsze praktyki GEO dla treści technicznych – od **natychmiastowych odpowiedzi i definicji**, przez **formatowanie (listy, tabele, kod)**, aż po **cytowanie źródeł, aktualizację i autorytet autora**. Celem jest, by Twoje materiały były dla modeli generatywnych **tym, czym dla tradycyjnego SEO jest pozycja #1 w Google**: zaufanym, często przywoływanym punktem odniesienia. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
|
||||
<!-- Copilot-Researcher-Visualization -->
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--accent: #464feb;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, #b0beff 15%, #b0beff 85%, transparent 100%);
|
||||
--timeline-border: #ffffff;
|
||||
--bg-card: #f5f7fa;
|
||||
--bg-hover: #ebefff;
|
||||
--text-title: #424242;
|
||||
--text-accent: var(--accent);
|
||||
--text-sub: #424242;
|
||||
--radius: 12px;
|
||||
--border: #e0e0e0;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.06);
|
||||
--hover-shadow: 0 4px 14px rgba(39, 16, 16, 0.1);
|
||||
--font: "Segoe Sans", "Segoe UI", "Segoe UI Web (West European)", -apple-system, "system-ui", Roboto, "Helvetica Neue", sans-serif;
|
||||
--overflow-wrap: break-word;
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--accent: #7385ff;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, transparent 3%, #6264a7 30%, #6264a7 50%, transparent 97%, transparent 100%);
|
||||
--timeline-border: #424242;
|
||||
--bg-card: #1a1a1a;
|
||||
--bg-hover: #2a2a2a;
|
||||
--text-title: #ffffff;
|
||||
--text-sub: #ffffff;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.3);
|
||||
--hover-shadow: 0 4px 14px rgba(0, 0, 0, 0.5);
|
||||
--border: #3d3d3d;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-contrast: more),
|
||||
(forced-colors: active) {
|
||||
:root {
|
||||
--accent: ActiveText;
|
||||
--timeline-ln: ActiveText;
|
||||
--timeline-border: Canvas;
|
||||
--bg-card: Canvas;
|
||||
--bg-hover: Canvas;
|
||||
--text-title: CanvasText;
|
||||
--text-sub: CanvasText;
|
||||
--shadow: 0 2px 10px Canvas;
|
||||
--hover-shadow: 0 4px 14px Canvas;
|
||||
--border: ButtonBorder;
|
||||
}
|
||||
}
|
||||
|
||||
.insights-container {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2,minmax(240px,1fr));
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
margin: 0 0;
|
||||
font-family: var(--font);
|
||||
}
|
||||
|
||||
.insight-card:last-child:nth-child(odd){
|
||||
grid-column: 1 / -1;
|
||||
}
|
||||
|
||||
.insight-card {
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
box-shadow: var(--shadow);
|
||||
min-width: 220px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
}
|
||||
|
||||
.insight-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.insight-card h4 {
|
||||
margin: 0px 0px 8px 0px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
font-weight: 600;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.insight-card .icon {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 20px;
|
||||
height: 20px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.insight-card p {
|
||||
font-size: 0.92rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.5;
|
||||
margin: 0px;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.insight-card p b, .insight-card p strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metrics-container {
|
||||
display:grid;
|
||||
grid-template-columns:repeat(2,minmax(210px,1fr));
|
||||
font-family: var(--font);
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.metric-card:last-child:nth-child(odd){
|
||||
grid-column:1 / -1;
|
||||
}
|
||||
|
||||
.metric-card {
|
||||
flex: 1 1 210px;
|
||||
padding: 16px;
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
text-align: center;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.metric-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.metric-card h4 {
|
||||
margin: 0px;
|
||||
font-size: 1rem;
|
||||
color: var(--text-title);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metric-card .metric-card-value {
|
||||
margin: 0px;
|
||||
font-size: 1.4rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.metric-card p {
|
||||
font-size: 0.85rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.45;
|
||||
margin: 0;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.timeline-container {
|
||||
position: relative;
|
||||
margin: 0 0 0 0;
|
||||
padding: 0px 16px 0px 56px;
|
||||
list-style: none;
|
||||
font-family: var(--font);
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: calc(-40px + 56px);
|
||||
width: 2px;
|
||||
height: 100%;
|
||||
background: var(--timeline-ln);
|
||||
}
|
||||
|
||||
.timeline-container > li {
|
||||
position: relative;
|
||||
margin-bottom: 16px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
border-radius: var(--radius);
|
||||
background: var(--bg-card);
|
||||
border: 1px solid var(--border);
|
||||
}
|
||||
|
||||
.timeline-container > li:last-child {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.timeline-container > li:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.timeline-container > li::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 18px;
|
||||
left: -40px;
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
background: var(--accent);
|
||||
border: var(--timeline-border) 2px solid;
|
||||
border-radius: 50%;
|
||||
transform: translateX(-50%);
|
||||
box-shadow: 0px 0px 2px 0px #00000012, 0px 4px 8px 0px #00000014;
|
||||
}
|
||||
|
||||
.timeline-container > li h4 {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
}
|
||||
|
||||
.timeline-container > li h4 em {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
.timeline-container > li * {
|
||||
margin: 0;
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container > li * b, .timeline-container > li * strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
@media (max-width:600px){
|
||||
.metrics-container,
|
||||
.insights-container{
|
||||
grid-template-columns:1fr;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
<div class="insights-container">
|
||||
<div class="insight-card">
|
||||
<h4>Myśl jak twórca dokumentacji</h4>
|
||||
<p>Twórz treści techniczne w formie <b>stabilnych odniesień</b> (referencji): definiuj pojęcia, podawaj checklisty, instrukcje krok-po-kroku, benchmarki, scenariusze „co zrobić, gdy...”. Takie treści – bogate w fakty i porady – są łatwo <b>wychwytywane i cytowane</b> przez systemy AI.</p>
|
||||
</div>
|
||||
<div class="insight-card">
|
||||
<h4>Struktura przyjazna AI</h4>
|
||||
<p>Modele AI preferują <b>zorganizowane treści</b>: wyraźne nagłówki (H2/H3) i następujące po nich konkretne odpowiedzi, krótkie akapity, listy punktowane lub numerowane, tabele. Taka struktura czyni treść w wysokim stopniu <b>„wybieralną” do odpowiedzi</b>.</p>
|
||||
</div>
|
||||
<div class="insight-card">
|
||||
<h4>Zaufanie i aktualność</h4>
|
||||
<p><b>Cytuj źródła, podawaj dane i daty.</b> Modele AI szukają treści wiarygodnych i świeżych – artykuły uzupełnione o źródła i aktualizowane regularnie zdobywają większe zaufanie i są cytowane częściej niż przestarzałe materiały.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Copilot-Researcher-Visualization -->
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--accent: #464feb;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, #b0beff 15%, #b0beff 85%, transparent 100%);
|
||||
--timeline-border: #ffffff;
|
||||
--bg-card: #f5f7fa;
|
||||
--bg-hover: #ebefff;
|
||||
--text-title: #424242;
|
||||
--text-accent: var(--accent);
|
||||
--text-sub: #424242;
|
||||
--radius: 12px;
|
||||
--border: #e0e0e0;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.06);
|
||||
--hover-shadow: 0 4px 14px rgba(39, 16, 16, 0.1);
|
||||
--font: "Segoe Sans", "Segoe UI", "Segoe UI Web (West European)", -apple-system, "system-ui", Roboto, "Helvetica Neue", sans-serif;
|
||||
--overflow-wrap: break-word;
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--accent: #7385ff;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, transparent 3%, #6264a7 30%, #6264a7 50%, transparent 97%, transparent 100%);
|
||||
--timeline-border: #424242;
|
||||
--bg-card: #1a1a1a;
|
||||
--bg-hover: #2a2a2a;
|
||||
--text-title: #ffffff;
|
||||
--text-sub: #ffffff;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.3);
|
||||
--hover-shadow: 0 4px 14px rgba(0, 0, 0, 0.5);
|
||||
--border: #3d3d3d;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-contrast: more),
|
||||
(forced-colors: active) {
|
||||
:root {
|
||||
--accent: ActiveText;
|
||||
--timeline-ln: ActiveText;
|
||||
--timeline-border: Canvas;
|
||||
--bg-card: Canvas;
|
||||
--bg-hover: Canvas;
|
||||
--text-title: CanvasText;
|
||||
--text-sub: CanvasText;
|
||||
--shadow: 0 2px 10px Canvas;
|
||||
--hover-shadow: 0 4px 14px Canvas;
|
||||
--border: ButtonBorder;
|
||||
}
|
||||
}
|
||||
|
||||
.insights-container {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2,minmax(240px,1fr));
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
margin: 0 0;
|
||||
font-family: var(--font);
|
||||
}
|
||||
|
||||
.insight-card:last-child:nth-child(odd){
|
||||
grid-column: 1 / -1;
|
||||
}
|
||||
|
||||
.insight-card {
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
box-shadow: var(--shadow);
|
||||
min-width: 220px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
}
|
||||
|
||||
.insight-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.insight-card h4 {
|
||||
margin: 0px 0px 8px 0px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
font-weight: 600;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.insight-card .icon {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 20px;
|
||||
height: 20px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.insight-card p {
|
||||
font-size: 0.92rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.5;
|
||||
margin: 0px;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.insight-card p b, .insight-card p strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metrics-container {
|
||||
display:grid;
|
||||
grid-template-columns:repeat(2,minmax(210px,1fr));
|
||||
font-family: var(--font);
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.metric-card:last-child:nth-child(odd){
|
||||
grid-column:1 / -1;
|
||||
}
|
||||
|
||||
.metric-card {
|
||||
flex: 1 1 210px;
|
||||
padding: 16px;
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
text-align: center;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.metric-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.metric-card h4 {
|
||||
margin: 0px;
|
||||
font-size: 1rem;
|
||||
color: var(--text-title);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metric-card .metric-card-value {
|
||||
margin: 0px;
|
||||
font-size: 1.4rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.metric-card p {
|
||||
font-size: 0.85rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.45;
|
||||
margin: 0;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.timeline-container {
|
||||
position: relative;
|
||||
margin: 0 0 0 0;
|
||||
padding: 0px 16px 0px 56px;
|
||||
list-style: none;
|
||||
font-family: var(--font);
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: calc(-40px + 56px);
|
||||
width: 2px;
|
||||
height: 100%;
|
||||
background: var(--timeline-ln);
|
||||
}
|
||||
|
||||
.timeline-container > li {
|
||||
position: relative;
|
||||
margin-bottom: 16px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
border-radius: var(--radius);
|
||||
background: var(--bg-card);
|
||||
border: 1px solid var(--border);
|
||||
}
|
||||
|
||||
.timeline-container > li:last-child {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.timeline-container > li:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.timeline-container > li::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 18px;
|
||||
left: -40px;
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
background: var(--accent);
|
||||
border: var(--timeline-border) 2px solid;
|
||||
border-radius: 50%;
|
||||
transform: translateX(-50%);
|
||||
box-shadow: 0px 0px 2px 0px #00000012, 0px 4px 8px 0px #00000014;
|
||||
}
|
||||
|
||||
.timeline-container > li h4 {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
}
|
||||
|
||||
.timeline-container > li h4 em {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
.timeline-container > li * {
|
||||
margin: 0;
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container > li * b, .timeline-container > li * strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
@media (max-width:600px){
|
||||
.metrics-container,
|
||||
.insights-container{
|
||||
grid-template-columns:1fr;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
<div class="metrics-container">
|
||||
<div class="metric-card">
|
||||
<h4>Struktura Q&A a cytowalność</h4>
|
||||
<div class="metric-card-value">+40% <small>szans</small></div>
|
||||
<p>Treści z <b>hierarchią nagłówków (H2→H3) i listami</b> mają ok. 40% większą szansę na cytowanie przez AI niż teksty blokowe.</p>
|
||||
</div>
|
||||
<div class="metric-card">
|
||||
<h4>Siła aktualizacji</h4>
|
||||
<div class="metric-card-value">3,2× <small>wzrost</small></div>
|
||||
<p>Treści <b>zaktualizowane w ciągu ostatnich 30 dni</b> są średnio 3,2 raza częściej cytowane przez systemy AI niż starsze materiały.</p>
|
||||
</div>
|
||||
<div class="metric-card">
|
||||
<h4>Cytowania stron firm</h4>
|
||||
<div class="metric-card-value">9%</div>
|
||||
<p>Tylko ~9% źródeł cytowanych przez modele AI stanowią <b>oficjalne strony firm</b> – reszta to treści niezależne, fora i witryny społecznościowe. Twoje treści muszą więc wybijać się ponad marketing i dostarczać realnej wartości, by były wybierane.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Najważniejsze praktyki GEO w treściach technicznych
|
||||
|
||||
Poniższa tabela podsumowuje kluczowe praktyki GEO oraz ich znaczenie i zastosowanie w kontekście treści technicznych (dokumentacja, poradniki dla inżynierów danych, artykuły o bazach danych, architekturze systemów itp.):
|
||||
|
||||
| **Praktyka GEO** | **Dlaczego działa?** (uzasadnienie) | **Jak zastosować w treściach technicznych?** (wskazówki) |
|
||||
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Natychmiastowa definicja i szybka odpowiedź (Quick Answer)** | *Front-loading* informacji – od razu podajesz sedno odpowiedzi. AI może szybko zidentyfikować i zacytować taką esencję. Dla użytkownika to natychmiastowa wartość. | Zacznij od **2–3-zdaniowego podsumowania** najważniejszej odpowiedzi tuż pod tytułem. Zdefiniuj kluczowe pojęcia – np. „**Co to jest X?** \[krótka definicja]” – takim językiem, jakbyś odpowiadał na pytanie wprost [\[genmark.ai\]](https://www.genmark.ai/resources/learn/chatgpt-optimization). To może być wyróżniona ramka lub pogrubiony akapit na początku strony. |
|
||||
| **Hierarchiczna struktura pytań i odpowiedzi** | Czytelna struktura (H2/H3 jako pytania, poniżej odpowiedzi) pozwala AI łatwo „zrozumieć” Twoją treść. Witryny z prawidłowo zagnieżdżonymi nagłówkami i sekcjami Q\&A są **częściej wybierane przez modele AI** [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success), bo pasują do stylu konwersacyjnych zapytań użytkowników. | **Formułuj nagłówki jako pytania** lub jednoznaczne hasła (np. „Jak skonfigurować replikację w MySQL?”). Pod każdym nagłówkiem od razu udziel konkretnej odpowiedzi (1–3 zdania), a następnie podaj szczegóły techniczne. Taki układ – pytanie → odpowiedź → rozwinięcie – **odzwierciedla strukturę dialogu z AI** [\[genmark.ai\]](https://www.genmark.ai/resources/learn/chatgpt-optimization). |
|
||||
| **Listy punktowane, numerowane i kroki (How-To)** | **Listy i sekwencje kroków** są wysoce czytelne i łatwe do wydobycia. AI często zamienia odpowiedzi na listy kroków lub wypunktowania – jeśli Twoja treść już taką formę ma, model chętniej przywoła ją w całości [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide). Listy porządkują informacje, a dla AI to sygnał, że w tekście są wypisane kluczowe punkty lub instrukcje. | Stosuj listy zawsze, gdy wyliczasz **zalety, funkcje, kroki lub elementy składowe**. Np. prezentując *„5 kroków instalacji bazy danych MySQL”*, użyj listy numerowanej z jasnym opisem każdego etapu. Wymieniając korzyści nowej technologii, użyj list punktowanych. Twórz też **sekcje w formie checklist** (np. *„Lista kontrolna wdrożenia backupu bazy danych”*). |
|
||||
| **Tabele i porównania** | **Tabele porządkują dane** i pozwalają modelowi łatwo zacytować konkretny wiersz lub kolumnę. Dla AI tabela to „zestaw faktów” – np. porównanie parametrów czy wyników testów – który można przytoczyć bez przerabiania formy. Porównania w formie tabel i schematów decyzji ułatwiają też AI udzielanie **precyzyjnych odpowiedzi** (np. „X vs Y”) [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide). | Jeśli opisujesz różne technologie lub opcje, używaj **tabel** do ich porównania (np. kolumny z cechami serwerów baz danych A vs B). Dodawaj wiersze z konkretnymi danymi (np. limit zapytań na sekundę, wsparcie transakcji itp.). Pamiętaj o podpisach i nagłówkach kolumn – AI może rozpoznać kontekst tabeli po tych etykietach. W treściach typu *„X vs Y – porównanie”* umieść podsumowanie różnic w tabeli oraz w formie wypunktowanych *plusów i minusów*. |
|
||||
| **Przykłady kodu i schematów (z objaśnieniami)** | Dla pytań technicznych modele często poszukują **fragmentów kodu lub konfiguracji**, które mogą bezpośrednio przytoczyć jako odpowiedź. Jeżeli Twój artykuł zawiera działający, zrozumiały kod (np. zapytanie SQL, fragment skryptu) z kontekstem, AI chętnie go użyje zamiast generować kod od zera (co bywa zawodne) [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/). Również ilustracje (diagramy architektury, schematy danych) z opisem tekstowym zwiększają **„widoczność”** treści – modele lepiej trawią tekstowy opis diagramu niż sam obrazek. | Dołączaj **fragmenty kodu, zapytań lub konfiguracji** ilustrujące ważne przypadki użycia. Poprzedzaj każdy blok kodu 1–2 zdaniami wyjaśniającymi, *co* on robi i *kiedy* go użyć. Dzięki temu model AI zrozumie kontekst i może zacytować zarówno opis, jak i sam kod. Przykład: przed pokazaniem zrzutu struktury bazy danych (diagramu ERD) dodaj opis: „Poniższy diagram przedstawia schemat bazy danych dla systemu e-commerce, z podziałem na tabele zamówień, klientów i produktów” – to zdanie może zostać zacytowane przez AI wraz z linkiem do Twojej strony. |
|
||||
| **Cytowanie źródeł, dane i aktualność** | **Podpieranie się źródłami** (np. dokumentacją producenta, normami, badaniami) oraz podawanie konkretnych danych buduje **zaufanie** AI do Twojej treści [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/). Model woli zacytować stronę, która wskazuje, skąd czerpie informacje – bo to uwiarygadnia przekaz. Równie ważna jest **aktualność**: treści oznaczone jako niedawno aktualizowane są uznawane za bardziej wiarygodne i bezpieczne do cytowania [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/). | Wpleć w tekst **cytaty i odnośniki** do wiarygodnych źródeł (np. dokumentacja Oracle, artykuły techniczne, wyniki testów). Stosuj przypisy lub linki najlepiej przy **każdej ważnej danej liczbowej** czy definicji. Dodaj na górze lub dole artykułu informację **„Ostatnia aktualizacja: \[data]”** i rzeczywiście uzupełniaj treść na bieżąco (np. co kilka tygodni lub gdy pojawią się nowe wersje narzędzi). Treści aktualizowane częściej zyskują nawet **trzykrotnie wyższy wskaźnik cytowań przez AI** niż te pozostawione bez zmian [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success). |
|
||||
| **Autorytet autora (E-E-A-T) i dane strukturalne** | Systemy AI preferują treści pochodzące od **uznanych ekspertów i serwisów o wysokim autorytecie** – zmniejsza to ryzyko błędu. Kluczowe jest więc wykazanie doświadczenia i wiarygodności: kto jest autorem i jakie ma kompetencje, oraz czy strona wygląda na godną zaufania [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/), [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/). Istotne jest także ułatwienie modelom zadania poprzez **znaczniki schema i semantyczny HTML** – jasno opisane meta-dane o stronie pozwalają AI lepiej zrozumieć, z jakim typem treści ma do czynienia [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide). | Przy **każdym artykule technicznym podawaj autora z imienia i nazwiska**, wraz z krótką notką biograficzną (np. stanowisko, doświadczenie w danej technologii). Wspomnij instytucję lub firmę – treści na oficjalnych blogach technicznych (np. Google Developers Blog, Microsoft Learn) z definicji mają większy autorytet. Z punktu widzenia kodu strony – używaj znaczników **schema.org**: dla artykułów technicznych idealny jest `TechArticle` (odmiana `Article`) lub `BlogPosting`. Dodaj też sekcje FAQ (schema `FAQPage`) czy HowTo, jeśli pasują do treści [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide). Dopilnuj semantycznego HTML (nagłówki, section, code, pre, figure z podpisem itp.), co ułatwi AI ekstrakcję informacji [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide), [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide). |
|
||||
|
||||
## Formaty treści technicznych najchętniej cytowane przez AI
|
||||
|
||||
W dziedzinie inżynierii danych i pokrewnych (programowanie, architektura systemów, DevOps itp.) **największe szanse na bycie zacytowanym** mają takie typy materiałów, które **bezpośrednio odpowiadają na pytania lub dostarczają konkretnych informacji** przydatnych w rozwiązywaniu problemów. Według analiz rynkowych z 2025–2026 r. systemy generatywne najczęściej cytują następujące rodzaje treści: [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide)
|
||||
|
||||
* **Obszerne przewodniki i „ultymatywne” poradniki** – wyczerpujące artykuły (2–5 tys. słów) z podziałem na sekcje, często zawierające spis treści i liczne przykłady. Jeśli faktycznie są bogate merytorycznie i napisane przez eksperta, mogą stać się *kanonicznym* źródłem cytowań o danym zagadnieniu.
|
||||
* **Treści oparte na danych (data-driven)** – publikacje prezentujące wyniki badań własnych, benchmarki wydajności, statystyki branżowe, raporty z testów porównawczych. Unikalne dane liczbowe to magnes na AI, bo stanowią *nową wiedzę*, której nie ma gdzie indziej. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide)
|
||||
* **Instrukcje „How-To” / SOP** – krok-po-kroku wyjaśniają konkretny proces (np. „Jak wdrożyć sharding w MongoDB?”) z ponumerowanymi etapami, zrzutami ekranu/diagramami i poradami co zrobić, gdy coś pójdzie nie tak. Tego typu **proceduralne artykuły** są idealne dla AI, bo odpowiadają dokładnie na pytanie „jak coś zrobić” i zawierają uporządkowane kroki do zacytowania. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide)
|
||||
* **Materiały porównawcze (X vs Y)** – np. porównanie technologii, narzędzi, podejść (SQL vs NoSQL, monolit vs mikroserwisy). Często przybierają formę tabel porównawczych i list *za i przeciw*. AI chętnie przywołuje takie treści, bo użytkownicy często pytają o porównania wprost (np. „Which is better, X or Y?”) i oczekują klarownej odpowiedzi. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide)
|
||||
* **Strony z definicjami pojęć** – np. *„Co to jest eventual consistency?”*, *„Na czym polega algorytm Paxos?”*. Systemy AI wysoko cenią **klarowne, wyczerpujące definicje** z rzetelnym kontekstem i przykładami. Niejednokrotnie ChatGPT czerpie właśnie z definicji na Wikipedii (treści encyklopedyczne to blisko połowa cytowań w ChatGPT). Jeśli więc na swoim blogu wyjaśniasz podstawowe pojęcie, zrób to na poziomie przewodnika: przedstaw *co* oznacza termin, *jak działa*, *dlaczego jest ważny* oraz podaj związane terminy i często zadawane pytania. Taki **kompletny „fragment encyklopedii”** ma dużą szansę stać się preferowanym źródłem AI. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide) [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
|
||||
W praktyce wiele powyższych formatów można łączyć w obrębie jednego większego opracowania. Na przykład **„kompletny przewodnik”** może zawierać definicję, następnie sekcję *how-to*, dalej tabelaryczne porównanie opcji i na końcu FAQ. **Kluczem jest maksymalna przydatność i usystematyzowanie informacji** – tak, by **każdy fragment mógł zostać zacytowany niezależnie** i wciąż stanowił wartościową odpowiedź. Warto przyjąć perspektywę: *czy jeśli ktoś zada pytanie X, to czy mój tekst zawiera akapit lub listę, którą AI mogłoby w odpowiedzi przytoczyć?*
|
||||
|
||||
Co istotne, z analiz wynika, że **treści tworzone przez samych dostawców technologii (firmy) rzadziej trafiają do cytatów AI**, o ile mają charakter czysto marketingowy lub powierzchowny. Generatywne AI wykazują skłonność do sięgania po **niezależne źródła**, fora (np. Reddit) i społeczności developerów, które oferują praktyczne, *szczere* porady i przykłady z życia wzięte. Dla twórcy treści technicznych oznacza to, że **ton i styl powinny być maksymalnie merytoryczne, neutralne i nastawione na pomoc**. Np. **zamiast materiału marketingowego o zaletach Twojego produktu, lepiej sprawdzi się artykuł „Jak rozwiązać problem X za pomocą \[Twoje narzędzie]”** – gdzie pokażesz konkretny kod, wyniki testów, porównanie z innymi rozwiązaniami oraz uczciwie opiszesz ograniczenia. Taka treść będzie atrakcyjniejsza dla czytelników *i* modeli AI. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
|
||||
## Struktura, długość i styl – jak pisać pod AI?
|
||||
|
||||
**Język i styl:** W treściach technicznych kierowanych do systemów AI **jasność i precyzja górują nad kwiecistością stylu**. Zdania powinny być krótkie i pozbawione dwuznaczności – tak, by model mógł je łatwo zinterpretować. Unikaj żargonu branżowego bez wyjaśnienia; **zdefiniuj skróty i terminologię** przy pierwszym użyciu (np. *„OLTP (Online Transaction Processing) to…”*). Zauważono, że AI preferuje styl *neutralny i encyklopedyczny*, zbliżony do tonacji dokumentacji lub Wikipedii. Staraj się pisać bez marketingowego „zabarwienia” – **obiektywnie, w trzeciej osobie**, skupiając się na faktach, a nie opiniach. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
|
||||
**Długość odpowiedzi:** Modele językowe operują na **kontekstach o ograniczonej długości** (zwykle kilka tysięcy tokenów). Dlatego w podejściu GEO zaleca się dostarczać esencję informacji tak wcześnie i zwięźle, jak to możliwe (stąd **quick answer na początku tekstu**). Ogólna wytyczna brzmi: **jedno zagadnienie na sekcję/akapit** i od razu odpowiedź w pierwszym zdaniu. Dopiero potem – szczegóły. Taki *styl odwróconej piramidy* zapewnia, że nawet gdy AI utnie resztę (bo skończył mu się kontekst), to **clue odpowiedzi już zostało wydobyte**. Jeśli chodzi o całościową długość artykułu, dostosuj ją do tematu: proste pytanie (np. definicja pojęcia) może zamknąć się w 500 słowach, ale złożony przewodnik techniczny może mieć i 3000 słów – ważne, by całość była dobrze zorganizowana i podzielona na logiczne części. Dłuższa treść daje szansę odpowiedzieć na więcej potencjalnych pytań (większy *coverage* long-tail), ale **unikaj lania wody** – każda sekcja ma wnosić konkrety. Modele i tak pomijają treści poboczne, szukając konkretnych odpowiedzi. [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/)
|
||||
|
||||
**Struktura strony:** Zastosuj **elementy semantyczne HTML5** zgodnie z przeznaczeniem (nagłówki, sekcje, artykuły, element `<code>` do kodu, `<pre>` do bloków kodu, `<figure>` i `<figcaption>` do ilustracji, itd.). To ułatwia automatom *zrozumienie* Twojej strony. OpenAI zaleca stosowanie np. **znaczników ARIA i semantycznego HTML**, tak jak dla czytników ekranu, aby ich agent mógł lepiej interpretować strukturę strony i elementy interaktywne. W praktyce – **dobrze skonstruowany dokument HTML to dla AI jak czysty kod dla kompilatora**: im mniej szumu i niejednoznaczności, tym większa szansa poprawnej ekstrakcji informacji. Przykładowo, zamiast umieszczać nazwę sekcji jako pogrubiony tekst w `<div>`, użyj prawidłowego `<h2>` wewnątrz semantycznego `<section>` z odpowiednim atrybutem ID. Dla dokumentacji API lub bibliotek programistycznych warto zastosować nawet specjalistyczny typ schema **TechArticle**, a dla instrukcji krok-po-kroku – **HowTo**; w obu przypadkach każdy etap/sekcję powinny mieć własne kotwice (anchor link), by AI mogła bezpośrednio odesłać do konkretnego fragmentu. [\[help.openai.com\]](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide), [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide) [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide)
|
||||
|
||||
## Przykłady dobrze zoptymalizowanych treści GEO (techniczne)
|
||||
|
||||
**1. Dokumentacje oficjalne i bazy wiedzy:** Wiele oficjalnych dokumentacji technicznych (np. dokumentacja MongoDB, PostgreSQL, Microsoft Learn) już stosuje zbliżone praktyki. Mają klarowny podział na sekcje, przykłady kodu, sekcje FAQ, a także znacznik schema (wielu dostawców stosuje `FAQPage` czy `HowTo` w swoich help center). Takie strony są częstym celem cytowań, gdyż **oferują autorytatywne, aktualne informacje, nierzadko wsparte przykładami**. Przykładowo, **Mozilla Developer Network (MDN)** – serwis dokumentujący standardy web – słynie z klarownych definicji i przykładów kodu dla każdej funkcji czy znacznika. Nic dziwnego, że fragmenty z MDN są regularnie wykorzystywane przez modele AI odpowiadające na pytania programistów (co potwierdza też fakt, że Wikipedia i podobne zasoby typu encyklopedycznego dominują w cytowaniach ChatGPT). Innym przykładem jest **strona Stack Overflow lub jej pochodne (Server Fault, DBA StackExchange)** – pojedyncze wątki pytań i odpowiedzi z zaakceptowanym rozwiązaniem stanowią wręcz gotowe moduły wiedzy. Choć treści z forum nie są formalnie oznaczone schema, ich czysta struktura Q\&A sprawia, że narzędzia w stylu Perplexity czy Google SGE często po nie sięgają. Dla Ciebie inspiracją może być format odpowiedzi z Stack Overflow – postaraj się, by Twój artykuł w pewnym sensie *przypominał takie pytanie i najlepszą odpowiedź* (oczywiście bardziej rozbudowaną i bogatszą w kontekst, kody, itp.). [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success) [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
|
||||
**2. Blogi techniczne i artykuły eksperckie:** Niektóre blogi inżynierów i firm technologicznych wyróżniają się dbałością o GEO. Przykładowo, blogi typu *„Engineering at… (Uber/Airbnb/etc.)”* często publikują **case study z konkretnymi danymi i kodem**, z jasno wyodrębnionymi wnioskami. Takie wpisy, jeśli nie są nadmiernie marketingowe, mogą stawać się źródłem cytatów (np. gdy użytkownik pyta o konkretne studium przypadku lub statystykę). Innym wzorem do naśladowania może być cykl artykułów **„PerfPlanet”** (dot. wydajności web) – oprócz tekstu zawierają wykresy, wyniki testów oraz krótkie podsumowania „Key Takeaways”, które AI może łatwo zacytować jako listę najważniejszych wniosków. Jeśli prowadzisz blog techniczny, spróbuj przygotować raz na jakiś czas **głęboką analizę lub test porównawczy** (np. różnych silników baz danych) z oryginalnymi danymi – inne strony prawdopodobnie do Ciebie podlinkują, a i AI chętnie zacytuje unikatowe wyniki.
|
||||
|
||||
**3. Treści społecznościowe i repozytoria kodu:** W przestrzeni inżynierii danych warto zwrócić uwagę na **materiały tworzone przez społeczność** – od wpisów na blogach osobistych, przez odpowiedzi na forum, po **dokumentacje projektów open source na GitHubie**. Często to tam znajdują się cenne fragmenty wiedzy (np. rozwiązanie nietypowego błędu konfiguracyjnego), których próżno szukać w oficjalnych materiałach. Modele AI (szczególnie Perplexity czy Google SGE) aktywnie przeszukują te zasoby – dlatego, jeśli udzielasz się w takich miejscach, **warto dbać o jakość swoich odpowiedzi**. Jeżeli natomiast prowadzisz projekt open source, upewnij się, że **README oraz wiki projektu** wyjaśniają najważniejsze kwestie (cel, sposób użycia, przykłady) w duchu GEO – z sekcją FAQ, wyjaśnieniem kluczowych pojęć, a nawet prostą tabelką „Funkcje i korzyści” czy „Najczęstsze problemy i rozwiązania”. Dobrze zorganizowana dokumentacja open-source’owa może stać się często cytowanym źródłem – zwłaszcza, gdy dotyczy popularnego narzędzia lub biblioteki.
|
||||
|
||||
## Narzędzia i metody analizy skuteczności GEO
|
||||
|
||||
Ocena, czy nasze wysiłki w zakresie GEO przynoszą efekty, wymaga nowych miar i podejścia. W tradycyjnym SEO patrzyliśmy na pozycje w rankingu i ruch organiczny. W świecie GEO kluczowe staje się śledzenie **cytowań i ruchu referencyjnego z AI**. Oto kilka sposobów i narzędzi, które mogą w tym pomóc:
|
||||
|
||||
* **Analityka odwiedzin z AI:** Monitoruj ruch przychodzący z platform AI. OpenAI udostępnia parametr `utm_source=chatgpt.com` w URL, gdy użytkownik kliknie Twój link w wynikach ChatGPT. Możesz więc w Google Analytics czy innym narzędziu sprawdzać sesje z tym parametrem lub z domeny `chat.openai.com`. Podobnie, kliknięcia z **Perplexity.ai** czy **Bing Chat** będą widoczne w logach jako odwołania z tych domen. Obserwuj zmiany w czasie – np. czy **AI-referred sessions** rosną i jak się mają do tradycyjnego ruchu organicznego. [\[help.openai.com\]](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
* **Własne testy w AI:** Narzędziem analizy może być… samo AI. Przykładowo, możesz w Perplexity lub Bing Chat wpisać pytania, na które odpowiada Twoja treść, i sprawdzić, czy wśród cytowanych źródeł pojawia się Twój materiał. Jeśli nie, przeanalizuj które źródła są cytowane – być może zawierają elementy, których Twojej stronie brakuje (np. świeżej daty, konkretnych liczb, listy kroków). **Porównanie się z cytowanymi konkurentami** to cenna wskazówka do dalszej optymalizacji.
|
||||
* **Śledzenie indeksowania przez AI:** Sprawdzaj, czy Twoja strona jest **odwiedzana przez boty AI**. W logach serwera lub w usługach jak Google Search Console/Bing Webmaster możesz wykryć user-agenty typu `GPTBot` (służy głównie do treningu modeli) oraz `OAI-SearchBot` (odpowiedzialny za indeksowanie treści do ChatGPT z włączonym przeszukiwaniem). Jeśli Twoje kluczowe strony nie są regularnie odświeżane przez te boty, upewnij się, że nie są zablokowane w `robots.txt` (powinny być dozwolone dla OAI-SearchBota). Częstotliwość wizyt tych botów (np. **GPTBot odwiedzający co kilka tygodni** vs. codziennie) może pośrednio wskazywać na znaczenie Twojej strony w ekosystemie AI. [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/) [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/) [\[genmark.ai\]](https://www.genmark.ai/resources/learn/chatgpt-optimization), [\[genmark.ai\]](https://www.genmark.ai/resources/learn/chatgpt-optimization)
|
||||
* **Nowe metryki GEO:** Rozważ śledzenie wskaźników takich jak **współczynnik cytowalności** (np. liczba cytatów Twojej strony na 1000 zapytań w danej dziedzinie – choć to trudne do zmierzenia bez dostępu do danych AI). Bardziej praktyczne może być monitorowanie **wzmiankowań marki/produktu przez AI**. Przykładowo, jeśli rozwijasz biblioteki open source, możesz szukać (ręcznie lub przy pomocy narzędzi monitorujących Internet) czy asystenci AI wspominają nazwę Twojego projektu w odpowiedziach. W ten sposób zmierzysz **świadomość Twojego rozwiązania w generowanych odpowiedziach** – coś w rodzaju brand mentions w świecie AI. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
* **Feedback od użytkowników:** Jeśli Twoi czytelnicy trafiają na Twoje treści przez AI, zbieraj od nich informacje zwrotne. Mogą sygnalizować, że *„znaleźli informację o Twoim projekcie w odpowiedzi ChatGPT”* albo że *Perplexity cytowała Twój wpis*. Takie relacje to cenne jakościowe potwierdzenie skuteczności GEO. Możesz także sam zaobserwować dyskusje w sieci (np. na Twitterze czy forach branżowych), gdzie ludzie dzielą się odpowiedziami wygenerowanymi przez AI – jeśli widać tam Twój link, masz dowód sukcesu.
|
||||
|
||||
Na koniec pamiętaj: **Generative Engine Optimization to proces ciągły**. Tak jak w klasycznym SEO śledzisz pozycje i ruch, tak w GEO powinieneś monitorować, czy Twoje treści są regularnie wykorzystywane przez AI. Jeżeli nie – testuj i udoskonalaj. Być może trzeba dodać sekcję FAQ, uzupełnić artykuł o nowsze dane albo przeformułować nagłówki na bardziej opisowe. Kieruj się zasadą, że tworzysz treść nie tylko dla ludzi, ale i dla *„czytającej cię” sztucznej inteligencji*. Dzięki powyższym najlepszym praktykom Twoje artykuły i dokumentacje techniczne mogą stać się **niezastąpionymi „cytatogennymi” źródłami** – takimi, które **AI będzie cytować chętnie i często**, wspierając tym samym promocję Twojej wiedzy, produktów lub projektów wśród milionów użytkowników szukających informacji. [\[strapi.io\]](https://strapi.io/blog/generative-engine-optimization-geo-guide), [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/)
|
||||
|
||||
**Źródła i odniesienia:**
|
||||
|
||||
* Flying Cat Marketing (2024), *The Anatomy of a GEO-Optimized Blog Post* – infografika przedstawiająca strukturę idealnego wpisu GEO.
|
||||
* Bluearray (2023), *SEO for AI: How to Optimize for ChatGPT & AI Search* – omówienie strategii AEO (Answer Engine Optimization) i GEO z perspektywy SEO.
|
||||
* Akselera Tech (2025), *GEO Complete Guide 2026* – kompleksowy przewodnik po GEO, dane rynkowe i praktyki optymalizacyjne. [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success), [\[akselera.tech\]](https://akselera.tech/en/insights/guides/geo-generative-engine-optimization-guide#measuring-geo-success)
|
||||
* RivuletIQ (2025), *How to Get Cited by ChatGPT and Perplexity* – artykuł doradczy nt. GEO, tzw. *citation magnet formats* i różnice GEO vs SEO. [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/), [\[rivuletiq.com\]](https://www.rivuletiq.com/generative-engine-optimization-geo-how-to-get-cited-by-chatgpt-and-perplexity/)
|
||||
* Genmark AI (2025), *ChatGPT Optimization Guide* – praktyczne wskazówki struktury treści pod kątem ChatGPT. [\[genmark.ai\]](https://www.genmark.ai/resources/learn/chatgpt-optimization), [\[genmark.ai\]](https://www.genmark.ai/resources/learn/chatgpt-optimization)
|
||||
* OpenAI (2024–25), *Poradniki dla wydawców* – zalecenia dot. indeksowania treści w ChatGPT (m.in. o robotach OAI i znaczeniu dostępności strony). [\[help.openai.com\]](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/)
|
||||
* SearchEngineJournal (2024), *ChatGPT Search Indexing: Essential Steps* – przegląd technicznych aspektów indeksowania treści przez ChatGPT (rola OAI-SearchBot, znaczenie świeżości contentu). [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/chatgpt-search-indexing-essential-steps-for-websites/531739/)
|
||||
@@ -0,0 +1,317 @@
|
||||
Oto przykładowy plik SKILL.md dla skilla GEO w formacie zgodnym z AgentSkills i OpenClaw:
|
||||
|
||||
````yaml
|
||||
---
|
||||
name: geo-optimizer
|
||||
description: Audyt i optymalizacja treści technicznych pod kątem Generative Engine Optimization (GEO)
|
||||
homepage: https://geo-skill.docs.example.com
|
||||
user-invocable: true
|
||||
disable-model-invocation: false
|
||||
command-dispatch: tool
|
||||
command-tool: geo-audit
|
||||
command-arg-mode: raw
|
||||
metadata:
|
||||
openclaw:
|
||||
requires:
|
||||
bins: ["node", "python3"]
|
||||
env: ["GEO_OPENAI_KEY"]
|
||||
config: ["geo.enabled"]
|
||||
primaryEnv: GEO_OPENAI_KEY
|
||||
---
|
||||
# GEO Optimizer Skill
|
||||
|
||||
Ten skill analizuje i optymalizuje treści techniczne (np. dokumentacje API, artykuły inżynierskie, poradniki) pod kątem **Generative Engine Optimization (GEO)** – czyli zwiększenia szansy na cytowanie przez systemy AI (ChatGPT, Perplexity, Google SGE itp.).
|
||||
|
||||
## Jak używać
|
||||
|
||||
Aby uruchomić skill ręcznie:
|
||||
|
||||
```bash
|
||||
/geo-optimize <ścieżka_do_pliku.md>
|
||||
````
|
||||
|
||||
Skill wykona:
|
||||
|
||||
1. Analizę struktury dokumentu (nagłówki, listy, kod, FAQ).
|
||||
2. Ocenę zgodności z checklistą GEO.
|
||||
3. Wygeneruje raport z rekomendacjami GEO.
|
||||
4. (Opcjonalnie) zaproponuje poprawki: Quick Answer, schema.org JSON-LD, FAQ.
|
||||
5. (Opcjonalnie) zastosuje poprawki automatycznie (jeśli `--apply`).
|
||||
|
||||
## Przykład użycia
|
||||
|
||||
```bash
|
||||
/geo-optimize docs/architektura-baz-danych.md
|
||||
```
|
||||
|
||||
## Parametry
|
||||
|
||||
* `--apply`: automatycznie zastosuj poprawki (jeśli możliwe).
|
||||
* `--report-only`: wygeneruj tylko raport (domyślnie).
|
||||
* `--format=json|markdown`: format raportu (domyślnie: markdown).
|
||||
* `--lang=pl|en`: język raportu (domyślnie: pl).
|
||||
|
||||
## Wymagania
|
||||
|
||||
* Node.js i Python 3 (do przetwarzania treści i generowania JSON-LD).
|
||||
* Klucz API OpenAI (`GEO_OPENAI_KEY`) – do generowania propozycji Quick Answer, FAQ, rewritingu.
|
||||
* Konfiguracja `geo.enabled: true` w `openclaw.json`.
|
||||
|
||||
## Bezpieczeństwo
|
||||
|
||||
* Skill działa w sandboxie.
|
||||
* Nie wysyła danych poufnych do zewnętrznych API.
|
||||
* Wspiera tryb dry-run i loguje wszystkie działania.
|
||||
|
||||
## Autorzy
|
||||
|
||||
Zespół Inżynierii Dokumentacji i AI
|
||||
|
||||
```
|
||||
|
||||
Jeśli chcesz, mogę również przygotować plik `geo-audit.js` lub `geo-audit.py`, który będzie implementował logikę działania skilla zgodnie z opisanym wcześniej planem. Czy chcesz, abym przygotował taki kod?
|
||||
```
|
||||
Oto przykładowy plik geo-audit.js – implementacja skilla GEO dla OpenClaw w Node.js. Skrypt analizuje dokument Markdown lub HTML pod kątem zgodności z najlepszymi praktykami GEO i generuje raport z rekomendacjami.
|
||||
|
||||
📁 Plik: geo-audit.js
|
||||
|
||||
```js
|
||||
#!/usr/bin/env node
|
||||
|
||||
/**
|
||||
* GEO Optimizer Skill – geo-audit.js
|
||||
* Audyt treści technicznych pod kątem Generative Engine Optimization (GEO)
|
||||
* Autor: Zespół Inżynierii Dokumentacji i AI
|
||||
*/
|
||||
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
const { JSDOM } = require('jsdom');
|
||||
const { marked } = require('marked');
|
||||
const { Configuration, OpenAIApi } = require('openai');
|
||||
|
||||
// Konfiguracja środowiska
|
||||
const OPENAI_KEY = process.env.GEO_OPENAI_KEY;
|
||||
const openai = OPENAI_KEY
|
||||
? new OpenAIApi(new Configuration({ apiKey: OPENAI_KEY }))
|
||||
: null;
|
||||
|
||||
// Pomocnicze funkcje
|
||||
function isQuestion(text) {
|
||||
return /\?$/.test(text.trim());
|
||||
}
|
||||
|
||||
function extractQuickAnswer(html) {
|
||||
const dom = new JSDOM(html);
|
||||
const firstParagraph = dom.window.document.querySelector('p');
|
||||
return firstParagraph ? firstParagraph.textContent.trim() : null;
|
||||
}
|
||||
|
||||
function extractHeadings(html) {
|
||||
const dom = new JSDOM(html);
|
||||
const headings = [...dom.window.document.querySelectorAll('h1, h2, h3')];
|
||||
return headings.map(h => ({
|
||||
level: h.tagName,
|
||||
text: h.textContent.trim(),
|
||||
isQuestion: isQuestion(h.textContent),
|
||||
}));
|
||||
}
|
||||
|
||||
function extractLists(html) {
|
||||
const dom = new JSDOM(html);
|
||||
const lists = [...dom.window.document.querySelectorAll('ul, ol')];
|
||||
return lists.length;
|
||||
}
|
||||
|
||||
function extractCodeBlocks(html) {
|
||||
const dom = new JSDOM(html);
|
||||
return [...dom.window.document.querySelectorAll('pre code')].length;
|
||||
}
|
||||
|
||||
function extractFAQ(html) {
|
||||
const dom = new JSDOM(html);
|
||||
const faqs = [...dom.window.document.querySelectorAll('h2, h3')]
|
||||
.filter(h => /faq|najczęściej zadawane/i.test(h.textContent));
|
||||
return faqs.length;
|
||||
}
|
||||
|
||||
async function generateQuickAnswer(text) {
|
||||
if (!openai) return null;
|
||||
const prompt = `Streszcz poniższy tekst w 2-3 zdaniach jako odpowiedź na pytanie:\n\n${text}`;
|
||||
const res = await openai.createChatCompletion({
|
||||
model: 'gpt-4',
|
||||
messages: [{ role: 'user', content: prompt }],
|
||||
temperature: 0.5,
|
||||
});
|
||||
return res.data.choices[0].message.content.trim();
|
||||
}
|
||||
|
||||
// Główna funkcja audytu
|
||||
async function audit(filePath) {
|
||||
const raw = fs.readFileSync(filePath, 'utf-8');
|
||||
const html = marked.parse(raw);
|
||||
|
||||
const headings = extractHeadings(html);
|
||||
const quickAnswer = extractQuickAnswer(html);
|
||||
const lists = extractLists(html);
|
||||
const codeBlocks = extractCodeBlocks(html);
|
||||
const faqCount = extractFAQ(html);
|
||||
|
||||
const report = [];
|
||||
|
||||
// Tytuł jako pytanie
|
||||
if (!headings[0]?.isQuestion) {
|
||||
report.push(`🔶 Tytuł (H1) nie jest pytaniem: "${headings[0]?.text}"`);
|
||||
}
|
||||
|
||||
// Quick Answer
|
||||
if (!quickAnswer || quickAnswer.length > 300) {
|
||||
const suggestion = await generateQuickAnswer(raw.slice(0, 1000));
|
||||
report.push(`🔶 Brak lub zbyt długi Quick Answer. Propozycja:\n> ${suggestion}`);
|
||||
}
|
||||
|
||||
// Listy
|
||||
if (lists < 1) {
|
||||
report.push('🔶 Brak list punktowanych lub numerowanych – rozważ dodanie.');
|
||||
}
|
||||
|
||||
// Kod
|
||||
if (codeBlocks < 1) {
|
||||
report.push('🔶 Brak przykładów kodu – rozważ dodanie fragmentów kodu.');
|
||||
}
|
||||
|
||||
// FAQ
|
||||
if (faqCount < 1) {
|
||||
report.push('🔶 Brak sekcji FAQ – rozważ dodanie najczęstszych pytań i odpowiedzi.');
|
||||
}
|
||||
|
||||
// Podsumowanie
|
||||
console.log(`📄 Audyt GEO: ${path.basename(filePath)}\n`);
|
||||
if (report.length === 0) {
|
||||
console.log('✅ Treść spełnia większość zaleceń GEO. Świetna robota!');
|
||||
} else {
|
||||
report.forEach(r => console.log(r));
|
||||
}
|
||||
}
|
||||
|
||||
// Uruchomienie
|
||||
const args = process.argv.slice(2);
|
||||
if (!args[0]) {
|
||||
console.error('❌ Podaj ścieżkę do pliku Markdown jako argument.');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
audit(args[0]);
|
||||
```
|
||||
|
||||
📦 Wymagania:
|
||||
|
||||
* Node.js
|
||||
* Zainstalowane pakiety: `jsdom`, `marked`, `openai`
|
||||
* Klucz API OpenAI w zmiennej środowiskowej `GEO_OPENAI_KEY` (opcjonalnie)
|
||||
|
||||
🛠 Instalacja zależności:
|
||||
|
||||
```bash
|
||||
npm install jsdom marked openai
|
||||
```
|
||||
|
||||
Czy chcesz, abym przygotował również wersję tego skilla w Pythonie lub dodał obsługę JSON-LD schema.org?
|
||||
Aby uruchomić skrypt geo-audit.js i przeprowadzić audyt treści technicznej pod kątem Generative Engine Optimization (GEO), wykonaj poniższe kroki:
|
||||
|
||||
***
|
||||
|
||||
## ✅ Krok po kroku: Jak uruchomić geo-audit.js
|
||||
|
||||
### 1. Zainstaluj Node.js (jeśli jeszcze nie masz)
|
||||
|
||||
Jeśli nie masz Node.js, pobierz i zainstaluj go ze strony:
|
||||
👉 <https://nodejs.org/>
|
||||
|
||||
Po instalacji sprawdź wersję:
|
||||
|
||||
```bash
|
||||
node -v
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
### 2. Przygotuj katalog skilla
|
||||
|
||||
Utwórz folder na skill GEO, np.:
|
||||
|
||||
```bash
|
||||
mkdir geo-skill
|
||||
cd geo-skill
|
||||
```
|
||||
|
||||
W tym folderze umieść:
|
||||
|
||||
* plik `geo-audit.js` (zawartość podałem wcześniej),
|
||||
* plik `SKILL.md` (zdefiniowany wcześniej),
|
||||
* ewentualnie plik testowy `.md` do analizy (np. `przyklad.md`).
|
||||
|
||||
***
|
||||
|
||||
### 3. Zainstaluj zależności
|
||||
|
||||
W katalogu skilla zainstaluj wymagane biblioteki:
|
||||
|
||||
```bash
|
||||
npm init -y
|
||||
npm install jsdom marked openai
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
### 4. Ustaw klucz OpenAI (opcjonalnie)
|
||||
|
||||
Jeśli chcesz, aby skill generował propozycje Quick Answer lub FAQ, potrzebujesz klucza OpenAI.
|
||||
|
||||
Ustaw go jako zmienną środowiskową:
|
||||
|
||||
```bash
|
||||
export GEO_OPENAI_KEY=sk-... # Twój klucz OpenAI
|
||||
```
|
||||
|
||||
Możesz też dodać go do pliku `.env` i użyć biblioteki dotenv (jeśli chcesz, mogę dodać obsługę dotenv do skryptu).
|
||||
|
||||
***
|
||||
|
||||
### 5. Uruchom audyt
|
||||
|
||||
W katalogu skilla uruchom skrypt z podaniem ścieżki do pliku Markdown:
|
||||
|
||||
```bash
|
||||
node geo-audit.js przyklad.md
|
||||
```
|
||||
|
||||
📄 Wyniki audytu pojawią się w konsoli – będą zawierać rekomendacje GEO, np. brak Quick Answer, brak FAQ, zbyt długie akapity itp.
|
||||
|
||||
***
|
||||
|
||||
## 🔁 Przykład działania
|
||||
|
||||
```bash
|
||||
node geo-audit.js docs/architektura-baz-danych.md
|
||||
```
|
||||
|
||||
Wynik:
|
||||
|
||||
📄 Audyt GEO: architektura-baz-danych.md
|
||||
|
||||
🔶 Tytuł (H1) nie jest pytaniem: "Architektura baz danych w systemach rozproszonych"
|
||||
🔶 Brak lub zbyt długi Quick Answer. Propozycja:
|
||||
> Architektura baz danych w systemach rozproszonych to sposób organizacji danych, który zapewnia skalowalność i odporność na awarie...
|
||||
🔶 Brak sekcji FAQ – rozważ dodanie najczęstszych pytań i odpowiedzi.
|
||||
|
||||
***
|
||||
|
||||
Jeśli chcesz, mogę też przygotować:
|
||||
|
||||
* wersję z automatycznym generowaniem JSON-LD schema.org,
|
||||
* wersję z obsługą plików HTML,
|
||||
* wersję w Pythonie.
|
||||
|
||||
Czy chcesz rozszerzyć ten skill o automatyczne poprawki lub integrację z repozytorium (np. generowanie pull requestów)?
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
# Using Foam
|
||||
|
||||
Foam is a personal knowledge management system built on [Visual Studio Code](https://code.visualstudio.com/) and [GitHub](https://github.com/). It helps you organize research, create discoverable notes, and publish your knowledge.
|
||||
|
||||
> See also [[frequently-asked-questions]].
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Wikilinks** - Connect thoughts with `[[double bracket]]` syntax
|
||||
- **Block anchors** - Link or embed specific paragraphs, list items, and headings with `[[note#^id]]`
|
||||
- **Embeds** - Include content from other notes with `![[note]]` syntax
|
||||
- **Backlinks** - Automatically discover connections between notes
|
||||
- **Graph visualization** - See your knowledge network visually
|
||||
- **Daily notes** - Capture timestamped thoughts
|
||||
- **Templates** - Standardize note creation
|
||||
- **Tags** - Organize and filter content
|
||||
|
||||
## Why Choose Foam?
|
||||
|
||||
- **Free and open source** - No subscriptions or vendor lock-in
|
||||
- **Own your data** - Notes stored as standard Markdown files
|
||||
- **VS Code integration** - Leverage powerful editing and extensions
|
||||
- **Git-based** - Version control and collaboration built-in
|
||||
|
||||
Foam is like a bathtub: _What you get out of it depends on what you put into it._
|
||||
|
||||
## Getting Started
|
||||
|
||||
- [[installation]]
|
||||
- [[get-started-with-vscode]]
|
||||
- [[recommended-extensions]]
|
||||
- [[first-workspace]]
|
||||
- [[note-taking-in-foam]]
|
||||
- [[sync-notes]]
|
||||
- [[keyboard-shortcuts]]
|
||||
|
||||
## Features
|
||||
|
||||
- [[wikilinks]]
|
||||
- [[block-anchors]]
|
||||
- [[embeds]]
|
||||
- [[foam-queries]]
|
||||
- [[tags]]
|
||||
- [[backlinking]]
|
||||
- [[daily-notes]]
|
||||
- [[spell-checking]]
|
||||
- [[graph-view]]
|
||||
- [[note-properties]]
|
||||
- [[templates]]
|
||||
- [[paste-images-from-clipboard]]
|
||||
- [[custom-markdown-preview-styles]]
|
||||
- [[link-reference-definitions]]
|
||||
- [[custom-snippets]]
|
||||
|
||||
## Recipes
|
||||
|
||||
[[recipes]] is a collection of user-contributed patterns that describe different ways you could utilize Foam or integrate it with other tools.
|
||||
|
||||
## Publishing
|
||||
|
||||
You can publish your Foam notes for consumption in different formats.
|
||||
Examples: [[publish-to-github-pages]], [[generate-gatsby-site]], [[publish-to-vercel]]
|
||||
|
||||
See [[publishing]] for more details.
|
||||
|
||||
## Tools
|
||||
|
||||
- [[cli]]
|
||||
- [[workspace-janitor]]
|
||||
- [[orphans]]
|
||||
- [[foam-logging-in-vscode]]
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
# Raport Inwentaryzacji Projektu: DBAdmin
|
||||
**Data:** 14 maja 2026 r.
|
||||
**Status:** Aktywny / Dokumentacyjny
|
||||
|
||||
## 1. Cel Projektu
|
||||
Projekt służy jako środowisko pracy i baza wiedzy dla **Agenta Senior DBA (Starszego Administratora Baz Danych)**. Integruje on standardy operacyjne, dzienniki pracy, zasoby edukacyjne oraz narzędzia automatyzacji (skille) w celu optymalizacji zarządzania systemami bazodanowymi.
|
||||
|
||||
## 2. Architektura Folderów
|
||||
|
||||
| Folder | Opis i Zawartość |
|
||||
| :--- | :--- |
|
||||
| `docs/` | **Rdzeń dokumentacji.** Zawiera standardy bezpieczeństwa, workflowy, checklisty oraz specyfikacje (np. OpenClaw). Znajdują się tu również materiały dotyczące SEO/GEO. |
|
||||
| `journals/` | **Historia operacyjna.** Codzienne notatki (dzienniki), raporty z incydentów (`incidents/`) oraz protokoły ze spotkań (`meetings/`). Aktywnie prowadzony do maja 2026. |
|
||||
| `inbox/` | **Strefa zrzutu i szkiców.** Ogromna kolekcja artykułów, notatek, projektów (np. PaperClip) i materiałów do przetworzenia. Miejsce o największej entropii. |
|
||||
| `skills/` | **Rozszerzenia agenta.** Definicje MCP (Model Context Protocol) i specyficzne skille (np. `dbadmin.skill`, `my-suite-report`). |
|
||||
| `kanban/` | **Zarządzanie zadaniami.** Wizualna struktura zadań w formacie YAML/Markdown. |
|
||||
| `archive/` | **Zasoby historyczne.** Starsze dokumenty, w tym materiały dotyczące NASA i OpenClaw. |
|
||||
| `brain/` | **Baza wiedzy (Second Brain).** Prawdopodobnie powiązane z metodologią Zettelkasten lub Foam. |
|
||||
| `scripts/` | **Automatyzacja.** Miejsce na skrypty pomocnicze (obecnie mało zasiedlone). |
|
||||
|
||||
## 3. Kluczowe Komponenty
|
||||
|
||||
- **`README.md`**: Definiuje personę Senior DBA, zasady "Security First" oraz ogólną strukturę.
|
||||
- **`todo.md`**: Lista zaległych zadań i linków do zewnętrznych zasobów (skille Claude/Gemini).
|
||||
- **`skills/dbadmin.skill`**: Kluczowy plik definiujący zachowanie i możliwości agenta.
|
||||
- **`journals/inbox.md`**: Centralny, bardzo obszerny plik logów/notatek (ponad 400KB).
|
||||
|
||||
## 4. Statystyki Projektu (szacunkowe)
|
||||
- **Liczba plików Markdown:** >100
|
||||
- **Aktywne skille:** 5-6 zestawów.
|
||||
- **Główne systemy bazodanowe w zakresie:** MSSQL, MySQL, MariaDB, PostgreSQL, MongoDB, OracleDB.
|
||||
|
||||
## 5. Obserwacje i Rekomendacje
|
||||
- **Wysoka aktywność:** Projekt jest codziennie aktualizowany (folder `journals`).
|
||||
- **Rozproszenie w `inbox/`**: Folder `inbox` zawiera bardzo dużo nieposegregowanych informacji, które mogłyby zostać przeniesione do `docs/` lub `archive/`.
|
||||
- **Integracja ze skillami**: Projekt jest przygotowany pod zaawansowaną współpracę z LLM poprzez zdefiniowane `skills`.
|
||||
|
||||
---
|
||||
*Raport wygenerowany automatycznie przez Gemini CLI.*
|
||||
@@ -0,0 +1,431 @@
|
||||
# Plan wdrożenia skilla **GEO** dla platformy OpenClaw
|
||||
|
||||
**Podsumowanie:** Celem skilla **Generative Engine Optimization (GEO)** w OpenClaw jest **automatyczne wsparcie optymalizacji treści technicznych** (dokumentacji, artykułów inżynierskich, poradników itp.) pod kątem bycia cytowanymi przez systemy AI (ChatGPT, Perplexity, Google SGE, itp.). Skill ten działa jako moduł analityczno-doradczy: **analizuje strukturę i zawartość treści, sugeruje ulepszenia** (np. dodanie sekcji Q\&A, uzupełnienie schematu danych, wstawienie brakujących cytowań) oraz **weryfikuje zgodność** z najlepszymi praktykami GEO. Dzięki integracji z OpenClaw, narzędzie to może być wykorzystywane przez agentów AI w procesach CI/CD dokumentacji lub na żądanie – zapewniając, że każda publikowana treść jest **czytelna dla modeli generatywnych i uważana przez nie za wiarygodną**. [\[expansedigital.co\]](https://www.expansedigital.co/post/geo-generative-engine-optimization-the-complete-guide-for-2026), [\[expansedigital.co\]](https://www.expansedigital.co/post/geo-generative-engine-optimization-the-complete-guide-for-2026)
|
||||
|
||||
Kluczowe założenia skilla GEO:
|
||||
|
||||
<!-- Copilot-Researcher-Visualization -->
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--accent: #464feb;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, #b0beff 15%, #b0beff 85%, transparent 100%);
|
||||
--timeline-border: #ffffff;
|
||||
--bg-card: #f5f7fa;
|
||||
--bg-hover: #ebefff;
|
||||
--text-title: #424242;
|
||||
--text-accent: var(--accent);
|
||||
--text-sub: #424242;
|
||||
--radius: 12px;
|
||||
--border: #e0e0e0;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.06);
|
||||
--hover-shadow: 0 4px 14px rgba(39, 16, 16, 0.1);
|
||||
--font: "Segoe Sans", "Segoe UI", "Segoe UI Web (West European)", -apple-system, "system-ui", Roboto, "Helvetica Neue", sans-serif;
|
||||
--overflow-wrap: break-word;
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--accent: #7385ff;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, transparent 3%, #6264a7 30%, #6264a7 50%, transparent 97%, transparent 100%);
|
||||
--timeline-border: #424242;
|
||||
--bg-card: #1a1a1a;
|
||||
--bg-hover: #2a2a2a;
|
||||
--text-title: #ffffff;
|
||||
--text-sub: #ffffff;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.3);
|
||||
--hover-shadow: 0 4px 14px rgba(0, 0, 0, 0.5);
|
||||
--border: #3d3d3d;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-contrast: more),
|
||||
(forced-colors: active) {
|
||||
:root {
|
||||
--accent: ActiveText;
|
||||
--timeline-ln: ActiveText;
|
||||
--timeline-border: Canvas;
|
||||
--bg-card: Canvas;
|
||||
--bg-hover: Canvas;
|
||||
--text-title: CanvasText;
|
||||
--text-sub: CanvasText;
|
||||
--shadow: 0 2px 10px Canvas;
|
||||
--hover-shadow: 0 4px 14px Canvas;
|
||||
--border: ButtonBorder;
|
||||
}
|
||||
}
|
||||
|
||||
.insights-container {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2,minmax(240px,1fr));
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
margin: 0 0;
|
||||
font-family: var(--font);
|
||||
}
|
||||
|
||||
.insight-card:last-child:nth-child(odd){
|
||||
grid-column: 1 / -1;
|
||||
}
|
||||
|
||||
.insight-card {
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
box-shadow: var(--shadow);
|
||||
min-width: 220px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
}
|
||||
|
||||
.insight-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.insight-card h4 {
|
||||
margin: 0px 0px 8px 0px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
font-weight: 600;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.insight-card .icon {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 20px;
|
||||
height: 20px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.insight-card p {
|
||||
font-size: 0.92rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.5;
|
||||
margin: 0px;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.insight-card p b, .insight-card p strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metrics-container {
|
||||
display:grid;
|
||||
grid-template-columns:repeat(2,minmax(210px,1fr));
|
||||
font-family: var(--font);
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.metric-card:last-child:nth-child(odd){
|
||||
grid-column:1 / -1;
|
||||
}
|
||||
|
||||
.metric-card {
|
||||
flex: 1 1 210px;
|
||||
padding: 16px;
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
text-align: center;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.metric-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.metric-card h4 {
|
||||
margin: 0px;
|
||||
font-size: 1rem;
|
||||
color: var(--text-title);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metric-card .metric-card-value {
|
||||
margin: 0px;
|
||||
font-size: 1.4rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.metric-card p {
|
||||
font-size: 0.85rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.45;
|
||||
margin: 0;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.timeline-container {
|
||||
position: relative;
|
||||
margin: 0 0 0 0;
|
||||
padding: 0px 16px 0px 56px;
|
||||
list-style: none;
|
||||
font-family: var(--font);
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: calc(-40px + 56px);
|
||||
width: 2px;
|
||||
height: 100%;
|
||||
background: var(--timeline-ln);
|
||||
}
|
||||
|
||||
.timeline-container > li {
|
||||
position: relative;
|
||||
margin-bottom: 16px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
border-radius: var(--radius);
|
||||
background: var(--bg-card);
|
||||
border: 1px solid var(--border);
|
||||
}
|
||||
|
||||
.timeline-container > li:last-child {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.timeline-container > li:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.timeline-container > li::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 18px;
|
||||
left: -40px;
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
background: var(--accent);
|
||||
border: var(--timeline-border) 2px solid;
|
||||
border-radius: 50%;
|
||||
transform: translateX(-50%);
|
||||
box-shadow: 0px 0px 2px 0px #00000012, 0px 4px 8px 0px #00000014;
|
||||
}
|
||||
|
||||
.timeline-container > li h4 {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
}
|
||||
|
||||
.timeline-container > li h4 em {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
.timeline-container > li * {
|
||||
margin: 0;
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container > li * b, .timeline-container > li * strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
@media (max-width:600px){
|
||||
.metrics-container,
|
||||
.insights-container{
|
||||
grid-template-columns:1fr;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
<div class="insights-container">
|
||||
<div class="insight-card">
|
||||
<h4>AI-first content</h4>
|
||||
<p>Skill GEO wymusza styl <b>AI-first</b>: treść od razu odpowiada na pytania, jest zwięzła i ustrukturyzowana (nagłówki, listy, kod). Taki format treści jest łatwiej przyswajalny i cytowany przez modele AI.</p>
|
||||
</div>
|
||||
<div class="insight-card">
|
||||
<h4>Autonomiczna analiza</h4>
|
||||
<p>Komponent analizujący treść rozpoznaje <b>braki GEO</b> (np. brak sekcji FAQ, brak danych strukturalnych) i może automatycznie generować zalecenia lub uzupełnienia (np. wygenerować JSON-LD schema czy streszczenie Quick Answer). Wykorzystuje do tego zarówno reguły, jak i integracje z API (np. LLM OpenAI).</p>
|
||||
</div>
|
||||
<div class="insight-card">
|
||||
<h4>Feedback i ciągłe doskonalenie</h4>
|
||||
<p>Skill monitoruje <b>skuteczność GEO</b>: śledzi, czy treści są cytowane przez AI (np. analizując ruch z ChatGPT), i udostępnia dane do dalszej poprawy. Dzięki temu mechanizm GEO staje się procesem ciągłym – treści są regularnie aktualizowane i weryfikowane by utrzymać wysoką <em>„cytowalność”</em>.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
***
|
||||
|
||||
## 1. Architektura i komponenty skilla GEO
|
||||
|
||||
Skill GEO zostanie zrealizowany jako **moduł AgentSkills** kompatybilny z OpenClaw – czyli osobny folder zawierający plik `SKILL.md` z definicją umiejętności (YAML + instrukcje). Architektura skilla jest modularna, aby łatwo integrować go z agentami i zewnętrznymi usługami. Poniżej przedstawiono główne **komponenty skilla GEO** i ich funkcje:
|
||||
|
||||
| **Komponent skilla** | **Rola / Funkcja** |
|
||||
| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Moduł wejściowy (Input Handler)** | Odbiera treści do analizy: może to być ścieżka do pliku, URL, lub obiekt dokumentu przekazany agentowi. Normalizuje dane wejściowe (usuwa znaczniki zbędne, konwertuje formaty – np. Markdown → HTML). Przygotowuje strukturę dokumentu do dalszej analizy. |
|
||||
| **Analizator struktury treści** | Analizuje dokument pod kątem elementów GEO: identyfikuje nagłówki (H1–H3), akapity, listy, tabele, bloki kodu. Sprawdza, czy obecne są kluczowe sekcje (definicja na początku, **Quick Answer**, FAQ, itp.). Wykrywa brakujące lub suboptymalne elementy, np. brak definicji wstępnej czy zbyt długie akapity [\[expansedigital.co\]](https://www.expansedigital.co/post/geo-generative-engine-optimization-the-complete-guide-for-2026). Wykorzystuje przy tym reguły z checklisty GEO (np. akapit > 5 zdań = ostrzeżenie). |
|
||||
| **Analizator treści semantycznej** | Ocenia **merytoryczną** stronę tekstu: czy główne pytanie jest jasno sformułowane i odpowiedź pojawia się na początku, czy użyto prostego języka, czy treść odpowiada na popularne pytania poboczne. Tutaj możliwa jest integracja z modelami językowymi (np. wywołanie OpenAI GPT z prośbą o streszczenie treści i porównanie go z założonym celem). Ten komponent może wykrywać luki: np. brak przykładu kodu tam, gdzie to wskazane, albo pominięcie ważnego tematu w FAQ. |
|
||||
| **Generator ulepszeń (Enhancer)** | Odpowiada za **proponowanie i generowanie poprawek** do treści. Na podstawie analizy struktury i semantyki przygotowuje listę rekomendacji GEO (np. „Dodaj sekcję FAQ z pytaniami X, Y”, „Skróć zdania w akapicie 3”, „Dodaj tabelę porównawczą funkcji A i B”). Wykorzystuje też integrację z LLM do wygenerowania **propozycji** brakujących elementów: np. wygenerowanie przykładowego *Quick Answer*, sformułowanie propozycji tytułu-pytania jeśli obecny tytuł jest opisowy, utworzenie szkicu JSON-LD schema.org na podstawie danych strony. |
|
||||
| **Moduł danych strukturalnych** | Odpowiada za obsługę **schema markup** i innych danych strukturalnych. Sprawdza, czy w dokumencie istnieją znaczniki schema (np. `FAQPage`, `TechArticle`), a jeśli nie – generator potrafi je wygenerować na podstawie treści (np. listy Q\&A przerobić na JSON-LD). Ten komponent waliduje też poprawność danych strukturalnych (np. użycie właściwych atrybutów schema.org, zgodność z wytycznymi Google). |
|
||||
| **Monitor cytowań i ruchu (Tracker)** | Komponent działający w trybie ciągłym lub okresowym, monitorujący **efekty GEO** po wdrożeniu treści. Zbiera dane o ruchu z AI (np. analizując logi serwera pod kątem odwołań z `chat.openai.com` czy `bing.com/new`), lub korzysta z API/SDK dostarczanych przez platformy (jeśli dostępne) do sprawdzania, czy dokument jest cytowany. Dane te zapisywane są w bazie lub logach analitycznych. Tracker może też okresowo odpalać testy (np. pytać ChatGPT/Perplexity o pewne zagadnienia i sprawdzać, czy zwrócą naszą stronę w źródłach – to realizowane ostrożnie, np. poprzez dedykowane API lub scraping wyników). |
|
||||
| **Interfejs wyniku (Output/Report)** | Przygotowuje **raport z analizy GEO** lub wprowadza automatyczne zmiany. W trybie „doradczym” komponent ten generuje raport (np. w formacie Markdown lub HTML) z listą znalezionych problemów i sugestii, który agent może przekazać autorowi treści. W trybie „autonomicznym” – może modyfikować treść bezpośrednio (np. wygenerować PR do repozytorium dokumentacji z poprawkami, lub poprzez API CMS-u zaktualizować stronę). Interfejs ten dba również o logowanie działań (audit log), aby każda zmiana/propozycja była rejestrowana. |
|
||||
| **Warstwa integracji i bezpieczeństwa** | Odpowiada za komunikację skilla z platformą OpenClaw i otoczeniem. Realizuje obsługę wywołań (np. **slash-command** użytkownika lub zdarzenia webhook), zarządza kolejką zadań (gdy wiele dokumentów jest w analizie) i utrzymuje parametry bezpieczeństwa. Ta warstwa sprawdza uprawnienia (czy agent ma dostęp do danego dokumentu), maskuje lub anonimizuje wrażliwe dane przed wysłaniem ich do usług zewnętrznych, oraz korzysta z mechanizmów sandbox OpenClaw dla potencjalnie niebezpiecznych operacji (np. wykonywanie kodu, wołanie API z kluczami) [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills), [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills). Także integruje konfigurację – np. klucze API w zmiennych środowiskowych (`metadata.openclaw.requires.env`) i warunki ładowania skilla (np. tylko w środowiskach z dostępem do internetu). |
|
||||
|
||||
*(Tabela 1. Główne komponenty skilla GEO i ich zadania.)*
|
||||
|
||||
**Architektura wewnętrzna** skilla zakłada więc **pipeline przetwarzania treści**: od wejścia → analiza → generowanie rekomendacji/ulepszeń → wyjście (raport lub auto-poprawki), z dodatkowymi usługami (monitoring, integracje). Całość zostanie opisana w `SKILL.md` zgodnie ze specyfikacją AgentSkills, co umożliwi agentom OpenClaw korzystanie z tej funkcjonalności w sposób deklaratywny. Instrukcje w `SKILL.md` będą definiowały kolejno kroki, np.: załaduj dokument, wykonaj analizę strukturalną, jeśli braki – wygeneruj zalecenia, itp., posługując się dostępnymi narzędziami OpenClaw (parser HTML, interfejs LLM, moduł do edycji plików itp.). Dzięki takiemu podejściu, skill może działać zarówno jako **automatyczny audytor** treści (wyzwalany zdarzeniowo), jak i **interaktywny asystent** (na żądanie użytkownika, np. komendą „/geo-optimize”).
|
||||
|
||||
## 2. Integracja skilla z platformą OpenClaw
|
||||
|
||||
Aby skill GEO efektywnie współpracował z agentami OpenClaw, należy przewidzieć kilka mechanizmów integracji:
|
||||
|
||||
* **Rejestracja skilla:** Skill zostanie zainstalowany jako **oddzielny moduł** w ekosystemie OpenClaw (np. poprzez `clawhub install geo-skill`). Dzięki temu dostępny będzie globalnie lub w konkretnym workspace agenta. Plik `SKILL.md` określi m.in. `name` (np. „geo-optimizer”), opis, ewentualne wymagania (np. dostępność klucza OpenAI API jako `GEO_OPENAI_KEY` w konfiguracji), oraz to, czy skill może być wywoływany przez model (dopóki jest w fazie testów, można ustawić `user-invocable: true, disable-model-invocation: true` aby tylko człowiek mógł go wyzwolić ręcznie). [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)
|
||||
|
||||
* **Interfejs wywołania:** Skill będzie można uruchomić **ręcznie** (np. komenda tekstowa agenta: `/geo-optimize <nazwa_pliku>`), a także **programowo** poprzez API OpenClaw lub wyzwalacz zdarzeń. OpenClaw obsługuje wywołania skilli w ramach planów działania agentów – np. agent otrzymując zadanie „Sprawdź ten artykuł pod GEO” użyje skilla GEO by to wykonać. Alternatywnie, integracja może nastąpić poprzez **webhooki lub kolejki**: przykładowo, po każdym wdrożeniu nowego artykułu w CMS, można wysłać webhook do OpenClaw, który w odpowiedzi odpali skill GEO dla URL-a nowej treści (OpenClaw pozwala na nasłuchiwanie webhooków i mapowanie ich na akcje agenta). W środowiskach continuous integration można dodać krok, który wykorzysta API OpenClaw do zlecenia audytu GEO każdej zmiany w dokumentacji.
|
||||
|
||||
* **Wejścia i wyjścia:** Skill będzie przyjmował jako wejście identyfikator treści – może to być ścieżka pliku Markdown/HTML w repozytorium, URL strony, lub bezpośrednio tekst (OpenClaw potrafi przekazywać pliki lub bufor tekstowy do skilla). Wyjście skilla to z kolei raport i/lub zmodyfikowana treść. W trybie tylko-raportującym, agent może wynik przedstawić autorowi (np. w interfejsie chat wyświetlić listę zaleceń lub załączyć plik Markdown z raportem). W trybie automatycznym, skill może wygenerować **pull request** do repozytorium (gdy dokumentacja jest utrzymywana w kontroli wersji) zawierający poprawki, bądź skorzystać z API platformy (np. REST CMS-a) do naniesienia zmian.
|
||||
|
||||
* **Harmonogram i kolejkowanie:** Jeśli oczekujemy regularnych audytów (np. co miesiąc ponowna weryfikacja całej bazy wiedzy), można użyć mechanizmu **harmonogramu OpenClaw** (konfiguracja agenta do wywoływania konkretnego skilla w zadanym interwale). Ewentualnie, gdy do przeanalizowania jest wiele dokumentów jednocześnie, agent może wykorzystać **kolejkę zadań** – skill GEO jest zaprojektowany tak, by wykonywać analizę dokument po dokumencie; OpenClaw może kolejkować te wywołania bądź uruchamiać instancje równolegle w ramach zasobów. Ważne jest zarządzanie obciążeniem: integracja powinna uwzględnić np. limit jednoczesnych wywołań skilla GEO, aby nie przekroczyć limitów API (OpenAI) lub nie zmonopolizować CPU przy parserze HTML itp. (można to skonfigurować w `openclaw.json`, sekcja `skills.concurrentLimit` dla danego skilla).
|
||||
|
||||
* **Współpraca z innymi skillami:** OpenClaw posiada wiele gotowych skilli (np. do web scrapingu, do analiz SEO, do obsługi GitHub itp.). Skill GEO może **wykorzystywać inne skill-komponenty** za pośrednictwem mechanizmów agentowych. Przykład: zamiast samodzielnie pisać logikę do pobierania strony WWW, skill GEO może wywołać istniejący skill „WebFetch” aby pobrać treść z URL, lub skill „GitAgent” by zaktualizować plik w repozytorium. Architekturę przewidujemy elastyczną – tam gdzie możliwe, korzystamy z istniejących narzędzi OpenClaw (np. narzędzia do analizy SEO, parser Markdown, modul do wysyłki email z raportem), aby uniknąć duplikacji funkcji. `SKILL.md` pozwala w swoich instrukcjach sekwencyjnie korzystać z takich narzędzi i warunków, tworząc **mini-program** sterujący wykonaniem skilla.
|
||||
|
||||
**Przykład integracji przepływu:** Firma może ustalić, że **przed publikacją** nowego artykułu w blogu technicznym, autor wywołuje agenta OpenClaw komendą “`/geo-optimize draft.md`”. Agent używa skilla GEO, który analizuje plik `draft.md` i zwraca autorowi raport z rekomendacjami. Autor nanosi poprawki i publikuje treść. Następnie, po 30 dniach od publikacji, inny proces (harmonogram lub osoba) ponownie uruchamia skill GEO na tej treści, aby upewnić się, że nadal spełnia ona aktualne wymogi (w razie potrzeby agent wygeneruje kolejny raport lub automatycznie uaktualni datę „Updated” w artykule). Taki **workflow integruje skilla** w cykl życia treści.
|
||||
|
||||
## 3. Sposób działania skilla (przebieg przetwarzania)
|
||||
|
||||
Poniżej opisano krok po kroku, jak skill GEO **działa po wywołaniu** – czyli jak realizuje audyt i ewentualną optymalizację przekazanej treści:
|
||||
|
||||
1. **Pobranie treści:** Skill otrzymuje od OpenClaw wskazaną treść – np. plik Markdown lub HTML. Jeśli wejściem jest plik źródłowy (Markdown), skill dokonuje konwersji do HTML (by ułatwić analizę struktury). Jeśli wejściem jest URL, wykorzystuje internalne narzędzie do pobrania strony. Rezultatem jest **ustandaryzowany HTML DOM** reprezentujący dokument.
|
||||
|
||||
2. **Analiza strukturalna:** Silnik przegląda DOM, wyodrębnia tytuł, sekcje, nagłówki, listy, tabele, bloki kodu. Tworzy mapę dokumentu: np. `H1 = "Jak skonfigurować X"; paragrafy pod H1; H2 = "Co to jest X?"; paragrafy...` etc. Weryfikuje obecność kluczowych elementów:
|
||||
|
||||
* Czy tytuł wygląda na pytanie? (jeśli nie – flaguje to do rekomendacji).
|
||||
* Czy zaraz pod tytułem jest zwięzła odpowiedź (Quick Answer)? (brak = do dodania).
|
||||
* Czy występują sekcje FAQ na końcu? (jeśli nie – zaleci utworzenie).
|
||||
* Czy w tekście są listy wypunktowane/numerowane oraz tabele? (jeśli brak, a temat by zyskał na tym – zaleci dodanie list/tabel).
|
||||
* Czy akapity nie są zbyt rozwlekłe? (np. >4 zdań – do uproszczenia).
|
||||
* Czy są wyróżnione definicje pojęć, ewentualnie cytaty ekspertów?
|
||||
* Czy na górze/opodzie strony widnieje data publikacji/aktualizacji? (jeśli brak lub bardzo stara – zaznaczy do aktualizacji, ponieważ świeżość to ważny czynnik GEO).
|
||||
|
||||
W tym kroku powstaje **lista znalezisk** (checklista różnic względem idealnej struktury GEO). Np.: *„Brak sekcji FAQ”, „Nagłówek H1 nie jest pytaniem (jest stwierdzeniem)”, „Brakuje szybkiej odpowiedzi pod tytułem”, „Stwierdzono długie zdania w sekcji 2.1”* etc.
|
||||
|
||||
3. **Analiza treści i jakości:** Teraz skill sprawdza **zawartość merytoryczną**:
|
||||
* **Pokrycie pytań użytkowników:** Korzystając ze zgromadzonych danych (np. listy typowych pytań z FAQ, czy tytuł), skill może **skonsultować zewnętrzne źródła** by upewnić się, że artykuł odpowiada na popularne pytania. Przykładowo, może wykonać zapytanie do bazy wiedzy (lub nawet do ChatGPT) typu: „Jakie pytania zadają deweloperzy o X?” – i porównać, czy nasz artykuł gdzieś udziela na nie odpowiedzi. Jeśli np. artykuł o konfiguracji MySQL nie porusza pytania „Jaką wersję MySQL wybrać?” a model/analiza sugeruje, że to częste pytanie – skill zarekomenduje dodanie takiej sekcji.
|
||||
* **Jakość i ton wypowiedzi:** Skill może wykorzystać model NLP do oceny stylu – czy język jest prosty, czy nie ma żargonu niewyjaśnionego. Jeśli model wskaże, że pewne zdania są wieloznaczne lub zbyt złożone, skill może to odnotować.
|
||||
* **Spójność z E-E-A-T:** Skill sprawdza, czy w tekście wskazano autora i jego kompetencje (jeśli brak sekcji autora lub metadanych – zaleci dodanie). Czy w treści padają odwołania do wiarygodnych źródeł (jeśli nie, lub mniej niż np. 2-3 przypisy na długi artykuł – zaleci wzbogacenie o źródła). Być może sięgnie po zewnętrzne bazy (np. czy domena artykułu ma wysokie DA – to poza zakresem samego skilla, ale agent może mieć taką informację), by ocenić autorytet. Generalnie jednak na tym etapie skill buduje **ocenę jakości**: np. *„Źródła: 1/5 (tylko jedno źródło cytowane) – dodać więcej”, „Autor: brak informacji – dodać bio”, „Język: OK, czytelny”, „Pokrycie tematu: dobre, oprócz braku info o XY”*.
|
||||
|
||||
4. **Przygotowanie rekomendacji:** Mając pełen obraz, skill gromadzi **rekomendacje optymalizacyjne GEO**. Priorytetyzuje je (np. krytyczne: brak **Quick Answer** lub brak FAQ; średnie: styl języka; niskie: drobne formatowanie). Dla każdej rekomendacji stara się dodać *konkretną wskazówkę jak ją zrealizować*. Wiele zaleceń może być generowanych automatycznie:
|
||||
|
||||
* Jeśli brak Quick Answer: skill może **wygenerować propozycję** takiego akapitu, bazując na treści (np. wyciągając z tekstu definicję i upraszczając ją modelem GPT). To pojawi się w raporcie jako: *„Dodaj szybkie podsumowanie: np. << *XYZ is ... (two-sentence definition)* >>”*.
|
||||
* Jeśli tytuł nie jest pytaniem: zaproponuje nowy tytuł. Np. oryg. tytuł: „Konfiguracja klastrów PostgreSQL” → sugestia: „Jak skonfigurować klaster PostgreSQL?”.
|
||||
* Brak FAQ: skill przeanalizuje treść i (być może z pomocą LLM) **wymyśli 2-3 pytania**, na które ta treść (lub jej autor) powinien odpowiedzieć, np.: „Jak monitorować klaster po konfiguracji?” itp. Umieści te Q wraz z zarysami odpowiedzi (np. punktami) w raporcie.
|
||||
* Braki w cytowaniach: skill może wskazać konkretne miejsca w tekście, gdzie warto podeprzeć się źródłem (np. przy wzmiance *„95% firm używa chmury”* brak przypisu – skill to zauważy). Zaproponuje: *„Dodaj źródło, np. \[Raport Flexera 2026]”* (tu pomagają wcześniej zebrane materiały podczas planowania treści – możliwe, że przy integracji do skilla dołączymy pewną bazę znanych źródeł branżowych).
|
||||
* Dane strukturalne: jeśli nie wykryto w HTML np. skryptu JSON-LD, skill wygeneruje **blok JSON-LD** zawierający zalecane oznaczenia, np. `TechArticle` z uzupełnionymi polami (tytuł, autor, data, opis), a jeśli dodaje FAQ – również obiekt FAQPage z listą Q/A. Ten JSON-LD znajdzie się w raporcie lub zostanie bezpośrednio zasugerowany do wstawienia w kod strony.
|
||||
* Optymalizacja techniczna: skill może wygenerować także zalecenia SEO pokrywające się z GEO – np. metatag og:image, czy struktura URL – choć to nie rdzeń GEO, czasem istotne (np. **krótsze URL** mogą być preferowane do wyświetlania jako źródło). Te sugestie będą uwzględniane, jeśli mieszczą się w ramach zadań GEO.
|
||||
|
||||
W efekcie powstaje uporządkowana lista zadań do wykonania, z której część ma od razu rozwiązania/propozycje.
|
||||
|
||||
5. **Generowanie raportu / zastosowanie zmian:** Ostatni etap to **wypisanie wyników**. Jeżeli skill działa w trybie raportu, formułuje czytelny dokument (Markdown lub HTML) zawierający:
|
||||
|
||||
* **Podsumowanie ogólne**: np. *„Twój artykuł spełnia \~70% rekomendacji GEO. Kluczowe braki: brak FAQ, nieaktualna data publikacji, mało źródeł.”*.
|
||||
* **Listę szczegółowych zaleceń** z priorytetami (np. w formie listy zadań do odhaczenia).
|
||||
* **Przykłady poprawek**: w formie diffów, fragmentów tekstu do wstawienia, wygenerowanego kodu JSON-LD, itp.
|
||||
* Ewentualnie **metryki**: np. ocena czytelności tekstu, liczba zdań w Quick Answer, itp., dla pełniejszego obrazu.
|
||||
|
||||
Taki raport może być przekazany użytkownikowi (np. w oknie czatu agenta lub wysłany emailem – jeśli przewidzimy integrację z notyfikacją).
|
||||
|
||||
Jeśli skill działa w trybie automatycznym, to:
|
||||
|
||||
* Może od razu wprowadzić niektóre poprawki: np. dodać wygenerowany JSON-LD do pliku HTML (poprzez wywołanie odpowiedniego narzędzia edycji pliku).
|
||||
* Może utworzyć nowy plik z uzupełnionym FAQ i poprosić autora o scalenie.
|
||||
* Każda automatyczna akcja przechodzi przez warstwę bezpieczeństwa – np. zanim agent wyśle commit do Git, może wymagać zatwierdzenia (workflow z *pull requestem*).
|
||||
* Pozostałe, nieautomatyczne kwestie (wymagające decyzji autorskich) będą wypisane w logu/raporcie.
|
||||
|
||||
6. **Aktualizacja i iteracja:** Po wdrożeniu poprawek skill może zostać ponownie uruchomiony na **zmienionej treści**, aby zweryfikować czy wszystkie problemy rozwiązano. Taka iteracja może trwać aż do osiągnięcia satysfakcjonującego wyniku GEO (np. autor poprawia wszystko co krytyczne, mniej istotne rzeczy mogą zostać na później). Zaimplementujemy mechanizm śledzenia wersji – skill przy kolejnym uruchomieniu może wykryć, że to ten sam dokument co wcześniej i sprawdzić, czy wcześniejsze zalecenia są już odhaczone.
|
||||
|
||||
7. **Zakończenie i transmisja danych:** Skill zwraca wynik do agenta OpenClaw, który zgodnie z konfiguracją:
|
||||
* Prezentuje raport użytkownikowi (lub powiadamia, że zmiany naniesiono).
|
||||
* Loguje akcję (np. wpis w logach audytu z timestampem i rezultatem).
|
||||
* Jeśli to zautomatyzowany pipeline – może oznaczyć zadanie jako zakończone lub przejść do kolejnej fazy (np. publikacja strony).
|
||||
|
||||
## 4. Wykorzystanie danych zewnętrznych i zasobów podczas działania
|
||||
|
||||
Skill GEO, oprócz analizy samej treści, może korzystać z kilku **zewnętrznych źródeł danych** w celu ulepszenia rekomendacji:
|
||||
|
||||
* **Bazy wiedzy i fora programistyczne:** Aby zidentyfikować popularne pytania lub problemy związane z tematem treści, skill może zapytować **API Stack Overflow lub Stack Exchange** (o ile dostępne) – np. wyszukać najczęściej zadawane pytania dla tagu `database` lub konkretnej technologii. Jeśli np. dokumentacja dotyczy MongoDB, skill sprawdzi, jakie pytania mają najwyższe głosy na dany temat i zweryfikuje, czy artykuł na nie odpowiada. Podobnie może przeszukać **GitHub Discussions czy Issues** dla często pojawiających się wątków (np. w repozytorium technologii X ludzie często pytają o konfig Y – warto to uwzględnić).
|
||||
|
||||
* **Wytyczne i schematy (schema.org, Google):** Skill ma wbudowaną wiedzę o **schematach JSON-LD** (np. definicja `TechArticle`, `FAQPage`, `HowTo` itp.), najpewniej wyciągniętą podczas developmentu z dokumentacji schema.org lub Google. W razie potrzeby może sięgnąć online do aktualnej specyfikacji (np. pobrać definicję ze schema.org, by upewnić się co do nazw pól). Ma też zakodowane (lub możliwe do pobrania z jakiegoś endpointa) **najświeższe wytyczne Google/OpenAI** odnośnie treści – np. Google Search Central blog mógł wydać wskazówki dot. AI content; OpenAI mogło opublikować parametry jak interpretują E-E-A-T. Skill może okresowo aktualizować te informacje (np. poprzez mechanizm update skill – `clawhub update`).
|
||||
|
||||
* **Usługi LLM (OpenAI):** Wartością dodaną skilla jest integracja z modelami językowymi do zadań generatywnych i oceny semantycznej. Skill może użyć:
|
||||
* **OpenAI GPT-4 API** (jeśli klucz jest skonfigurowany w `openclaw.json` i dopuszczony) do wygenerowania fragmentów tekstu (Quick Answer, FAQ) lub rewriting zdań dla lepszej klarowności. Również do *oceny odpowiedzi* – np. zapytać model: *„Czy poniższy tekst zawiera odpowiedź na pytanie XYZ?”* by sprawdzić pokrycie tematu.
|
||||
* **Modele open-source on-premise**: Jeśli polityka firmy nie pozwala wysyłać treści na zewnątrz, integracja może być przełączona na wewnętrzny model (np. lokalnie hostowany LLM). OpenClaw wspiera odpalanie poleceń na różnych „silnikach” – można więc np. spiąć skilla z lokalnym kontenerem z modelem typu LLaMA 2 fine-tuned do oceny tekstu. Wymaga to nieco konfiguracji (ponieważ wywołanie takiego modelu to pewnie komenda shellowa lub request do lokalnej usługi).
|
||||
|
||||
* **Platformy AI (ChatGPT, Perplexity, SGE):** Bezpośrednie API tych platform do sprawdzania cytowań nie są publiczne (stan na 2026). Można jednak użyć podejścia *„pseudo-user”*: skill potrafi zasymulować zapytanie do ChatGPT lub Perplexity i odczytać wyniki:
|
||||
* **ChatGPT**: OpenAI udostępnia mechanizm `Browsing` oraz pewne API (np. `ChatGPT Retrieval Plugin`), ale najpewniej skill po prostu skorzysta z modelu GPT-4, co i tak bazuje na wiedzy z internetu. Alternatywnie, można wykorzystać fakt, że ChatGPT dodaje do linków `utm_source=chatgpt` – monitoring tych odnośników (przez Tracker) daje pewne dane, ale do aktywnego sprawdzania skill raczej nie będzie „klikał” sam w ChatGPT.
|
||||
* **Perplexity**: Tu możliwe jest wykorzystanie ich API (Perplexity for Developers) jeśli istnieje – lub scrapowanie (co jest kruche i może naruszać ToS, więc ostrożnie). Ewentualnie skill może użyć klasycznego Google Search API i sprawdzić, czy nasz artykuł pojawia się w top 10 – bo analiza firmy Thirdparty pokazała, że aktualnie tylko \~38% źródeł SGE pokrywa się z TOP10 wyników organicznych, ale wciąż bycie wysoko w Google zwiększa szansę bycia dostrzeżonym przez AI. Tak więc skill może zebrać dane SEO (ranking, linki) jako proxy skuteczności GEO. [\[expansedigital.co\]](https://www.expansedigital.co/post/geo-generative-engine-optimization-the-complete-guide-for-2026)
|
||||
* **Trendy**: Skill może pobierać informacje o trendach wyszukiwania (np. Google Trends API do sprawdzenia, czy dane pojęcie rośnie na popularności – co sugeruje, że warto częściej aktualizować treść). Może też informować, jeśli temat zrobił się gorący i przydałaby się np. **nowa sekcja z aktualizacją** (to bardziej zaawansowana opcja, wymaga zewnętrznego feedu trendów).
|
||||
|
||||
* **Przykładowe repozytoria lub wzorce**: W ramach wdrożenia możemy dostarczyć skillowi pewne **przykłady idealnie zoptymalizowanych treści** (wzorcowych). Np. wzorzec dokumentacji API doskonałej pod GEO, wzorzec wpisu blogowego z pełnym E-E-A-T. Skill mógłby trzymać je w swoim pakiecie (folderze) i w razie potrzeby porównać strukturę „as is” z „wzorcem” (to trochę jak statyczny lint: np. *„wzorcowy dokument ma FAQ – Twój nie ma”*). W ten sposób wykorzystamy też wiedzę wcześniejszą z przygotowanej checklisty GEO dla treści technicznych – wiele z tamtych punktów jest zakodowanych jako reguły w logice skilla.
|
||||
|
||||
Podsumowując, skill GEO korzysta z danych zewnętrznych przede wszystkim **informatywnie** – by wiedzieć *co* zalecić (pytania ze Stack Overflow, trendy Google) i *jak* to powinno wyglądać (schema.org spec, przykładowe wzorce). W integracji ważne jest zapewnienie, że te zewnętrzne połączenia są odporne na błędy i zgodne z polityką (np. ograniczenie liczby zapytań do API, caching wyników, kluczowe dane nie wyciekają – o czym niżej).
|
||||
|
||||
## 5. Monitorowanie skuteczności i feedback loop
|
||||
|
||||
Wdrożenie GEO to nie jednorazowy akt, lecz proces ciągłego doskonalenia. Skill GEO będzie więc wyposażony w mechanizmy monitorujące i zamykające pętlę feedbacku:
|
||||
|
||||
* **Logowanie i metryki wewnętrzne:** Każde uruchomienie skilla zostanie zarejestrowane w logach OpenClaw (dzięki centralnemu loggingowi gatewaya). Log zawierać będzie m.in. identyfikator dokumentu, listę wykrytych problemów, wygenerowane zmiany, oraz flagę czy zmiany wdrożono automatycznie. Dodatkowo możemy logować **metryki** takie jak: ocena „GEO score” dokumentu przed i po poprawkach (np. % spełnionych checklist points), czas wykonania analizy, liczba wykorzystanych tokenów API (istotne dla kosztów). Te dane posłużą nam do oceny wpływu skilla oraz do ewentualnej optymalizacji wydajności.
|
||||
|
||||
* **Śledzenie ruchu z systemów AI:** Jak wspomniano, komponent **Tracker** będzie analizował ruch przychodzący na firmowe strony pod kątem źródeł AI. W praktyce, po wdrożeniu zmian GEO, chcemy odpowiedzieć na pytanie: *Czy cytowalność naszych treści wzrosła?*
|
||||
* W tym celu monitorujemy np. **Google Analytics / Matomo** z filtrami na parametry `utm_source=chatgpt` etc., oraz refererów zawierających `bing` (Bing Chat) czy domenę `perplexity.ai`. Skill może mieć zadanie okresowe (np. co tydzień) pobrać z API analityki liczbę wizyt z takich źródeł i logować trend.
|
||||
* Równocześnie, jeśli pozwalają na to mechanizmy OpenClaw, agent może **subskrybować alerty**: np. jeżeli ruch z AI do jakiejś strony spadnie do zera po byciu wcześniej obecnym, może to oznaczać, że content przestał być cytowany (być może stał się nieaktualny). Taki alert może automatycznie wyzwolić ponowną analizę GEO danej strony lub powiadomić zespół.
|
||||
|
||||
* **Analiza cytowań w odpowiedziach AI:** Pętla sprzężenia zwrotnego obejmuje również sprawdzanie rzeczywistej obecności naszych treści w odpowiedziach AI. O ile nie mamy oficjalnych API do tego, możliwe są pewne heurystyki:
|
||||
* Wspomniane testowe zapytania: np. co miesiąc skill generuje listę 5 kluczowych pytań związanych z naszą domeną (np. „What is <nasz produkt>?”, „How to do X with \<nasze narzędzie>?”) i używa kontrolowanego środowiska (np. niepublicznej instancji ChatGPT lub innego LLM z dostępem do sieci) by uzyskać odpowiedź **wraz z listą źródeł**. Następnie sprawdza, czy nasze domeny URL są wśród tych źródeł. Jeśli nie – to sygnał, że GEO można poprawić. Jeśli tak – zapisuje który URL i ewentualnie cytowany fragment.
|
||||
* Ręczny feedback: zachęcamy zespół/autorów, by zgłaszali do systemu (np. poprzez odznaczenie w panelu), gdy zobaczą swoją stronę cytowaną gdzieś. Ten feedback (choć manualny) może zasilać bazę sukcesów, co pozwoli zidentyfikować **jakie działania GEO przyniosły efekt** (np. zauważymy, że strony A, B, C zaczęły być cytowane po dodaniu tam sekcji FAQ – konkretny dowód skuteczności danego zabiegu).
|
||||
* *Cytowalność vs SEO:* Będziemy także zestawiać dane SEO z GEO. Np. jeśli jakaś strona **miała ruch organiczny, a po wprowadzeniu GEO ruch organiczny spadł o X% ale pojawił się ruch z AI** – to może być normalne (zjawisko zero-click, które przewidywaliśmy). Te analizy pomogą ocenić, czy w ogólnym rozrachunku content zyskuje (np. sumaryczny ruch +5%, choć struktura się zmienia). Tego typu raporty mogą być generowane kwartalnie jako część działania skilla (być może wymagające eksportu logów do zewnętrznego narzędzia BI – poza zakresem samego skilla, ale skill może przygotować surowe dane). [\[expansedigital.co\]](https://www.expansedigital.co/post/geo-generative-engine-optimization-the-complete-guide-for-2026)
|
||||
|
||||
* **Aktualizacja wiedzy skilla:** Monitorowanie obejmuje też samo **utrzymanie skilla**. GEO to nowa dziedzina, stale ewoluująca – np. wejdą nowe wytyczne, zmieni się algorytm Google SGE, OpenAI zacznie inaczej oceniać cytaty. Musimy więc aktualizować reguły i dane skilla:
|
||||
* Zaplanujemy okresowy **przegląd reguł** (np. co 2–3 miesiące ktoś z zespołu sprawdza czy np. minimalna sugerowana długość Quick Answer 40–60 słów jest nadal optymalna, czy może modele wolą dłuższe/krótsze).
|
||||
* Będziemy śledzić blogi branżowe (Google, OpenAI) o zmianach, i aktualizować skill (np. w sierpniu 2026 Google może ogłosić, że zaczyna ignorować pewien typ schema – nasz skill wtedy dostanie update).
|
||||
* Mechanizm OpenClaw/ClawHub pozwala na wydawanie wersji skilla – więc można wypuszczać updaty i instalować je centralnie.
|
||||
* Same **dane wzorcowe** (wspomniane repozytoria przykładów, listy pytań itp.) też powinny być przeglądane i poszerzane wraz z nowymi doświadczeniami.
|
||||
|
||||
* **Raportowanie KPI:** Dla interesariuszy możemy przygotować skondensowane KPI dotyczące GEO: np. *„% stron spełniających 90% wytycznych GEO”, „Liczba stron cytowanych przez AI (miesiąc do miesiąca)”, „Średni czas od publikacji do pierwszego cytatu”* itp. Skill może ułatwić zbieranie tych danych i np. generować miesięczny raport podsumowujący (poprzez integrację z np. Google Sheets API, wykresy generowane w Pythonie, czy po prostu formatkę Markdown ze statystykami).
|
||||
|
||||
## 6. Bezpieczeństwo i zgodność
|
||||
|
||||
Wdrażając skilla GEO, należy zwrócić szczególną uwagę na kwestie **bezpieczeństwa danych** oraz **zgodności z politykami firmy**:
|
||||
|
||||
* **Kontrola dostępu i uprawnień:** Skill będzie potencjalnie operował na różnorodnych treściach – w tym **wewnętrznych dokumentach**, szkicach nieopublikowanych artykułów, itp. Musimy zapewnić, że tylko uprawnione osoby/agent mają dostęp do określonych analiz. Rozwiązaniem jest korzystanie z mechanizmów uprawnień OpenClaw:
|
||||
* Możemy oznaczyć skilla jako dostępnego tylko dla agentów działających w określonych przestrzeniach (workspaces) lub z określonymi rolami. Np. skill GEO w środowisku publicznym może działać tylko na publicznych URL, a do audytu dokumentów wewnętrznych uruchamiany będzie w odrębnej instancji agenta na zamkniętej sieci.
|
||||
* Przy wywołaniu skilla, warstwa integracji sprawdza, czy agent (lub użytkownik, jeśli to komenda) ma prawo dostępu do danego pliku/URL. Jeśli nie – skill odmawia działania lub anonimizuje dane.
|
||||
|
||||
* **Ochrona danych przy wykorzystaniu AI zewnętrznego:** Gdy skill wysyła fragmenty treści do API OpenAI lub innych usług, istnieje ryzyko **wycieku wrażliwych informacji** (np. nieopublikowane dane techniczne). Polityka firmy może wymagać, by żadne dane nie trafiały na zewnątrz bez zgody. Dlatego:
|
||||
* W wypadku treści oznaczonych jako poufne (co można rozpoznać np. po etykiecie w nazwie pliku lub meta-znacznika), skill **wyłącza użycie zewnętrznych LLM** i działa jedynie w oparciu o reguły. Alternatywnie, używa trybu z lokalnym modelem.
|
||||
* Wszystkie klucze API (OpenAI, inne) są przechowywane w konfiguracji OpenClaw i **nie są logowane**. Skill powinien maskować w logach zapytania do API, by nie zapisywać np. pełnej treści wysyłanej do ChatGPT (można logować tylko np. „\[Prompty do OpenAI wysłane – zobacz STDOUT sandboxa]”).
|
||||
* Warto również wykorzystywać mechanizm OpenClaw **sandbox**: dzięki temu, jeśli skill wykonuje jakiś kod (np. Python do generowania czegoś) lub łączy się z siecią, to w izolowanym środowisku. W razie ewentualnego ataku (np. złośliwy plik wejściowy próbujący exploitować analizator), sandbox ograniczy skutki.
|
||||
|
||||
* **Bezpieczeństwo operacji automatycznych:** Jeśli dopuścimy tryb auto-poprawek, musimy upewnić się, że nie nastąpi **błędna masowa edycja** wskutek np. błędu skilla. Przykładowo, pomyłkowo wygenerowany JSON-LD może popsuć stronę, albo zbyt agresywna zmiana sformułowań może zmienić merytorykę. Dlatego zalecamy:
|
||||
* **Tryb suchy-run**: skill może mieć opcję, że zamiast zapisywać zmiany, najpierw generuje łatkę i stosuje ją tylko jeśli przejdzie walidację. Np. generujemy nowy HTML i przepuszczamy go przez validator (sprawdzający czy syntaktycznie OK, czy wszystkie stare sekcje są obecne) zanim podepniemy do publikacji.
|
||||
* **Recenzja zmian**: Możemy wymusić, że każde auto-działanie i tak tworzy PR lub diff do akceptacji przez człowieka. To kompromis między automatyzacją a kontrolą.
|
||||
* **Transaction log**: Skill będzie utrzymywał (np. w osobnym pliku log/db) listę dokonanych automatycznych poprawek z możliwością szybkiego rollbacku (np. PR można wycofać, albo skill może wygenerować „anty-diff” by odwrócić zmiany).
|
||||
|
||||
* **Zgodność z politykami firmy i prawnymi:**
|
||||
* Jeśli firma ma wytyczne contentowe (np. styl pisania, frazy zastrzeżone, disclaimery wymagane przy pewnych tematach), skill powinien je respektować. Można do analizy dodać moduł sprawdzający obecność **wymaganych formułek** (np. „Opinie własne autora” przy artykułach eksperckich) i dodawać zalecenia zgodnie z corporate styleguide.
|
||||
* W kwestii praw autorskich – skill generując treści (np. Quick Answer) musi tworzyć **oryginalne sformułowania**, by nie naruszać praw (tu duża rola LLM: generuje parafrazę zamiast kopiować z oryginału). Również cytując źródła, skill powinien zachować wymagany format (np. nie przytaczać za długich fragmentów chronionych prawem autorskim – raczej kierować linkiem).
|
||||
* **Polityka AI Usage**: Coraz więcej firm ma wewnętrzne polityki korzystania z generatywnej AI. Wdrożenie skilla GEO powinno być z nimi uzgodnione. Być może wymagana będzie np. rejestracja tego skilla w spisie narzędzi AI firmy, wzmianka o tym jakie dane przekazuje na zewnątrz, itp. Zapewnimy dokumentację tego aspektu dla zespołu bezpieczeństwa.
|
||||
|
||||
* **Testy i walidacja przed wdrożeniem:** Zanim skill ruszy w środowisku produkcyjnym, przeprowadzimy **testy jednostkowe scenariuszy** (np. na kilku przykładowych dokumentach: idealnym, słabym, średnim) oraz **testy bezpieczeństwa** (pentest skilla, np. dokument z złośliwą zawartością weryfikujący, czy sandbox zadziała). Również test wydajności – np. uruchomienie audytu na 100 stronach i monitor użycia pamięci/CPU, aby przewidzieć koszty. Dopiero po pozytywnych wynikach skill zostanie opublikowany dla szerszego grona.
|
||||
|
||||
Na koniec, skill GEO stanie się integralną częścią platformy OpenClaw w organizacji, pełniąc rolę **strażnika jakości treści pod kątem AI**. Dzięki niemu, inżynierowie i autorzy dokumentacji będą mieli natychmiastowe wsparcie w dostosowywaniu swoich materiałów do nowych realiów wyszukiwania – bez konieczności ręcznego śledzenia wszystkich zmian w algorytmach i trendach. Wdrażając ten skill, firma zyskuje **automatyzację eksperckiej wiedzy GEO**: agent będzie zawsze na bieżąco z najlepszymi praktykami i pilnował, by nasze dokumentacje i artykuły wyprzedzały konkurencję w wyścigu o widoczność w odpowiedziach generatywnych.
|
||||
|
||||
**Źródła:** niniejszy plan bazuje na wcześniejszej analizie zasad GEO (m.in. infografika *„The Anatomy of a GEO-Optimized Blog Post”*), wewnętrznej checkliście GEO dla treści technicznych, dokumentacji platformy OpenClaw, a także na publicznych przewodnikach branżowych dot. GEO. Wszystkie praktyki i zalecenia zostały dostosowane do kontekstu inżynierii danych i do możliwości implementacyjnych agenta OpenClaw. [\[expansedigital.co\]](https://www.expansedigital.co/post/geo-generative-engine-optimization-the-complete-guide-for-2026)
|
||||
@@ -0,0 +1,72 @@
|
||||
# Managing Modern Databases with Generative AI
|
||||
|
||||
## Introduction
|
||||
Managing large-scale databases requires more than just manual scripting and punctual maintenance. **Generative AI**—AI models that create new content—can automate routine work in database engineering, from writing SQL scripts to orchestrating ETL (extract, transform, load) pipelines and even performing statistical analyses for decision-making. Although the detailed content of the course *Managing Modern Databases with Generative AI* is behind the Pluralsight paywall, publicly available descriptions and independent articles provide substantial information. This report synthesizes those sources to explain how generative AI supports database management.
|
||||
|
||||
## Generative AI for ETL Processes
|
||||
|
||||
* **Automating ETL tasks:** Generative AI can streamline ETL by generating executable code for extracting, transforming and loading data. According to Pluralsight’s course description, learners first explore how to craft prompts that automate ETL, ensuring efficient data extraction, transformation and loading[5](https://www.pluralsight.com/courses/managing-modern-databases-generative-ai). This aligns with broader industry trends where generative models can convert natural-language instructions into SQL or Python code, infer data schemas, and produce data-quality rules[4](https://pingax.com/automating-etl-pipelines/).
|
||||
* **Intelligent code generation:** Recent guides highlight generative AI’s ability to generate SQL queries and Spark/Python scripts from prompts. For example, a prompt like “Aggregate total sales by product category for Q1 2025” may produce a complete SQL query that handles joins, aggregations and filtering[4](https://pingax.com/automating-etl-pipelines/). This capability is sometimes called NL2ETL (natural-language-to-ETL) and can extend to orchestrating workflows in tools like Airflow and Prefect[4](https://pingax.com/automating-etl-pipelines/).
|
||||
* **Adaptive pipelines:** AI-generated pipelines can be self-healing. By monitoring data patterns and schema changes, the pipelines adapt dynamically, reducing manual maintenance. Automated schema inference identifies data types and keys, while AI-suggested data-quality checks and error handling reduce human error[4](https://pingax.com/automating-etl-pipelines/).
|
||||
|
||||
## AI-Generated Database Monitoring
|
||||
|
||||
* **Monitoring scripts:** Pluralsight’s course description notes that generative AI can write scripts for database monitoring[5](https://www.pluralsight.com/courses/managing-modern-databases-generative-ai). Such scripts automate performance checks, track resource usage and detect anomalies. For instance, machine-learning models can analyze query patterns and system load to optimize execution plans in real time, thus reducing latency[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
* **Anomaly detection:** AI can identify unusual access patterns or behavior, improving security and compliance. The Built In article reports that AI-driven systems learn behavioral norms and flag deviations, such as credential misuse or unusual queries, thereby preventing breaches long before they occur[2](https://builtin.com/articles/generative-ai-database-management). AI also helps uncover shadow datasets or unmanaged data that pose compliance risks[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
|
||||
## Automating Routine Maintenance
|
||||
|
||||
* **Indexing and backups:** Routine tasks like creating indexes, performing backups and scheduling recovery operations can be automated using generative AI. Pluralsight’s overview indicates that learners will automate maintenance tasks, such as indexing, backups and recovery[5](https://www.pluralsight.com/courses/managing-modern-databases-generative-ai). Tools using generative AI can schedule these tasks, adjust index configurations based on access patterns and ensure backups are timely and consistent.
|
||||
* **Recovery procedures:** AI models can generate recovery scripts, validate backup integrity and recommend failover strategies. For instance, automated documentation can describe each step of an ETL pipeline and track dependencies, aiding restore processes[4](https://pingax.com/automating-etl-pipelines/).
|
||||
|
||||
## Integrating Generative AI Into Database Management
|
||||
|
||||
### Emerging Tools and Technologies
|
||||
|
||||
* **Language-to-SQL interfaces:** Tools like Oracle Autonomous Database’s **Select AI** let users generate SQL queries from natural-language prompts, removing the need for specialized SQL knowledge. These interfaces are becoming common across cloud platforms.
|
||||
* **Probabilistic generative models:** MIT researchers introduced **GenSQL**, a generative AI extension to SQL that integrates probabilistic models. It allows users to perform statistical analyses (e.g., predictions, anomaly detection, synthetic data generation) directly through SQL‐like commands, providing deeper insights compared to classic queries[1](https://news.mit.edu/2024/mit-researchers-introduce-generative-ai-databases-0708). GenSQL supports explainable models and produces calibrated uncertainty for predictions[1](https://news.mit.edu/2024/mit-researchers-introduce-generative-ai-databases-0708).
|
||||
* **LLM-powered assistants:** Large language models (LLMs) power assistants like Databricks’ **Unity Catalog AI**, GitHub Copilot, and many database IDE plugins. These assistants generate SQL, Python, or Spark code suggestions, recommend query optimizations and generate test cases, thus reducing development time[3](https://prama.ai/ai-augmented-sql-code-generation-supercharging-data-engineering-workflows/).[3](https://prama.ai/ai-augmented-sql-code-generation-supercharging-data-engineering-workflows/).
|
||||
|
||||
### Benefits
|
||||
|
||||
* **Agility and speed:** Generative AI enables near-real-time creation of queries and pipelines, drastically shortening ETL development cycles. A generative system can turn a description into code in minutes instead of days[4](https://pingax.com/automating-etl-pipelines/).
|
||||
* **Cost reduction:** Automating routine tasks reduces the need for manual coding, lowering operational costs. It also frees engineers to focus on high-impact design and strategy[4](https://pingax.com/automating-etl-pipelines/).
|
||||
* **Improved data quality:** AI-generated scripts incorporate best practices and can automatically flag anomalies, leading to cleaner data[4](https://pingax.com/automating-etl-pipelines/).
|
||||
* **Democratization of data:** Natural-language interfaces let business users request transformations without deep technical expertise, broadening access to data insights[4](https://pingax.com/automating-etl-pipelines/).
|
||||
* **Reduced technical debt:** AI-generated code tends to be standardized and well-documented. Some systems automatically produce metadata and lineage information, improving maintainability[4](https://pingax.com/automating-etl-pipelines/).
|
||||
|
||||
### Challenges and Considerations
|
||||
|
||||
* **Data privacy and security:** AI systems require access to sensitive data to function effectively. Ensuring compliance with privacy regulations (e.g., GDPR, HIPAA) and building explainable, auditable AI pipelines is critical[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
* **Integration with legacy systems:** Many enterprise architectures are siloed and not designed for large-scale AI. Integrating AI requires modernizing data pipelines and bringing together data and AI teams[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
* **Hallucination and errors:** LLMs can generate plausible but incorrect code or queries if not given enough context. Validation layers that check syntax and semantics against current schemas are essential.
|
||||
* **Explainability:** Some generative models act as “black boxes” unless designed to provide traceability and rationale. Systems like GenSQL emphasize explainable models, offering an example of how to mitigate this risk[1](https://news.mit.edu/2024/mit-researchers-introduce-generative-ai-databases-0708).
|
||||
* **Prompt engineering:** Crafting precise prompts is key to high-quality outputs. Ambiguous or incomplete instructions can yield unreliable results[3](https://prama.ai/ai-augmented-sql-code-generation-supercharging-data-engineering-workflows/).
|
||||
|
||||
## Examples Across Industries
|
||||
|
||||
* **Finance:** Banks use AI to monitor transactions for fraud by detecting unusual spending patterns and sequence anomalies[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
* **Healthcare:** AI models help clinicians identify disease progression from diverse patient data and recommend personalized treatments[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
* **E-commerce:** Retailers employ AI for personalized product recommendations, demand forecasting and dynamic pricing[2](https://builtin.com/articles/generative-ai-database-management).
|
||||
* **Genomic research:** GenSQL has been used to generate synthetic data that mirror complex relationships in genomics, enabling analysis while preserving privacy[1](https://news.mit.edu/2024/mit-researchers-introduce-generative-ai-databases-0708).
|
||||
|
||||
## Conclusion
|
||||
Generative AI is redefining how data is extracted, transformed, loaded and maintained in modern databases. By translating natural-language instructions into precise SQL or ETL code, it automates repetitive tasks and accelerates innovation. Models like GenSQL integrate probabilistic reasoning within databases, enabling more sophisticated analysis. However, adopting generative AI also introduces challenges—particularly around privacy, integration, prompt engineering and hallucination—that must be carefully managed. As generative AI capabilities mature and become integrated into database platforms, data teams will be able to focus more on strategic design and less on manual coding, thereby unlocking new levels of agility and efficiency.
|
||||
|
||||
Here are some of the most frequently noted challenges that organizations encounter when implementing AI-driven or generative AI techniques in database management systems:
|
||||
|
||||
1. **Data privacy and security concerns.** AI models often need access to sensitive data. Keeping that data secure while complying with regulations (e.g., GDPR, HIPAA, CCPA) requires careful design. Enterprises must establish strong encryption, access controls and audit measures to protect data and meet regulatory mandates,. [\[rapidflowapps.com\]](https://www.rapidflowapps.com/blogoracle/navigating-the-database-frontier-top-5-dba-concerns-in-the-age-of-ai-and-cloud/)
|
||||
|
||||
2. **Integration with legacy systems.** Many existing databases use older architectures that don’t support modern AI integration. These systems often store data in proprietary formats or silos and may lack real-time APIs, making it difficult and expensive to connect AI models and maintain continuity. Organizations must plan phased migrations or invest in middleware and modernization strategies, often involving significant cost and complexity. [\[eajournals.org\]](https://eajournals.org/ejcsit/wp-content/uploads/sites/21/2025/05/Integrating-Artificial-Intelligence.pdf)
|
||||
|
||||
3. **Model accuracy and reliability.** AI models need continual tuning and validation. Without sufficient context, large language models may produce plausible yet syntactically or semantically incorrect code or queries. False positives in anomaly detection or poorly optimized queries can negatively affect business operations, so robust validation steps are required.
|
||||
|
||||
4. **Hallucination and prompt sensitivity.** Generative models sometimes hallucinate—creating nonsensical or incorrect outputs—which can lead to faulty queries or improper joins (e.g., mistakenly linking unrelated tables). Outcomes depend heavily on the quality of the prompts provided; ambiguous instruction can result in unreliable code.
|
||||
|
||||
5. **Resource and cost requirements.** AI-enabled database solutions often demand substantial computational resources and specialized expertise. Organizations must weigh these costs against benefits, invest in infrastructure to support AI workloads and ensure they have skilled personnel to manage these systems. [\[dbadataverse.com\]](https://dbadataverse.com/tech/generative-ai/2025/02/generative-ai-for-databases-transforming-data-management)
|
||||
|
||||
6. **Bias, fairness and explainability.** Many AI models (especially large LLMs) act as “black boxes,” making it challenging to understand or explain their decisions. In regulated industries, it’s critical that AI-generated recommendations are transparent and auditable. Additionally, AI outputs can reflect biases in the training data, which DBAs must monitor and correct. [\[techchannel.com\]](https://techchannel.com/artificial-intelligence/ai-and-database-administration/)
|
||||
|
||||
7. **Skillset and cultural adaptation.** As AI automates routine database tasks, DBAs and data engineers need to acquire new skills in AI, machine learning and automation frameworks. They must also develop comfort with cross-functional collaboration to incorporate AI responsibly and effectively into their workflows. [\[techchannel.com\]](https://techchannel.com/artificial-intelligence/ai-and-database-administration/)
|
||||
|
||||
These challenges suggest that while generative AI can greatly improve database operations, it also introduces technical, organizational and ethical complexities that must be addressed for successful adoption.
|
||||
@@ -0,0 +1,164 @@
|
||||
**Checklistę treści SEO dla każdego etapu**
|
||||
|
||||
z Twojego modelu (Inicjacja → Badania → Porównywanie → Transakcja → Doświadczenie). Jest to *content checklist* (co tworzyć + jak to ułożyć na stronie), z domieszką kluczowych elementów on‑page/technicznych, które wg wewnętrznych materiałów obejmują m.in. **title, meta description, indeksację, duplikację/canonical, paginację, structured data, architekturę informacji, mobile‑first i performance**.
|
||||
W praktyce bazuje to na dopasowaniu treści do intencji (informacyjna / nawigacyjna / komercyjna / transakcyjna). [\[semrush.com\]](https://www.semrush.com/blog/types-of-keywords-commercial-informational-navigational-transactional/)
|
||||
|
||||
***
|
||||
|
||||
## 0) Wspólna „checklista bazowa” (dla KAŻDEJ treści, niezależnie od etapu)
|
||||
|
||||
* [ ] Zdefiniuj **intencję** strony (informacyjna / komercyjna / transakcyjna / nawigacyjna). [\[semrush.com\]](https://www.semrush.com/blog/types-of-keywords-commercial-informational-navigational-transactional/)
|
||||
* [ ] Ustal **1 temat główny + klaster pytań** (PAA/FAQ) i zrób mapę H2/H3.
|
||||
* [ ] Napisz unikalny **Page Title** i **Meta description** (Google może użyć opisu jako snippetu; opis ma streszczać i zachęcać) [\[developers...google.com\]](https://developers.google.com/search/docs/appearance/snippet)
|
||||
* [ ] Zaplanuj **internal linking** (do treści z poprzedniego etapu + następnego etapu).
|
||||
* [ ] Dodaj **structured data** tam, gdzie ma sens (FAQ/HowTo/Product/Review itp.) i przetestuj walidacją. [\[umarcomm.umn.edu\]](https://umarcomm.umn.edu/blog/2025/10/03/how-use-structured-data-stand-out-google)
|
||||
* [ ] Dopilnuj podstaw: **duplicate content / canonicalizacja / paginacja** (jeśli dotyczy).
|
||||
* [ ] UX/SEO: linki z **opisowym tekstem** i crawlable (to typowy błąd w audytach).
|
||||
* [ ] Mobile‑first i performance jako warunek „publish” (wewnętrznie opisywane jako wymóg/standard).
|
||||
***
|
||||
|
||||
# 1) INICJACJA (Awareness / Informacyjne)
|
||||
|
||||
**Cel SEO:** złapać szeroki popyt, „problem‑aware” i edukację (dużo długiego ogona).
|
||||
**Dominujące zapytania:** „co to jest…”, „jak działa…”, „dlaczego…”, „jak wybrać…”.
|
||||
|
||||
### Checklist: co publikować
|
||||
|
||||
* [ ] **Poradniki „co to jest / jak działa”** (definicje + przykłady zastosowań).
|
||||
* [ ] **Artykuły problemowe** („Jak rozwiązać \[problem]?”) + sekcja „najczęstsze błędy”.
|
||||
* [ ] **Glossary / słownik pojęć** (krótkie definicje → linki do poradników).
|
||||
* [ ] **Checklisty startowe** („Jak zacząć z \[kategoria] w 30 min”).
|
||||
* [ ] **FAQ/kompendium** (pod PAA i szybkie odpowiedzi).
|
||||
* [ ] **Infografika/wideo** wspierające (łatwe do udostępniania). (Praktyka „awareness content” jako przewodniki/edukacja pojawia się w opisach lejka). [\[hashmeta.com\]](https://hashmeta.com/blog/how-to-create-content-for-each-stage-of-the-search-funnel/), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/write-content-sales-funnel-stage/258359/)
|
||||
|
||||
### Checklist: jak ułożyć stronę (on‑page)
|
||||
|
||||
* [ ] Pierwsze 2–3 akapity odpowiadają wprost na pytanie („TL;DR”).
|
||||
* [ ] H2 = pytania użytkownika („Jak…”, „Czy…”, „Ile…”, „Kiedy…”).
|
||||
* [ ] Sekcja „Co dalej?” → link do **Badania** (rankingi / przewodnik zakupowy).
|
||||
* [ ] Dodaj **FAQ schema** (jeśli masz wyraźne Q/A). [\[umarcomm.umn.edu\]](https://umarcomm.umn.edu/blog/2025/10/03/how-use-structured-data-stand-out-google)
|
||||
|
||||
### KPI (orientacyjnie)
|
||||
|
||||
* [ ] Impressions + CTR na frazach informacyjnych
|
||||
* [ ] Udział w ruchu non‑brand (widoczność)
|
||||
|
||||
***
|
||||
|
||||
# 2) BADANIA (Consideration / „komercyjna analiza”)
|
||||
|
||||
**Cel SEO:** pomóc w wyborze opcji, zbudować zaufanie, „shortlist”.
|
||||
**Dominujące zapytania:** „najlepszy…”, „ranking…”, „opinie…”, „polecane…”.
|
||||
|
||||
### Checklist: co publikować
|
||||
|
||||
* [ ] **Rankingi / listy TOP** („Najlepsze \[kategoria] 2026”).
|
||||
* [ ] **Przewodniki zakupowe** („na co zwrócić uwagę przy wyborze…”).
|
||||
* [ ] **Recenzje ogólne kategorii** („które typy / warianty są dla kogo”).
|
||||
* [ ] **Porównania segmentów** („budżetowe vs premium”, „dla X vs dla Y”).
|
||||
* [ ] **Checklisty kryteriów** (do pobrania / do skopiowania).
|
||||
* [ ] **Case studies / zastosowania** (gdy to B2B/SaaS) – typowe dla etapu consideration. [\[hashmeta.com\]](https://hashmeta.com/blog/how-to-create-content-for-each-stage-of-the-search-funnel/), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/write-content-sales-funnel-stage/258359/)
|
||||
|
||||
### Checklist: jak ułożyć stronę (on‑page)
|
||||
|
||||
* [ ] Wyraźne kryteria oceny (sekcja „Metodologia rankingu”).
|
||||
* [ ] Tabela porównawcza + „dla kogo” przy każdym wariancie.
|
||||
* [ ] Linki do **Porównywanie** (porównania 1:1) oraz do stron produktowych (Transakcja).
|
||||
* [ ] Jeśli są elementy recenzji/ocen → rozważ właściwe structured data (np. Review/Rating tam, gdzie zgodne z zasadami i masz realne dane). [\[umarcomm.umn.edu\]](https://umarcomm.umn.edu/blog/2025/10/03/how-use-structured-data-stand-out-google)
|
||||
|
||||
### KPI
|
||||
|
||||
* [ ] Ruch na frazach „best/ranking/opinie”
|
||||
* [ ] Przejścia do porównań i stron produktowych
|
||||
|
||||
***
|
||||
|
||||
# 3) PORÓWNYWANIE (Commercial Investigation / „X vs Y”)
|
||||
|
||||
**Cel SEO:** domknąć decyzję poprzez konkret: funkcje, koszty, ograniczenia, ryzyka.
|
||||
**Dominujące zapytania:** „X vs Y”, „różnice”, „który lepszy”, „alternatywy”.
|
||||
|
||||
### Checklist: co publikować
|
||||
|
||||
* [ ] **Porównania 1:1** (X vs Y) + werdykt dla różnych profili użytkowników.
|
||||
* [ ] **„Alternatywy dla X”** (z powodami migracji/wyboru).
|
||||
* [ ] **„Najczęstsze pytania przed zakupem”** (koszty, gwarancje, kompatybilność).
|
||||
* [ ] **Kalkulatory / konfiguratory** („ile to kosztuje przy moim scenariuszu”).
|
||||
* [ ] **Dema / walkthrough** (wideo + transkrypcja na stronie).
|
||||
* [ ] „Mid-funnel” treści typu porównania / case studies są wskazywane jako typowe w tej fazie lejka. [\[hashmeta.com\]](https://hashmeta.com/blog/how-to-create-content-for-each-stage-of-the-search-funnel/), [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/write-content-sales-funnel-stage/258359/)
|
||||
|
||||
### Checklist: jak ułożyć stronę (on‑page)
|
||||
|
||||
* [ ] Stała sekcja: „Różnice w skrócie” + potem szczegóły.
|
||||
* [ ] Tabela: funkcje / koszty / ograniczenia / dla kogo.
|
||||
* [ ] Widoczne CTA „Sprawdź cenę / dostępność” → **Transakcja**.
|
||||
* [ ] FAQ z obiekcjami („Czy X działa z…”, „Czy Y ma…”) + schema. [\[umarcomm.umn.edu\]](https://umarcomm.umn.edu/blog/2025/10/03/how-use-structured-data-stand-out-google)
|
||||
|
||||
### KPI
|
||||
|
||||
* [ ] CTR na frazach „vs / alternatywy”
|
||||
* [ ] Kliknięcia w CTA do transakcji, scroll depth
|
||||
|
||||
***
|
||||
|
||||
# 4) TRANSAKCJA (Decision / Transactional)
|
||||
|
||||
**Cel SEO:** maksymalizować konwersję, widoczność na „kup teraz”, „cena”, „dostępność”.
|
||||
**Dominujące zapytania:** „kup”, „cena”, „promocja”, „gdzie kupić”, „dostępność”, „lokalnie”.
|
||||
|
||||
### Checklist: co publikować
|
||||
|
||||
* [ ] **Strony produktowe/landing pages** (jednoznaczny value prop + spec).
|
||||
* [ ] **Strony „cennik / pakiety”** + porównanie planów.
|
||||
* [ ] **„Gdzie kupić / dostępność / lokalizator”** (jeśli retail).
|
||||
* [ ] **Promocje** (jeśli uzasadnione) – najlepiej jako evergreen „jak działają rabaty” + aktualizacje.
|
||||
* [ ] **Strony kategorii** z filtrami (ale dopilnuj paginacji/canonical).
|
||||
### Checklist: jak ułożyć stronę (on‑page + techniczne minimum)
|
||||
|
||||
* [ ] Title i opis „transakcyjny” (jasno: co, dla kogo, korzyść) – snippety mogą być generowane z treści i/lub meta description. [\[developers...google.com\]](https://developers.google.com/search/docs/appearance/snippet)
|
||||
* [ ] **Structured data** (Product/Offer/Breadcrumb – zależnie od typu strony) i test walidacją. [\[umarcomm.umn.edu\]](https://umarcomm.umn.edu/blog/2025/10/03/how-use-structured-data-stand-out-google)
|
||||
* [ ] Linki „dodaj do koszyka / kontakt / demo” są crawlable i mają opisowy tekst (typowy problem w audytach).
|
||||
* [ ] Mobile‑first i performance jako warunek publikacji (wymóg w ujęciu „SEO templates + performance budgets”).
|
||||
|
||||
### KPI
|
||||
|
||||
* [ ] CR (conversion rate), revenue/leads z organic
|
||||
* [ ] Widoczność na frazy „cena/kup/dostępność”
|
||||
|
||||
***
|
||||
|
||||
# 5) DOŚWIADCZENIE (Retention / Post‑purchase)
|
||||
|
||||
**Cel SEO:** wsparcie po zakupie + redukcja ticketów + upsell/cross‑sell + lojalność.
|
||||
**Dominujące zapytania:** „jak używać”, „problem z…”, „instrukcja”, „serwis”, „akcesoria”.
|
||||
|
||||
### Checklist: co publikować
|
||||
|
||||
* [ ] **Centrum pomocy / Knowledge Base** (artykuły 1 problem = 1 strona).
|
||||
* [ ] **Instrukcje / How‑to** (krok po kroku) + grafiki + wideo + transkrypcja.
|
||||
* [ ] **Troubleshooting** („błąd X”, „nie działa Y”) z jasnymi krokami.
|
||||
* [ ] **FAQ posprzedażowe** (gwarancja, zwroty, serwis).
|
||||
* [ ] **Akcesoria / rozszerzenia / „co jeszcze warto”** (cross‑sell).
|
||||
* [ ] Ten etap w lejku bywa opisywany jako retention/loyalty: treści wsparciowe + pogłębiające relację. [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/write-content-sales-funnel-stage/258359/), [\[blog.hubspot.com\]](https://blog.hubspot.com/marketing/content-for-every-funnel-stage)
|
||||
|
||||
### Checklist: jak ułożyć stronę (on‑page)
|
||||
|
||||
* [ ] „Szybka odpowiedź” na górze + kroki poniżej (najpierw rozwiązanie, potem tło).
|
||||
* [ ] Sekcja „Powiązane artykuły” (silne linkowanie wewnętrzne).
|
||||
* [ ] HowTo/FAQ schema tam, gdzie pasuje + walidacja. [\[umarcomm.umn.edu\]](https://umarcomm.umn.edu/blog/2025/10/03/how-use-structured-data-stand-out-google)
|
||||
* [ ] Meta description opisuje konkretny problem i efekt („Napraw… w 5 krokach”). [\[developers...google.com\]](https://developers.google.com/search/docs/appearance/snippet)
|
||||
|
||||
### KPI
|
||||
|
||||
* [ ] Ruch na frazy problemowe + spadek zgłoszeń (jeśli mierzysz)
|
||||
* [ ] Powroty użytkowników / repeat visits
|
||||
|
||||
***
|
||||
|
||||
## Bonus: szybka mapa „rodzaj wyszukiwania → format treści”
|
||||
|
||||
* **Styczne/problemowe** → poradniki, definicje, how‑to, FAQ (Inicjacja). [\[hashmeta.com\]](https://hashmeta.com/blog/how-to-create-content-for-each-stage-of-the-search-funnel/), [\[semrush.com\]](https://www.semrush.com/blog/types-of-keywords-commercial-informational-navigational-transactional/)
|
||||
* **Kategoria** → przewodniki zakupowe, rankingi (Badania). [\[hashmeta.com\]](https://hashmeta.com/blog/how-to-create-content-for-each-stage-of-the-search-funnel/), [\[semrush.com\]](https://www.semrush.com/blog/types-of-keywords-commercial-informational-navigational-transactional/)
|
||||
* **Konkurencja/porównania** → X vs Y, alternatywy, kalkulatory (Porównywanie). [\[hashmeta.com\]](https://hashmeta.com/blog/how-to-create-content-for-each-stage-of-the-search-funnel/), [\[semrush.com\]](https://www.semrush.com/blog/types-of-keywords-commercial-informational-navigational-transactional/)
|
||||
* **Transakcyjne** → product/offer/pricing, gdzie kupić (Transakcja). [\[semrush.com\]](https://www.semrush.com/blog/types-of-keywords-commercial-informational-navigational-transactional/), [\[developers...google.com\]](https://developers.google.com/search/docs/appearance/snippet)
|
||||
* **Posprzedażowe** → KB, troubleshooting, instrukcje (Doświadczenie). [\[searchengi...ournal.com\]](https://www.searchenginejournal.com/write-content-sales-funnel-stage/258359/), [\[blog.hubspot.com\]](https://blog.hubspot.com/marketing/content-for-every-funnel-stage)
|
||||
@@ -0,0 +1,311 @@
|
||||
### Diagram: Customer Journey + checklisty SEO (high‑level)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Inicjacja<br/>Awareness] --> B[Badania<br/>Consideration]
|
||||
B --> C[Porównywanie<br/>Evaluation]
|
||||
C --> D[Transakcja<br/>Decision]
|
||||
D --> E[Doświadczenie<br/>Retention]
|
||||
|
||||
subgraph S1["Inicjacja – SEO"]
|
||||
A1["Poradniki: co to jest / jak działa"]
|
||||
A2["Treści problemowe"]
|
||||
A3["FAQ / Glossary"]
|
||||
A4["Checklisty startowe"]
|
||||
end
|
||||
|
||||
subgraph S2["Badania – SEO"]
|
||||
B1["Rankingi TOP"]
|
||||
B2["Przewodniki zakupowe"]
|
||||
B3["Opinie / Recenzje"]
|
||||
B4["Case studies"]
|
||||
end
|
||||
|
||||
subgraph S3["Porównywanie – SEO"]
|
||||
C1["X vs Y"]
|
||||
C2["Alternatywy"]
|
||||
C3["Tabele porównawcze"]
|
||||
C4["Kalkulatory"]
|
||||
end
|
||||
|
||||
subgraph S4["Transakcja – SEO"]
|
||||
D1["Strony produktowe"]
|
||||
D2["Cenniki / Pakiety"]
|
||||
D3["Gdzie kupić"]
|
||||
D4["Landing pages"]
|
||||
end
|
||||
|
||||
subgraph S5["Doświadczenie – SEO"]
|
||||
E1["Instrukcje How-To"]
|
||||
E2["Troubleshooting"]
|
||||
E3["Knowledge Base"]
|
||||
E4["Cross-sell / Up-sell"]
|
||||
end
|
||||
|
||||
A --> A1
|
||||
A --> A2
|
||||
A --> A3
|
||||
A --> A4
|
||||
|
||||
B --> B1
|
||||
B --> B2
|
||||
B --> B3
|
||||
B --> B4
|
||||
|
||||
C --> C1
|
||||
C --> C2
|
||||
C --> C3
|
||||
C --> C4
|
||||
|
||||
D --> D1
|
||||
D --> D2
|
||||
D --> D3
|
||||
D --> D4
|
||||
|
||||
E --> E1
|
||||
E --> E2
|
||||
E --> E3
|
||||
E --> E4
|
||||
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
### Wariant alternatywny (jeśli chcesz **czystszy diagram pod README / GitHub**)
|
||||
|
||||
Bez `<br/>`, tylko ASCII — **najmniej awaryjna wersja**:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Inicjacja --> Badania --> Porownywanie --> Transakcja --> Doswiadczenie
|
||||
|
||||
Inicjacja --> I1["Poradniki"]
|
||||
Inicjacja --> I2["FAQ"]
|
||||
Inicjacja --> I3["Problemy"]
|
||||
|
||||
Badania --> B1["Rankingi"]
|
||||
Badania --> B2["Przewodniki"]
|
||||
Badania --> B3["Opinie"]
|
||||
|
||||
Porownywanie --> P1["X vs Y"]
|
||||
Porownywanie --> P2["Alternatywy"]
|
||||
|
||||
Transakcja --> T1["Produkt"]
|
||||
Transakcja --> T2["Cena"]
|
||||
Transakcja --> T3["Kup teraz"]
|
||||
|
||||
Doswiadczenie --> D1["Instrukcje"]
|
||||
Doswiadczenie --> D2["Pomoc"]
|
||||
```
|
||||
|
||||
## Diagram Mermaid: AI Content Ops dla SEO (per etap)
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
%% =========================
|
||||
%% AI SEO CONTENT OPS PIPELINE
|
||||
%% =========================
|
||||
|
||||
subgraph G["Globalne bramki QA (AI) - obowiazkowe dla kazdej strony"]
|
||||
G1["Meta: Title + Description (unikalne, zgodne z intencja)"]
|
||||
G2["On-page: H1/H2, odpowiedz na intencje, linkowanie wewn."]
|
||||
G3["Tech: indexing, duplicate content, canonical, pagination"]
|
||||
G4["Structured Data: FAQ/HowTo/Product/Review (gdy pasuje)"]
|
||||
G5["UX: link text opisowy + crawlable"]
|
||||
G6["Mobile-first + performance budzet"]
|
||||
end
|
||||
|
||||
subgraph P["AI Pipeline (jedna iteracja)"]
|
||||
P0["Brief: etap + persona + intencja + KPI"]
|
||||
P1["Research: SERP intents + PAA/FAQ + konkurencja"]
|
||||
P2["Plan: outline H2/H3 + mapa linkow (prev/next etap)"]
|
||||
P3["Draft: wersja 1 (z sekcja TLDR)"]
|
||||
P4["On-page pass: meta + naglowki + internal links"]
|
||||
P5["Schema pass: dobierz i wygeneruj JSON-LD"]
|
||||
P6["QA pass: zgodnosc z bramkami G1-G6"]
|
||||
P7["Publish: URL + breadcrumbs + monitoring"]
|
||||
P8["Measure: GSC/GA sygnaly + refresh plan"]
|
||||
P0 --> P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7 --> P8
|
||||
end
|
||||
|
||||
%% =========================
|
||||
%% CUSTOMER JOURNEY STAGES
|
||||
%% =========================
|
||||
subgraph J["Customer Journey - etapy i AI deliverables"]
|
||||
A["Inicjacja (Awareness)"]
|
||||
B["Badania (Consideration)"]
|
||||
C["Porownywanie (Evaluation)"]
|
||||
D["Transakcja (Decision)"]
|
||||
E["Doswiadczenie (Retention)"]
|
||||
|
||||
A --> B --> C --> D --> E
|
||||
end
|
||||
|
||||
%% =========================
|
||||
%% PER-STAGE CONTENT OUTPUTS
|
||||
%% =========================
|
||||
subgraph OA["AI Output: Inicjacja"]
|
||||
A1["Content types: definicje, poradniki, problem->rozwiazanie, FAQ/glossary"]
|
||||
A2["Prompt focus: wyjasnij prosto, nie sprzedawaj, edukuj"]
|
||||
A3["Schema: FAQ / HowTo (jesli krok po kroku)"]
|
||||
end
|
||||
|
||||
subgraph OB["AI Output: Badania"]
|
||||
B1["Content types: rankingi, przewodniki zakupowe, recenzje, case studies"]
|
||||
B2["Prompt focus: kryteria wyboru, metodologia, rekomendacje dla person"]
|
||||
B3["Schema: FAQ; (opcjonalnie) Review gdy masz realne dane"]
|
||||
end
|
||||
|
||||
subgraph OC["AI Output: Porownywanie"]
|
||||
C1["Content types: X vs Y, alternatywy, tabele, kalkulatory, demo/walkthrough"]
|
||||
C2["Prompt focus: roznice, trade-offs, dla kogo co, obiekcje"]
|
||||
C3["Schema: FAQ; (opcjonalnie) HowTo dla konfiguracji"]
|
||||
end
|
||||
|
||||
subgraph OD["AI Output: Transakcja"]
|
||||
D1["Content types: product/landing, pricing, gdzie kupic, kategorie z filtrami"]
|
||||
D2["Prompt focus: jasne value prop, CTA, dostepnosc, warunki"]
|
||||
D3["Schema: Product/Offer/Breadcrumb (gdy dotyczy)"]
|
||||
end
|
||||
|
||||
subgraph OE["AI Output: Doswiadczenie"]
|
||||
E1["Content types: KB, instrukcje, troubleshooting, akcesoria/upsell"]
|
||||
E2["Prompt focus: szybka diagnoza, kroki naprawy, linki do powiazanych"]
|
||||
E3["Schema: HowTo / FAQ"]
|
||||
end
|
||||
|
||||
%% =========================
|
||||
%% WIRING PIPELINE TO STAGES
|
||||
%% =========================
|
||||
A -. "AI iteracja P0-P8" .-> P0
|
||||
B -. "AI iteracja P0-P8" .-> P0
|
||||
C -. "AI iteracja P0-P8" .-> P0
|
||||
D -. "AI iteracja P0-P8" .-> P0
|
||||
E -. "AI iteracja P0-P8" .-> P0
|
||||
|
||||
A --> OA
|
||||
B --> OB
|
||||
C --> OC
|
||||
D --> OD
|
||||
E --> OE
|
||||
|
||||
%% QA gates referenced by pipeline
|
||||
P6 --> G1
|
||||
P6 --> G2
|
||||
P6 --> G3
|
||||
P6 --> G4
|
||||
P6 --> G5
|
||||
P6 --> G6
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## Co dokładnie jest “AI‑ready” w tym diagramie (krótko i konkretnie)
|
||||
|
||||
1. **Jednolity pipeline P0–P8** (agent robi zawsze te same kroki), a etap (A–E) jedynie **zmienia brief i outputy**.
|
||||
2. Masz wprost wpisane bramki jakości, które w materiałach wewnętrznych przewijają się jako SEO must‑have (duplicate/canonical/pagination/structured data/IA/perf/mobile).
|
||||
Diagram jest:
|
||||
|
||||
* ✅ parsowalny
|
||||
* ✅ bez znaków problematycznych
|
||||
* ✅ nadaje się do README / dokumentacji systemowej
|
||||
* ✅ logicznie spójny z poprzednim diagramem (pipeline + QA gates)
|
||||
|
||||
***
|
||||
|
||||
## Diagram 2: AI Agent Router (Sequence Diagram)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
|
||||
participant HQ as HQ / Orchestrator
|
||||
participant R as ResearchAgent
|
||||
participant O as OutlineAgent
|
||||
participant W as WriterAgent
|
||||
participant S as SEOAgent
|
||||
participant C as SchemaAgent
|
||||
participant Q as QAAgent
|
||||
participant P as PublisherAgent
|
||||
participant A as AnalystAgent
|
||||
|
||||
%% ===== BRIEF =====
|
||||
HQ->>R: Brief JSON (stage, persona, intent, keywords, KPI)
|
||||
|
||||
%% ===== RESEARCH =====
|
||||
R->>R: SERP analysis + PAA + competitors
|
||||
R-->>HQ: Research JSON (intents, gaps, angles)
|
||||
|
||||
%% ===== OUTLINE =====
|
||||
HQ->>O: Research JSON
|
||||
O->>O: Build outline (H1-H3, sections, FAQs)
|
||||
O-->>HQ: Outline JSON
|
||||
|
||||
%% ===== WRITING =====
|
||||
HQ->>W: Outline JSON + tone rules
|
||||
W->>W: Draft content (TLDR, sections, internal links)
|
||||
W-->>HQ: Draft MD/HTML
|
||||
|
||||
%% ===== ON-PAGE SEO =====
|
||||
HQ->>S: Draft + keyword map
|
||||
S->>S: Optimize titles, meta, headings, links
|
||||
S-->>HQ: SEO-ready content
|
||||
|
||||
%% ===== STRUCTURED DATA =====
|
||||
HQ->>C: SEO-ready content
|
||||
C->>C: Generate JSON-LD (FAQ, HowTo, Product)
|
||||
C-->>HQ: Content + Schema
|
||||
|
||||
%% ===== QUALITY GATES =====
|
||||
HQ->>Q: Content + Schema
|
||||
Q->>Q: QA checks (intent, dup, canonical, mobile, perf)
|
||||
Q-->>HQ: QA report (pass / fix list)
|
||||
|
||||
%% ===== PUBLISH =====
|
||||
HQ->>P: Approved content
|
||||
P->>P: Publish + index + breadcrumbs
|
||||
P-->>HQ: URL + publish metadata
|
||||
|
||||
%% ===== MEASURE & FEEDBACK =====
|
||||
HQ->>A: URL + KPI
|
||||
A->>A: Analyze GSC/GA signals
|
||||
A-->>HQ: Insights + refresh recommendations
|
||||
```
|
||||
***
|
||||
|
||||
## Jak to czytać (krótko, systemowo)
|
||||
|
||||
### 1. HQ / Orchestrator
|
||||
|
||||
* jedyny „świadomy” agent
|
||||
* zna **etap customer journey**
|
||||
* decyduje **kiedy iterować, a kiedy publikować**
|
||||
|
||||
### 2. Agenci są **wąsko wyspecjalizowani**
|
||||
|
||||
* Research ≠ Outline ≠ Writing ≠ SEO ≠ Schema ≠ QA
|
||||
* zero mieszania odpowiedzialności
|
||||
|
||||
### 3. Artefakty są jawne
|
||||
|
||||
* **JSON** → decyzje
|
||||
* **MD / HTML** → treść
|
||||
* **JSON‑LD** → struktura
|
||||
* **QA report** → bramka decyzyjna
|
||||
|
||||
To dokładnie pasuje do Twojego podejścia:
|
||||
|
||||
> *deterministyczne, audytowalne, reproducible workflows*
|
||||
|
||||
***
|
||||
|
||||
## Bonus: mapowanie agentów na etapy (mental model)
|
||||
|
||||
| Etap | Najważniejszy agent |
|
||||
| ------------- | ------------------- |
|
||||
| Inicjacja | Research + Writer |
|
||||
| Badania | Outline + Writer |
|
||||
| Porównywanie | Writer + SEO |
|
||||
| Transakcja | SEO + Schema |
|
||||
| Doświadczenie | QA + Analyst |
|
||||
|
||||
@@ -0,0 +1,174 @@
|
||||
Poniżej masz **konkretny, README‑ready opis HOOK‑a typu `command‑logger`**, dopasowany do Twojego stylu operacyjnego (OpenClaw / org‑mode / „plaintext productivity”). To **opis projektowy + kontrakt**, nie marketing.
|
||||
|
||||
***
|
||||
|
||||
# HOOK: `command-logger`
|
||||
|
||||
## Cel
|
||||
|
||||
`command-logger` to **globalny hook obserwacyjny**, który **rejestruje każde polecenie / wywołanie SKILL‑a** wraz z kontekstem wykonania, **bez wpływu na logikę biznesową**.
|
||||
Jego jedyną odpowiedzialnością jest **audit trail** i **rekonstrukcja przebiegu pracy**.
|
||||
|
||||
> To jest odpowiednik `bash history + strace + journalctl`, ale na poziomie **AI / SKILL routera**.
|
||||
|
||||
***
|
||||
|
||||
## Miejsce w architekturze
|
||||
|
||||
* typ: **HOOK (side‑effect only)**
|
||||
* moment: **BEFORE + AFTER execution**
|
||||
* zasięg: **router + wszystkie sub‑skills**
|
||||
* brak modyfikacji danych wejściowych/wyjściowych
|
||||
|
||||
<!---->
|
||||
|
||||
User → Router
|
||||
↳ HOOK: command-logger (BEFORE)
|
||||
→ Skill / Sub-skill
|
||||
↳ HOOK: command-logger (AFTER)
|
||||
|
||||
***
|
||||
|
||||
## Co jest logowane (kontrakt)
|
||||
|
||||
### 1. Metadane techniczne
|
||||
|
||||
* `timestamp_start`
|
||||
* `timestamp_end`
|
||||
* `duration_ms`
|
||||
* `session_id`
|
||||
* `trace_id`
|
||||
* `parent_trace_id`
|
||||
* `host` / `agent_id`
|
||||
|
||||
### 2. Kontekst wykonania
|
||||
|
||||
* `actor` (user / system / agent)
|
||||
* `skill_name`
|
||||
* `skill_version`
|
||||
* `hook_phase` (`before` | `after`)
|
||||
* `stage` (np. Inicjacja / Badania / Transakcja)
|
||||
* `intent` (jeśli wykryty przez router)
|
||||
|
||||
### 3. Dane operacyjne (bezpieczne)
|
||||
|
||||
* `command` – **skrót/identyfikator**, nie pełny prompt
|
||||
* `input_fingerprint` (hash / checksum)
|
||||
* `output_fingerprint`
|
||||
* `status` (`ok` | `error`)
|
||||
* `error_type` (jeśli wystąpił)
|
||||
|
||||
> **Zasada**: logujemy **fakty o operacji**, nie jej treść semantyczną.
|
||||
|
||||
***
|
||||
|
||||
## Format zapisu (org‑mode friendly)
|
||||
|
||||
### Jeden plik = jeden strumień pracy
|
||||
|
||||
`command-log.org`
|
||||
|
||||
```org
|
||||
* 2026-03-16 09:12:04 | router
|
||||
:PROPERTIES:
|
||||
:session: 9f3a…
|
||||
:trace: r-001
|
||||
:phase: before
|
||||
:actor: user
|
||||
:stage: Badania
|
||||
:intent: seo-research
|
||||
:END:
|
||||
Command: route → seo-research
|
||||
Input: sha256:8ac7…
|
||||
```
|
||||
|
||||
```org
|
||||
* 2026-03-16 09:12:18 | seo-research
|
||||
:PROPERTIES:
|
||||
:session: 9f3a…
|
||||
:trace: r-001
|
||||
:parent: r-000
|
||||
:phase: after
|
||||
:status: ok
|
||||
:duration_ms: 14231
|
||||
:END:
|
||||
Output: sha256:91bd…
|
||||
```
|
||||
|
||||
✅ spełnia:
|
||||
|
||||
* plaintext
|
||||
* diff‑friendly
|
||||
* audytowalne
|
||||
* nadaje się do grep / ripgrep / org‑agenda
|
||||
|
||||
***
|
||||
|
||||
## Zasady projektowe (ważne)
|
||||
|
||||
### ✅ Co `command-logger` MOŻE
|
||||
|
||||
* rejestrować
|
||||
* tagować
|
||||
* agregować
|
||||
* eksportować (np. do Splunk / JSONL)
|
||||
|
||||
### ❌ Czego NIE MOŻE
|
||||
|
||||
* zmieniać inputu
|
||||
* zmieniać outputu
|
||||
* blokować wykonania
|
||||
* podejmować decyzji
|
||||
|
||||
> Jeśli HOOK zaczyna „myśleć” → to **nie jest już hook**, tylko policy‑engine.
|
||||
|
||||
***
|
||||
|
||||
## Przykładowa definicja (konceptualna)
|
||||
|
||||
```yaml
|
||||
hook:
|
||||
name: command-logger
|
||||
type: observer
|
||||
phases: [before, after]
|
||||
scope: global
|
||||
output:
|
||||
format: org
|
||||
file: command-log.org
|
||||
privacy:
|
||||
log_payload: false
|
||||
use_fingerprints: true
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## Typowe use‑case’y
|
||||
|
||||
* ✅ **rekonstrukcja dnia pracy** („co robiłem i dlaczego”)
|
||||
* ✅ **debug AI** (gdzie poszło nie tak)
|
||||
* ✅ **time audit** pod książkę o produktywności
|
||||
* ✅ **compliance / audit trail**
|
||||
* ✅ **trening systemu** (analiza sekwencji, nie treści)
|
||||
|
||||
***
|
||||
|
||||
## Anty‑wzorce
|
||||
|
||||
❌ logowanie pełnych promptów
|
||||
❌ logowanie danych wrażliwych
|
||||
❌ zależność innych SKILL‑i od loggera
|
||||
❌ brak identyfikatorów sesji / trace
|
||||
|
||||
***
|
||||
|
||||
## TL;DR (jednym zdaniem)
|
||||
|
||||
> **`command-logger` to czarny skrzynkowy rejestr zdarzeń**, który zapisuje *że coś się stało, kiedy, gdzie i z jakim skutkiem* — **bez ingerencji w to, co i dlaczego**.
|
||||
|
||||
***
|
||||
|
||||
Jeśli chcesz, w kolejnym kroku mogę:
|
||||
|
||||
* dodać **diagram Mermaid tylko dla HOOK‑ów**
|
||||
* rozpisać **drugiego hooka**: `decision-logger` (tylko dla routera)
|
||||
* albo przygotować **OpenClaw SKILL: hooks/command-logger** (router + middleware)
|
||||
@@ -0,0 +1,244 @@
|
||||
Poniżej masz **opracowanie merytoryczne** tego materiału – tak, żeby dało się go użyć **do prezentacji, strategii marketingowej, opisu customer journey albo jako rozdział w dokumencie/README**. Trzymam się sensu grafiki, ale rozwijam ją o kontekst i praktyczne wnioski.
|
||||
|
||||
***
|
||||
|
||||
## 1. Czym jest ten model?
|
||||
|
||||
Materiał przedstawia **ścieżkę decyzyjną klienta (Customer Journey)** w procesie zakupowym – od pierwszego kontaktu z potrzebą aż po doświadczenie po zakupie – oraz **rodzaje wyszukiwań**, które użytkownik wykonuje na różnych etapach.
|
||||
|
||||
To połączenie:
|
||||
|
||||
* **etapów decyzyjnych użytkownika**
|
||||
* **intencji wyszukiwania (search intent)**
|
||||
|
||||
Kluczowa idea:
|
||||
👉 *użytkownik w różnych momentach zadaje różne pytania i oczekuje innego typu odpowiedzi / treści*.
|
||||
|
||||
***
|
||||
|
||||
## 2. Etapy ścieżki klienta (górna część diagramu)
|
||||
|
||||
### 2.1 Inicjacja
|
||||
|
||||
**Cel użytkownika:**
|
||||
Uzyskanie podstawowych informacji i zrozumienie problemu lub potrzeby zakupowej.
|
||||
|
||||
**Charakterystyka:**
|
||||
|
||||
* użytkownik dopiero uświadamia sobie potrzebę
|
||||
* nie zna jeszcze marek ani konkretnych produktów
|
||||
* szuka ogólnej wiedzy
|
||||
|
||||
**Typowe pytania:**
|
||||
|
||||
* „co to jest…”
|
||||
* „jak działa…”
|
||||
* „czy warto…”
|
||||
* „jak wybrać…”
|
||||
|
||||
**Przykładowe treści:**
|
||||
|
||||
* artykuły edukacyjne
|
||||
* poradniki „dla początkujących”
|
||||
* wpisy blogowe
|
||||
* wideo wyjaśniające
|
||||
|
||||
👉 **To etap budowania świadomości, nie sprzedaży.**
|
||||
|
||||
***
|
||||
|
||||
### 2.2 Badania
|
||||
|
||||
**Cel użytkownika:**
|
||||
Poznanie dostępnych opcji, rekomendacji i wstępna selekcja produktów.
|
||||
|
||||
**Charakterystyka:**
|
||||
|
||||
* użytkownik zna już kategorię produktu
|
||||
* zaczyna rozpoznawać marki
|
||||
* sprawdza opinie i rankingi
|
||||
|
||||
**Typowe pytania:**
|
||||
|
||||
* „najlepszy …”
|
||||
* „ranking …”
|
||||
* „opinie …”
|
||||
* „polecane …”
|
||||
|
||||
**Przykładowe treści:**
|
||||
|
||||
* rankingi i zestawienia
|
||||
* recenzje
|
||||
* poradniki zakupowe
|
||||
* artykuły „top 10”
|
||||
|
||||
👉 **To etap wpływu i zaufania.**
|
||||
|
||||
***
|
||||
|
||||
### 2.3 Porównywanie
|
||||
|
||||
**Cel użytkownika:**
|
||||
Dogłębne porównanie konkretnych opcji przed podjęciem decyzji.
|
||||
|
||||
**Charakterystyka:**
|
||||
|
||||
* użytkownik ma shortlistę produktów
|
||||
* porównuje parametry, funkcje i cenę
|
||||
* analizuje „za i przeciw”
|
||||
|
||||
**Typowe pytania:**
|
||||
|
||||
* „X vs Y”
|
||||
* „różnice między…”
|
||||
* „czy X ma funkcję…”
|
||||
* „który lepszy…”
|
||||
|
||||
**Przykładowe treści:**
|
||||
|
||||
* porównania 1:1
|
||||
* tabele porównawcze
|
||||
* szczegółowe recenzje
|
||||
* case studies
|
||||
|
||||
👉 **To etap racjonalizacji decyzji.**
|
||||
|
||||
***
|
||||
|
||||
### 2.4 Transakcja
|
||||
|
||||
**Cel użytkownika:**
|
||||
Zakup produktu w najlepszych możliwych warunkach.
|
||||
|
||||
**Charakterystyka:**
|
||||
|
||||
* decyzja jest prawie podjęta
|
||||
* liczy się dostępność, cena, szybkość
|
||||
* użytkownik porównuje sklepy, nie produkt
|
||||
|
||||
**Typowe pytania:**
|
||||
|
||||
* „gdzie kupić…”
|
||||
* „cena …”
|
||||
* „promocja …”
|
||||
* „dostępność …”
|
||||
|
||||
**Przykładowe treści:**
|
||||
|
||||
* strony produktowe
|
||||
* oferty cenowe
|
||||
* landing pages
|
||||
* lokalizatory sklepów
|
||||
|
||||
👉 **To etap konwersji.**
|
||||
|
||||
***
|
||||
|
||||
### 2.5 Doświadczenie
|
||||
|
||||
**Cel użytkownika:**
|
||||
Korzystanie z produktu i kontakt z marką po zakupie.
|
||||
|
||||
**Charakterystyka:**
|
||||
|
||||
* użytkownik jest już klientem
|
||||
* potrzebuje wsparcia lub inspiracji
|
||||
* może wrócić po kolejne zakupy
|
||||
|
||||
**Typowe pytania:**
|
||||
|
||||
* „jak używać…”
|
||||
* „problem z…”
|
||||
* „akcesoria do…”
|
||||
* „serwis / gwarancja”
|
||||
|
||||
**Przykładowe treści:**
|
||||
|
||||
* FAQ
|
||||
* instrukcje
|
||||
* helpdesk / support
|
||||
* cross‑sell i up‑sell
|
||||
|
||||
👉 **To etap lojalności i retencji.**
|
||||
|
||||
***
|
||||
|
||||
## 3. Rodzaje wyszukiwań (dolna część diagramu)
|
||||
|
||||
Te paski pokazują, **jakie typy zapytań dominują na różnych etapach**.
|
||||
|
||||
### 3.1 Wyszukiwanie marki
|
||||
|
||||
* zapytania zawierające nazwę marki
|
||||
* występują na wielu etapach, ale nasilają się od badań do transakcji
|
||||
* świadczą o **rozpoznawalności i zaufaniu**
|
||||
|
||||
👉 Przykład: „Dell laptop”, „Samsung opinie”
|
||||
|
||||
***
|
||||
|
||||
### 3.2 Wyszukiwanie kategorii
|
||||
|
||||
* ogólne zapytania produktowe
|
||||
* dominują na etapie inicjacji i badań
|
||||
* użytkownik jeszcze nie wybrał marki
|
||||
|
||||
👉 Przykład: „laptop do pracy”, „monitor 27 cali”
|
||||
|
||||
***
|
||||
|
||||
### 3.3 Wyszukiwanie styczne (problemowe / tematyczne)
|
||||
|
||||
* zapytania związane z potrzebą lub problemem
|
||||
* często bardzo szerokie
|
||||
* kluczowe na początku ścieżki
|
||||
|
||||
👉 Przykład: „jak przyspieszyć pracę”, „sprzęt do home office”
|
||||
|
||||
***
|
||||
|
||||
### 3.4 Wyszukiwanie konkurencyjnych marek
|
||||
|
||||
* zapytania porównawcze między markami
|
||||
* dominują na etapie porównywania
|
||||
* użytkownik jest blisko decyzji
|
||||
|
||||
👉 Przykład: „Dell vs Lenovo”, „iPhone czy Samsung”
|
||||
|
||||
***
|
||||
|
||||
## 4. Najważniejsze wnioski praktyczne
|
||||
|
||||
### 1️⃣ Jedna treść ≠ jeden użytkownik
|
||||
|
||||
Każdy etap wymaga **innego typu treści i innego języka**.
|
||||
|
||||
### 2️⃣ Sprzedaż za wcześnie nie działa
|
||||
|
||||
Treści transakcyjne na etapie inicjacji są ignorowane.
|
||||
|
||||
### 3️⃣ SEO = intencja, nie słowa kluczowe
|
||||
|
||||
To **intencja użytkownika** decyduje, czy treść zadziała.
|
||||
|
||||
### 4️⃣ Doświadczenie po zakupie to część lejka
|
||||
|
||||
Obsługa, wiedza i wsparcie generują:
|
||||
|
||||
* powroty
|
||||
* rekomendacje
|
||||
* kolejne zakupy
|
||||
|
||||
***
|
||||
|
||||
## 5. Jak możesz to dalej wykorzystać?
|
||||
|
||||
Jeśli chcesz, mogę:
|
||||
|
||||
* ✅ przerobić to na **tekst do prezentacji (slajdy)**
|
||||
* ✅ rozpisać **checklistę treści SEO dla każdego etapu**
|
||||
* ✅ przygotować **wersję techniczną (np. pod AI / Copilota / agentów)**
|
||||
* ✅ zamienić to w **org‑mode / markdown / README**
|
||||
* ✅ narysować **diagram w Mermaid (bez błędów parsera)**
|
||||
|
||||
Powiedz tylko **do czego dokładnie** ma to służyć (marketing, SEO, strategia produktu, dokumentacja, AI-agent).
|
||||
@@ -0,0 +1,625 @@
|
||||
# **Kompletny pakiet OpenClaw SKILL** w układzie **router + sub‑skills**, gotowy do skopiowania jako katalogi z `SKILL.md`.
|
||||
|
||||
Oparłem format o to, że **OpenClaw skill to katalog zawierający `SKILL.md` z YAML frontmatter + instrukcje**, a skills są ładowane m.in. z `<workspace>/skills` oraz `~/.openclaw/skills` (z priorytetem workspace > local > bundled).
|
||||
W samym pliku frontmatter typowo występują pola jak `name`, `description`, opcjonalnie `version`, `trigger`, `tools` itd. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills), [\[openclaws.io\]](https://openclaws.io/docs/tools/skills/), [\[deepwiki.com\]](https://deepwiki.com/lekt9/openclaw-foundry/5.1-skill-format-and-structure) [\[clawdocs.org\]](https://clawdocs.org/guides/skill-development/), [\[deepwiki.com\]](https://deepwiki.com/lekt9/openclaw-foundry/5.1-skill-format-and-structure)
|
||||
|
||||
Dodatkowo w QA uwzględniłem bramki SEO, które przewijają się w materiałach typu “SEO recommendations / requirements”: m.in. **duplicate content, canonicalization, pagination, structured data, IA, on‑page, performance, mobile-first**.
|
||||
|
||||
***
|
||||
|
||||
## 1) Struktura katalogów (wklej do `<workspace>/skills/`)
|
||||
|
||||
skills/
|
||||
seo-ai-router/
|
||||
SKILL.md
|
||||
artifacts/
|
||||
brief.schema.json
|
||||
research.schema.json
|
||||
outline.schema.json
|
||||
draft.schema.json
|
||||
qa.schema.json
|
||||
|
||||
seo-research/
|
||||
SKILL.md
|
||||
|
||||
seo-outline/
|
||||
SKILL.md
|
||||
|
||||
seo-writer/
|
||||
SKILL.md
|
||||
|
||||
seo-onpage/
|
||||
SKILL.md
|
||||
|
||||
seo-schema/
|
||||
SKILL.md
|
||||
|
||||
seo-qa-gates/
|
||||
SKILL.md
|
||||
|
||||
seo-publish/
|
||||
SKILL.md
|
||||
|
||||
seo-measure-refresh/
|
||||
SKILL.md
|
||||
|
||||
***
|
||||
|
||||
## 2) Router SKILL — `skills/seo-ai-router/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-ai-router
|
||||
version: 1.0.0
|
||||
description: Router i orkiestrator procesu tworzenia tresci SEO per etap customer journey (Inicjacja->Badania->Porownywanie->Transakcja->Doswiadczenie) z artefaktami JSON i bramkami QA.
|
||||
trigger: "seo pipeline|seo workflow|customer journey|inicjacja|badania|porownywanie|transakcja|doswiadczenie|checklista seo|seo machine"
|
||||
tools: [filesystem, browser, http, shell]
|
||||
---
|
||||
|
||||
# SEO AI Router (Customer Journey)
|
||||
|
||||
## Cel
|
||||
Gdy uzytkownik prosi o tresc SEO, strategie, checklisty, artykul, landing, porownanie lub material pod dowolny etap sciezki zakupowej,
|
||||
ten skill ma:
|
||||
1) wykryc etap i intencje,
|
||||
2) wygenerowac artefakty (Brief -> Research -> Outline -> Draft -> OnPage -> Schema -> QA -> Publish -> Measure),
|
||||
3) wywolac (konceptualnie) sub-skills w odpowiedniej kolejnosci.
|
||||
|
||||
## Kiedy uzywac
|
||||
Aktywuj, gdy prosba dotyczy:
|
||||
- tworzenia/planowania tresci SEO,
|
||||
- dopasowania do intencji/funnel/journey,
|
||||
- przygotowania materialu “pod AI/agentow”,
|
||||
- wdrozenia procesu content ops (research->publish->refresh).
|
||||
|
||||
## Detekcja etapu (reguly)
|
||||
- Inicjacja: definicje, "co to jest", edukacja, problem
|
||||
- Badania: rankingi, opinie, przewodniki zakupowe
|
||||
- Porownywanie: "X vs Y", alternatywy, tabele, kalkulatory
|
||||
- Transakcja: "kup", "cena", "gdzie kupic", landing/product/pricing
|
||||
- Doswiadczenie: instrukcje, KB, troubleshooting, posprzedaz
|
||||
|
||||
Jesli niejasne: przyjmij Badania jako domysl i w brief oznacz `stage_confidence: low`.
|
||||
|
||||
## Kontrakt artefaktow (pliki lub bloki w odpowiedzi)
|
||||
W kazdym kroku generuj JSON zgodny z prostym schematem:
|
||||
- `brief.json`
|
||||
- `research.json`
|
||||
- `outline.json`
|
||||
- `draft.md` (lub html)
|
||||
- `onpage.json`
|
||||
- `schema.jsonld`
|
||||
- `qa.json`
|
||||
- `publish.json`
|
||||
- `measure.json`
|
||||
|
||||
## Orkiestracja (kolejnosc sub-skills)
|
||||
1) Uruchom **seo-research**
|
||||
2) Uruchom **seo-outline**
|
||||
3) Uruchom **seo-writer**
|
||||
4) Uruchom **seo-onpage**
|
||||
5) Uruchom **seo-schema**
|
||||
6) Uruchom **seo-qa-gates**
|
||||
7) Uruchom **seo-publish**
|
||||
8) Uruchom **seo-measure-refresh**
|
||||
|
||||
## Wyjscie finalne dla uzytkownika
|
||||
Zawsze zwroc:
|
||||
- gotowy artefakt docelowy (np. artykul/landing/KB),
|
||||
- oraz komplet JSON-ow (albo “bundle” w jednej odpowiedzi),
|
||||
- oraz liste decyzji: etap, intencja, target, CTA, linkowanie wewn.
|
||||
|
||||
## Notatka o snippetach (meta)
|
||||
Pamietaj: snippet w wynikach wyszukiwania jest zwykle generowany z tresci strony, ale meta description moze zostac uzyte, gdy lepiej opisuje strone.
|
||||
Uwzglednij to w kroku seo-onpage.
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 3) Sub-skill: Research — `skills/seo-research/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-research
|
||||
version: 1.0.0
|
||||
description: Research SEO: intencja, pytania, katy, konkurencja, mapa slow kluczowych pod etap customer journey.
|
||||
trigger: "seo research|intencja|paa|faq|konkurencja|serp"
|
||||
tools: [browser, http]
|
||||
---
|
||||
|
||||
# SEO Research Agent
|
||||
|
||||
## Wejscie
|
||||
Oczekuj `brief.json`:
|
||||
- stage, persona, intent, topic, geo/lang, KPI
|
||||
|
||||
## Kroki
|
||||
1) Okresl primary intent: informational / commercial / transactional / navigational.
|
||||
2) Zbierz liste pytan (FAQ/PAA style) + obiekcje + synonimy.
|
||||
3) Zaproponuj 3-5 katow (angles) dopasowanych do etapu:
|
||||
- Inicjacja: edukacja, definicja, problem->rozwiazanie
|
||||
- Badania: metodologia, kryteria, ranking
|
||||
- Porownywanie: roznice, trade-offs, "dla kogo"
|
||||
- Transakcja: wartosc, oferta, dowody, CTA
|
||||
- Doswiadczenie: diagnoza, kroki naprawy, KB
|
||||
4) Zbuduj mapowanie: query cluster -> sekcje strony (H2/H3).
|
||||
5) Zapisz `research.json`.
|
||||
|
||||
## Output: research.json (minimal)
|
||||
{
|
||||
"stage": "...",
|
||||
"intent": "...",
|
||||
"topic": "...",
|
||||
"keyword_clusters": [
|
||||
{"cluster":"...", "queries":["..."], "notes":"..."}
|
||||
],
|
||||
"questions": ["..."],
|
||||
"objections": ["..."],
|
||||
"angles": ["..."],
|
||||
"internal_links_suggested": {
|
||||
"prev_stage": ["..."],
|
||||
"next_stage": ["..."]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 4) Sub-skill: Outline — `skills/seo-outline/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-outline
|
||||
version: 1.0.0
|
||||
description: Buduje outline H1-H3 + FAQ + plan linkowania wewnetrznego na podstawie research.
|
||||
trigger: "outline|struktura|h2|h3|plan tresci"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO Outline Agent
|
||||
|
||||
## Wejscie
|
||||
`research.json`
|
||||
|
||||
## Kroki
|
||||
1) Stworz H1 zgodny z intencja.
|
||||
2) Zaprojektuj H2/H3 tak, by:
|
||||
- w pierwszych sekcjach odpowiadac “wprost” na potrzebe,
|
||||
- pokrywac klastry slow kluczowych,
|
||||
- dodac FAQ (Q/A).
|
||||
3) Dodaj sekcje “dla kogo”, “kiedy wybrac”, “alternatywy” jesli etap >= Badania.
|
||||
4) Ustal CTA i linki do poprzedniego/nastepnego etapu.
|
||||
|
||||
## Output: outline.json
|
||||
{
|
||||
"h1": "...",
|
||||
"sections": [
|
||||
{"h2":"...", "h3":["..."], "intent_note":"..."}
|
||||
],
|
||||
"faq": [{"q":"...", "a_hint":"..."}],
|
||||
"cta": {"primary":"...", "secondary":"..."},
|
||||
"internal_links": [{"anchor":"...", "target":"..."}]
|
||||
}
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 5) Sub-skill: Writer — `skills/seo-writer/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-writer
|
||||
version: 1.0.0
|
||||
description: Pisze draft na podstawie outline; dodaje TLDR, przyklady, sekcje dopasowane do etapu.
|
||||
trigger: "napisz|draft|artykul|landing|kb"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO Writer Agent
|
||||
|
||||
## Wejscie
|
||||
`outline.json`
|
||||
|
||||
## Kroki
|
||||
1) Napisz wersje 1 w Markdown:
|
||||
- TLDR na gorze (2-5 zdan)
|
||||
- H2/H3 zgodnie z outline
|
||||
2) Styl:
|
||||
- Inicjacja: edukacyjnie, bez sprzedazy
|
||||
- Badania: kryteria + metodologia + rekomendacje
|
||||
- Porownywanie: trade-offs, tabela roznic (tekstowo)
|
||||
- Transakcja: wartosc, dowody, CTA
|
||||
- Doswiadczenie: szybka diagnoza + kroki
|
||||
3) Dodaj sekcje FAQ.
|
||||
4) Dodaj placeholdery do linkow wewnetrznych.
|
||||
|
||||
## Output
|
||||
- `draft.md`
|
||||
- `draft.json` (opcjonalnie): streszczenie + kluczowe tezy
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 6) Sub-skill: On-page — `skills/seo-onpage/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-onpage
|
||||
version: 1.0.0
|
||||
description: On-page SEO: title, meta description, naglowki, link text, IA, canonical/pagination checklist.
|
||||
trigger: "meta title|meta description|onpage|optymalizacja"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO On-page Agent
|
||||
|
||||
## Wejscie
|
||||
`draft.md` + `research.json`
|
||||
|
||||
## Kroki
|
||||
1) Uloz Title i Meta Description:
|
||||
- unikalne,
|
||||
- zgodne z intencja,
|
||||
- streszczaja i zachecaja (meta moze byc uzyte jako snippet, gdy lepiej opisuje strone niz fragment tresci).
|
||||
2) Sprawdz zgodnosc H1/H2/H3 z klastrami.
|
||||
3) Popraw linki wewnetrzne:
|
||||
- anchor text opisowy,
|
||||
- logiczny flow prev/next stage.
|
||||
4) Zapisz `onpage.json`:
|
||||
- title, description,
|
||||
- link plan,
|
||||
- uwagi do IA.
|
||||
5) Dodaj tech-checklist:
|
||||
- duplicate content / canonical / pagination / indexing.
|
||||
|
||||
## Output: onpage.json
|
||||
{
|
||||
"title": "...",
|
||||
"meta_description": "...",
|
||||
"internal_links": [{"anchor":"...", "target":"..."}],
|
||||
"tech_notes": ["duplicate content", "canonical", "pagination", "indexing"]
|
||||
}
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 7) Sub-skill: Structured Data — `skills/seo-schema/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-schema
|
||||
version: 1.0.0
|
||||
description: Dobiera i generuje JSON-LD (FAQ/HowTo/Product/Offer/Breadcrumb) na podstawie typu strony.
|
||||
trigger: "schema|json-ld|structured data|faq schema|howto schema"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO Schema Agent
|
||||
|
||||
## Wejscie
|
||||
`draft.md` + `onpage.json` + stage
|
||||
|
||||
## Kroki
|
||||
1) Dobierz typ:
|
||||
- FAQPage: gdy masz realne Q/A
|
||||
- HowTo: gdy masz kroki
|
||||
- Product/Offer: gdy to strona produktu/oferty
|
||||
- BreadcrumbList: gdy to strona w hierarchii
|
||||
2) Wygeneruj `schema.jsonld` jako JSON-LD.
|
||||
3) Dodaj notatke: structured data wspiera rich results i “zrozumienie” tresci przez wyszukiwarki.
|
||||
|
||||
## Output
|
||||
- `schema.jsonld`
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 8) Sub-skill: QA Gates — `skills/seo-qa-gates/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-qa-gates
|
||||
version: 1.0.0
|
||||
description: Bramki jakosci SEO: intencja, duplikacja/canonical/pagination, structured data, linki, mobile-first, performance.
|
||||
trigger: "qa seo|bramki|quality gates|audit"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO QA Gates Agent
|
||||
|
||||
## Wejscie
|
||||
`draft.md` + `onpage.json` + `schema.jsonld`
|
||||
|
||||
## Bramki (PASS/FAIL + fixlist)
|
||||
1) Intent match: czy tresc odpowiada na intencje etapu?
|
||||
2) Meta: Title/Description unikalne i zgodne z trescia.
|
||||
3) Tech: duplicate content, canonicalization, pagination, indexing.
|
||||
4) Structured data: czy pasuje do strony i jest sensowne.
|
||||
5) Linki: opisowy anchor text + crawlable (typowy problem w audytach).
|
||||
6) Mobile-first + performance (traktuj jako release gate).
|
||||
|
||||
## Output: qa.json
|
||||
{
|
||||
"status": "pass|fail",
|
||||
"checks": [
|
||||
{"name":"intent", "status":"pass|fail", "notes":"..."},
|
||||
{"name":"meta", "status":"pass|fail", "notes":"..."},
|
||||
{"name":"tech", "status":"pass|fail", "notes":"..."},
|
||||
{"name":"schema", "status":"pass|fail", "notes":"..."},
|
||||
{"name":"links", "status":"pass|fail", "notes":"..."},
|
||||
{"name":"mobile_perf", "status":"pass|fail", "notes":"..."}
|
||||
],
|
||||
"fixlist": ["..."]
|
||||
}
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 9) Sub-skill: Publish — `skills/seo-publish/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-publish
|
||||
version: 1.0.0
|
||||
description: Przygotowanie do publikacji: URL, breadcrumbs, mapowanie do kategorii, plan indeksacji, checklist pre-publish.
|
||||
trigger: "publish|publikuj|wdroz|deploy content"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO Publish Agent
|
||||
|
||||
## Wejscie
|
||||
`qa.json` + `draft.md` + `onpage.json` + `schema.jsonld`
|
||||
|
||||
## Reguly
|
||||
- Jesli QA fail: nie publikuj, zwroc fixlist.
|
||||
- Jesli QA pass:
|
||||
1) Zaproponuj slug URL (ASCII, krotki).
|
||||
2) Zapisz paczke: content + schema + meta.
|
||||
3) Zapisz `publish.json` z polami:
|
||||
- url_slug
|
||||
- breadcrumbs
|
||||
- next_refresh_hint
|
||||
|
||||
## Output: publish.json
|
||||
{
|
||||
"url_slug": "...",
|
||||
"breadcrumbs": ["...","..."],
|
||||
"publish_notes": ["..."],
|
||||
"next_refresh_hint": "..."
|
||||
}
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## 10) Sub-skill: Measure & Refresh — `skills/seo-measure-refresh/SKILL.md`
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: seo-measure-refresh
|
||||
version: 1.0.0
|
||||
description: Pomiar i refresh: sygnaly z ruchu, CTR, nowe pytania, plan aktualizacji, retarget do kolejnego etapu.
|
||||
trigger: "measure|refresh|aktualizacja|performance review seo"
|
||||
tools: [filesystem]
|
||||
---
|
||||
|
||||
# SEO Measure & Refresh Agent
|
||||
|
||||
## Wejscie
|
||||
`publish.json` + KPI z brief
|
||||
|
||||
## Kroki
|
||||
1) Zdefiniuj “refresh triggers”:
|
||||
- spadek CTR,
|
||||
- zmiana intencji,
|
||||
- nowe pytania,
|
||||
- nowy konkurent/format SERP.
|
||||
2) Zaproponuj plan refresh:
|
||||
- update meta,
|
||||
- rozbudowa FAQ,
|
||||
- dodanie sekcji porownawczej lub CTA do kolejnego etapu.
|
||||
3) Output `measure.json`.
|
||||
|
||||
## Output: measure.json
|
||||
{
|
||||
"signals": ["..."],
|
||||
"hypotheses": ["..."],
|
||||
"refresh_actions": ["..."],
|
||||
"next_review_window": "..."
|
||||
}
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
# 11) (Opcjonalnie) Minimalne schematy JSON (router artifacts)
|
||||
|
||||
Jeśli chcesz walidować artefakty, wrzuć te pliki do `skills/seo-ai-router/artifacts/`. To są ultra-proste schematy (bez zależności).
|
||||
|
||||
### `brief.schema.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
||||
"type": "object",
|
||||
"required": ["stage", "topic", "intent"],
|
||||
"properties": {
|
||||
"stage": {"type": "string"},
|
||||
"topic": {"type": "string"},
|
||||
"intent": {"type": "string"},
|
||||
"persona": {"type": "string"},
|
||||
"kpi": {"type": "array", "items": {"type": "string"}},
|
||||
"stage_confidence": {"type": "string"}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
(Pozostałe schematy mogę Ci dopisać analogicznie, ale już teraz masz “działający” pakiet — OpenClaw nie wymaga schematów, to tylko Twoje QA/porządek.)
|
||||
|
||||
***
|
||||
|
||||
## Jak tego używać (praktycznie, bez filozofii)
|
||||
|
||||
1. Skopiuj katalogi do `<workspace>/skills/` (to ma najwyższy priorytet ładowania skills). [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills), [\[openclaws.io\]](https://openclaws.io/docs/tools/skills/)
|
||||
2. W rozmowie piszesz np.:
|
||||
* „Zrob mi content pod etap Porownywanie dla \[temat]”
|
||||
* „Przygotuj landing pod Transakcja dla \[produkt]”
|
||||
* „Zrob KB pod Doswiadczenie: jak naprawic \[problem]”
|
||||
|
||||
Router ma wtedy poprowadzić agentową sekwencję i zwrócić paczkę artefaktów.
|
||||
|
||||
***
|
||||
|
||||
|
||||
> Mała uwaga techniczna: w Mermaid **nie używaj słowa `end` jako tekstu w węźle flowchart** (potrafi „wywalić” parser) — lepiej `END` albo `[END]`.\
|
||||
> Dla sequenceDiagram `alt/else/loop` są wspierane wprost. [\[mermaid.ai\]](https://mermaid.ai/open-source/syntax/flowchart.html), [\[emersonbot....github.io\]](https://emersonbottero.github.io/mermaid-docs/syntax/flowchart.html) [\[docs.merma...viewer.com\]](https://docs.mermaidviewer.com/diagrams/sequence.html), [\[mermaid.ai\]](https://mermaid.ai/open-source/syntax/examples.html), [\[emersonbot....github.io\]](https://emersonbottero.github.io/mermaid-docs/syntax/sequenceDiagram.html)
|
||||
|
||||
***
|
||||
|
||||
## 1) Diagram (Flowchart): Router + artefakty + QA gates + retry loop
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
%% =========================
|
||||
%% ENTRY
|
||||
%% =========================
|
||||
U[User request: temat + cel] --> R0[Router: detect stage + intent]
|
||||
R0 --> D1{Stage detected?}
|
||||
D1 -->|yes| BR[brief.json]
|
||||
D1 -->|no| BR_LOW[brief.json + stage_confidence=low]
|
||||
|
||||
%% =========================
|
||||
%% STAGE MAP (customer journey)
|
||||
%% =========================
|
||||
subgraph ST["Stage map"]
|
||||
S1[Inicjacja]
|
||||
S2[Badania]
|
||||
S3[Porownywanie]
|
||||
S4[Transakcja]
|
||||
S5[Doswiadczenie]
|
||||
S1 --> S2 --> S3 --> S4 --> S5
|
||||
end
|
||||
|
||||
BR --> ST
|
||||
BR_LOW --> ST
|
||||
|
||||
%% =========================
|
||||
%% PIPELINE
|
||||
%% =========================
|
||||
subgraph PL["AI Pipeline (artefakty)"]
|
||||
direction TB
|
||||
P1[seo-research] --> A1[research.json]
|
||||
A1 --> P2[seo-outline] --> A2[outline.json]
|
||||
A2 --> P3[seo-writer] --> A3[draft.md]
|
||||
A3 --> P4[seo-onpage] --> A4[onpage.json]
|
||||
A4 --> P5[seo-schema] --> A5[schema.jsonld]
|
||||
A5 --> P6[seo-qa-gates] --> A6[qa.json]
|
||||
A6 --> DEC_QA{QA status?}
|
||||
end
|
||||
|
||||
BR --> P1
|
||||
BR_LOW --> P1
|
||||
|
||||
%% =========================
|
||||
%% QA BRANCHING + FIX LOOP
|
||||
%% =========================
|
||||
DEC_QA -->|pass| P7[seo-publish] --> A7[publish.json]
|
||||
DEC_QA -->|fail| FIX[Fixlist: what to change]
|
||||
FIX --> P3
|
||||
|
||||
%% =========================
|
||||
%% PUBLISH + MEASURE
|
||||
%% =========================
|
||||
A7 --> P8[seo-measure-refresh] --> A8[measure.json]
|
||||
A8 --> DEC_REFRESH{Refresh needed?}
|
||||
DEC_REFRESH -->|yes| P1
|
||||
DEC_REFRESH -->|no| OUT[Output bundle: content + JSON artifacts]
|
||||
|
||||
%% =========================
|
||||
%% QA GATES DETAILS (what QA checks)
|
||||
%% =========================
|
||||
subgraph QA["QA Gates (co sprawdzamy)"]
|
||||
direction TB
|
||||
Q1[Intent match: etap vs tresc]
|
||||
Q2[Meta: title + description unique]
|
||||
Q3[Tech: duplicate/canonical/pagination/indexing]
|
||||
Q4[Structured data: FAQ/HowTo/Product when fits]
|
||||
Q5[Links: opisowe + crawlable]
|
||||
Q6[Mobile-first + performance]
|
||||
end
|
||||
|
||||
P6 --> QA
|
||||
```
|
||||
|
||||
Dlaczego to jest „bardziej szczegółowe”:
|
||||
|
||||
* Masz **artefakty jako węzły** (`brief.json`, `research.json`, `outline.json`, `draft.md`, `onpage.json`, `schema.jsonld`, `qa.json`, `publish.json`, `measure.json`)
|
||||
* Jest **gałąź QA pass/fail** oraz **pętla naprawcza** (wracasz do `seo-writer` i przechodzisz dalej)
|
||||
* Jest **pętla refresh** po pomiarach (wraca do research, jeśli trzeba)
|
||||
* Jest osobny subgraph „QA Gates” opisujący *co* sprawdzasz (zgodne z tym, co przewija się w checklistach SEO: duplicate/canonical/pagination/structured data/perf/mobile etc.).
|
||||
## 2) Diagram (Sequence): Router + sub‑skills + alt/loop/opt + artefakty
|
||||
|
||||
Ten wariant jest „bardziej operacyjny” — pokazuje kto (który agent) co produkuje i kiedy następuje retry.
|
||||
|
||||
``` mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
|
||||
participant U as User
|
||||
participant HQ as Orchestrator
|
||||
participant R as seo-research
|
||||
participant O as seo-outline
|
||||
participant W as seo-writer
|
||||
participant S as seo-onpage
|
||||
participant SC as seo-schema
|
||||
participant Q as seo-qa-gates
|
||||
participant PB as seo-publish
|
||||
participant M as seo-measure-refresh
|
||||
|
||||
U->>HQ: Request (topic, goal, stage optional)
|
||||
HQ->>HQ: Detect stage + intent
|
||||
HQ-->>U: Plan preview (stage, intent, artifacts list)
|
||||
|
||||
HQ->>R: brief.json
|
||||
R-->>HQ: research.json
|
||||
|
||||
HQ->>O: research.json
|
||||
O-->>HQ: outline.json
|
||||
|
||||
HQ->>W: outline.json
|
||||
W-->>HQ: draft.md
|
||||
|
||||
HQ->>S: draft.md + research.json
|
||||
S-->>HQ: onpage.json (title, meta, links)
|
||||
|
||||
HQ->>SC: draft.md + onpage.json
|
||||
SC-->>HQ: schema.jsonld
|
||||
|
||||
loop QA until pass
|
||||
HQ->>Q: draft.md + onpage.json + schema.jsonld
|
||||
Q-->>HQ: qa.json (pass/fail + fixlist)
|
||||
|
||||
alt QA fail
|
||||
HQ->>W: fixlist + outline.json
|
||||
W-->>HQ: draft.md (revised)
|
||||
HQ->>S: draft.md update
|
||||
S-->>HQ: onpage.json update
|
||||
HQ->>SC: schema update if needed
|
||||
SC-->>HQ: schema.jsonld
|
||||
else QA pass
|
||||
HQ->>PB: content bundle
|
||||
PB-->>HQ: publish.json (slug, notes)
|
||||
end
|
||||
end
|
||||
|
||||
opt Measure and refresh
|
||||
HQ->>M: publish.json + KPI
|
||||
M-->>HQ: measure.json (signals + refresh plan)
|
||||
end
|
||||
|
||||
HQ-->>U: Final bundle (content + JSON artifacts)
|
||||
```
|
||||
|
||||
`loop`, `alt/else`, `opt` są natywnie wspierane w Mermaid sequenceDiagram (to standardowy sposób na pokazanie retry i warunków). [\[docs.merma...viewer.com\]](https://docs.mermaidviewer.com/diagrams/sequence.html), [\[mermaid.ai\]](https://mermaid.ai/open-source/syntax/examples.html), [\[emersonbot....github.io\]](https://emersonbottero.github.io/mermaid-docs/syntax/sequenceDiagram.html)
|
||||
|
||||
***
|
||||
@@ -0,0 +1,596 @@
|
||||
# GEO vs SEO – optymalizacja treści pod AI a tradycyjne SEO
|
||||
|
||||
**Generative Engine Optimization (GEO)** to podejście uzupełniające klasyczne SEO, skupione na tym, by treści były **cytowane przez systemy AI** (ChatGPT, Perplexity, Google SGE itp.), a nie tylko wysoko pozycjonowane w wynikach wyszukiwarek. Poniżej znajduje się podsumowanie kluczowych różnic między GEO a SEO, a następnie szczegółowa analiza infografiki „The Anatomy of a GEO‑Optimized Blog Post” oraz porównanie zaleceń GEO z zasadami SEO.
|
||||
|
||||
<!-- Copilot-Researcher-Visualization -->
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--accent: #464feb;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, #b0beff 15%, #b0beff 85%, transparent 100%);
|
||||
--timeline-border: #ffffff;
|
||||
--bg-card: #f5f7fa;
|
||||
--bg-hover: #ebefff;
|
||||
--text-title: #424242;
|
||||
--text-accent: var(--accent);
|
||||
--text-sub: #424242;
|
||||
--radius: 12px;
|
||||
--border: #e0e0e0;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.06);
|
||||
--hover-shadow: 0 4px 14px rgba(39, 16, 16, 0.1);
|
||||
--font: "Segoe Sans", "Segoe UI", "Segoe UI Web (West European)", -apple-system, "system-ui", Roboto, "Helvetica Neue", sans-serif;
|
||||
--overflow-wrap: break-word;
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--accent: #7385ff;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, transparent 3%, #6264a7 30%, #6264a7 50%, transparent 97%, transparent 100%);
|
||||
--timeline-border: #424242;
|
||||
--bg-card: #1a1a1a;
|
||||
--bg-hover: #2a2a2a;
|
||||
--text-title: #ffffff;
|
||||
--text-sub: #ffffff;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.3);
|
||||
--hover-shadow: 0 4px 14px rgba(0, 0, 0, 0.5);
|
||||
--border: #3d3d3d;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-contrast: more),
|
||||
(forced-colors: active) {
|
||||
:root {
|
||||
--accent: ActiveText;
|
||||
--timeline-ln: ActiveText;
|
||||
--timeline-border: Canvas;
|
||||
--bg-card: Canvas;
|
||||
--bg-hover: Canvas;
|
||||
--text-title: CanvasText;
|
||||
--text-sub: CanvasText;
|
||||
--shadow: 0 2px 10px Canvas;
|
||||
--hover-shadow: 0 4px 14px Canvas;
|
||||
--border: ButtonBorder;
|
||||
}
|
||||
}
|
||||
|
||||
.insights-container {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2,minmax(240px,1fr));
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
margin: 0 0;
|
||||
font-family: var(--font);
|
||||
}
|
||||
|
||||
.insight-card:last-child:nth-child(odd){
|
||||
grid-column: 1 / -1;
|
||||
}
|
||||
|
||||
.insight-card {
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
box-shadow: var(--shadow);
|
||||
min-width: 220px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
}
|
||||
|
||||
.insight-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.insight-card h4 {
|
||||
margin: 0px 0px 8px 0px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
font-weight: 600;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.insight-card .icon {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 20px;
|
||||
height: 20px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.insight-card p {
|
||||
font-size: 0.92rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.5;
|
||||
margin: 0px;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.insight-card p b, .insight-card p strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metrics-container {
|
||||
display:grid;
|
||||
grid-template-columns:repeat(2,minmax(210px,1fr));
|
||||
font-family: var(--font);
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.metric-card:last-child:nth-child(odd){
|
||||
grid-column:1 / -1;
|
||||
}
|
||||
|
||||
.metric-card {
|
||||
flex: 1 1 210px;
|
||||
padding: 16px;
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
text-align: center;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.metric-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.metric-card h4 {
|
||||
margin: 0px;
|
||||
font-size: 1rem;
|
||||
color: var(--text-title);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metric-card .metric-card-value {
|
||||
margin: 0px;
|
||||
font-size: 1.4rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.metric-card p {
|
||||
font-size: 0.85rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.45;
|
||||
margin: 0;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.timeline-container {
|
||||
position: relative;
|
||||
margin: 0 0 0 0;
|
||||
padding: 0px 16px 0px 56px;
|
||||
list-style: none;
|
||||
font-family: var(--font);
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: calc(-40px + 56px);
|
||||
width: 2px;
|
||||
height: 100%;
|
||||
background: var(--timeline-ln);
|
||||
}
|
||||
|
||||
.timeline-container > li {
|
||||
position: relative;
|
||||
margin-bottom: 16px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
border-radius: var(--radius);
|
||||
background: var(--bg-card);
|
||||
border: 1px solid var(--border);
|
||||
}
|
||||
|
||||
.timeline-container > li:last-child {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.timeline-container > li:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.timeline-container > li::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 18px;
|
||||
left: -40px;
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
background: var(--accent);
|
||||
border: var(--timeline-border) 2px solid;
|
||||
border-radius: 50%;
|
||||
transform: translateX(-50%);
|
||||
box-shadow: 0px 0px 2px 0px #00000012, 0px 4px 8px 0px #00000014;
|
||||
}
|
||||
|
||||
.timeline-container > li h4 {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
}
|
||||
|
||||
.timeline-container > li h4 em {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
.timeline-container > li * {
|
||||
margin: 0;
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container > li * b, .timeline-container > li * strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
@media (max-width:600px){
|
||||
.metrics-container,
|
||||
.insights-container{
|
||||
grid-template-columns:1fr;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
<div class="insights-container">
|
||||
<div class="insight-card">
|
||||
<h4>Cel: Rankingi vs. Odpowiedzi AI</h4>
|
||||
<p>SEO dąży do wysokiej pozycji strony w wynikach Google, podczas gdy GEO – do bycia uwzględnionym jako <b>źródło odpowiedzi</b> generowanej przez AI.</p>
|
||||
</div>
|
||||
<div class="insight-card">
|
||||
<h4>Wspólna baza, nowe wymagania</h4>
|
||||
<p>GEO opiera się na fundamentach SEO (jakość treści, słowa kluczowe, linki), dodając nacisk na <b>strukturę pytań i odpowiedzi</b>, aktualność oraz <b>cytowalność</b> treści, aby ułatwić AI wybór naszej strony jako źródła.</p>
|
||||
</div>
|
||||
<div class="insight-card">
|
||||
<h4>Treść pod AI</h4>
|
||||
<p>W GEO treść jest tworzona tak, by <b>od razu odpowiadać na pytania</b> użytkownika, zawierać źródła i dane – AI preferuje konkrety. W SEO częściej rozwija się temat stopniowo, licząc na kliknięcie i <b>dalsze czytanie na stronie</b>.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Copilot-Researcher-Visualization -->
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--accent: #464feb;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, #b0beff 15%, #b0beff 85%, transparent 100%);
|
||||
--timeline-border: #ffffff;
|
||||
--bg-card: #f5f7fa;
|
||||
--bg-hover: #ebefff;
|
||||
--text-title: #424242;
|
||||
--text-accent: var(--accent);
|
||||
--text-sub: #424242;
|
||||
--radius: 12px;
|
||||
--border: #e0e0e0;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.06);
|
||||
--hover-shadow: 0 4px 14px rgba(39, 16, 16, 0.1);
|
||||
--font: "Segoe Sans", "Segoe UI", "Segoe UI Web (West European)", -apple-system, "system-ui", Roboto, "Helvetica Neue", sans-serif;
|
||||
--overflow-wrap: break-word;
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--accent: #7385ff;
|
||||
--timeline-ln: linear-gradient(to bottom, transparent 0%, transparent 3%, #6264a7 30%, #6264a7 50%, transparent 97%, transparent 100%);
|
||||
--timeline-border: #424242;
|
||||
--bg-card: #1a1a1a;
|
||||
--bg-hover: #2a2a2a;
|
||||
--text-title: #ffffff;
|
||||
--text-sub: #ffffff;
|
||||
--shadow: 0 2px 10px rgba(0, 0, 0, 0.3);
|
||||
--hover-shadow: 0 4px 14px rgba(0, 0, 0, 0.5);
|
||||
--border: #3d3d3d;
|
||||
}
|
||||
}
|
||||
|
||||
@media (prefers-contrast: more),
|
||||
(forced-colors: active) {
|
||||
:root {
|
||||
--accent: ActiveText;
|
||||
--timeline-ln: ActiveText;
|
||||
--timeline-border: Canvas;
|
||||
--bg-card: Canvas;
|
||||
--bg-hover: Canvas;
|
||||
--text-title: CanvasText;
|
||||
--text-sub: CanvasText;
|
||||
--shadow: 0 2px 10px Canvas;
|
||||
--hover-shadow: 0 4px 14px Canvas;
|
||||
--border: ButtonBorder;
|
||||
}
|
||||
}
|
||||
|
||||
.insights-container {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2,minmax(240px,1fr));
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
margin: 0 0;
|
||||
font-family: var(--font);
|
||||
}
|
||||
|
||||
.insight-card:last-child:nth-child(odd){
|
||||
grid-column: 1 / -1;
|
||||
}
|
||||
|
||||
.insight-card {
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
box-shadow: var(--shadow);
|
||||
min-width: 220px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
}
|
||||
|
||||
.insight-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.insight-card h4 {
|
||||
margin: 0px 0px 8px 0px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
font-weight: 600;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.insight-card .icon {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
width: 20px;
|
||||
height: 20px;
|
||||
font-size: 1.1rem;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.insight-card p {
|
||||
font-size: 0.92rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.5;
|
||||
margin: 0px;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.insight-card p b, .insight-card p strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metrics-container {
|
||||
display:grid;
|
||||
grid-template-columns:repeat(2,minmax(210px,1fr));
|
||||
font-family: var(--font);
|
||||
padding: 0px 16px 0px 16px;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.metric-card:last-child:nth-child(odd){
|
||||
grid-column:1 / -1;
|
||||
}
|
||||
|
||||
.metric-card {
|
||||
flex: 1 1 210px;
|
||||
padding: 16px;
|
||||
background-color: var(--bg-card);
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
text-align: center;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 8px;
|
||||
}
|
||||
|
||||
.metric-card:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.metric-card h4 {
|
||||
margin: 0px;
|
||||
font-size: 1rem;
|
||||
color: var(--text-title);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.metric-card .metric-card-value {
|
||||
margin: 0px;
|
||||
font-size: 1.4rem;
|
||||
font-weight: 600;
|
||||
color: var(--text-accent);
|
||||
}
|
||||
|
||||
.metric-card p {
|
||||
font-size: 0.85rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.45;
|
||||
margin: 0;
|
||||
overflow-wrap: var(--overflow-wrap);
|
||||
}
|
||||
|
||||
.timeline-container {
|
||||
position: relative;
|
||||
margin: 0 0 0 0;
|
||||
padding: 0px 16px 0px 56px;
|
||||
list-style: none;
|
||||
font-family: var(--font);
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: calc(-40px + 56px);
|
||||
width: 2px;
|
||||
height: 100%;
|
||||
background: var(--timeline-ln);
|
||||
}
|
||||
|
||||
.timeline-container > li {
|
||||
position: relative;
|
||||
margin-bottom: 16px;
|
||||
padding: 16px 20px 16px 20px;
|
||||
border-radius: var(--radius);
|
||||
background: var(--bg-card);
|
||||
border: 1px solid var(--border);
|
||||
}
|
||||
|
||||
.timeline-container > li:last-child {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.timeline-container > li:hover {
|
||||
background-color: var(--bg-hover);
|
||||
}
|
||||
|
||||
.timeline-container > li::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 18px;
|
||||
left: -40px;
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
background: var(--accent);
|
||||
border: var(--timeline-border) 2px solid;
|
||||
border-radius: 50%;
|
||||
transform: translateX(-50%);
|
||||
box-shadow: 0px 0px 2px 0px #00000012, 0px 4px 8px 0px #00000014;
|
||||
}
|
||||
|
||||
.timeline-container > li h4 {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
}
|
||||
|
||||
.timeline-container > li h4 em {
|
||||
margin: 0 0 5px;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
.timeline-container > li * {
|
||||
margin: 0;
|
||||
font-size: 0.9rem;
|
||||
color: var(--text-sub);
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
.timeline-container > li * b, .timeline-container > li * strong {
|
||||
font-weight: 600;
|
||||
}
|
||||
@media (max-width:600px){
|
||||
.metrics-container,
|
||||
.insights-container{
|
||||
grid-template-columns:1fr;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
<div class="metrics-container">
|
||||
<div class="metric-card">
|
||||
<h4>Udział SEO w cytowaniach AI</h4>
|
||||
<div class="metric-card-value">38% <small>(↓76%)</small></div>
|
||||
<p>Obecnie tylko 38% cytowanych przez Google AI źródeł to strony z top 10 wyników organicznych (spadek z 76% rok wcześniej). AI sięga więc coraz częściej poza tradycyjnie najwyżej pozycjonowane strony.</p>
|
||||
</div>
|
||||
<div class="metric-card">
|
||||
<h4>Spadek CTR przez AI</h4>
|
||||
<div class="metric-card-value">−35%</div>
|
||||
<p>O tyle spada współczynnik klikalności (CTR), gdy Google wyświetla podsumowanie AI. CTR wyników organicznych maleje z ~15% do ~8%, bo wielu użytkowników zadowala się gotową odpowiedzią bez klikania wyniku.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Anatomia GEO‑optymalizowanego wpisu blogowego (analiza infografiki)
|
||||
|
||||
Infografika **„The Anatomy of a GEO‑Optimized Blog Post”** przedstawia idealną strukturę oraz elementy wpisu na blogu, który został zoptymalizowany pod kątem cytowania przez generatywne systemy AI (GEO). Każdy element pełni określoną rolę w zwiększeniu szans, że treść zostanie **zauważona i zacytowana przez modele AI**. Poniżej wyjaśniono poszczególne komponenty takiego artykułu:
|
||||
|
||||
* **Znaczniki schema (Article + FAQPage)** – W kodzie strony zastosowano **dane strukturalne** (np. schema typu Article oraz FAQPage) w formacie JSON-LD. Tagi te ułatwiają algorytmom wyszukiwarek i systemom AI zrozumienie struktury strony: wskazują tytuł, autora, datę publikacji, listę pytań i odpowiedzi itp. Włączenie znaczników schema (zwłaszcza dla sekcji FAQ i poradników HowTo) poprawia **interpretację i widoczność treści** zarówno w Google, jak i w AI. Według badań, zastosowanie schema markup może zwiększyć szansę wyboru strony przez AI o ok. **73%**. [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/) [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/)
|
||||
|
||||
* **Aktualność treści („Freshness”)** – Infografika podkreśla wagę wyraźnie zaznaczonej daty aktualizacji (np. adnotacja „Updated Dec 2024” tuż pod tytułem wpisu). Systemy AI zwracają uwagę na **świeżość informacji** – treści uaktualniane niedawno są uznawane za bardziej wiarygodne i są częściej cytowane. Zaleca się **regularne aktualizowanie artykułów**, najlepiej co 30 dni lub częściej, zwłaszcza jeśli temat szybko się zmienia. Przykładowo, analiza Perplexity.ai wykazała, że strony zaktualizowane w ciągu ostatniego miesiąca były cytowane przez AI średnio **3,2 raza częściej** niż starsze materiały. Widoczna data „Updated” służy więc jako sygnał świeżości zarówno dla użytkowników, jak i dla algorytmów AI. [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/)
|
||||
|
||||
* **Tytuł w formie pytania** – Tytuł artykułu jest sformułowany jako **bezpośrednie pytanie**, np. *„Jak działa X?”*. Taki format odzwierciedla styl zapytań użytkowników do asystentów AI i wyszukiwarki – wiele osób zadaje pytania pełnym zdaniem. Dzięki temu **tytuł idealnie pokrywa się z zapytaniem** i zwiększa szanse, że zarówno Google, jak i AI uznają treść za odpowiedź na pytanie użytkownika. Dodatkowo zaleca się, by tytuł miał **< 60 znaków** i zawierał główne słowo kluczowe, aby był czytelny w wynikach wyszukiwania. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Blok autora i E-E-A-T** – Zaraz pod tytułem umieszczono informacje o autorze (tzw. **author bio**), podkreślając jego doświadczenie i ekspertyzę. E-E-A-T to skrót od **Experience, Expertise, Authoritativeness, Trustworthiness** (doświadczenie, wiedza/ekspertyza, autorytet i zaufanie). Ten blok zazwyczaj zawiera link do strony autora z opisem kwalifikacji, osiągnięć oraz ustrukturyzowanymi danymi (schema Author). Celem jest wzmocnienie **wiarygodności treści w oczach AI** – modele preferują treści podpisane przez osoby o uznanym autorytecie w danej dziedzinie. Google od lat promuje witryny wykazujące się wysokim E-E-A-T, zwłaszcza w obszarach YMYL (Your Money, Your Life), a w kontekście GEO ma to jeszcze większe znaczenie: AI „szuka” sygnałów, że treść jest godna zaufania i napisana przez eksperta. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Sekcja definicji / wprowadzenia** – Artykuł zaczyna się od krótkiego wstępu, często sformułowanego również w formie pytania, np. **„Czym jest \[temat] i jak działa?”**. Pierwsze akapity od razu **definiują kluczowe pojęcie** prostym językiem. Taka sekcja daje zarówno czytelnikowi, jak i algorytmowi AI **kontekst i podstawową odpowiedź na główne pytanie】**. AI chętnie wykorzystuje takie definicje jako punkt wyjścia, np. odpowiadając na zapytanie “Co to jest X?”, model może zacytować właśnie te pierwsze zdania artykułu. Według ekspertów od GEO zwięzłe definicje i objaśnienia pojęć na początku tekstu znacząco zwiększają szansę pojawienia się w odpowiedziach na pytania w stylu „What is...?”. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Ramka „Quick Answer” (szybka odpowiedź)** – Kluczowy element GEO: krótka, wyróżniona graficznie odpowiedź (np. w ramce lub pogrubieniu) umieszczona zaraz na początku artykułu. Obejmuje 1–3 zdania (około **40–60 słów**), które **esencjonalnie odpowiadają na główne pytanie** poruszane w tekście. Taka zwięzła odpowiedź ma dwie funkcje: po pierwsze, natychmiast satysfakcjonuje czytelnika szukającego szybkiej informacji, a po drugie – **stanowi gotowy fragment do zacytowania przez AI**. Analizy wykazały, że bardzo wiele odpowiedzi ChatGPT pochodzi właśnie z pierwszych akapitów artykułów – front-loading treści (umieszczenie odpowiedzi na górze) pozwalało uchwycić \~44% cytatów, które ChatGPT pobiera z danego tekstu. Innymi słowy, jeśli szybko podasz konkretną odpowiedź na pytanie w treści, model AI z większym prawdopodobieństwem włączy ją do swojej odpowiedzi. [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/)
|
||||
|
||||
* **Główna część artykułu (explanation)** – Dalej następuje właściwy, **rozwinięty opis tematu**, podzielony na sekcje odpowiadające na kolejne **pytania pomocnicze** (np. „Jak to działa?”, „Zalety i wady...”, „Przykłady zastosowań...” itp.). Każda sekcja zaczyna się od nagłówka (H2/H3) często sformułowanego pytaniem oraz **bezpośrednią odpowiedzią tuż pod nagłówkiem** (tzw. format *answer-first*). Dzięki temu nawet dłuższa część artykułu jest podzielona na wyraźne bloki Q\&A. Każdy akapit stara się od razu **przedstawić sedno odpowiedzi**, rozwijając szczegóły w kolejnych zdaniach. Taki *inverted pyramid style* (odpowiedź na górze, szczegóły poniżej) sprzyja zarówno czytelnikowi o ograniczonym czasie, jak i algorytmom AI, które **parsują treść sekcjami**. Ważne jest też utrzymanie **krótkich akapitów (1–3 zdania)** oraz jasnego języka – modele generatywne lepiej radzą sobie z prostymi, treściwymi zdaniami bez zbędnego „lania wody”. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Listy punktowane i numerowane** – Treść GEO powinna wykorzystywać **listy wypunktowane i numerowane** wszędzie tam, gdzie to możliwe (wymienianie przykładów, kroków, korzyści, rankingów itp.). Takie sformatowanie informacji zwiększa czytelność i **ułatwia AI ekstrakcję kluczowych punktów】**. Według analiz przytoczonych w infografice, około **50% cytatów, które pojawiają się w odpowiedziach AI, pochodzi z treści ujętych w formie list** wypunktowanych/numerowanych, a \~60% najlepiej cytowanych artykułów online zawiera co najmniej jedną listę w swojej strukturze. Innymi słowy – jeśli odpowiadasz na pytanie listą kroków lub porad, znacznie rośnie szansa, że AI zacytuje właśnie te punkty (często generatory prezentują odpowiedzi użytkownikom właśnie w formie listy). Praktyka ta przypomina znane z SEO tworzenie list *„Top 10 …”* czy *FAQ*, ale w GEO jest to wręcz krytyczne. **Bulleted lists** i numerowane sekwencje zaleca m.in. przewodnik Bluefly, podkreślając ich rolę w przejrzystej strukturze pod AI. [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/)
|
||||
|
||||
* **Tabele jako „magnesy cytowań”** – Infografika zwraca uwagę na moc tabel: usystematyzowane **zestawienia danych w formie tabelarycznej** stanowią dla AI znakomite źródło do bezpośredniego przytoczenia fragmentu. Tabela pozwala skondensować informacje (np. porównanie cech, statystyk, wyników badań) w uporządkowany sposób – modele językowe mogą wtedy łatwo zaciągnąć konkretny wiersz/kolumnę jako odpowiedź na szczegółowe zapytanie. Zaleca się, by tabela miała czytelne nagłówki kolumn i minimum 2–5 wierszy danych. Przykładowo na infografice pokazano tabelę porównującą platformy (ChatGPT, Perplexity, Google AI) pod kątem źródeł cytowanych informacji i procentu cytowań z różnych typów źródeł. **Treści przedstawione w formie tabel** cieszą się istotnie wyższą szansą na cytowanie – silniki generatywne doceniają klarowność takiej prezentacji. Wskazuje się, że AI cytuje dane liczbowe z tabel około **2× częściej** niż z ciągłego tekstu (według danych z branżowych case studies). [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Cytowania źródeł (referencje)** – Bardzo ważny element GEO to **jawne cytowanie źródeł w tekście**. Oznacza to w praktyce wstawianie przypisów lub linków do autorytatywnych źródeł przy podawaniu istotnych faktów, statystyk czy definicji. Taki model przypomina styl pisania prac naukowych, ale ma konkretny cel: podnosi **wiarygodność** treści. Systemy AI przeszukując internet **szukają potwierdzeń** – jeśli w Twoim artykule dana informacja jest opatrzona wiarygodnym źródłem (np. linkiem do badań, oficjalnych raportów), treść zyskuje na zaufaniu i ma większą szansę zostać wybrana do odpowiedzi. Wewnętrzne testy pokazują ogromne przełożenie tej praktyki: dodanie do swoich treści źródeł i referencji dało średnio ponad **2× wzrost widoczności w odpowiedziach AI**. Także badanie naukowe przeprowadzone m.in. na Princeton University potwierdziło, że uwzględnienie w tekście **cytatów i odnośników** może zwiększyć „impression score” (widoczność źródła w odpowiedzi AI) nawet o **\~40%**. Podsumowując – z punktu widzenia GEO zamiast obawiać się, że użytkownik „ucieknie” przez link wychodzący, wolimy pokazać AI (i czytelnikom), że nasze treści są podparte solidnymi danymi. [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/) [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/) [\[seo.ai\]](https://seo.ai/blog/generative-engine-optimization-geo)
|
||||
|
||||
* **Cytaty wypowiedzi ekspertów** – Oprócz linkowania do zewnętrznych źródeł warto zawrzeć **cytaty** uznanych ekspertów lub autorytetów branżowych we własnym tekście. Na infografice zaznaczono to jako osobny element: pełna atrybucja cytowanej osoby (imię, nazwisko, tytuł/nazwa organizacji) sygnalizuje AI, że w treści pojawiają się **wiarygodne opinie i dane spoza naszej własnej witryny**. Takie cytaty zwiększają różnorodność źródeł w artykule i przez to mogą podnieść jego autorytet. To również wpisuje się w E-E-A-T: pokazujemy, że nasze treści są poparte zdaniem niezależnych ekspertów, co buduje **zaufanie**. Wspomniana wcześniej praca badawcza (Princeton/Georgia Tech) uznała włączenie cytatów z innych źródeł za jedną ze skutecznych technik GEO. Przykładowo, jeśli piszemy o medycynie, warto zacytować lekarza lub raport WHO; jeśli o finansach – analityka z renomowanej instytucji. AI chętniej zaufa tekstowi zawierającemu takie **zweryfikowane wypowiedzi**. [\[seo.ai\]](https://seo.ai/blog/generative-engine-optimization-geo)
|
||||
|
||||
* **Checklist sygnałów wspierających** – Infografika wymienia także krótką listę kontrolną elementów, o które należy zadbać w treści GEO. Na liście znalazły się m.in.:
|
||||
|
||||
* **Oryginalne statystyki lub dane** (najlepiej unikalne, z własnych badań) – bo AI ceni **pierwotne źródła informacji** i może je wyróżniać.
|
||||
* **Cytaty ekspertów** – omówione powyżej, zwiększają autentyczność i wiarygodność.
|
||||
* **Krótkie akapity i sekcje** – zapewniają lepszą **czytelność** i „strawność” dla algorytmu (unikanie ściany tekstu).
|
||||
* **Listy i tabelki** – jak wyjaśniono, są bardzo chętnie cytowane (np. **tabele \~2× częściej** niż zwykły tekst).
|
||||
|
||||
Tego rodzaju **„sygnały jakości”** sumują się, zwiększając szansę, że nasz artykuł zostanie pozytywnie oceniony przez model AI podczas generowania odpowiedzi. Można traktować te punkty jako podsumowanie najlepszych praktyk GEO do odhaczenia przed publikacją. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Sekcja FAQ (Często zadawane pytania)** – Na końcu wpisu GEO zaleca się dodać osobną sekcję **FAQ** zawierającą kilka powiązanych pytań i odpowiedzi. Przykładowo, dla artykułu o danym temacie, w FAQ mogą znaleźć się pytania w stylu: „Jak często należy aktualizować X?”, „Czy GEO zastępuje SEO?” – wraz z zwięzłymi odpowiedziami. Taka sekcja spełnia dwie role. Po pierwsze, odpowiada na **długie ogonki wyszukiwania** (long-tail), czyli bardziej szczegółowe pytania, jakie użytkownicy mogą zadawać asystentom AI. Po drugie, jeśli dodamy do strony znaczniki schema FAQPage, to zarówno Google, jak i inne silniki mogą zrozumieć, że to jest sekcja pytań i odpowiedzi. **Wyniki FAQ są często wykorzystywane w generowanych podsumowaniach AI**, szczególnie w Google (SGE) – zastosowanie schema FAQ zwiększa prawdopodobieństwo pojawienia się w AI-owych „overview” nawet kilkukrotnie według obserwacji z branży. Google od lat promuje dane strukturalne FAQ w zwykłych wynikach (pokazując bezpośrednio pytania z rozwijanymi odpowiedziami), a w erze AI ten trend się rozszerza. Z tych powodów dodanie sekcji FAQ z poprawnym formatowaniem jest stałym elementem strategii GEO. [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/), [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
* **Ramka z kluczowymi wnioskami (Key Takeaways)** – Wielu twórców treści GEO zamyka artykuł wyróżnionym podsumowaniem najważniejszych punktów. Może to przybrać formę graficznej ramki lub po prostu ostatniej sekcji **„Key Takeaways”** z wypunktowanymi najistotniejszymi stwierdzeniami. Taki zabieg sprawia, że nawet jeśli czytelnik (lub model AI) przewinie od razu na dół strony, znajdzie tam **esencję artykułu** w pigułce. Dla AI stanowi to dodatkową, dobrze wyodrębnioną porcję wiedzy do potencjalnego zacytowania. Podsumowanie powinno być zwięzłe i konkretne – np. 3–5 najważniejszych zdań lub punktów, które odpowiadają na pytanie przewodnie artykułu i **potwierdzają jego główne tezy**. W praktyce, taka sekcja pełni rolę podobną do podsumowania wykonawczego czy konkluzji, ale sformułowanego bardziej pod kątem automatycznego wyciągania informacji.
|
||||
|
||||
Powyższe elementy składają się na wpis blogowy zoptymalizowany pod **Generative Engine Optimization**. Wiele z nich pokrywa się z dobrymi praktykami **SEO content marketingu** (np. strukturyzacja treści, użycie nagłówków, linkowanie do źródeł), jednak **GEO stawia dodatkowy nacisk** na rzeczy, które wcześniej nie zawsze były priorytetem – jak chociażby umieszczanie gotowych odpowiedzi na pytania czy formalne cytowanie źródeł w treści. Wszystko to dlatego, aby ułatwić modelom AI znalezienie w naszym tekście dokładnie tej informacji, której potrzebują, i **dostarczenie jej użytkownikowi wraz z atrybucją** (linkiem) do naszej strony. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/), [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
## GEO a tradycyjne SEO – podobieństwa i różnice
|
||||
|
||||
Poniżej przedstawiono porównanie kluczowych aspektów GEO vs. SEO:
|
||||
|
||||
| **Aspekt** | **Tradycyjne SEO** (Search Engine Optimization) | **GEO** (Generative Engine Optimization) |
|
||||
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Cel optymalizacji** | Wysoka pozycja strony w wynikach wyszukiwarki (SERP) – celem jest przyciągnięcie kliknięcia użytkownika na stronę [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/). | Obecność treści **w odpowiedziach generowanych przez AI** – celem jest, by model AI wybrał naszą stronę jako źródło informacji i zacytował ją użytkownikowi [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/), [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/). |
|
||||
| **Metryka sukcesu** | **Rankingi i ruch organiczny:** sukces mierzy się pozycją w Google oraz ilością odwiedzin z wyszukiwarki. | **Cytowania przez AI i widoczność w AI:** sukces to pojawienie się naszej treści w odpowiedzi (np. link lub wzmianka w ChatGPT/SGE). Liczy się bycie **cytowanym jako autorytet** [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/). |
|
||||
| **Charakter zapytań** | Koncentruje się na słowach kluczowych (często fragmentarycznych, np. *„optymalizacja SEO blog”*). Treści są optymalizowane pod frazy, które użytkownicy wpisują w Google. | Koncentruje się na **pełnych pytaniach językiem naturalnym** (np. *„Jak optymalizować blog pod AI?”*). Treści formułuje się tak, by pasowały do konwersacyjnych zapytań użytkowników do AI [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/). |
|
||||
| **Struktura i format treści** | Dłuższe formy, wyczerpująca treść często podzielona nagłówkami H2/H3. Ważna jest **czytelność dla człowieka**, ale bez konieczności natychmiastowej odpowiedzi – użytkownik musi przeczytać całość, by znaleźć wszystkie informacje. Listy i tabele stosowane są opcjonalnie, głównie by poprawić UX i szansę na *featured snippet*. | **Treść podzielona na pytania i odpowiedzi**. Każda sekcja zaczyna się od pytania (nagłówek) i natychmiastowej odpowiedzi (1–2 zdania). **Krótkie akapity, listy punktowane, tabele** są standardem – struktura maksymalnie ułatwia **parsowanie treści przez AI** [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/), [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/). Priorytetem jest błyskawiczne dostarczenie konkretów (tzw. answer-first), a dopiero potem rozwinięcie szczegółów. |
|
||||
| **Tytuł i nagłówki** | Tytuł ma przyciągnąć uwagę i zawierać słowa kluczowe, ale nie musi być pytaniem. Często stosuje się chwytliwe tytuły pod SEO, np. *„10 sposobów na lepsze SEO bloga”*. Nagłówki H2/H3 grupują treść tematycznie, ale nie zawsze pokrywają pytania użytkowników. | **Tytuł sformułowany jako pytanie**, które użytkownik mógłby zadać (np. *„Jak GEO różni się od SEO?”*). Zawiera główne słowo kluczowe, ale w formie naturalnego pytania [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/). Podnagłówki również często mają formę pytań, co sprawia, że **struktura treści odpowiada na wiele potencjalnych zapytań**. To zwiększa szansę, że AI „wyłowi” odpowiedni fragment pod konkretny query. |
|
||||
| **Autorytet i autor (E-E-A-T)** | Istotna jest wiarygodność domeny (backlinki, autorytet strony) oraz jakość treści. Google coraz bardziej uwzględnia E-A-T – więc podawanie autora i jego kwalifikacji jest zalecane, ale nie zawsze praktykowane. W przeszłości wiele treści SEO publikowano bez wyraźnej tożsamości autora. | **Mocny nacisk na E-E-A-T autora i źródła.** Każdy artykuł powinien mieć przypisanego eksperta z imienia i nazwiska, z podkreśleniem doświadczenia (Experience) i wiedzy (Expertise). AI zwraca uwagę na te sygnały zaufania – **treści podpisane przez eksperta są chętniej wybierane** [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/). Autorytet buduje się też poprzez cytowanie innych uznanych źródeł w artykule (co pokazuje, że autor zebrał informacje z wiarygodnych miejsc). |
|
||||
| **Odnośniki i cytowania** | Linki wychodzące do źródeł zewnętrznych są używane umiarkowanie – mają wspierać użytkownika i sygnalizować Google, że treść odnosi się do autorytetów (co może pośrednio wspomagać E-A-T). Jednak formalne **cytowanie źródeł w tekście** (np. w formie przypisów) nie jest standardową praktyką SEO. Ważniejsze było linkowanie wewnętrzne i zdobywanie backlinków. | **Obfite cytowanie źródeł i referencji.** Artykuł GEO zawiera przypisy do badań, statystyk, cytaty ekspertów – wszystko, co czyni go **lepiej udokumentowanym**. Ma to bezpośredni wpływ na AI: modele oceniają treść pod kątem wiarygodności i preferują podać użytkownikowi informacje poparte źródłami [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/), [\[seo.ai\]](https://seo.ai/blog/generative-engine-optimization-geo). Linkowanie wewnętrzne i tradycyjne SEO-faktory wciąż się liczą, ale **dodanie źródeł** istotnie podnosi szanse na cytowanie (najwyższy zwrot spośród technik GEO) [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/). |
|
||||
| **Dane strukturalne (schema)** | Stosowane są głównie w celu uzyskania rich snippetów (np. **FAQ schema** do wypisania pytań w wynikach Google, **Recipe/HowTo** by pojawiły się specjalne elementy). Implementacja schema pomaga SEO, ale nie była absolutnie wymagana – wiele stron rankuje wysoko bez danych strukturalnych. | **Schema markup to podstawa GEO.** Strony zoptymalizowane pod AI niemal zawsze zawierają JSON-LD z oznaczeniem artykułu, autora, FAQ itp. – tak by **algorytmy AI mogły łatwo zrozumieć strukturę treści** [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/). W efekcie AI szybciej „wie”, gdzie są pytania, gdzie odpowiedzi, kto jest autorem, kiedy zaktualizowano treść. Badania wskazują, że użycie schema może zwiększyć częstotliwość wybierania naszej strony przez AI o kilkadziesiąt procent [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/). |
|
||||
| **Aktualność treści** | Ważna głównie przy zapytaniach wrażliwych na czas (trendy, newsy). Google ma mechanizm „Query Deserves Freshness”, ale dla wielu fraz starsze, ugruntowane treści nadal radzą sobie dobrze. Częsta aktualizacja nie zawsze jest priorytetem, jeśli content jest „evergreen”. | **Świeżość jest kluczowa.** Modele AI (np. w trybie online) faworyzują nowsze informacje – wprost widać to po tym, że np. Perplexity podbija nowsze źródła. W GEO zaleca się regularne uaktualnianie artykułów i pokazywanie daty aktualizacji. Strony z ostatnimi aktualizacjami mają znacznie **większą szansę na cytowanie** [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/). W praktyce kontekst AI wymusza, by nawet „evergreen” był odświeżany, bo inaczej model może uznać dane za nieaktualne. |
|
||||
| **Interakcja użytkownika** | Użytkownik widzi wynik w Google i **klika**, aby przeczytać całość na naszej stronie. Sukces SEO to sprowadzenie użytkownika do serwisu – dalsze doświadczenie (czas na stronie, konwersja) następuje już po kliknięciu. | Użytkownik często **otrzymuje odpowiedź bezpośrednio** od AI (np. w oknie czatu lub w ramce nad wynikami). Może wcale nie odwiedzić strony, a jedynie zobaczyć krótką wzmiankę i źródło. Dlatego w GEO treść musi być **kompletna w oderwaniu od strony** – to, co AI zacytuje, ma samo dostarczyć wartości. Wizyty z AI są mniej liczne, ale za to bardziej zaangażowane (dłuższe sesje, wyższy współczynnik konwersji użytkowników, którzy jednak klikną) [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/), [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/). |
|
||||
|
||||
**Podobieństwa:** Warto podkreślić, że GEO nie zastępuje SEO, lecz je **uzupełnia**. Obie strategie opierają się na tworzeniu **wysokiej jakości treści**, które są relewantne dla zapytań użytkowników. Zarówno SEO, jak i GEO wymagają dbałości o **autorytet strony** (marki), dobrą optymalizację techniczną (np. szybkość, mobilność) i zrozumienie intencji użytkownika. Fundamenty – takie jak **trafne słowa kluczowe, wartościowy content, linki zwrotne, przyjazność dla crawlera** – pozostają ważne, bo bez tego nasza treść w ogóle nie zostanie odnaleziona ani przez Google, ani przez AI. GEO można więc postrzegać jako **kolejną warstwę** na bazie SEO: dopiero mając solidne podstawy SEO, warto szlifować treści pod kątem AI. [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/) [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
**Różnice priorytetów:** W tradycyjnym SEO często skupiano się na **optymalizacji pod algorytm Google** – nasyceniu słów kluczowych, meta-tagach, zdobywaniu linków, poprawie CTR. Tworząc treści w podejściu GEO, bardziej koncentrujemy się na **optymalizacji pod użytkownika i algorytmy AI**, które czytają tekst „jak człowiek”. Priorytetem staje się klarowna struktura odpowiedzi, **bezpośredniość i źródłowość informacji**. Przykładowo, **dodanie sekcji FAQ, aktualizowanie artykułu co kilka tygodni, dodanie przypisów do źródeł – to elementy, które wcześniej nie zawsze były standardem SEO**, a teraz mogą decydować o byciu lub niebyciu w odpowiedzi AI. Ponieważ coraz więcej użytkowników polega na odpowiedziach generowanych (według badań **50% internautów aktywnie korzysta z wyszukiwania AI**), **autorzy treści muszą dostosować się do tych zmian**. Oznacza to, że **pisząc nowy artykuł, myślimy już nie tylko o tym, jak zadowolić algorytm Google, ale też jak sprawić, by nasz tekst „spodobał się” modelowi AI** na etapie generowania odpowiedzi. Konkretnie, **rosnące znaczenie mają:** [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/)
|
||||
|
||||
* *Aktualność i szybkość aktualizowania treści* – bo AI preferuje najświeższe informacje.
|
||||
* *Struktura pytań i odpowiedzi* – bo AI lepiej trafia na treść sformatowaną pod zapytania w języku naturalnym.
|
||||
* *Cytowalność i wiarygodność* – bo AI wybierze treść popartą źródłami i ekspercką (aby nie ryzykować błędu). [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
* *Klarowność i zwięzłość* – bo model nie „kliknie” dalej; jeśli nie znajdzie szybko odpowiedzi w tekście, sięgnie do innego źródła. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
|
||||
Podsumowując, **w erze AI zmieniają się akcenty w tworzeniu treści**: nadal trzeba stosować SEO, by treść była widoczna w sieci, ale dodatkowo **trzeba ją przygotować jak materiał referencyjny dla sztucznej inteligencji**. Treść GEO-friendly **wygrywa** tym, że staje się częścią odpowiedzi udzielanej użytkownikowi bezpośrednio przez model – co zwiększa **autorytet marki** i pośrednio może przekładać się na ruch (choć mniejszy wolumen, to bardziej jakościowy). Firmy i twórcy contentu, którzy już teraz wdrażają zasady GEO obok tradycyjnego SEO, zyskują przewagę konkurencyjną – ich content jest gotowy zarówno na wyszukiwarkę, jak i na asystenta AI przyszłości. [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/), [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/)
|
||||
|
||||
**Źródła i dalsza lektura:**
|
||||
|
||||
* Infografika „The Anatomy of a GEO-Optimized Blog Post” (Flying Cat Marketing, 2024) – zawiera wizualny schemat omówionych elementów.
|
||||
* Przewodnik Bluefly Studios: *„How To GEO-Optimize Blog Content for AI and Search”* – opisuje kroki GEO-optimalizacji wpisu. [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/), [\[blueflystudios.com\]](https://blueflystudios.com/geo-optimize-blog-content/)
|
||||
* Obszerne opracowanie *„Generative Engine Optimization: The Ultimate Guide”* (Scopic Studios, 2025) – wyjaśnia filary GEO i różnice vs SEO. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/), [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
* Omówienie badania *„GEO: Generative Engine Optimization”* (Princeton, Georgia Tech, 2024) – na blogu SEO.ai. [\[seo.ai\]](https://seo.ai/blog/generative-engine-optimization-geo), [\[seo.ai\]](https://seo.ai/blog/generative-engine-optimization-geo)
|
||||
* Case study *„How to Get Cited by AI”* (ZipTie.dev, 2026) z danymi o wpływie różnych czynników (schema, świeżość, cytowania) na częstotliwość cytowania przez AI. [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/), [\[ziptie.dev\]](https://ziptie.dev/blog/how-to-get-cited-by-ai/)
|
||||
|
||||
Rozwijająca się integracja AI w wyszukiwaniu informacji to wyzwanie, ale i szansa. Stosując zarówno praktyki SEO, jak i GEO, możemy **maksymalizować widoczność** naszych treści w obu światach – tradycyjnych wyników wyszukiwania i odpowiedzi generowanych przez sztuczną inteligencję. Dzięki temu nasz content pozostanie **konkurencyjny i łatwo dostępny** niezależnie od tego, w jaki sposób użytkownik szuka informacji. [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/), [\[scopicstudios.com\]](https://scopicstudios.com/blog/generative-engine-optimization-geo/)
|
||||
Reference in New Issue
Block a user