n8n定时产出结构化SEO长文并推送收录

原文要点

该模板每两天定时运行或经webhook（POST /sunoapi-generate-content）按需触发，可带topic/keyword覆盖字段。它选取预定义的Suno API关键词，准备文章简报与目标slug，调OpenAI Chat Completions生成含markdown正文与FAQ的结构化JSON长文，解析后统计字数，组装Schema.org的TechArticle、FAQPage、BreadcrumbList三种JSON-LD；过了基础质检就把内容、元数据与结构化数据POST到作者自己的发布端点https://sunoapi.top/api/blog/publish（带x-sync-secret头），再把已发布URL提交IndexNow加速收录，并向webhook调用方返回JSON状态。要用必须替换为自己的发布接口、密钥和IndexNow key。

这次做成什么

按该模板结构搭一条“定时/webhook→AI长文→JSON-LD→发布→IndexNow”流水线，但把发布端点换成本站练习用的本地模拟接口，先验证质检与结构化数据再接真实CMS。

准备什么

• 可调用OpenAI Chat Completions的API Key（或兼容服务）
• 一个你自己控制的博客发布接口（练习期用本地模拟接口，勿向sunoapi.top发请求）
• IndexNow key及可托管key文件的站点（练习期可跳过此步）
• 能跑定时任务并能暴露webhook的n8n实例

具体怎么做

1. 建双触发与选题

   加Schedule Trigger设为每两天一次；再加Webhook节点监听POST路径（如/content-generate），body可选带topic、keyword、slug覆盖。用Code节点维护关键词清单：默认取清单下一个词，webhook传了keyword就用覆盖值，同时生成目标slug（小写字母与连字符）。

2. 生成结构化长文JSON

   用HTTP Request节点调Chat Completions，用下方提示词要求模型只输出JSON对象：title、slug、markdown正文、faq数组（question/answer对）、metaDescription。练习期先用一次手动执行拿到样例输出，固定为后续节点的测试数据。

3. 质检与组装JSON-LD

   Code节点解析JSON并做基础质检：正文字数达到下限、faq至少3条、title非空、slug合法；不合格则标记failed不发布。通过后组装三段JSON-LD：TechArticle（headline、wordCount、datePublished）、FAQPage（把faq数组映射为mainEntity）、BreadcrumbList（首页/栏目/文章三级）。

4. 发布与提交收录

   练习期把发布请求发到一个本地模拟接口（如n8n自带的测试webhook或本地HTTP服务），请求头带x-sync-secret，body含content、metadata与schemas，模拟接口校验密钥后返回{ok:true,url}；拿到url后再决定是否调IndexNow（body填你的key与keyLocation，key文件须已托管在该URL）。最后把{status, slug, url, wordCount}作为JSON返回给webhook调用方。

可直接复制的材料

你是技术SEO撰稿人。围绕关键词「{{ $json.keyword }}」写一篇面向开发者的长文，只输出一个JSON对象，不要markdown围栏，字段如下：title（不超过60字符的中文标题）、slug（小写英文与连字符）、metaDescription（不超过155字符）、content（markdown正文，至少1500字，含H2/H3小节、代码示例）、faq（3至5个对象，每个含question和answer，问题必须是开发者真实会搜的疑问）。主题背景：{{ $json.brief }}

const a = $input.first().json;
const wordCount = a.content.split(/\s+/).length;
const slugOk = /^[a-z0-9-]+$/.test(a.slug);
const pass = wordCount >= 800 && (a.faq||[]).length >= 3 && a.title && slugOk;
const base = 'https://blog.example.com';
const schemas = [
  {"@context":"https://schema.org","@type":"TechArticle","headline":a.title,"wordCount":wordCount,"datePublished":new Date().toISOString()},
  {"@context":"https://schema.org","@type":"FAQPage","mainEntity":(a.faq||[]).map(f=>({"@type":"Question","name":f.question,"acceptedAnswer":{"@type":"Answer","text":f.answer}}))},
  {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[
    {"@type":"ListItem","position":1,"name":"首页","item":base},
    {"@type":"ListItem","position":2,"name":"专栏","item":base+'/articles'},
    {"@type":"ListItem","position":3,"name":a.title,"item":base+'/articles/'+a.slug}
  ]}
];
return [{json:{pass, wordCount, slug:a.slug, payload:{content:a.content, metadata:{title:a.title, description:a.metaDescription}, schemas}}}];

{"keyword":"local llm api rate limit","topic":"本地大模型API限流实践","slug":"local-llm-api-rate-limit"}

输入与输出示例

本站虚构演示，非作者工作流的真实运行结果；域名与字数均为练习设定。

输入

向webhook POST上方测试体，要求围绕“local llm api rate limit”生成文章。

对应输出

模型返回JSON：title="本地大模型API限流：开发者的重试与队列实践"，content约1800字含H2小节与代码示例，faq含4条问答。质检输出pass=true、wordCount=1800，三段JSON-LD中FAQPage的mainEntity含4个Question。模拟发布接口收到带x-sync-secret的请求并返回{ok:true,url:"https://blog.example.com/articles/local-llm-api-rate-limit"}，webhook调用方收到{status:"published",slug,url,wordCount:1800}。

做完检查这些

• webhook传slug覆盖时，最终发布URL使用该slug而非自动生成的
• 正文不足字数下限或faq少于3条时pass=false，发布请求不会发出
• x-sync-secret错误的请求被模拟接口拒绝，返回非200状态
• FAQPage的mainEntity数量与模型返回的faq数组长度一致

容易卡住的地方

• 模板默认发布端点是作者自己的sunoapi.top，直接导入运行会往别人的接口发请求，必须换成自己的发布地址和密钥
• AI生成的技术长文可能有事实错误，发布到真实站点前应有人工审校环节，本流程的质检只查结构不查事实
• IndexNow要求key文件真实托管在keyLocation，且收录速度由搜索引擎决定，流程只负责提交
• 每两天自动发文的频率会产生持续的模型调用费用，且批量低质内容有搜索排名风险
• Chat Completions返回非合法JSON时解析会失败，需加错误处理分支