SEO-Workflow als CI-Pipeline.
CLI-driven, JSON-Output, AI-Brief.
lifecycle plan
erzeugt einen datengestützten Brief aus sechs Quellen.
14/28/56-Tage-Followups als Cron, Auto-Tickets bei
Position-11-20-Drift oder Snippet-CTR-Schwäche.
Stateless zwischen Runs, kein SaaS-Lock, kein
Sistrix, kein Ahrefs, kein Semrush nötig.
Acht Schichten, was sie können.
Konkrete Tool-Wahl behalte ich für mich, was zählt sind die Eigenschaften: stateless, cron-tauglich, optional AI-Layer, kein SaaS-Lock.
Cron-tauglich · kein Server-Setup nötig Kein Headless-Browser-Overhead für Static-Sites Workaround gegen Service-Account-Block ~4k Output-Tokens pro Plan · Cent-Bereich pro Lauf 2000 Calls/Monat · 1500 Quota-Cap intern 7d-Disk-Cache gegen Rate-Limit Stateless · audit-history als Snapshot-Diff Type-safe Format · Migration-tauglich Fünf Subcommands decken den Lifecycle.
site-audit <url> Site-Audit-Run (über 30 Module). Output: audit-data.json + audit-report.md + recommendations.md + pages/<slug>.md
lifecycle plan <audit>.json --topic=... Brief-Generation aus sechs Datenquellen. Output: <date>-<slug>.json + .md
lifecycle followup <plan>.json <new-audit>.json Re-Audit gegen Plan, Auto-Tickets aus Befund
lifecycle list <lifecycle-dir> Alle Plans mit Status und nächstem Check-Termin
submit-sitemap <url> --gsc-json=<path> Sitemap-Submit + URL-Inspection-Status für jede URL
CI-Action für Auto-Followup.
Wöchentliches Audit plus Followup gegen alle aktiven Plans. Wenn Recommendations gefunden, automatisch ein GitHub-Issue mit konkreten Tickets als Body.
# .github/workflows/seo-followup.yml
name: SEO Lifecycle Followup
on:
schedule:
- cron: '0 7 * * MON' # Montags 07:00 UTC
workflow_dispatch:
jobs:
followup:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup CLI-Runtime
run: # ... Runtime-Setup
- name: Audit + Followup laufen
env:
GOOGLE_API_KEY: ${{ secrets.GOOGLE_API_KEY }}
GSC_OAUTH_TOKEN: ${{ secrets.GSC_OAUTH_TOKEN }}
LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
BRAVE_API_KEY: ${{ secrets.BRAVE_API_KEY }}
run: |
site-audit ${{ vars.SITE_URL }} --pages=50
AUDIT=$(ls -1 output/*/*/audit-data.json | head -1)
for plan in output/*/lifecycle/*.json; do
lifecycle followup "$plan" "$AUDIT"
done
- name: Issues aus Tickets erzeugen
run: recs-to-issues --repo ${{ github.repository }} Tech-Fragen.
Wie sieht der CLI-Aufruf aus?
Welche Datenquellen fließen in den Brief?
Was passiert im Followup automatisch?
Kann das in eine CI-Pipeline?
Wie ist die Brief-Generation strukturiert?
Welche API-Verbrauchskosten fallen pro Page-Lauf an?
Wie skaliert das auf Mandanten-Sites?
Open-Source oder proprietär?
Code-Walkthrough oder Tech-Sparring?
Erstgespräch 30 Min, kostenlos. Walkthrough an einer Reference-Implementierung, ob Lifecycle in deine Site-Pipeline passt.
Erstgespräch buchen