如何用 Codex 自动化网站 SEO：新手指南

在用 Codex 改善页面之前，你不需要先懂 canonical 标签的意思。你需要的是一个页面 URL、在准备修改时可使用的网站项目访问权限，以及一条清楚的规则：先让 Codex 检查，再由你批准更改。

本指南会示范如何使用 Codex 与 seo-auto-optimizer 技能，让新手也能安全地自动化重复性 SEO 工作。你会让 Codex 检查页面、用日常语言解释发现事项、在网站文件中准备已批准的更新，并在上线前测试结果。

SEO 自动化不是把网站交给代理人后叫它「全部修好」。它是让代理人处理耗时而可重复的部分，同时把可能让页面从搜索结果消失或使访客困惑的决定留在你手上。

这是一篇以代码仓库为优先的教学。SEO 技能负责审核页面；Codex 的任务是在与网站相同的代码仓库内工作、遵循既有的 AGENTS.md 指引，并留下可供审核的 diff。你不必要求它「在电脑里某处找代码」。

完成这套流程后，你会拥有什么

完成第一次工作流程时，你将拥有：

• 一个重要 URL 的可见 SEO 问题检查结果；
• 一份 Codex 可以协助处理、且已按优先顺序排列的短清单；
• 每项建议的白话解释；
• 若你决定实施，则有一组已审核的本地网站项目更改；以及
• 一份部署前的测试清单。

第一次操作请预留 30 到 60 分钟。选一个对业务重要的页面：首页、产品页、服务页，或已获得一些流量的文章。不要一开始就处理整个网站。

这里的「完成」是指你能指出该页面、说明改了什么及为什么改，并确认更新后页面仍正常运作。这不代表保证排名上升；搜索引擎还需要时间重新抓取与评估页面。

开始前准备四样东西

即使没有 Google Search Console 或技术背景，你仍可开始。第一次检查使用公开页面可见的信号，请先备妥以下项目。

Google Search Console、Bing Webmaster Tools 与爬虫导出数据会在之后派上用场。它们能回答单一页面无法回答的问题，例如点击是否下滑、是否与其他 URL 竞争，或是否有大范围索引阻碍。

在 Codex 工作区建立 SEO Auto Optimizer 技能

你需要自行建立技能文件，不必从本文下载任何附件。

最快的办法：把本文发给 Codex

若本文已发布，你可以把文章URL交给 Codex，请它为你设置技能。复制以下提示词，将 [ARTICLE URL] 改成本文实际URL，再传给 Codex。

请阅读本文，并依照本文指示安装 seo-auto-optimizer 技能：
[ARTICLE URL]

我是新手。请找出文章中完整的 SKILL.md 代码区块。先检查此代码仓库的 Codex 设置或指引，找出已设置的项目技能目录；接着在该位置建立必要的 seo-auto-optimizer/SKILL.md 文件，并逐字复制该代码区块。

写入文件前，请先告诉我你将使用的完整路径。写入后请显示前 10 行，并确认技能名称是 seo-auto-optimizer。

现在不要检查我的网站、编辑网站文件、更改设置、部署任何内容或执行 SEO 稽核；只安装并验证此技能。

如果 Codex 无法打开文章URL，请采用下方手动方法。必要时，你也可以在此提示词后直接贴上完整代码区块。不要把项目专用技能随意放进全域文件夹；请使用代码仓库已设置的位置，或请 Codex 先显示可用的技能位置。

在要用于 SEO 的 Codex 工作区根目录中，建立以下文件夹与文件：

your-codex-workspace/
skills/
seo-auto-optimizer/
SKILL.md

Codex 可从已设置的项目或个人技能目录载入技能。先请 Codex 检查代码仓库的 AGENTS.md 与 .codex 设置，并使用它回报的确切技能位置。文件夹名称和文件内的 name 都必须是 seo-auto-optimizer，Codex 才能以 $seo-auto-optimizer 呼叫它。

建立一个名为 SKILL.md 的纯文本文件，贴上以下完整内容。不要把它贴进网站代码；它应放在 skills/seo-auto-optimizer/ 文件夹内。

此技能从唯读模式开始，这是刻意的设计。它会检查公开资讯并提出修正计划，但不会发布页面、提交网站地图、编辑 Search Console，或更改正式网站。

---
name: seo-auto-optimizer
description: Audit one public URL or a group of website URLs with evidence, then create an SEO optimization plan ranked by impact and effort. Use when a user asks to check, diagnose, optimize, or create an SEO task list, especially for indexing, technical SEO, metadata, structured data, content quality, internal links, search intent, keyword cannibalization, Core Web Vitals, mobile experience, CTR, Google Search Console, Bing Webmaster Tools, sitemaps, robots.txt, or E-E-A-T. By default, audit and provide code or copy recommendations only. Do not change the website, CMS, search-engine consoles, or third-party platforms.
---

# SEO Auto Optimizer

Turn a supplied URL into a verifiable SEO optimization plan that a developer, content team, or growth team can act on. Never present an item as checked or fixed when public evidence cannot confirm it.

## Working boundaries

- Default to read-only work. Inspect public pages, resources, and public site files. Do not change live pages, submit a sitemap, publish content, buy links, or operate any account.
- For a single-URL request, audit that URL and only the same-domain public files needed to verify it, such as `robots.txt`, a sitemap, or page links. Do not turn a single-page observation into a site-wide conclusion.
- Mark work that needs a login, search-performance data, a full crawl, server logs, or business facts as `Needs data`. State what data is needed and how to check it.
- Do not recommend black-hat, manipulative, or fabricated SEO: no purchased links, fake reviews/authors/comments, doorway pages, keyword stuffing, or bulk low-value AI pages.
- Follow the site's market, page language, URL conventions, and content standards. Proposed titles, meta descriptions, H1s, and body copy must use the target page's language.

## Inputs and clarification

A request needs at least one URL. If available, use the target market, language, business model, primary conversion, target keywords, Google Search Console or Bing exports, and local website project.

When those details are missing, do not block the work. Infer what you can from the page language, page type, and visible content, then state your assumptions at the beginning of the report. Ask one focused question only when the user requests keyword strategy, competitive content, or a site-wide change and the answer would materially depend on the target market or business.

## Audit process

### 1. Build an evidence baseline

1. Record the inspection date, final URL, HTTP status, redirect chain, `<html lang>`, visible robots instructions, and page-rendering limits.
2. Read the first screen, main content, and available source or DOM. Record the title, meta description, canonical, robots meta, viewport, H1-H6, visible publish or update date, author information, approximate body length, images, internal and external links, JSON-LD, and important JavaScript dependencies.
3. Check the same-domain `/robots.txt`. Check a sitemap only when one is discoverable; do not say a sitemap does not exist merely because its URL is not explicitly listed.
4. Keep locatable evidence for every conclusion: tag text, HTTP header, link URL, DOM observation, screenshot observation, or public-tool result. If the page is blocked by a WAF, login, geography, or another access limit, state the limitation immediately.

### 2. Classify every check

Use exactly one status for each item:

| Status | Meaning |
| --- | --- |
| `Pass` | Public evidence shows the item meets its purpose. |
| `Issue` | Public evidence shows an error, risk, or clear omission. |
| `Opportunity` | It may not be an error, but there is a reasonable opportunity to improve visibility, click-through rate, user experience, or conversion. |
| `Needs data` | Google Search Console, Bing, logs, a full crawl, field performance data, or keyword data is required. |
| `Not applicable` | The page type or business does not need this item; explain why. |

Do not turn `Needs data` into an `Issue` just to fill a checklist. Resolve the root causes that affect crawling, indexing, user experience, or the page's main intent before minor copy changes.

### 3. Create an action plan

Merge findings into non-duplicative tasks and rank them:

- `P0`: The page cannot be crawled or indexed; an incorrect canonical; accidental `noindex`; critical 4xx/5xx; site-wide robots blocking; severe mobile or rendering failure.
- `P1`: Main-page intent or content mismatch; duplicate or thin content; missing or conflicting title and H1; unacceptable structured data; missing key internal links; obvious performance bottleneck.
- `P2`: CTR improvements; images and alt text; FAQs; author and update information; content expansion; topic or comparison pages; local link and URL improvements.
- `P3`: Growth experiments, link earning, business profiles, and monitoring that require performance data or external coordination.

For every task, state the problem, evidence, recommended action, owner (developer, content, SEO, or growth), acceptance criteria, and risk or prerequisite. Give specific code or copy only when current information supports it. Where brand facts are missing, use clear placeholders instead of inventing facts.

## What to check

### A. Crawling, indexing, and URLs

Check and report:

- HTTP status, whether redirects are single-hop and appropriate, loops, and HTTP/HTTPS or www/non-www confusion.
- `robots.txt`, meta robots, `X-Robots-Tag`, and whether canonical URLs are reachable, absolute, single, self-referencing, or point to a sensible preferred URL.
- Whether canonical, `noindex`, pagination or filtering rules, and sitemap behavior agree. Mark uncertain cases as `Needs data`.
- Whether URLs are stable, readable, descriptive, free of meaningless parameters, case or trailing-slash duplication, and keyword stuffing. Do not recommend casual URL changes unless the plan includes 301 redirects, internal-link updates, canonical updates, sitemap updates, and rollback conditions.
- Whether main content appears in initial HTML or can render reliably. When important content depends only on client-side JavaScript, recommend verification with URL Inspection, rendering tests, and server-side rendering or prerendering options.
- Discoverable broken links, 404s, soft 404s, and incorrect internal destinations. A single URL cannot prove that a whole site has no broken links.

### B. Page structure and metadata

Check:

- A unique, accurate, intent-matched title. For Latin-script languages, a rough 50-60 characters can be useful, but accuracy matters more than reaching a count.
- A unique meta description that describes the page's real value without keyword lists or false promises. A meta description is not a ranking guarantee; prioritize relevance and likely click-through appeal.
- One H1 that describes the page's main question. Organize H2 and H3 headings by real topic hierarchy, without skipped levels or decorative text disguised as headings.
- `lang`, viewport, mobile usability, the ratio of main content to template noise, and breadcrumb visibility and semantics.
- Appropriate image formats, dimensions, lazy loading, and specific alt text. Decorative images should have empty alt text. Do not force keywords into alt text.

When recommending a rewrite, provide one adoptable title, meta description, H1, and heading outline. Label any information that needs a brand-owner confirmation.

### C. Structured data and trust signals

Check whether visible page content and JSON-LD, Microdata, or RDFa agree. Consider only schema appropriate to the page type: `BreadcrumbList`, `Article` or `BlogPosting`, `Product`, `SoftwareApplication`, `Organization`, `LocalBusiness`, `FAQPage`, and `WebPage`.

- Recommend schema only when it represents visible, real page information. Never add invented ratings, reviews, prices, authors, FAQs, or awards.
- Identify required fields such as URL, name, description, image, author, publish date, `dateModified`, breadcrumb positions, and entity identifiers.
- For content pages, check visible author information, author page or experience, editorial policy, sources, contact information, organization information, update date, and factual citations. E-E-A-T is not a tag that can be added; it comes from verifiable content and entity information.
- When schema exists, recommend the Google Rich Results Test and Schema Markup Validator as acceptance checks.

### D. Content, intent, and duplication

Identify the page's main query intent: informational, commercial research, transactional, local, navigational, or mixed. Check whether the main content answers the question early and adds value through original evidence, examples, steps, data, or product detail.

- Flag clear thin content, template repetition, unanswered core questions, intent mismatch, and stale content. Do not define thin content by word count alone.
- A single URL cannot prove site-wide duplicate content, keyword cannibalization, or orphan pages. Explain that these require a URL inventory, canonical and index status, GSC query-to-page data, an internal-link graph, and similarity analysis.
- For overlapping pages, first define the evidence and decision criteria for keep, merge, split, or redirect. Never recommend deleting a page based on a guess.
- When content creation is requested, provide a search-intent brief, unique value, information architecture, sources needed for claims, and internal-link targets. Original content means independent insight or verification, not a competitor rewrite.
- Suggest comparison, alternatives, list, or FAQ pages only when they have distinct intent, real comparison criteria, and maintainable facts. Do not create batches of low-value templates.

### E. Internal links, architecture, and topic coverage

Assess how the page can be found and understood:

- Check whether important pages have crawlable HTML links from relevant parent pages, topic hubs, navigation, or breadcrumbs. Anchor text should naturally describe the destination.
- Mark orphan pages as `Needs data` unless a sitemap and full link graph prove the finding.
- For a topic cluster, define one pillar or owner URL, a distinct intent for each support page, link direction, and a cannibalization rule. Multiple near-identical owner pages should not compete for one head topic.
- Before suggesting feature, use-case, integration, comparison, alternatives, or FAQ pages, define the user question, target query, unique content, owner URL, and link-back path.

### F. Performance, mobile use, and Core Web Vitals

Separate lab data from field data. Prefer real-user data from CrUX or PageSpeed Insights to validate LCP, INP, and CLS. Without it, inspect obvious risks: oversized hero media, images without dimensions, render-blocking CSS or JavaScript, third-party scripts, font loading, layout shifts, and heavy client-side rendering.

Every performance recommendation must explain its mechanism and test method. For example: responsive, compressed hero media may improve LCP; image width and height reduce CLS risk; splitting long tasks may improve INP. Do not promise a score or ranking improvement.

### G. Search performance, keywords, and external authority

Unless the user supplies data or access, mark these items as `Needs data`:

- Page-two rankings, traffic or ranking declines, and query-to-page keyword cannibalization.
- URLs or queries with high impressions and low CTR, plus title and meta tests.
- High-volume, low-difficulty keywords, SERP and People Also Ask opportunities, competitor gaps, and search intent.
- High-quality backlinks, broken-link opportunities, brand mentions, Google Business Profile, and local citations.
- GSC or Bing sitemap submission, URL Inspection, index coverage, and crawl errors.

Give an executable data-checking instruction. For example: in GSC, compare the last 28 days with the previous 28 days, filter to the target URL, export queries, impressions, clicks, CTR, and average position, then test a new title or meta description for high-impression, same-intent queries with weak CTR. Link strategies must use audience-relevant, editorially independent, verifiable channels and genuinely useful assets.

## Default deliverable format

Unless the user asks for a shorter response, return these sections in this order:

1. `Scope and limits`: target URL, check date, accessibility, what could not be verified, and key assumptions.
2. `Executive summary`: the three to seven most important findings and what to address first.
3. `Check matrix`: status, evidence, and short conclusion for items A-G. Cover the user's supplied checklist, and state `Needs data` where necessary.
4. `Prioritized action list`: P0-P3 tasks with owner, effort (S/M/L), acceptance criteria, and dependencies.
5. `Implementation-ready recommendations`: where appropriate, include metadata, heading structure, JSON-LD templates, internal-link locations, content briefs, or performance fixes.
6. `Data and human follow-up`: needed GSC, Bing, crawl, log, keyword, and business inputs, plus exact validation steps.

Use careful language. Say a change may improve relevance, discoverability, or CTR. Do not promise indexing, first place rankings, or that every SEO issue has been fixed.

## Completion standard

Before delivering the work, confirm:

- Every conclusion has public evidence or is explicitly labeled as an assumption or `Needs data`.
- Tasks are ordered by impact, dependency, and actual executability, not copied mechanically from a checklist.
- Recommendations do not risk breaking URLs, canonicals, index status, or content facts. Migration, deletion, and merge suggestions include redirect and rollback conditions.
- Schema and E-E-A-T recommendations come from visible facts or are clearly marked as information still needed.
- The report makes clear that no live changes, submissions, or publishing actions were performed.

储存文件。如设置需要，请重新启动或重新载入 Codex，然后询问：请列出此工作区可用的技能。seo-auto-optimizer 可以使用吗？ 在 Codex 确认此技能可用之前，请不要开始后续教学。

在 Codex 编辑前先设置一条代码仓库规则

在 Codex 里，AGENTS.md 是放置长期代码仓库规则的合适位置。你可以记录如何执行网站、SEO 文件在哪里、需要什么检查，以及哪些范围必须先取得批准。如果代码仓库已有 AGENTS.md，请让 Codex 先阅读；不要用通用范本覆盖它。

若代码仓库没有指引档，请在第一次实施前于代码仓库根目录建立一个小型 AGENTS.md，内容如下：

# SEO 自动化规则

- 编辑文件前先阅读既有网站结构。
- 使用 seo-auto-optimizer 技能进行页面检查并提出有证据支持的建议。
- 编辑任何文件前，先列出所有将更改的文件并等待批准。
- 除非使用者明确批准该项确切更改，否则不得更改 URL、重定向、robots.txt、noindex、canonical 标签、网站地图文件或部署设置。
- 对已批准工作采取范围最小的更改。
- 编辑后显示 Git diff，并在可用时执行代码仓库相关检查。
- 除非使用者明确要求，否则不得部署、commit 或 push。

这不是 SEO 设置档，而是 Codex 在此代码仓库必须遵循的长期指引。重点很简单：即使你下周忘了今天使用的确切提示词，规则仍然有效。

在请 Codex 更改任何内容前先检查页面

打开 Codex 并贴上以下提示词，将范例URL换成自己的页面URL。

请使用 $seo-auto-optimizer 检查这个页面：
https://example.com/your-page

我是 SEO 新手。请用白话中文说明每一项发现。
不要更改文件、发布页面、提交任何内容或修改正式网站。

每项建议都请列出：
1. Codex 找到什么，以及在哪里找到。
2. 为什么它可能影响访客或搜索引擎。
3. 它是已确认的问题、改善机会，还是需要更多数据。
4. 最安全的下一步。
5. 我是否需要开发者或 Google Search Console 数据。

请依 P0、P1、P2、P3 的优先顺序整理工作。

第一份输出应该是报告，而不是已被修改的网站。这才是正确顺序。

Codex 通常可以检查可见信号，例如页面标题、meta description、主标题、图片 alt 文字、内部链接、canonical 标签、robots 指令、结构化数据、移动端 viewport，以及明显的失效链接。它也能找出明显的页面层级内容缺口。

它不应表现得好像无所不知。与其用一个 URL 就断言整个网站，更值得信赖的报告往往会明确标示 Needs data。

不懂 SEO 也能看懂这份报告

此技能使用两种简单标签：状态和优先顺序。在批准任何事情前，请先看懂两者。

优先顺序会告诉你该先看什么。

不要因为报告列出就全部批准。第一次实施应限制在一到三个低风险更改；第一次发布越小，越容易检查和还原。

选择安全的第一批更改，把高风险决策留到之后

多数新手可以从清楚的页面层级改善开始。下表可作为有用的界线。

例如，canonical 标签是一项小指示，用来告诉搜索引擎：相似页面中哪一个版本应视为主要版本。更改它可能很重要，却也可能意外让 Google 忽略你在意的页面。更改前，请 Codex 显示目前与建议的 canonical URL，再取得技术审核。

同样原则也适用于 robots.txt 与 noindex。感谢页、私人预览页或筛选后的结果页可能正确使用这些设置；它们不会自动构成错误。

请 Codex 提出实施计划，不要突然直接编辑

从报告复制已批准项目，并在网站项目中使用以下提示词。它会告诉 Codex 可以改什么，以及同等重要的：不能碰什么。

我只批准以下 SEO 更改：
[贴上已批准项目]

请审核我的本地网站项目，并准备一份实施计划。
编辑任何文件前，请显示：
1. 预计更改的每一个文件。
2. 每个文件会影响的确切页面或元件。
3. 访客与搜索引擎会看到什么不同。
4. 我们将如何测试结果。
5. 若更改错误，如何还原。

不要更改 URL、删除页面、编辑 robots.txt、新增 noindex 标签、
更改重定向、发布内容、部署网站，或修改批准清单以外的任何项目。

显示计划后请等待我的批准。

回复前先检查文件清单。如果 Codex 想动到你不认识的文件，请问清楚原因。若计划只说「最佳化 SEO」，却无法列出文件名称与预期结果，请要求它说得更具体。

当计划看起来正确时，给出范围明确的批准：

已批准。只实施上方计划。

编辑后请：
- 显示简短的逐档摘要；
- 显示相关 Git diff 或修改前后文字；
- 说明我需要手动验证的项目；
- 若可用，运行项目既有的检查；
- 不要部署。

这正是自动化变得有用的地方。Codex 可以完成重复编辑，但改什么、何时公开，仍由你决定。对 Codex 而言，Git diff 是重要的审核证据：它让你准确看到代码仓库中哪些行真的发生了变化。

页面上线前检查结果

不要跳过预览。技术上有效的更改，仍可能读起来不自然、破坏版面，或降低页面的实用性。

请使用以下发布检查清单：

若更改了 schema，请在部署后或可存取的测试页面上执行 Google Rich Results Test 或 Schema Markup Validator。schema 格式有效还不够，它也必须符合使用者在页面上实际看得到的内容。

如果某项检查失败，不要请 Codex 任意追加编辑。告诉它确切错误、是哪一项已批准更改造成，并要求最小范围的修正。若你无法解释或验证一项更改，请在部署前还原。

SEO 自动化无法从单一页面得知的事

这是新手最容易被看起来信心十足的 AI 输出误导的地方。有些 SEO 问题需要浏览器看不到的数据。

你之后可以自动化这些输入数据的搜集与整理。对第一个页面而言，让 Codex 标示 Needs data 就足够了，不要把猜测假装成诊断。

一套能长期保持的简单每周例行流程

第一个页面上线并完成检查后，每周针对一个重要页面重复这套流程：

1. 选择有商业目的的页面，而不是任意 URL。
2. 执行唯读的 Codex 检查。
3. 最多批准几项明确、低风险的更新。
4. 审核实施计划与 Git diff。
5. 部署前先在本地或测试环境测试。
6. 在简单试算表或 Markdown 档中记下页面、日期、更改与未解问题。

累积几周的更改后，再加入 GSC 导出数据。接着 Codex 能协助你找出下个值得改善的页面，并以真实曝光、点击或查询数据支持判断。若需要更广泛的诊断，请结合代码层级审核使用 网站 SEO 评分检查工具 。

常见问题

Codex 能自动化我网站的所有 SEO 吗？

不能。Codex 能自动化审核公开页面信号、整理问题清单、起草 title 与 description、准备代码或内容更改，以及检查已批准更改清单等重复工作。涉及删除页面、重定向、索引控制、canonical、商业声明、部署或成效数据的决策，仍需要人工审核。

开始前需要先懂 SEO 关键字吗？

不需要。先从一个重要页面开始，请 Codex 以白话解释可见的 SEO 设置。当你要建立新页面，或决定哪些既有页面值得投入更多工作时，关键字研究才会派上用场。它需要研究数据与你对客户的理解，而不只是一份代理人产生的清单。

Codex 可以帮我编辑 WordPress、Webflow 或 Shopify 页面吗？

只有在你的 Codex 环境拥有该系统或网站文件的已批准访问权限时才可以。第一次操作时，请 Codex 准备确切的文字、代码或文件层级更改，再由你自行更新 CMS，或请网站拥有者批准。建立可靠的审核流程前，不要授予发布权限。

这些更改能让我的页面登上 Google 第一名吗？

不能。SEO 更改可能改善可抓取性、相关性、清晰度与使用者体验。排名还取决于竞争、搜索意图、网站品质、链接，以及搜索引擎随时间评估页面的方式。请把 Codex 视为帮助你做出更好、更安全决策的方法，而不是排名保证。

作者：Auspia 的技术 SEO 实务工作者 Julian Mercer。Julian 拥有 14 年经验，专注于可抓取性、schema、渲染、网站架构，以及让 AI 更容易读取内容的技术基础。