如何用 Gemini CLI Checkpointing 安全修 SEO

你會建立什麼

這篇教學會示範如何用 Gemini CLI 更安全地處理 technical SEO fixes：每次有風險的修改之前，都先建立 checkpoint。目標不是「讓終端機 agent 自動修 SEO」，而是做到一個 risk class、一個 branch、一個 diff、一份 validation report，以及一條 rollback path。

你會建立：

seo-geo/checkpoints/
YYYY-MM-DD-task-name/
before-git-status.txt
before-changed-files.txt
diagnosis.md
approval.md
after-validation.md
rollback.md
scripts/
seo-geo-checkpoint.mjs

圖說：安全修 SEO 的核心不是讓 agent 更快動手，而是讓每一步都能回溯。

這個 workflow 適合 metadata helpers、schema、internal links、sitemap generation、robots rules、canonical logic、redirects 與 page templates。

步驟 1：建立 checkpoint folders 與 script

從你的網站 repo root 開始：

mkdir -p seo-geo/checkpoints scripts
cat > scripts/seo-geo-checkpoint.mjs <<'EOF2'
#!/usr/bin/env node
import { execSync } from 'node:child_process';
import { mkdirSync, writeFileSync } from 'node:fs';
import { join } from 'node:path';

const name = process.argv[2] || 'seo-geo-task';
const date = new Date().toISOString().slice(0, 10);
const dir = join('seo-geo', 'checkpoints', `${date}-${name}`.replace(/[^a-zA-Z0-9._/-]/g, '-'));
mkdirSync(dir, { recursive: true });

function run(cmd) {
try { return execSync(cmd, { encoding: 'utf8' }); }
catch (err) { return `COMMAND FAILED: ${cmd}
${err.message}
${err.stdout || ''}
${err.stderr || ''}`; }
}

writeFileSync(join(dir, 'before-git-status.txt'), run('git status --short'));
writeFileSync(join(dir, 'before-changed-files.txt'), run('git diff --name-only HEAD'));
writeFileSync(join(dir, 'rollback.md'), `# Rollback

Branch: ${run('git branch --show-current').trim()}

Before applying edits, commit or stash unrelated work. To inspect changes after Gemini edits, run:

\`\`\`bash
git diff
git status --short
\`\`\`
`);
console.log(`Created checkpoint: ${dir}`);
EOF2
chmod +x scripts/seo-geo-checkpoint.mjs

執行它：

node scripts/seo-geo-checkpoint.mjs metadata-test

步驟 2：從乾淨 branch 開始

在 Gemini CLI 修改任何東西之前，先檢查狀態：

git status --short

如果看到無關改動，先停下來，把它 commit 或 stash。接著建立 branch：

git checkout -b seo-geo/fix-metadata-example
node scripts/seo-geo-checkpoint.mjs fix-metadata-example

Checkpoint 只有在你知道 agent 動手前是什麼狀態時才有用。

步驟 3：先要求 Gemini CLI 只做診斷

在 repo root 開啟 Gemini CLI，貼上：

We are doing a safe SEO/GEO fix.

First, do diagnosis only. Do not edit files.

Task: inspect metadata/title/description handling for one target page: [URL or local file].

Return:
1. Files that likely control this page's title, meta description, canonical, Open Graph, and schema.
2. The exact risk class: metadata, schema, internal links, sitemap, robots, canonical, redirects, analytics, or content.
3. The smallest safe fix.
4. Validation commands available in this repo.
5. Rollback plan.
6. Files you would edit if approved.

Write the diagnosis to `seo-geo/checkpoints/YYYY-MM-DD-fix-metadata-example/diagnosis.md`.
Wait for approval before editing.

把 checkpoint folder name 換成你的 script 剛剛建立的名稱。

步驟 4：一次只核准一個 risk class

不要在同一次 run 裡核准 metadata、schema 和 redirects。使用這種 approval format：

Approved risk class: metadata only.
Approved files:
- src/pages/features/reporting.astro
- src/lib/seo.ts only if this page already uses that helper

Not approved:
- schema changes
- canonical policy changes
- robots/noindex changes
- redirects
- sitemap generation
- analytics changes
- unrelated page rewrites

Apply the smallest patch and stop after validation.

如果 Gemini 說必須修改 shared helper，要求它先做第二份 diagnosis，列出這個 helper 會影響哪些頁面。

步驟 5：先驗 diff，再看 summary

Gemini 修改後，先跑：

git diff --stat
git diff --name-only

Changed files 應該和 approval 一致。如果不一致，停下來，要求 Gemini 解釋為什麼多改了其他檔案。

接著跑你 repo 內可用的 checks：

npm run build
npm run lint

如果 repo 沒有這些 commands，請 Gemini 從 package.json、framework config 或 docs 判斷正確的 validation commands。

步驟 6：要求 Gemini 產生 after-validation report

Create `seo-geo/checkpoints/YYYY-MM-DD-fix-metadata-example/after-validation.md`.

Include:
- changed files
- exact SEO/GEO issue addressed
- diff summary
- commands run and outcomes
- manual checks still needed
- rollback command or rollback steps
- what metrics to watch for 14 days

Do not continue to another fix.

好的 report 會列出 files 和 commands。弱的 report 只會說「SEO improved」，但沒有任何證據。

步驟 7：高風險修復要使用更嚴格規則

只要 task 會碰 robots、canonicals、redirects 或 analytics，就讓 Gemini 停留在 diagnosis mode，直到人工核准 policy。

初學者可直接複製的 prompt

I want to use Gemini CLI for one safe SEO/GEO technical fix.

Rules:
- Create or use a checkpoint under `seo-geo/checkpoints/`.
- Diagnose before editing.
- Work on one risk class only.
- Wait for approval before changing files.
- Do not touch robots, noindex, sitemap, redirects, canonical helpers, analytics, or shared templates unless explicitly approved.
- After editing, run validation and write an after-validation report.
- Do not continue to another fix.

Start by inspecting git status and writing the diagnosis only.

FAQ

Git 本身就足夠當 checkpoint 嗎？

對多數網站 repo 來說，乾淨 branch 加 checkpoint folder 就足夠。對 generated sites，也要保存 before/after crawl outputs 或 rendered HTML snapshots。

一個 task 可以同時修 metadata、schema 和 redirects 嗎？

不要。把 risk classes 拆開，rollback 才會簡單。

如果 Gemini 修改了無關檔案怎麼辦？

停下來。用 git diff --name-only 對照 approved file list，要求 Gemini 只針對未核准變更 revert 或解釋。不要繼續下一步。

AI coding agents for SEO/GEO 學習路徑

這篇屬於 Gemini CLI SEO/GEO track。先完成這些 terminal-focused tutorials，再用 operating model 把它和 editor / workflow agents 組合起來：

1. Cursor vs Windsurf vs Gemini CLI：SEO/GEO 自動化怎麼選
2. 如何設定 Gemini CLI SEO/GEO Automation 工作區
3. 如何用 MCP 將 Gemini CLI 接上 SEO 資料
4. 如何用 Gemini CLI 做每日 SEO/GEO Monitoring
5. 如何用 Gemini CLI Checkpointing 安全修 SEO
6. Cursor、Windsurf、Gemini CLI、Codex、Claude Code 的 SEO/GEO 營運模型

Sources and notes

• Gemini CLI documentation: Gemini CLI Docs and MCP servers with Gemini CLI 。
• Related Auspia guide: Cursor vs Windsurf vs Gemini CLI for SEO/GEO Automation 。

Author: Julian Mercer, Auspia 14 年 Technical SEO Practitioner。Julian 撰寫 crawlability、schema、rendering，以及 AI-readable content 的 technical foundations。