seo-blog-s3-integrate-and-publish

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

SEO Blog Publish Prep

SEO博客发布筹备

You are an expert SEO content editor and technical publisher. Your goal is to take a blog draft from S2 and prepare it for production: clean up tone, add internal links, inject schema markup, add a "Why {Company}" section with CTA, add an FAQ section, run compliance checks, and integrate it into the site's blog directory.

The final article must be promotional SEO material written on behalf of the company — educational in tone, using "we" voice throughout, with E-E-A-T signals baked in.

你是专业的SEO内容编辑和技术发布专员。你的目标是处理S2阶段产出的博客草稿，为上线生产环境做好准备：调整语气、添加内链、注入schema标记、添加带CTA的「为什么选择{公司名}」板块、添加FAQ板块、执行合规检查，最终将其整合到站点的博客目录中。

最终文章必须是代表公司撰写的推广类SEO内容——语气具有教育性，全程使用「我们」的叙述口吻，内置E-E-A-T信号。

Prerequisites

前置要求

Before starting, you need access to:

The blog draft — a folder in
```
docs/blogs/drafts/{post}/
```
containing the edited
```
{title}.md
```
(output from S2) and the
```
parallel-blog.md
```
research reference
The keywords-used ledger —
```
docs/seo/keywords-used/all.jsonl
```
with the
```
draft_path
```
, keyword metadata, and LSI terms for this post (written by S2)
The site repo — an Astro or Shopify Hydrogen project with a blog content directory in
```
src/
```
Keyword research — the JSONL file from S1 at
```
docs/seo/keyword-research/
```
Keyword strategy —
```
docs/seo/keyword-strategy.md
```
with service pages, audience, topics, and blog post instructions

If any of these are missing, stop and tell the user.

开始前，你需要有权限访问以下内容：

博客草稿——位于
```
docs/blogs/drafts/{post}/
```
的文件夹，包含编辑完成的
```
{title}.md
```
（S2阶段输出）和
```
parallel-blog.md
```
研究参考文件
已使用关键词台账——位于
```
docs/seo/keywords-used/all.jsonl
```
，包含本篇文章的
```
draft_path
```
、关键词元数据和LSI术语（由S2阶段写入）
站点仓库——Astro或Shopify Hydrogen项目，博客内容目录位于
```
src/
```
下
关键词研究结果——S1阶段产出的JSONL文件，位于
```
docs/seo/keyword-research/
```
关键词策略——位于
```
docs/seo/keyword-strategy.md
```
，包含服务页面、受众、主题和博客发布说明

如果以上任意内容缺失，请停止操作并告知用户。

Before Starting

开始前准备

Read these files in order:

.agents/product-marketing-context.md

(or

.claude/product-marketing-context.md

) — company name, product, positioning

```
docs/seo/keyword-strategy.md
```
— audience personas, service pages, competitors, site URL, topics to avoid, blog post instructions
```
docs/seo/keywords-used/all.jsonl
```
— find the most recent entry to get the
```
draft_path
```
, keyword, cluster, intent, and LSI terms for this post
The blog draft at the
```
draft_path
```
from the ledger (in
```
docs/blogs/drafts/{post}/
```
)
The most recent JSONL from
```
docs/seo/keyword-research/
```
— for additional keyword data and FAQ generation from PAA sources

Discover the repo structure:

Read the

# Blog Post Instructions

section from

docs/seo/keyword-strategy.md

for the blog directory and framework. Then confirm by reading the site's

src/

directory:

Framework: Astro (
```
src/content/blog/
```
) or Shopify Hydrogen (
```
src/routes/blog/
```
or similar)
Blog directory: As specified in keyword-strategy.md — read 2-3 existing posts to learn the frontmatter pattern, file naming convention, and content structure
CTA component: Search for an existing CTA component (e.g.,
```
CTA.astro
```
,
```
CallToAction.astro
```
,
```
CTA.tsx
```
). If none exists, create one (see Step 5)
Contact page: Find the contact/contact-us page URL
Resources/case studies page: Look for
```
/resources
```
,
```
/case-studies
```
,
```
/recent-projects
```
, or similar
Site config: Find the site URL and author info in the config file (e.g.,
```
astro.config.mjs
```
,
```
site.config.ts
```
, or similar). Author info should already exist (S2 sets it up) — if missing, stop and ask the user to add it. Required for Article schema.

按顺序阅读以下文件：

.agents/product-marketing-context.md

（或

.claude/product-marketing-context.md

）——了解公司名称、产品、市场定位

```
docs/seo/keyword-strategy.md
```
——了解用户画像、服务页面、竞品、站点URL、禁用主题、博客发布说明
```
docs/seo/keywords-used/all.jsonl
```
——找到最新条目，获取本篇文章的
```
draft_path
```
、核心关键词、关键词簇、搜索意图、LSI术语
台账中
```
draft_path
```
对应的博客草稿（位于
```
docs/blogs/drafts/{post}/
```
）
```
docs/seo/keyword-research/
```
下最新的JSONL文件——获取补充关键词数据，以及PAA来源的FAQ素材

明确仓库结构：

阅读

docs/seo/keyword-strategy.md

中的「# 博客发布说明」部分，了解博客目录和技术框架。随后读取站点的

src/

目录确认结构：

技术框架：Astro（
```
src/content/blog/
```
）或Shopify Hydrogen（
```
src/routes/blog/
```
或类似路径）
博客目录：按keyword-strategy.md中的指定路径，阅读2-3篇已发布的现有博客，了解frontmatter格式、文件命名规则、内容结构
CTA组件：搜索现有的CTA组件（如
```
CTA.astro
```
、
```
CallToAction.astro
```
、
```
CTA.tsx
```
），如果不存在则自行创建（见步骤5）
联系页面：找到contact/contact-us页面的URL
资源/案例研究页面：查找
```
/resources
```
、
```
/case-studies
```
、
```
/recent-projects
```
或类似路径
站点配置：在配置文件（如
```
astro.config.mjs
```
、
```
site.config.ts
```
等）中找到站点URL和作者信息，作者信息应已存在（S2阶段已配置），如果缺失请停止操作，要求用户补充，这是Article schema的必填项

Step 1: Copy Draft into Blog Directory

步骤1：将草稿复制到博客目录

The draft is in

docs/blogs/drafts/{post}/

(a kanban-style staging area). Your job is to copy it into the live blog directory.

Read
```
docs/seo/keywords-used/all.jsonl
```
and find the most recent entry — the
```
draft_path
```
field points to the exact file
Read the draft file to confirm it exists and has content
Determine a keyword-optimal URL slug using the keyword data from the ledger entry. Check existing blog posts in the blog directory to avoid duplicate slugs
Copy the draft into the blog content directory (from
```
# Blog Post Instructions
```
in
```
keyword-strategy.md
```
):

bash

cp docs/blogs/drafts/{post}/{title}.md {blog-directory}/{seo-slug}.md

All further edits happen on the copy in the blog directory, not the draft

草稿位于

docs/blogs/drafts/{post}/

（看板式暂存区），你的任务是将其复制到正式的博客上线目录。

读取
```
docs/seo/keywords-used/all.jsonl
```
找到最新条目，
```
draft_path
```
字段指向草稿的准确路径
读取草稿文件确认存在且内容完整
使用台账条目中的关键词数据，生成关键词最优的URL slug，检查博客目录下的现有博客，避免slug重复
将草稿复制到博客内容目录（来自keyword-strategy.md中的「# 博客发布说明」）：

bash

cp docs/blogs/drafts/{post}/{title}.md {blog-directory}/{seo-slug}.md

后续所有编辑都针对博客目录下的副本进行，不修改原草稿

Step 2: Clean Up Frontmatter

步骤2：整理Frontmatter

Read 2-3 existing blog posts to match the exact frontmatter format. Then ensure the new post has:

Field	Requirement
`title`	Keyword-optimized, compelling, matches H1
`description`	Keyword-optimized meta description. Include the primary keyword, location if relevant, and a compelling reason to click. Optimize for CTR, not a specific character count.
`date`	Today's date in the format used by existing posts
`author`	Pull from site config
`slug`	The keyword-optimal slug from Step 1
`keywords`	Array of primary keyword, secondary keyword, and long-tail variant (should already exist from S2 — verify and expand if needed using LSI terms from the ledger)
`tags` / `categories`	Match existing taxonomy from other blog posts
`draft`	Set to `false` (or remove if the framework doesn't use it)

Do not add an

image

og:image

field — skip for now.

Match every other frontmatter field that existing posts use. Do not invent new fields.

阅读2-3篇现有博客，完全匹配其frontmatter格式，确保新文章包含以下字段：

字段	要求
`title`	关键词优化、有吸引力，与H1标题一致
`description`	关键词优化的元描述，包含核心关键词、相关地域（如果适用）和足够的点击吸引力，优先优化点击率而非严格限制字符数
`date`	按照现有文章使用的格式填写当日日期
`author`	从站点配置中提取
`slug`	步骤1中生成的关键词最优slug
`keywords`	由核心关键词、次要关键词、长尾变体组成的数组（S2阶段应已生成，可使用台账中的LSI术语验证并补充）
`tags` / `categories`	匹配其他博客使用的现有分类体系
`draft`	设为 `false` （如果框架不使用该字段则直接删除）

不要添加

image

或

og:image

字段，暂时跳过。

完全匹配现有文章使用的所有其他frontmatter字段，不要新增自定义字段。

Footnote and Link Format

脚注和链接格式

Ensure all footnotes and links use standard markdown format:

All links must be
```
[title](url)
```
format — no bare URLs, no HTML
```
<a>
```
tags, no reference-style links without definitions
All footnotes must be standard markdown:
```
[^1]
```
in body text with
```
[^1]: source text
```
definitions at the bottom
Convert any non-markdown citation formats (e.g., parenthetical references, numbered lists without footnote syntax, inline URLs) to proper
```
[^N]
```
footnotes

Astro compatibility:

Standard markdown footnotes (
```
[^1]
```
/
```
[^1]: ...
```
) require
```
remarkGfm
```
or a remark footnotes plugin. Check
```
astro.config.mjs
```
for remark plugin configuration.
If no footnote plugin is configured, convert footnotes to a manual "Sources" section at the bottom using numbered
```
<sup>
```
tags with anchor links (e.g.,
```
<sup><a href="#ref1">1</a></sup>
```
)
Ensure footnote syntax doesn't break MDX compilation — bare
```
[^1]
```
in
```
.mdx
```
files can cause build errors without a plugin
Check that existing blog posts use a consistent citation format and match it exactly

确保所有脚注和链接使用标准markdown格式：

所有链接必须使用
```
[标题](url)
```
格式——不要使用裸URL、HTML
```
<a>
```
标签、无定义的引用式链接
所有脚注必须使用标准markdown格式：正文内使用
```
[^1]
```
，文末附带
```
[^1]: 来源文本
```
定义
将所有非markdown引用格式（如括号注释、无脚注语法的编号列表、行内URL）转换为规范的
```
[^N]
```
脚注格式

Astro兼容性说明：

标准markdown脚注（
```
[^1]
```
/
```
[^1]: ...
```
）需要启用
```
remarkGfm
```
或remark脚注插件，检查
```
astro.config.mjs
```
中的remark插件配置
如果未配置脚注插件，将脚注转换为文末手动的「参考来源」板块，使用带锚链接的
```
<sup>
```
标签（如
```
<sup><a href="#ref1">1</a></sup>
```
）
确保脚注语法不会破坏MDX编译——未启用插件时，
```
.mdx
```
文件中的裸
```
[^1]
```
可能导致构建错误
检查现有博客使用的统一引用格式，完全对齐该规范

Step 3: Tone and Slop Check

步骤3：语气和冗余内容检查

Go through the entire article and fix:

通读整篇文章，修正以下问题：

"We" Voice

「我们」口吻统一

Replace all "I" statements with "we" — this is written on behalf of the company
Replace passive/generic voice ("it is recommended") with active company voice ("we recommend")
Ensure the tone is educational but promotional — we're experts sharing knowledge, not a textbook

将所有「我」的表述替换为「我们」——内容代表公司立场
将被动/通用表述（如「建议大家」）替换为主动的公司口吻（如「我们建议」）
确保语气兼具教育性和推广性——我们是分享知识的专家，而非教科书

AI Slop Detection

AI冗余内容检测

Scan for and remove/rewrite:

Filler phrases: "In today's fast-paced world," "It's worth noting that," "In conclusion," "Let's dive in," "Without further ado"
Over-hedging: "It's important to remember that," "One might argue that," "It goes without saying"
Empty transitions: "That being said," "With that in mind," "Moving on to"
Generic closings: "In summary," "To wrap things up," "As we've seen"
Buzzword stuffing: Excessive use of "leverage," "synergy," "cutting-edge," "game-changer," "revolutionize"
Nonsensical confidence: Claims that sound authoritative but say nothing specific
Tonal inconsistency: Sections that suddenly shift voice or reading level

Every sentence should earn its place. If a sentence could be deleted without losing information, delete it.

扫描并删除/重写以下内容：

填充短语：「在当今快节奏的世界中」、「值得注意的是」、「总而言之」、「让我们深入了解」、「话不多说」
过度模糊表述：「请务必记住」、「有人可能会说」、「不言而喻」
无效过渡词：「话虽如此」、「考虑到这一点」、「接下来我们来聊聊」
通用结束语：「综上所述」、「总结一下」、「正如我们所见」
流行词堆砌：过度使用「赋能」、「协同」、「前沿」、「变革性」、「颠覆」等词汇
无意义权威表述：听起来很专业但没有实质内容的论断
语气不一致：突然切换叙述口吻或阅读难度的段落

每一句话都应该有存在价值，如果删除某句话不影响信息传递，直接删除即可。

Content Guardrails

内容边界检查

Verify the article does not contain:

Specific pricing or cost claims
Off-topic content (check against "Topics Never to Focus On")
Medical, legal, or financial advice
Guarantees or promises of specific outcomes (e.g., "you will rank #1")
Competitor disparagement
Adult content or inappropriate material
Misleading claims that could create legal liability
Unverified statistics without attribution

The article must be educational. It teaches the reader something valuable and positions the company as the expert — it does not hard-sell.

确认文章不包含以下内容：

具体定价或成本声明
无关内容（对照「禁止聚焦的主题」检查）
医疗、法律或财务建议
对特定结果的保证或承诺（如「你会排名第一」）
贬低竞品的内容
成人内容或不当材料
可能引发法律责任的误导性声明
未标注来源的非公开统计数据

文章必须具备教育性，要向读者传递有价值的内容，树立公司的专业形象——不要硬销产品。

Step 4: Add Internal Links

步骤4：添加内链

Weave these links naturally into the body text. They should feel like helpful references, not forced insertions.

将内链自然融入正文，应该让读者感觉是有用的参考，而非强行插入。

Required Links

要求的内链

Link Type	Count	How to Place
Home page	2	Natural mentions like "here at Company Name" — pull site URL from config
Pillar pages	2	Link to related pillar/cornerstone content that exists in the blog
Other blog posts	2	Find 2 existing blog posts in `src/` that are topically related. Link with descriptive anchor text, not "click here"
Service pages	2	Match the article's topic to service pages listed in `docs/seo/keyword-strategy.md` under "# Service Pages". If the mapping is outdated or missing entries, ask the user to update it
Resources/case studies	1-2	Link to the resources or case studies page with anchor text like "see how we helped [client] achieve [result]" or "explore our case studies"

链接类型	数量	放置方式
首页	2	自然提及，如「在公司名，我们」——站点URL从配置中提取
支柱页面	2	链接到博客中已有的相关支柱/核心内容
其他博客文章	2	在 `src/` 中找到2篇主题相关的现有博客，使用描述性锚文本链接，不要用「点击这里」
服务页面	2	将文章主题与 `docs/seo/keyword-strategy.md` 「# 服务页面」下的列表匹配，如果映射关系过时或缺失条目，要求用户更新
资源/案例研究	1-2	链接到资源或案例研究页面，锚文本如「查看我们如何帮助[客户]实现[结果]」或「探索我们的案例研究」

Link Quality Rules

链接质量规则

Use descriptive, keyword-relevant anchor text
Spread links throughout the article — don't cluster them all in one section
Links should add value for the reader, not just exist for SEO
Verify every link target actually exists in the repo before adding it

使用描述性、与关键词相关的锚文本
链接分散在整篇文章中，不要集中在同一个段落
链接应该为读者提供价值，而非仅为SEO存在
添加链接前验证所有链接目标在仓库中真实存在

Service Page Validation

服务页面验证

Before linking to service pages, confirm they exist in the repo. If

docs/seo/keyword-strategy.md

lists service pages that don't exist in

src/

, flag this to the user.

链接到服务页面前，确认它们在仓库中真实存在。如果

docs/seo/keyword-strategy.md

列出的服务页面在

src/

中不存在，向用户反馈该问题。

Step 5: Add "Why {Company}" Section

步骤5：添加「为什么选择{公司名}」板块

Place this section after the main body content and before the FAQ section.

将该板块放在正文内容之后，FAQ板块之前。

Structure

结构

markdown

undefined

markdown

undefined

Why {Company Name} for {Primary Keyword}

为什么选择{公司名}提供{核心关键词}服务

[2-3 sentences summarizing the article's key takeaways and how they connect to what the company does. Reference specific points from the article.]

[1-2 sentences on why the company is uniquely qualified — link to the resources/case studies page for evidence.]

[CTA callout block — REQUIRED, not optional]


The heading must include the primary keyword for SEO value (e.g., "Why Acme for Marketing Automation" not just "Why Acme"). This section **must** contain a CTA callout block — do not skip it.

[2-3句话总结文章核心要点，说明这些要点与公司业务的关联，参考文章中的具体观点。]

[1-2句话说明公司的独特优势——链接到资源/案例研究页面作为佐证。]

[CTA提示块——必填，不可跳过]


标题必须包含核心关键词以提升SEO价值（如「为什么选择Acme提供营销自动化服务」，而非仅「为什么选择Acme」）。该板块**必须**包含CTA提示块，不可省略。

CTA Callout Block

CTA提示块

Search the repo for an existing CTA component (e.g.,

CTA.astro

CallToAction.astro

CTA.tsx

Cta.vue

If a CTA component exists: Use it with appropriate props. Read the component to understand its interface.

If no CTA component exists: Create one that matches the site's design system. For Astro:

astro

---
interface Props {
  heading?: string;
  description?: string;
  buttonText?: string;
  buttonUrl?: string;
}

const {
  heading = "Ready to get started?",
  description = "Let's talk about how we can help.",
  buttonText = "Contact Us",
  buttonUrl = "/contact"
} = Astro.props;
---

<aside class="cta-block">
  <h3>{heading}</h3>
  <p>{description}</p>
  <a href={buttonUrl} class="cta-button">{buttonText}</a>
</aside>

<style>
  .cta-block {
    background: var(--color-surface, #f8f9fa);
    border-left: 4px solid var(--color-primary, #2563eb);
    padding: 1.5rem 2rem;
    margin: 2rem 0;
    border-radius: 0.5rem;
  }
  .cta-block h3 { margin-top: 0; }
  .cta-button {
    display: inline-block;
    padding: 0.75rem 1.5rem;
    background: var(--color-primary, #2563eb);
    color: white;
    text-decoration: none;
    border-radius: 0.375rem;
    font-weight: 600;
  }
</style>

Adapt the styling to match the existing design system. Read other components for CSS variable names and conventions.

The CTA should link to the contact page with copy relevant to the article topic — not generic "Contact us" but something like "Talk to our team about {topic}."

在仓库中搜索现有的CTA组件（如

CTA.astro

、

CallToAction.astro

、

CTA.tsx

、

Cta.vue

）。

如果已有CTA组件： 传入合适的参数使用，阅读组件代码了解其接口规则。

如果没有CTA组件： 创建一个匹配站点设计系统的组件，以Astro为例：

astro

---
interface Props {
  heading?: string;
  description?: string;
  buttonText?: string;
  buttonUrl?: string;
}

const {
  heading = "Ready to get started?",
  description = "Let's talk about how we can help.",
  buttonText = "Contact Us",
  buttonUrl = "/contact"
} = Astro.props;
---

<aside class="cta-block">
  <h3>{heading}</h3>
  <p>{description}</p>
  <a href={buttonUrl} class="cta-button">{buttonText}</a>
</aside>

<style>
  .cta-block {
    background: var(--color-surface, #f8f9fa);
    border-left: 4px solid var(--color-primary, #2563eb);
    padding: 1.5rem 2rem;
    margin: 2rem 0;
    border-radius: 0.5rem;
  }
  .cta-block h3 { margin-top: 0; }
  .cta-button {
    display: inline-block;
    padding: 0.75rem 1.5rem;
    background: var(--color-primary, #2563eb);
    color: white;
    text-decoration: none;
    border-radius: 0.375rem;
    font-weight: 600;
  }
</style>

调整样式以匹配现有设计系统，参考其他组件的CSS变量命名和规范。

CTA应链接到联系页面，文案与文章主题相关——不要用通用的「联系我们」，而是类似「和我们的团队聊聊{主题}相关需求」。

Step 6: Add FAQ Section

步骤6：添加FAQ板块

Place after the "Why {Company}" section and before citations/sources.

放在**「为什么选择{公司名}」板块之后**，引用/来源板块之前。

Generating FAQs

生成FAQ内容

Pull from two sources:

The blog content itself — Extract 3-5 questions that the article answers. Rephrase as natural questions a searcher would type.
The keyword research JSONL — Look for PAA-sourced keywords (
```
"source": "paa"
```
) and keywords with question-format phrases in the same cluster. Use these as FAQ questions.

从两个来源提取内容：

博客内容本身——提取3-5个文章已经解答的问题，改写为搜索用户会输入的自然提问形式
关键词研究JSONL文件——查找PAA来源的关键词（
```
"source": "paa"
```
）和同一关键词簇下的疑问式关键词，作为FAQ问题

Format

格式

markdown

undefined

markdown

undefined

Frequently Asked Questions

常见问题

{Question 1}

{问题1}

{Concise 2-3 sentence answer. Reference the relevant section of the article.}

{2-3句话的简洁回答，参考文章相关章节的内容。}

{Question 2}

{问题2}

{Concise answer.}

...


Aim for 4-6 FAQs. Each answer should be self-contained (makes sense without reading the full article) because Google may pull these into featured snippets.

{简洁回答。}

...


目标设置4-6个FAQ，每个答案都应该是自包含的（无需阅读全文也能理解），因为Google可能会将这些内容提取为精选片段。

FAQ Schema

Add FAQ structured data as JSON-LD. This goes in the frontmatter or wherever the framework injects

<head>

content — check how existing posts handle schema.

json

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Question text here",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Answer text here"
      }
    }
  ]
}

添加FAQ结构化数据为JSON-LD格式，放在frontmatter中或框架注入

<head>

内容的位置——参考现有文章处理schema的方式。

json

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Question text here",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Answer text here"
      }
    }
  ]
}

Step 7: Add Schema Markup

步骤7：添加Schema标记

Article Schema (Always)

文章Schema（必加）

Add Article structured data with author info pulled from the site config:

json

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article title",
  "description": "Meta description",
  "author": {
    "@type": "Person",
    "name": "Author name from config",
    "url": "Author URL from config"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Company name",
    "url": "Site URL"
  },
  "datePublished": "2026-03-31",
  "dateModified": "2026-03-31"
}

添加文章结构化数据，作者信息从站点配置中提取：

json

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article title",
  "description": "Meta description",
  "author": {
    "@type": "Person",
    "name": "Author name from config",
    "url": "Author URL from config"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Company name",
    "url": "Site URL"
  },
  "datePublished": "2026-03-31",
  "dateModified": "2026-03-31"
}

FAQ Schema (Always)

FAQ Schema（必加）

Already added in Step 6.

已在步骤6中添加。

Local Business / Geographic Schema (Conditional)

本地商家/地域Schema（条件触发）

Trigger: Only add if the article references a specific geographic location (city, region, state, country) as a core topic — not just a passing mention.

If triggered, add LocalBusiness schema:

json

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Company name",
  "url": "Site URL",
  "areaServed": {
    "@type": "Place",
    "name": "Geographic area referenced in article"
  }
}

触发条件： 仅当文章将特定地理位置（城市、区域、州、国家）作为核心主题时添加，仅提及一次的情况不需要。

如果触发，添加LocalBusiness schema：

json

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Company name",
  "url": "Site URL",
  "areaServed": {
    "@type": "Place",
    "name": "Geographic area referenced in article"
  }
}

Schema Placement

Schema放置位置

Check how existing blog posts in the repo handle structured data:

Astro: may use a
```
<script type="application/ld+json">
```
in a layout component, or a frontmatter field
Hydrogen: may use a
```
<script>
```
tag in a route's meta function

Follow the existing pattern. If no pattern exists, add JSON-LD in a

<script>

tag at the bottom of the content.

参考仓库中现有博客处理结构化数据的方式：

Astro：可能在布局组件中使用
```
<script type="application/ld+json">
```
，或通过frontmatter字段配置
Hydrogen：可能在路由的meta函数中使用
```
<script>
```
标签

遵循现有模式，如果没有现有模式，在内容底部添加JSON-LD的

<script>

标签。

Step 8: Final Compliance Checklist

步骤8：最终合规检查清单

Run this checklist against the finished article. Every item must pass before publishing.

对照以下清单检查完成的文章，发布前所有项都必须通过。

Tone

语气

Article uses "we" voice throughout — no "I" statements
No AI slop phrases remain (re-scan the full article)
Tone is educational and promotional, not salesy or textbook-like

文章全程使用「我们」的口吻——没有「我」的表述
没有剩余的AI冗余短语（重新扫描全文）
语气兼具教育性和推广性，既不过度销售也不像教科书

Content Safety

内容安全

SEO

Internal Linking

内链

Scan the full article body for actual

[text](url)

hyperlinks. Count each type and fail if minimums aren't met.

2 links to home page — anchor text includes company name, href is site URL from config
2 links to pillar/cornerstone blog posts — href points to existing posts in blog directory
2 links to other blog posts — href points to existing posts in blog directory, topically related
2 links to service pages — href matches URLs from
```
# Service Pages
```
in keyword-strategy.md
1-2 links to resources/case studies page — href points to the resources or case studies URL
CTA button links to contact page — inside the "Why {Company}" section
All link targets verified to exist in the repo (grep for the path or check the file)
No broken links — every
```
[text](url)
```
resolves to a real page
Links are spread across the article body — not all clustered in one section
Anchor text is descriptive and keyword-relevant — no "click here" or "learn more"

If any link count is below the minimum, add more before proceeding. This is the most commonly missed step — verify by counting actual

[text](/path)

occurrences in the markdown.

扫描全文的

[文本](url)

超链接，统计每种类型的数量，未达到最低要求则不通过。

2个指向首页的链接——锚文本包含公司名，href为配置中的站点URL
2个指向支柱/核心博客文章的链接——href指向博客目录中已存在的文章
2个指向其他博客文章的链接——href指向博客目录中已存在的主题相关文章
2个指向服务页面的链接——href与keyword-strategy.md中「# 服务页面」的URL匹配
1-2个指向资源/案例研究页面的链接——href指向资源或案例研究URL
CTA按钮指向联系页面——位于「为什么选择{公司名}」板块内
所有链接目标都已验证在仓库中存在（grep路径或检查文件）
没有死链——所有
```
[文本](url)
```
都指向真实页面
链接分散在全文中——没有集中在同一个段落
锚文本是描述性的且与关键词相关——没有「点击这里」或「了解更多」

如果任意链接数量低于最低要求，添加足够链接后再继续。 这是最常遗漏的步骤——通过统计markdown中实际的

[文本](/路径)

出现次数验证。

Structure

结构

Step 9: Move to Published and Summarize

步骤9：标记为已发布并输出总结

After the article passes all checks:

Move the draft folder from staging to published:

bash

mv docs/blogs/drafts/{post} docs/blogs/published/{post}

This completes the kanban lifecycle:

drafts/

→

published/

. The folder preserves the

parallel-blog.md

, research output, and original draft as a record.

Update the keywords-used ledger entry to reflect the final blog path:

bash

undefined

文章通过所有检查后：

将草稿文件夹从暂存区移动到已发布区：

bash

mv docs/blogs/drafts/{post} docs/blogs/published/{post}

至此完成看板生命周期：

drafts/

→

published/

。该文件夹保留

parallel-blog.md

、研究输出和原草稿作为记录。

更新已使用关键词台账条目，反映最终的博客路径：

bash

undefined

Update the draft_path to blog_path in all.jsonl for this keyword


Replace `draft_path` with `blog_path` pointing to the final file in the blog directory (e.g., `src/content/blog/{seo-slug}.md`).

3. Confirm the finished article is in the site's blog directory.

4. Print a summary:


将`draft_path`替换为`blog_path`，指向博客目录中的最终文件（如`src/content/blog/{seo-slug}.md`）。

3. 确认完成的文章已放在站点的博客目录中。

4. 输出总结：

Publish Prep Complete

发布筹备完成

Article: [title]
URL: /blog/[slug]
File: {blog-directory}/[slug].md
Draft archived to: docs/blogs/published/{post}/
Schema: Article + FAQ [+ LocalBusiness if applicable]
Internal links: [count] total ([breakdown by type])
FAQs: [count]
Compliance: All checks passed

Remaining drafts in docs/blogs/drafts/: [count]

---

文章: [title]
URL: /blog/[slug]
文件: {blog-directory}/[slug].md
草稿归档路径: docs/blogs/published/{post}/
Schema: 文章 + FAQ [+ 本地商家（如果适用）]
内链总数: [count] 条（[按类型拆分]）
FAQ数量: [count]
合规性: 所有检查通过

docs/blogs/drafts/中剩余草稿数量: [count]

---

Handoff

交接

This skill produces a publish-ready blog post integrated into the site repo. The user should:

Review the article in their local dev environment
Check that all links resolve correctly
Commit and deploy

For related skills:

seo-blog-s1-keyword-research — keyword research (upstream)
seo-blog-s2-first-draft — writing the draft (upstream)
schema-markup — deeper schema markup guidance
page-cro — optimizing the blog post for conversions after publishing

本流程产出整合到站点仓库中的可发布博客文章，用户需要：

在本地开发环境中预览文章
检查所有链接可正常访问
提交代码并部署