Jak to ogarnąć w PaperClip Najkrótsza rekomendacja: jedna firma / workspace w PaperClip, osobny projekt per blog, wspólna biblioteka promptów i szablonów. Personalny blog traktuj jako główny authority hub, a blogi niszowe jako osobne projekty produkcyjne podpięte do tej samej tożsamości autora, taksonomii i pipeline’u. Decyzja: jedna firma czy wiele? Wariant rekomendowany Ustaw: 1 firma / workspace: np. DexterTeam / PaperClip Media Lab 1 projekt główny: Personal Authority Hub 1 projekt per blog niszowy: AI Agents / OpenClaw Self-hosted DevOps Databases / DBA CMS / WordPress / Ghost Paper Models / Papermodels To daje najlepszy balans między kontrolą, SEO, promptami i automatyzacją. Kiedy jedna firma? Użyj jednej firmy, jeżeli: wszystkie blogi są Twoje, korzystają z tej samej tożsamości autora, mają wspólne zasady E-E-A-T, chcesz współdzielić szablony, promptbook, checklisty i workflow, chcesz łatwo robić cross-linking między blogami, chcesz mieć jedno centrum zarządzania produkcją treści. To jest Twój przypadek. Kiedy wiele firm? Wiele firm w PaperClip ma sens tylko wtedy, gdy: blogi należą do różnych klientów, mają różne zespoły, brandy, faktury, dostępy i polityki, nie chcesz mieszać danych, promptów ani historii publikacji, jeden blog ma działać jako zupełnie niezależny biznes. Dla Twojego systemu multi-blogowego wiele firm raczej wprowadzi chaos. Czy projekt per blog? Tak. Projekt per blog to najlepszy układ. Nie robiłbym jednego wielkiego projektu dla wszystkich blogów, bo po czasie zrobi się bałagan w: intencjach SEO, tonie głosu, promptach, linkowaniu, kalendarzu publikacji, topical authority, danych analitycznych, checklistach jakości. Lepszy układ: text Firma: DexterTeam / PaperClip Media Lab Projekt 1: Personal Authority Hub Cel: autor, reputacja, portfolio, metodologia, linkowanie do nisz Projekt 2: OpenClaw / AI Agents Blog Cel: AI agents, prompt engineering, automatyzacje, OpenClaw Projekt 3: Self-hosted DevOps Blog Cel: Docker, VPS, Linux, reverse proxy, monitoring Projekt 4: DBA / Database Architecture Blog Cel: Oracle, SQL Server, PostgreSQL, backup, HA, troubleshooting Projekt 5: CMS / WordPress / Ghost Blog Cel: CMS, SEO, publikowanie, architektura contentowa Projekt 6: Paper Models / Hobby Blog Cel: modele kartonowe, niszowy content hobbystyczny Jak to ustawić krok po kroku Krok 1: Zdefiniuj firmę jako centrum operacyjne W PaperClip utwórz jedną firmę, np.: text company: name: DexterTeam Content Network owner_entity: "Twoje imię / marka osobista" main_domain: "personalny-blog.pl" content_model: "hub-and-spoke multi-blog" language: "pl" secondary_language: "en" Firma nie oznacza jednego bloga. Firma oznacza centrum kontroli. W firmie trzymaj: globalne zasady E-E-A-T, główną tożsamość autora, politykę AI disclosure, listę domen, wspólną bibliotekę promptów, wspólne szablony frontmatter, wspólne style pisania, wspólną checklistę publikacji. Krok 2: Utwórz projekt główny dla personalnego hubu Projekt: text project: name: Personal Authority Hub role: authority_hub domain: "twojadomena.pl" purpose: "Budowa zaufania, reputacji, author entity i centralnej mapy tematów" Ten blog nie powinien być zwykłym blogiem z przypadkowymi wpisami. On ma być warstwą autorytetu. Publikuj tam: stronę About, stronę Uses, stronę Projects, stronę Now, portfolio, mapę wszystkich blogów, case studies, metodologię pracy, artykuły opiniotwórcze, podsumowania eksperckie, linki do blogów niszowych. Krok 3: Utwórz osobny projekt dla każdego bloga niszowego Każdy blog powinien mieć własny projekt, np.: text project: name: Self-hosted DevOps Blog role: niche_spoke parent_hub: Personal Authority Hub domain: "devops.twojadomena.pl" topical_scope: - Docker - Linux - VPS - Nginx Proxy Manager - monitoring - backups Dla każdego projektu ustaw osobno: grupę keywordów, topical map, tone of voice, szablony artykułów, częstotliwość publikacji, linki do hubu, linki do siostrzanych blogów, checklistę jakości. Krok 4: Nie mieszaj topical authority Największy błąd przy multi-blogu to wrzucanie wszystkiego wszędzie. Zasada: text Personal hub odpowiada na pytanie: kim jestem i dlaczego warto mi ufać? Blog niszowy odpowiada na pytanie: jak rozwiązać konkretny problem w danej dziedzinie? Przykład: Artykuł Jak projektuję agentów OpenClaw - personal hub albo AI Agents Blog. Artykuł Docker Compose dla n8n, Directus i Listmonk - Self-hosted DevOps Blog. Artykuł Backup strategia dla Oracle RMAN i NetWorker - DBA Blog. Artykuł Jak skonfigurować Ghost CMS pod multi-author SEO - CMS Blog. Krok 5: Zrób wspólną bibliotekę promptów W PaperClip trzymaj jedną globalną bibliotekę promptów, ale podzieloną na warstwy. Struktura: text /prompts /global 00-author-entity.md 01-eeat-policy.md 02-ai-disclosure.md 03-source-verification.md 04-internal-linking.md /hub hub-positioning-article.md personal-case-study.md project-retrospective.md authority-page.md /niche how-to-technical.md comparison-article.md troubleshooting-guide.md listicle-seo.md glossary-entry.md pillar-page.md spoke-article.md /quality eeat-review.md geo-review.md seo-review.md schema-review.md final-editorial-check.md Dzięki temu każdy projekt korzysta z tych samych zasad, ale ma własny kontekst. Krok 6: Ustal standardowy pipeline dla każdego posta Najlepszy pipeline: text 1. Topic selection 2. Keyword + intent mapping 3. Brief generation 4. Source research 5. Outline 6. Draft 7. E-E-A-T enrichment 8. GEO enrichment 9. SEO optimization 10. Internal linking 11. Schema/frontmatter 12. Human review 13. Publish 14. Measure 15. Update prompt memory W PaperClip możesz to rozbić na automaty: text pipeline: - topic_research - seo_brief - article_outline - first_draft - eeat_enrichment - geo_blocks - internal_links - metadata_schema - qa_review - publish_ready_export Jakich modeli użyć? Moja rekomendacja: nie jeden model do wszystkiego. Zrób pipeline wielomodelowy. Najlepszy podział modeli Strategia, architektura, ważne decyzje Używaj: Claude Opus 4.7 - najlepszy do strategii, architektury contentowej, dużych dokumentów, planów, złożonych promptbooków. GPT-5.4 - dobry do twardego rozumowania, walidacji logiki, checklist, struktury danych i technicznych decyzji. Użycie: text content strategy site architecture hub-and-spoke design prompt system design taxonomy design cross-blog linking rules Codzienna produkcja artykułów Używaj: Claude Sonnet 4.6 - główny model roboczy do pisania, redakcji, rozbudowy artykułów. Gemini 3.1 Pro - dobry jako tańszy model do researchu, streszczeń, wariantów tematów i prostszych briefów. Użycie: text draft articles rewrite tone adaptation SEO intro FAQ meta descriptions social snippets newsletter summaries Research i źródła Używaj: Claude Sonnet 4.6 - gdy research wymaga selekcji i syntezy. Gemini 3.1 Pro - gdy robisz dużo szybkich researchy na wiele tematów. GPT-5.4 - gdy trzeba sprawdzić spójność argumentów, tabel, zależności i kryteriów. Użycie: text keyword research source extraction competitor analysis SERP intent analysis GEO source mapping QA, E-E-A-T i GEO review Używaj: GPT-5.4 - jako reviewer logiczny i krytyczny. Claude Sonnet 4.6 - jako reviewer redakcyjny. Claude Opus 4.7 - do okresowego audytu całego systemu. Użycie: text fact-check checklist E-E-A-T scoring GEO scoring schema validation duplicate intent detection cannibalization review Proponowany stack modeli w PaperClip Ustaw tak: text models: strategy_model: Claude Opus 4.7 reasoning_review_model: GPT-5.4 production_writer_model: Claude Sonnet 4.6 research_model: Gemini 3.1 Pro seo_editor_model: Claude Sonnet 4.6 qa_model: GPT-5.4 Jeżeli chcesz taniej: text models_budget: strategy_model: Claude Sonnet 4.6 research_model: Gemini 3.1 Pro writer_model: Claude Sonnet 4.6 qa_model: Gemini 3.1 Pro Jeżeli chcesz najlepszą jakość: text models_quality: strategy_model: Claude Opus 4.7 writer_model: Claude Opus 4.7 research_model: Claude Sonnet 4.6 qa_model: GPT-5.4 Jak ustawić projekty w praktyce Minimalny układ na start Nie zaczynaj od 10 blogów. Zacznij od 3 poziomów: text 1. Personal Authority Hub 2. Najważniejszy blog techniczny 3. Drugi blog niszowy Dla Ciebie zacząłbym tak: text Projekt 1: Personal Authority Hub Projekt 2: OpenClaw / AI Agents Projekt 3: Self-hosted DevOps Dopiero po 4-6 tygodniach dodaj: text Projekt 4: Databases / DBA Projekt 5: CMS / WordPress / Ghost Projekt 6: Paper Models Krok 7: Każdy projekt powinien mieć własny plik konfiguracyjny Przykład: text project_id: openclaw_ai_agents project_type: niche_blog parent_hub: personal_authority_hub domain: production: "ai.twojadomena.pl" staging: "staging-ai.twojadomena.pl" content: language: "pl" tone: "techniczny, praktyczny, ekspercki, bez lania wody" audience: - developerzy - DevOps - twórcy agentów AI - osoby self-hostujące automatyzacje seo: primary_topics: - OpenClaw - AI agents - prompt engineering - automatyzacja LLM - self-hosted AI excluded_topics: - ogólne newsy AI bez praktyki - recenzje bez testów - clickbait eeat: author_entity: "main_author" requires_first_hand_experience: true requires_disclosure: true requires_sources: true geo: requires_summary_box: true requires_faq: true requires_definitions: true requires_comparison_table: true requires_evidence_pack: true Krok 8: Zrób globalny author entity To powinno być wspólne dla wszystkich projektów. text author_entity: id: main_author name: "Twoje imię i nazwisko / marka" role: - Full-stack developer - DevOps engineer - Database administrator - CMS specialist - AI automation builder experience: - "25+ lat Oracle i SQL Server" - "WordPress, Ghost, CMS" - "Docker, VPS, Linux" - "OpenClaw, PaperClip, agent systems" same_as: - "GitHub" - "LinkedIn" - "personal blog" - "project pages" Każdy blog niszowy powinien linkować do tego samego author entity. Krok 9: Zrób reguły linkowania Przykład: text linking_rules: personal_hub_to_niche: allowed: - pillar pages - best guides - project pages - case studies avoid: - linking to every generated post - sitewide footer spam niche_to_personal_hub: allowed: - author bio - methodology - about - disclosure - related case study niche_to_niche: allowed: - only when contextually useful - only with descriptive anchor - max 1-3 links per article To jest ważne, bo multi-blog może łatwo wyglądać jak sieć sztucznego linkowania. Chcesz, żeby wyglądało jak logiczny system ekspercki. Krok 10: Ustal typy treści dla każdego bloga Dla każdego projektu zrób katalog typów wpisów. Przykład dla bloga DevOps: text content_types: - troubleshooting_guide - docker_compose_walkthrough - architecture_note - migration_case_study - tool_comparison - checklist - glossary_entry Przykład dla bloga AI Agents: text content_types: - agent_design_note - prompt_pattern - openclaw_plugin_walkthrough - model_comparison - automation_pipeline - failure_analysis Przykład dla personalnego hubu: text content_types: - personal_case_study - project_retrospective - expert_position - portfolio_update - methodology_note - monthly_build_log Moja docelowa architektura dla Ciebie Zrobiłbym tak: text Firma: DexterTeam Content Network Shared layer: author entity AI disclosure policy E-E-A-T checklist GEO checklist prompt library schema templates link policy source policy Projects: 1. Personal Authority Hub 2. OpenClaw / AI Agents 3. Self-hosted DevOps 4. Database Engineering 5. CMS / WordPress / Ghost 6. Paper Models Najważniejsza zasada Nie traktuj blogów jako oddzielnych silosów. Traktuj je jako jeden system wiedzy z osobnymi frontami tematycznymi. Czyli: text Jedna firma. Jedna tożsamość autora. Wiele projektów. Jeden wspólny promptbook. Osobne topical maps. Osobne pipeline’y publikacji. Wspólne QA i E-E-A-T. Co bym zrobił jako następny krok Najpierw zbudowałbym Ci plik: text paperclip-multiblog-architecture.md Zawartość: struktura firmy, lista projektów, konfiguracja YAML per blog, globalny author entity, prompt routing, model routing, pipeline publikacji, reguły linkowania, checklisty E-E-A-T i GEO. Chcesz, żebym od razu przygotował taki gotowy plik .md do wklejenia do PaperClip jako blueprint?