CodexでSEOを自動化する方法

Codexは、SEOを月次チェックリストから、繰り返し実行できるエンジニアリングワークフローへ変えられます。このガイドでは、audit、fix、content ops、structured data、安全なautomationにCodexを使う方法を解説します。

短い答え

Codexは多くのSEO作業を自動化できます。ただし、最も安全な使い方は「AIに全部公開させる」ことではありません。より良い使い方は、repository、SEOルール、analytics export、明確なdefinition of doneをCodexに渡し、inspection、patch、test、summaryを任せることです。

これにより、SEOは次のようなengineering loopになります。

1. templates、content、metadata、schema、sitemaps、redirects、performanceにまたがるissueを検出する。
2. Codexにscoped fixを提案させる。
3. Codexにcodeまたはcontent filesを編集させる。
4. validation commandsを実行する。
5. 公開前にdiffをreviewする。
6. 同じworkflowをskill、script、CI jobで繰り返す。

これが重要なのは、SEOが四半期に1回のauditではなくなっているからです。siteは毎日変わります。templatesはずれます。contentは古くなります。product pagesがmetadataなしで出荷されます。JavaScriptが重要なcopyを隠します。migration中にcanonicalsが壊れます。navigationが変わるとinternal linksが消えます。Codexが役立つのは、こうした問題の多くが生まれるcodebaseの中で作業できるからです。

このAuspia playbookでは、実用的なautomationに集中します。何を自動化し、何を人間reviewに残し、どうCodexへpromptし、どう繰り返し可能なSEO operating systemを作るかを扱います。

CodexがSEOで得意なこと

Codexはcoding agentなので、SEO taskがfiles、code、templates、tests、structured dataに触れるときに最も強いです。site repositoryを読み、routingを調べ、content modelsを更新し、Markdownを編集し、ReactやAstro templatesを修正し、validation scriptsを追加し、local checksを実行できます。

そのため、次のようなtaskに向いています。

Codexは、監督なしのstrategy decisionには向きません。positioningを決める、case-study metricsを発明する、sourceなしでclaimsを公開する、editorial reviewなしで数百pageを書き換える、といったことはさせるべきではありません。Codexは高速なSEO engineerとして扱い、oracleとして扱わないでください。

なぜ現代SEOに合うのか

GoogleのSEO starter guidanceは今でも明快です。検索エンジンがcontentを理解しやすくし、userがsiteを訪問すべきか判断しやすくすることです。また、siteを自動的に1位へ押し上げるsecretはなく、多くの変更は結果が出るまで時間がかかるとも説明されています。これはCodex automationにも適した考え方です。

Codexはfundamentalsを置き換えません。fundamentalsをより一貫して適用する助けになります。

Googleは、crawlerが平均的なuserと同じようにpageを見られるのが望ましいとも説明しています。重要なCSSやJavaScript resourcesへアクセスできることも含まれます。ここでengineering automationが重要になります。templateがproduct copyをclient-only renderingの裏に隠している場合、noindex tagがproductionへ出てしまう場合、structured dataが古いfieldから生成されている場合、content calendarでは根本原因を直せません。

AI-assisted contentについても、Googleのguidanceは役立ちます。automation自体が禁止されているわけではありませんが、contentはhelpfulでreliableであり、search manipulationではなくpeopleのために作られるべきです。したがって、Codex workflowにはevidence、review、quality gatesを含めます。目的はsiteを大量ページで埋めることではありません。technical mistakesを減らし、より良いpageを出荷することです。

Codex SEO automation stack

実用的なsetupには5つのlayerがあります。

Codexは「完了」の意味を知っているときに最もよく動きます。SEOでは、promptは「SEOを改善して」では不十分です。より良いpromptは、「canonical URLsが欠けているblog templatesをすべて見つけ、route slugからcanonical generationを追加し、buildを実行し、変更したfileを要約して」のようにします。

Caption: SEOをinput、diagnose、patch、validate、reviewのloopとして扱うと、Codexは最も力を発揮します。

SEO用のAGENTS.mdから始める

Codexは AGENTS.md から永続的なrepository guidanceを読み込めます。SEO automationでは、このfileに繰り返し使うpreferencesを、Codexが従えるrulesとして書きます。

軽量なSEO sectionは次のようにできます。

## SEO rules

- Every indexable page needs a unique title, meta description, canonical URL, and OG image.
- Blog posts should include Article JSON-LD when the required fields are available.
- Product pages should not invent ratings, reviews, prices, or availability.
- Do not add FAQ schema unless the FAQ is visible on the page.
- Keep internal links useful and limited. Do not add keyword-stuffed link blocks.
- Run `pnpm lint:seo` and `pnpm build` before saying the task is complete.
- If a claim needs external evidence, mark it for review instead of inventing a source.

これは小さいですが、workflowを変えます。毎回同じSEO standardsをpromptへ書かなくてよくなります。間違いが繰り返されるなら、guidanceを更新します。

大きなteamなら、rulesを分けます。

• AGENTS.md: 短いrepo-level instructions。
• docs/seo-rules.md: 詳細requirements。
• docs/content-quality.md: editorial standards。
• Codex skill: 繰り返しworkflow。

Workflow 1: automated technical SEO audit

codebaseを調べ、編集前に優先順位付きissue listを作りたいときに使います。

Prompt:

Audit this website repository for technical SEO issues.

Focus on:
- missing or duplicate titles and meta descriptions
- canonical URL generation
- robots and noindex handling
- sitemap generation
- structured data validity
- internal links in blog templates
- client-only rendering of important indexable text

Do not edit files yet. Return a prioritized table with issue, evidence, affected files, risk, and suggested fix.

このpromptが良いのは、Codexをdiagnosis modeに留めるからです。突然のrewriteではなく、scoped planが得られます。

planを承認したら、2つ目のpromptを使います。

Implement only the high-confidence fixes from the audit.

Constraints:
- Do not change page design.
- Do not rewrite article body content.
- Add or update tests where practical.
- Run `pnpm build` and any existing SEO validation commands.
- Summarize the diff and list anything that still needs human review.

auditとimplementationを1つの広いpromptで頼むより、この2-step patternのほうが安全です。

Workflow 2: metadata and snippet repair at scale

Metadataは自動化できるほど反復的ですが、reviewが必要なほど主観的です。

URLs、primary keyword、page intent、current title、current description、Search Consoleやcrawl toolのnotesを含むCSVをCodexに渡します。まずはproposed titles and descriptionsをreview fileへ書かせます。

Use `seo-pages.csv` to propose improved titles and meta descriptions.

Rules:
- Keep titles under 60 characters where possible.
- Keep descriptions under 155 characters where possible.
- Match the page intent in the CSV.
- Do not use clickbait or unsupported claims.
- Output to `tmp/metadata-proposals.csv` only. Do not edit templates yet.

review後に、approved recordsだけをCMS seed files、Markdown frontmatter、route metadataへpatchさせます。

重要なのは「先に提案、次にpatch」です。AIの速度を活かしつつ、site全体のsearch snippetsを静かに変更させないためです。

Workflow 3: structured data generation and validation

Structured dataはCodexに向いています。code-likeで、rule-basedで、validateしやすいからです。ただし、invalidまたはmisleading schemaはquality problemを作るため、リスクもあります。

Codexに向いているtask:

• blog templatesへArticle JSON-LDを追加する。
• route segmentsからBreadcrumbList schemaを追加する。
• approved company fieldsからOrganization schemaを追加する。
• real product fieldsだけを使ってProduct schemaを追加する。
• required propertiesを確認するschema validation testを作る。

Codexに向かないtask:

• aggregate ratingsを発明する。
• reviewsが見えないのにreview markupを追加する。
• hiddenまたはunrelated questionsのFAQ schemaを生成する。
• fake author credentialsを作る。

強いprompt:

Add Article JSON-LD to the blog post template.

Use only fields already available in the content model:
- title
- excerpt
- publishedAt
- updatedAt
- author name
- featured image
- canonical URL

Do not invent missing values. If a required field is unavailable, add a TODO and explain what content model field is needed. Run the build after editing.

Codexはregression testも作れます。これにより、将来のpostがrequired schema fieldsなしで公開されるのを防げます。

Workflow 4: sitemap and robots regression checks

Sitemapsとrobots filesは小さいですが、悪い変更はdiscoveryにすぐ悪影響を与えます。Googleは、sitemapを「search enginesに重要なURLを伝えるfile」と説明し、robots.txtを「siteの一部へのcrawler accessを制御するもの」と説明しています。Codexは、この2つがずれないようにできます。

Codexに、expected routesとgenerated sitemapを比較するcheckを追加させます。

Create an SEO validation script named `scripts/check-seo.ts`.

It should:
- build or read the generated sitemap
- confirm that indexable pages are present
- confirm that draft, admin, and preview routes are absent
- confirm that canonical URLs use the production domain
- warn if robots.txt blocks important public directories

Add an npm script `lint:seo` and document how to run it.

そのcommandをCIにつなぎます。目的は、Codexが毎回手動でsitemapを確認することではありません。Codexにguardrailを一度作らせ、その後は自動で実行することです。

Workflow 5: source control付きcontent refresh

Content refreshは、teamがAIを誤用しやすい領域です。悪い例は「この80本の記事をSEO向けに書き換えて」です。より良い例は「approved sourcesを使って、古くなった特定sectionを更新して」です。

各articleについて、Codexに次を渡します。

• 現在のページ本文
• 対象クエリと検索意図
• 承認済みのsource notes
• product facts
• 許可されたinternal links
• 変更してはいけないsections
• toneとclaim rules

Prompt:

Refresh this article for 2026 search intent.

Use only the facts in `source-notes.md` and the existing article.
Update:
- the intro
- outdated tool references
- the comparison table
- FAQ questions
- meta title and description

Do not invent statistics. Mark any uncertain claim as `[needs review]`.
Keep the existing URL slug.
Return a short change log after editing.

このworkflowなら、scaleを出しながらeditorial accountabilityを失いません。

Workflow 6: spamにしないinternal link suggestions

Internal linksは有用ですが、自動internal linkingはすぐ見苦しくなります。Codexには、keyword matchingだけでなく、site graphとreader intentを理解させるべきです。

まずreview tableを作らせます。

Analyze the latest 30 blog posts and suggest internal links.

Rules:
- Max 2 suggested links per article.
- The link must help the reader continue the task.
- Avoid repeated exact-match anchors.
- Do not link every mention of a keyword.
- Output a table with source page, target page, suggested anchor, sentence context, and reason.

review後にだけ、Codexへfilesを編集させます。

Auspia式のSEO/GEO programでは、これは特に有用です。internal linksはranking signalであるだけではありません。AI systemsがsite全体のtopic relationshipsを理解する助けにもなります。

Workflow 7: codex exec によるCI-based SEO guardrails

Codexは codex exec を使ってscriptsからnon-interactiveに実行することもできます。OpenAIのCodex manualでは、これはpipeline内でCodexを実行し、他のtoolsが消費できるoutputを作り、明示的なsandboxとapproval settingsを使う方法として説明されています。

単純なuse caseは、nightly SEO triage jobです。

pnpm lint:seo --json \
| codex exec --json \
"Summarize these SEO validation failures. Group by template, estimate severity, and propose the smallest safe fix. Do not edit files." \
> seo-triage.jsonl

CIではpermissionsを厳しくします。Codex documentationでは、non-interactive runsはdefaultでread-only sandboxになり、より広いaccessは必要なときだけgrantすべきと説明されています。これはSEO automationでも良いruleです。reporting jobにはwrite accessは不要です。patch-generation jobはcontrolled branchまたはisolated runnerで実行します。

成熟したpatternは次のとおりです。

1. CIがSEO validation scriptを実行する。
2. 失敗したら、Codexがfailuresを要約する。
3. high-confidence issuesについて、Codexが別branchにpatchを作る。
4. 人間がPRをreviewする。
5. merge前に同じvalidation scriptがpassする必要がある。

ここまで来ると、automated SEOはmanual auditsの寄せ集めではなく、real operationsのように感じられます。

自動化してはいけないもの

一部のSEO workはhuman-ledのままにすべきです。

Codexに自動公開させてはいけないもの:

• legal、medical、financial、compliance-sensitive claims
• numbersを含むcustomer case studies
• pricing、discounts、contractual terms
• review schema、rating data、author credentials
• keywords獲得だけを目的にした大量のAI-written pages
• staging verificationなしのredirectsまたはrobots changes

source packetなしでcontentを作らせることも避けます。pageにresearchが必要ならresearchを渡します。claimにevidenceが必要ならevidenceを追加します。product limitationが重要なら直接書きます。Codexはorganize、patch、explainできますが、truthはteamが所有します。

Caption: 最初はrule-based checksを自動化します。strategy、claims、publishingは人間のcontrol下に残します。

実用的な30日rollout plan

1か月後の成果は、cleaner metadataやbetter sitemapだけではありません。成果は、diagnose、fix、validate、review、publishを繰り返せるsystemです。

Auspia take

多くのSEO teamでは、strategyとimplementationがまだ分断されています。strategyはdocsやspreadsheetsにあります。implementationはtemplates、CMS fields、schemas、deploy pipelinesにあります。このgapでSEO recommendationsは死にます。

Codexが有用なのは、implementation layerの中に入れるからです。実際のfilesを調べ、routesの生成方法を見て、templateをpatchし、testを実行し、何が変わったかを説明できます。うまく使えば、SEOは1回のheroic auditに依存するものではなく、repeatable checksに依存するものになります。

teamがより広いAI traffic systemを作っているなら、このworkflowをAuspiaのSEO、GEO、AEO toolsと接続します。toolsでvisibility gapsを特定し、Codexでfixをcode、content、validationへ変えます。

Codex SEO prompt template

starter promptとして使ってください。

You are helping with SEO automation for this repository.

Goal:
[Describe the specific SEO outcome.]

Context:
- Important files: [list files/folders]
- Data inputs: [CSV, crawl export, Search Console export, brief]
- Target pages: [URLs or route patterns]

Constraints:
- Do not invent facts, metrics, ratings, reviews, or sources.
- Do not change slugs unless explicitly requested.
- Keep human-readable content helpful and natural.
- Follow Google Search fundamentals: make pages crawlable, understandable, and useful.
- Keep changes small enough to review.

Validation:
- Run [build command].
- Run [SEO validation command].
- If validation cannot run, explain why.

Done when:
- The issue is fixed in code or content.
- Tests or validation pass.
- The final response includes changed files, remaining risks, and manual review notes.

FAQ

CodexはSEOを完全自動化できますか？

Codexは多くのSEO workflowを自動化できます。特にtechnical audits、metadata cleanup、schema implementation、sitemap checks、internal link suggestions、content refresh operationsに向いています。ただし、strategy、factual claims、publishing、high-risk changesをreviewなしで完全自動化すべきではありません。

Codexはtechnical SEOとcontent SEOのどちらに向いていますか？

repository内で直接作業できるため、technical SEOに最も強いです。source notes、product facts、target intent、editorial rulesを渡せば、content SEOにも役立ちます。

CodexはSEO contentをscaleできますか？

draftやrefreshはできますが、quality controlなしのscaleは危険です。source packets、人間review、明確なrulesを使います。目的はmass-produced search fillerではなく、helpful pagesです。

teamはCodex SEO automationをどう測定すべきですか？

まずoperational metricsを追います。issues found、issues fixed、validation pass rate、time saved、pages refreshed、regressions preventedです。search performanceが反映されるまでには、数週間から数か月かかることがあります。

最も安全な最初のprojectは何ですか？

読み取り専用のtechnical SEO auditから始めます。その後、title、canonical、sitemap inclusion、robots rulesを確認するvalidation scriptを1つ追加します。これにより、production-facing contentを編集し始める前に、Codexへ明確でlow-riskな役割を与えられます。

Source notes

この記事は、prompting、AGENTS.md、skills、non-interactive codex exec workflowsに関するOpenAI Codex manualと、SEO fundamentals、generative AI content、sitemaps、robots.txtに関するGoogle Search Central guidanceをもとにしています。

Codex SEO/GEO 学習パス

この記事は Codex SEO/GEO オペレーターシリーズの一部です。ゼロから構築する場合は、次の順番で進めてください。

1. 2026年にCodexで自動GEOを実践する方法
2. CodexでSEOを自動化する方法
3. AGENTS.mdでCodex SEOワークスペースを作る方法
4. MCPでCodexをSEOデータに接続する方法
5. 2026年版：最も実用的なCodex GEO Skill
6. キーワードクラスタリング用のCodex Skillを作る方法
7. SERP、コンテンツ、テクニカルSEOでCodex Subagentsを使う方法
8. 本番を壊さずにCodexでテクニカルSEOを修正する方法
9. Codex Automationsで毎日のSEO/GEO監視を行う方法
10. Codex SEO/GEO品質ゲート：Diff、証拠、テスト、人間の承認
11. CodexでSEO/GEO対応のWebサイトを作成・デプロイする方法

次に読むべき記事

前の記事: 2026年にCodexで自動GEOを実践する方法

次の記事: AGENTS.mdでCodex SEOワークスペースを作る方法