Gemini CLI CheckpointingでSEO修正を安全にする方法

作るもの

このtutorialでは、Gemini CLIでtechnical SEO fixesを安全に行うために、riskのあるedit前にcheckpointを作る方法を説明します。目的は「terminal agentにSEOを直させる」ことではありません。1つのrisk class、1つのbranch、1つのdiff、1つのvalidation report、1つの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

metadata helpers、schema、internal links、sitemap generation、robots rules、canonical logic、redirects、page templatesで使います。

キャプション: Gemini CLIの技術修正は、1risk classずつ、承認済みfileだけを変更し、rollback pathを残します。

Step 1: checkpoint folders and scriptを作る

website 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

Step 2: clean branchから始める

Gemini CLIに何かを編集させる前にstateを確認します。

git status --short

unrelated workが見える場合は、先にcommitまたはstashします。それからbranchを作ります。

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

checkpointが役立つのは、agentがfilesを変える前に何が存在したか分かる場合だけです。

Step 3: Gemini CLIにはdiagnosis onlyを依頼する

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が作ったものに置き換えます。

Step 4: 1つの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を変更する必要があると言う場合は、そのhelperが影響するすべてのpageを示すsecond diagnosisを求めます。

Step 5: summaryを読む前にdiffをvalidateする

Geminiのedit後に実行します。

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

changed filesはapprovalと一致しているべきです。一致しなければ止め、extra filesが変わった理由をGeminiに説明させます。

利用可能なchecksを実行します。

npm run build
npm run lint

repoにそれらのcommandsがない場合は、package.json、framework config、docsから正しいcommandsを特定するようGeminiに依頼します。

Step 6: 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」と言います。

Step 7: high-risk fixesにはより厳しいrulesを使う

robots、canonicals、redirects、analyticsに触るtaskでは、人間がpolicyを承認するまでGeminiをdiagnosis modeに保ちます。

初心者向けcopy-paste 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になりますか？

多くのwebsite reposでは、clean branchとcheckpoint folderで十分です。generated sitesでは、before/after crawl outputsやrendered HTML snapshotsも保存します。

1つのtaskでmetadata、schema、redirectsをまとめて直すべきですか？

いいえ。risk classesを分けるとrollbackが簡単になります。

Geminiがunrelated filesを編集したらどうしますか？

止めます。git diff --name-onlyでapproved file listと比較し、unapproved changesだけについてGeminiにrevertまたは説明させます。taskを続行しないでください。

AI coding agents for SEO/GEO 学習パス

このpageはGemini CLI SEO/GEO trackに属します。まずterminal-focused tutorialsを進め、その後operating modelでeditor and 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でDaily 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-Year Technical SEO Practitioner。Julianはcrawlability、schema、rendering、AI-readable contentのtechnical foundationsについて執筆しています。