游戏热词站：从选词到上线
# 游戏热词站：从选词到上线
目标：跟着本篇完成选词、真实素材调研、建站、上线、统计和广告，再根据数据决定补页或换词。先跑通一个站和一篇真实有用的攻略，再做模板化与批量。
正文按 生财实战手册 (opens new window) 关卡 1–8 的顺序整理。手册用 Vercel (opens new window) 部署，本篇按已确定方案改用 Cloudflare Pages (opens new window)；对应构建、DNS 和 HTTPS 操作随平台适配。“评论补充” 与正文建议分开标注；文中的 “经验帖补充” 来自 林广恩的游戏攻略站经验帖 (opens new window)，属于运营参考，不替代手册关卡、选词标准或原文提示词。原文涉及第三方规则的说法，另说明核验边界，不把经验写成平台保证。
| 关卡 | 按顺序完成 | 本关产出 |
|---|---|---|
| 1 选词与域名 | 找 3–5 个候选，查趋势、KD、细分需求与首页竞争，再选域名 | 候选判断表、一个主词与域名 |
| 2 挖需求 | 收集三路真实查询，合并同义词、分类 | 关键词.md、keywords.json，10–20 个内页 |
| 3 调研素材 | 查首页信息、语言、图标；逐页收攻略、字幕与官方资料 | 首页资料、图标、关键词素材.md |
| 4 搭网站 | 挑参考站，复刻三类页面，填真实内容，本地检查后推送私有仓库 | 可运行的网站与源码仓库 |
| 5 部署与数据 | 接 GA、部署、绑定域名，再验证 GSC、sitemap 与统计 | 正式网址、搜索与统计接入结果 |
| 6 运营与广告 | 看搜索词补页，接广告，用数据决定继续或换词 | 复盘表、广告展示与收入数据 |
| 7 模板化 | 第一个站跑通后分离框架、配置和内容 | 换游戏只改配置与内容的模板 |
| 8 批量内页 | 固定一篇样板与提示词，同类少量一批生成、复核 | 真实、有差异的攻略内页 |
先分清这些工具与文件
SEO（Search Engine Optimization，搜索引擎优化）帮助搜索引擎发现、理解页面。KD（Keyword Difficulty，关键词难度）估计一个搜索词的竞争难度；DR（Domain Rating，域名评级）是第三方对网站外链强度的估计，二者都不是 Google 给出的排名分数。
GSC (opens new window)（Google Search Console，搜索控制台）看收录、搜索词、曝光和点击；GA4 (opens new window)（Google Analytics 4，网站分析）看访问来源与页面行为。GitHub (opens new window) 存代码，Cloudflare Pages (opens new window) 构建和托管网站，DNS（Domain Name System，域名系统）把域名连到网站。
关键词.md 存原始需求，keywords.json 存分类，关键词素材.md 存研究材料；它们不是已经搭好的网站。MDX (opens new window) 是框架读取的文章内容，网页还需要组件、路由和构建。
每个游戏先建一个独立项目目录，研究文件和网站源码都放在该游戏目录；后面另建独立私有仓库与部署项目。下文提示词里的 {GAME} / {TOPIC} 换成游戏英文名，[URL] 换成实际打开过的地址；示例游戏和数值不能当作本游戏事实。
# 1．找到值得做的游戏词，再买域名
# 找出 3–5 个候选
- 从 Steam (opens new window) 新品榜、热销榜，以及 SteamDB (opens new window) / IGDB (opens new window) 找新上线、玩家人数持续上升的游戏。记录英文名、官方商店地址、App ID 和发行日期，排除同名旧游戏。
- 另一条线索是在 YouTube (opens new window) 搜
gameplay trailer，关注预售或实机视频，再核对对应游戏。 - 先留 3–5 个候选，再验证。社媒热闹、在线人数和评测数都不能直接当作 Google 搜索需求。
# 用 Trends、Similarweb 和 Google 判断能不能做
- 打开 Google Trends (opens new window)，输入完整游戏名，添加
GPTs对比；选Worldwide / Past month / Web Search / Search term。看全球近 30 天，再补看近 7 天。手册优先选择一周内陡升的新词：持续往上有机会，平或跌建议换，突然暴涨又回落的山形曲线要警惕。评论建议补看短时段与旧版可用的预测；界面没有预测就不自行补画。 - 手册用曲线与
GPTs的相对高度判断量级：约为其 1/3，表示有量但不大；接近时热度不错；远超时重点关注。选词综合条件是趋势上涨、热度接近或超过参考词、KD 低、首页竞争小。 正文与评论对GPTs日搜索量的举例不一致，不能把曲线比例写成游戏的精确日搜索量。 - 打开 Similarweb (opens new window)，进入
Keyword research → Keyword explorer → Overview，搜同一个完整游戏名，地区用Worldwide，设备用All traffic，核对统计月份及可用的Last 28 days。记录Volume、Organic difficulty（KD），并查看游戏相关的细分关键词数量。手册推荐新手 KD 为 0–30，>40 尽量不做；30–40 不是自动通过区间。- / N/A表示无数据，<50是区间，不能改写成 0 或精确值；新游戏要检查数据是否早于发行日期。 - 到 Google (opens new window) 搜游戏名及
游戏名 wiki，实际打开首页主要自然结果。Fandom、官方 Wiki、成熟攻略站如果已充分覆盖，主词较难切入；大媒体的普通内页若内容浅、过时、没回答细分问题，可能有机会。用 SiteData (opens new window) / AITDK (opens new window) 辅助看 DR、站龄和流量，不把插件估计当成后台实数。
填完再选一个主词，不用 “感觉会火” 代替判断：
| 候选游戏 | Trends 趋势与相对热度 | KD / 数据时段 | 细分需求数量 | 首页竞争与可补缺口 | 做 / 不做 |
|---|---|---|---|---|---|
| 候选 1–5 | 涨 / 平 / 跌 / 山形；相对 GPTs 的量级 | 真实值或无数据 | 有效长尾数量 | 主要结果、URL、具体缺口 | 写明依据 |
评论补充：热度回落后仍接近 GPTs，也不能直接判可做；可再看 24 小时、4 小时的热度是否仍在，是否有长尾流量、竞争是否不足。数据读不到就先补查；纯练手可以跳过购买域名，但不能把练习词说成已通过商业选词验证。
# 域名怎么选、怎么买
- 正文首选：
.wiki；被注册后考虑.com、.org、.net、.online、.site等。原文没有给这五个备选规定固定排序。 - 评论补充：另有建议优先
.com，其次.org/.net，也提到.ai、.io、.app、.pro。这些是备选，不代表更便宜或必须购买。 - 正文建议避开：
.cc、.xyz。保留手册的选购建议；“这些后缀必然被 Google 降权” 不能当成已验证的平台规则。
确认词值得做再买，优先使用游戏词对应的名称；不要提前囤一堆域名。名称被占用时可查含 guide / guides 的清晰名称，避免误导为官方站。一个域名可用不同语言路径承载多语言，不必每种语言另买。
- 手册用 Spaceship (opens new window) 演示，支持支付宝；按你的补充，也用 GoDaddy (opens new window) 比价。两边查询同一个完整域名，确认
Available，不是误选相似推荐或高价Premium域名。 - 在购物车核对一年含税费总价、续费价、优惠是否要求多年购买，移除不需要的主机、邮箱和建站附加项。便宜优先比较实际结算价，不能只比广告上的后缀起价。
- 由本人确认拼写、年限、条款并付款；完成注册商要求的邮箱验证。若不想自动续费，在域名管理中关闭
Auto-renew，记下到期日。 - 域名可先绑定 Cloudflare (opens new window) DNS：
Add / Connect a domain→ 填域名 → 选免费方案 → 核对 DNS → 复制两条 Nameservers；回注册商的Nameservers & DNS改成这两条，再回 Cloudflare 检查至Active。手册演示删除空白新域名的默认 A / CNAME；已有邮件、验证或其他业务记录不能一并清空。
完成标志：有候选判断表，选定一个有理由继续的主词；域名归属、费用和到期日清楚。你的发布约定：每个游戏站独立购买正式域名，付款前比较 Spaceship / GoDaddy 的实际结算与续费价；正式域名未确定时只做本地预览，不以 pages.dev 对外试运营，也不拿它注册 GSC / GA / Adsterra。Pages 分配的平台地址属于托管信息，正式域名才是 canonical、sitemap、统计与广告的目标。这是你的操作选择，不是手册对所有人的统一要求。
# 2．挖真实需求，规划 10–20 个内页
把以下三路内容都收进当前游戏目录的 关键词.md，保留查询原文与来源：
- Google (opens new window) 输入游戏名，先不回车，复制自动补全；提交搜索后也可点回搜索框查看下拉建议。
- Google Trends (opens new window) 打开同一游戏的
Related queries，收集相关查询并翻页；分清查询与主题，查看可用的Top / Rising。 - Similarweb (opens new window) 进入
Keyword research → Keyword generator，输入游戏名，核对地区和日期，复制结果关键词列。手册演示复制第一页；实际存在更多相关结果时继续收集，先排除同名游戏和无关主题。不同界面的Phrase Match / Related Keywords / Questions Queries是找结果的入口，不是手册规定必须各凑一份数据。
手册提到 Similarweb 数据约滞后 3 天；实际以页面的数据截至日期为准。不要为了凑数自行组合 “游戏名 + 攻略词”。有效意图不足就继续查需求。
把 关键词.md 和下方提示词交给 Codex (opens new window) / ChatGPT (opens new window) 分类，输出 keywords.json。首版：首页 + 10–20 个攻略型长尾问题页，含 Guide。 同义词、单复数和同意图合并；Codes 最多一个合并页，没有真实兑换码不硬做。
经验帖补充：每页对应一个玩家任务。同一问题的单复数、拼写和近义词合并；先在已有页面补直接答案与章节，确有独立任务和足够资料时再拆页。例如具体鱼种的查询先补到钓鱼攻略，不为每种拼写新建页面。规划时写清 “目标查询 → 玩家要完成什么 → 现有答案缺什么 → 本页提供什么 → 来源”，沿用现有关键词与素材记录，不另建一套表。看搜索结果实际需要的是步骤、图片、视频还是工具；只在有真实素材时采用对应形式，不能用通用文字替代玩家要找的布局图。
# 关键词分类提示词（原文）
基于关键词.md，新建一个关键词分类文档：keywords.json。
对【所有关键词】分类，必须有的分类：guide，要求最终关键词总数 10-20 个。
分类禁止大空，例如 gameplay、general。
假设有 Codes 分类: 其分类下只能有一个关键词。
关键词中核心主词和非本主题词过滤掉。
同义词要合并（合并后的关键词必须是搜索量最大、大众习惯搜索那个）。
并给出同义词合并后，还有多少，即还能做多少"一个词一个内页"的精品内容。
分类 1：xxx
关键词 1
关键词 2
…
严禁缺少任何一个关键词（游戏词本身和非该游戏主题词除外）。
关键词优化：
1、不允许存在非英文（需翻译成英文）
2、可修改某单词拼写错误，但禁止扩写
3、主题词统一，**关键词命名统一成 游戏主题名 xxx**。
除此之外，禁止做其他修改。
注意事项：
**Mutually Exclusive（相互独立）**：
1、不同分类下，不要存在包含关系，例如 Guides 和 Beginner Guides
2、一个分类下,不能出现同义关键词（例如只是单复数区别）
Collectively Exhaustive（完全穷尽）：一个分类下所有有效关键词要覆盖这个分类可能的所有需求，且具备一定逻辑关系（顺序或包含）
还有一些是 YouTube 视频标题，也请分析高流量视频，提取关键词。
手动写,禁止使用脚本处理。
每个分类下,重要(流量大的)关键词排在前面。
输出格式必须是（禁止增加无用信息）：
{
"categories": [
{"category": "100 Waves Later", "keywords": ["100 waves later tier list", "100 wave later code"]},
{"category": "Anime Card Collection", "keywords": ["anime card collection codes", "anime card collection guide"]}
]
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
原文 JSON 中跨游戏的内容只示范格式，实际全部换成当前游戏。分类由模型理解语义后整理，不用脚本机械造词；脚本可做格式检查。分类后自己检查：有没有漏掉有效原词、两页回答同一问题、分类互相包含，或没有需求支撑的页面。
完成标志：关键词.md 有三路原始查询，keywords.json 有分类后的英文关键词；能说清每个内页回答什么问题，同义词已合并。
# 3．调研首页信息、语言、图标和内页素材
# 首页画像与语言先调研
把游戏名交给 ChatGPT (opens new window) 网页端联网调研，使用下面的原提示词。逐个打开返回的官方商店、官网、社群和视频链接，剔除 404、竞品链接和错误游戏资料。
首页信息最终填进第 4 关复刻好的页面：Hero 首屏、Start Here 四卡、游戏介绍、底部 CTA、页脚、SEO 信息和主题色。四组首屏数据应是玩家关心的真实游戏信息，不能拿 “本站有几篇攻略” 代替。
多语言按手册要求：根据地区热度和流量排优先级，搜索本地化游戏名，最多 4 门，必须含英语，不含中文；新手先把英语做好。 调研结果要写依据，不能先定英俄再找理由。不要求每门语言都有同一指标的精确搜索量。 可以结合地区热度、流量分布和本地化搜索结果说明优先级；暂时判断不清时，先把英语做好，再补其他语言。国家分布不等于语言分布，平台支持某语言也不等于该语言需求最多；没有可靠数据时说明判断限制，不编百分比。
# 首页画像与语言提示词（原文）
游戏词：{TOPIC}
请按以下结构提供完整的网站开发信息：
【特别注意：1.注意不要附上我的竞对的网站（官网除外）2.禁止输出任何一个 404/打不开的链接】
## 1、主题基础信息
（1）给出官方网站（禁止输出任何一个 404/打不开的链接）和常用社群（如 Discord、reddit 等）和官方 trailer youtube 链接（如果没有随便选一个爆款 youtube 视频）。
（2）搜索给出这 4 组用户关心的数据和 SEO 元数据，严格按照以下格式返回：（注意：4 组用户关心的数据一定要最贴近玩家直觉，具体内容不限制，不要死板只查找 Active Codes、Daily Updates、Total Visits、Units Available 这 4 项，Players Online、 Peak CCU"、User Reviews、Release Date·····都可以。注意：1.某项数据为 0 就不要写，比如：禁止写 Active Codes：0 2.value 的值后面不要写任何括号）
{
"home": {
"meta": {"title": "游戏名 Wiki — 核心关键词 1, 核心关键词 2", "description": "SEO description（140-160 字符）"},
"hero": {
"eyebrow": "Fan-Made Community Wiki（或类似标语）", "title": "游戏名",
"description": "游戏核心玩法介绍，2-3 句，吸引玩家点击",
"stats": ["发布日期（如 Launched Jun 2025）", "最近更新日期", "核心数据 1（如 3 Races）", "核心数据 2（如 Lv100 Cap）", "核心数据 3（如 130+ Skills）"],
"primaryCta": "Start Beginner Guide（或类似首要行动按钮）", "secondaryCta": "Compare Races（或类似次要行动）", "tertiaryCta": "Check Active Codes（或类似第三行动）", "videoLabel": "Official media"
},
"start": {"eyebrow": "Start Here", "title": "Your 游戏名 Journey", "cards": [
{"number": "1", "title": "Beginner Guide（固定：新手入门）", "description": "新手入门的完整攻略介绍。"},
{"number": "2", "title": "升级/刷资源/职业/Boss 等（根据游戏特点选择）", "description": "该游戏前 2 小时玩家最常搜的内容。"},
{"number": "3", "title": "与卡片 2 不同类型", "description": "该游戏核心玩法的教学。"},
{"number": "4", "title": "与卡片 2/3 不同类型", "description": "游戏特色机制或进阶内容。"}
]},
"aboutGame": {
"title": "What is 游戏名?",
"paragraphs": ["游戏类型和核心玩法的 2-3 句介绍（如：游戏名 是一个 Roblox 上受 XX 启发的格斗 RPG...）", "进一步说明游戏特色的 2-3 句（如：无论是解锁第一个 XX、进化系统、还是...）"],
"stats": [{"label": "Developer", "value": "开发工作室名"}, {"label": "Platform", "value": "Roblox / Steam / PS5 等"}, {"label": "Genre", "value": "Fighting RPG 等"}, {"label": "Visits", "value": "12.6M+"}, {"label": "Favorites", "value": "243K+"}, {"label": "核心内容数", "value": "130+ Skills 等"}, {"label": "等级上限", "value": "100 等"}],
"cta": "Explore All Guides"
},
"finalCta": {"title": "Ready to Master 游戏名?", "description": "号召性文案（如：From your first steps in XX to endgame boss fights, our community wiki has you covered...）", "primary": "Read the Beginner Guide", "secondary": "Play on Roblox（或对应平台）"}
},
"footer": {
"aboutTitle": "游戏名 Wiki", "about": "Wiki 的简要介绍（如：游戏名 Wiki 是一个独立的粉丝攻略站，覆盖...）", "description": "一句话描述游戏（如：Free XX-inspired fighting RPG on Roblox. 3 races, 130+ skills, Lv100 cap.）",
"playGame": "Play 游戏名（或对应平台按钮文字）", "officialDiscord": "Official Discord", "officialYoutube": "Official YouTube", "communityTool": "社区工具名称和链接（如有，如 Skill Planner）", "privacyPolicy": "Privacy Policy", "termsOfService": "Terms of Service"
},
"metadata": {"title": "游戏名 Wiki — 核心关键词 1, 核心关键词 2（≤60 字符）", "description": "简洁描述网站提供的内容和价值（140-160 字符）", "keywords": "游戏名, 平台, 核心关键词列表（≤100 字符）"}
}
完成后自查：
- home.meta.title 字符数是否 ≤ 60？
- metadata.title 字符数是否 ≤ 60？
- metadata.description 字符数是否在 140-160 之间？
- metadata.keywords 字符数是否 ≤ 100？
- home.hero.stats 数组是否为纯字符串（不含对象）？
- home.start.cards 是否有 4 个对象？
- home.aboutGame.stats 是否有 label+value 对？
- footer.about 是否有 2-3 句介绍？
- sidebarCodes 是否有 2 条兑换码？（如果没有兑换码则填"暂无"）
## 3、网站主题色应该什么颜色？默认颜色应该选择深色还是亮色
按照这种格式给我：
/* 导航页主题色 - 亮色主题 */
--nav-theme: 152 60% 48%; /* green-500 (原来的 #43b176) */
--nav-theme-light: 152 60% 58%; /* 更浅的绿色 */
/* 导航页主题色 - 暗色主题 */
--nav-theme: 152 60% 48%; /* green-500 */
--nav-theme-light: 152 60% 58%; /* 更浅的绿色 */
## 4、多语言
根据热度，分析应该支持哪几门语言（并搜索对应本地化主题名），按流量排优先级
先说结论，按优先级排列, 最多 4 门语言（必须有一个是英语，中文除外）
请以清晰的 Markdown 格式返回所有信息。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
提示词的示例数值、Roblox 机制和兑换码不能直接使用；没有兑换码就写 “暂无”，不要为了通过示例自查凑两条。无官方视频时可用相关热门视频，但必须标成实际来源，不能冒充官方。
# 生成并安装网站图标
- 用下面的提示词，让 ChatGPT (opens new window) 给出本游戏 favicon 的英文绘画描述，再生成
512 × 512 PNG；也可用其他图片生成模型。 - 打开 favicon.io 图片转换器 (opens new window)，上传 PNG，下载多尺寸图标压缩包。
- 将转换包交给 Codex (opens new window)，放入游戏项目并正确引用
favicon.ico、各尺寸 PNG、Apple 图标和包内 manifest。之后在浏览器标签和手机上检查，不以下载完成代替安装完成。
# 图标提示词（原文）
游戏词：{TOPIC}
直接适合该网站的 favicon logo 英文绘画提示词，目标格式为：512*512 png
2
# 每个内页都收三路素材
拿第 2 关的 keywords.json，对每个内页词分别操作；按关键词分组写进 关键词素材.md，不能把几个无关问题的资料混成一团。
- Google (opens new window) 搜这个内页关键词，打开该主题排名前二的攻略 / Wiki，将与问题有关的板块、来源网址放入材料。比如
farever classes，就收职业相关内容，不把整站无关内容全贴进来。 - YouTube (opens new window) 搜同一个词，选两个较新、观看量较大的相关视频。手册使用 YouTube TranscriptGenerator (opens new window)：打开视频后用
Pro Transcription提取，选择简体中文并Export复制文本；保留视频 URL。也可用视频本身的Show transcript入口取得字幕，插件收费和可用性以实际界面为准。保留原始游戏术语与能支持结论的时间点，视频标题不能冒充字幕。 - 打开官网或 Steam (opens new window) 官方商店页，查这个内页主题的说明。有重要信息就补进去；仅有一句无用简介可以跳过。
- 同一个信息至少在两个不同来源交叉验证。 再问一遍 AI、重复 URL、同一篇转载不算第二来源；遇到冲突先查游戏版本。关键事实找不到可靠来源的页先补查或暂缓，不编造键位、数值、技能和打法。
素材格式沿用手册的三块，按每个关键词重复：
关键词：当前内页的真实目标词
Google 素材：来源地址 + 与问题有关的内容
YouTube 素材：视频地址 + 字幕 / 关键时间点
游戏官方资料：来源地址 + 相关说明；无有用内容时说明跳过
交叉核对：哪些结论得到不同来源支持，哪些冲突或尚需确认
2
3
4
5
完成标志：首页信息和语言优先级能追溯依据，图标准备好；每个计划内页都有独立材料，足以解释条件、步骤、结果和限制。AI 审阅不等于自己玩过。
经验帖补充：素材中的关键事实保留来源 URL、适用版本、核查日期与确定性，再让 AI 组织内容；官方 “正在评估” 不能翻译成 “即将推出”。先用现有来源 / 事实记录独立复核，优先检查平台支持、获取条件、数值与 Mod 兼容性。内容与翻译修改源文件并进入 Git，不直接修生成后的 HTML；干净克隆应能重建所有语言。
# 4．参考竞品搭网站，填真实内容并推送仓库
# 先找参考站，不从空白重设计
- 手册建议问 ChatGPT (opens new window)“最近一个月 Steam、Roblox 上新了什么游戏”，再核对游戏是否真实、是否近期发行；到 Google (opens new window) 搜
游戏词 wiki，看实际排名和页面。 - 收集 5–10 个参考站，优先选排名靠前、DR 为 0 或接近 0 的新站，用 SiteData (opens new window) 辅助查看。DR 低是筛选线索，不能单独证明没发外链或只靠结构排名。
- 比较导航、Hero、Tab、大标题、内容组织，以及首页模块是否承接真实高需求，选一个值得复刻的站。至少打开首页、列表 / 导航页、文章详情页，准备三个真实 URL。
手册列出的四个参考站：VV Ultimatum (opens new window)、Farever (opens new window)、Gamble With Your Friends (opens new window)、Miniwars (opens new window)。这是候选列表，不是按美观或访问量排序；选哪个应按实际页面与需求判断。
# 用 Codex 复刻三类页面
主线是把三个 URL 和原提示词交给 Codex (opens new window)，技术栈用 Next.js (opens new window) + 多语言 + MDX (opens new window)。参考结构、导航、配色和内容组织；所有游戏文案、图片、数据与官方链接换成自己调研的内容。
复刻这个游戏站：[对标站首页 URL]，至少实现三个页面——
首页：[URL]、列表 / 导航页：[URL，如 /classes]、文章详情页：[URL，如 /classes/xxx]。
UI 布局完全参照目标站复刻，不要自行设计。
技术栈用 Next.js + 多语言 + MDX 写内容。
2
3
4
手册还有可选方式：same.new (opens new window) 接收 “对标首页 URL + 同一份复刻要求” 生成前端项目，再交给 Codex 修正不一致的地方；不要只给 URL。手册演示 25 美元套餐（支持支付宝、示例可做 2–3 个站），模型选 GPT 5.5；当前费用、用量和模型选项以实际界面为准。superpowers 是可选流程插件，首次可以直接用上面的提示词跑通，不必为它增加前置步骤。
# 先填首页，再逐页填攻略
把第 3 关的首页调研结果与下方提示词一起交给 Codex (opens new window)：
把第 3 关用 ChatGPT 调研出的首页信息，填进复刻好的网站：
1. 全站旧游戏名 → 替换成我的游戏名（首页、页脚、侧边栏、法律页都要换，无残留）
2. 首页各模块（Hero / 新手引导 / 游戏介绍 / 兑换码 / 底部号召）用调研的真实文案
3. 官方链接（官网 / Discord / YouTube）、SEO title / description / keywords、主题色（HSL）、多语言，按调研结果配置
4. 侧边栏兑换码用调研的真实码；没有就写"暂无"，绝不编造
所有内容只写第 4 关调研的真实信息，不确定的标"待确认"，不要编造数值和兑换码。
2
3
4
5
6
然后把 keywords.json、某个内页对应的真实材料和下方提示词一起交给 Codex，逐页填内容。原文有章节编号笔误，输入应是已经完成的素材，不是让模型凭空补资料。
针对内页关键词，把收集到的信息过滤无效信息，整合收集的多源数据，然后填进各个内页。
一个关键词填一个内页，输入如下：
- 游戏关键词：keywords.json
- 为这个关键词收集到的真实信息（第 4 关调研的素材，贴在这里）：关键词素材.md
要求：
1. 页面 title 含这个关键词，40-60 字符；meta description 含关键词、140-160 字符
2. 开头直接回答玩家的搜索问题，不绕弯
3. 全文 1200 字左右；分 H2 小节，每段 3-4 句，适合扫读；
4. 只写上面收集到的真实信息，不确定的标"待确认"
5. 不要编造数值、角色名、兑换码；
2
3
4
5
6
7
8
9
10
先把英语页做好，再按第 3 关的语言优先级翻译；保持游戏术语、条件、数值、来源与对应页面一致。首版约 1200 字是写作深度参考，不靠重复内容凑字数。所有答案正常显示，不折叠。
# 本地检查，再推送私有 GitHub 仓库
- 让 Codex (opens new window) 在本游戏目录安装项目依赖并运行
npm run dev，给出实际预览网址；再运行npm run build。没有锁文件时正常安装生成锁文件，已有匹配锁文件时用npm ci。按项目所需的 Node.js 版本运行，不改其他项目的全局默认版本。 - 浏览器逐一打开首页、列表页、攻略页、About / Contact / Privacy 等实际入口，直接刷新内页；检查正文、链接、手机布局、图标和语言切换。检查 title / description、H1 / H2、canonical、hreflang、robots、sitemap，无旧游戏、旧域名和占位内容。
- 打开 GitHub (opens new window) →
New repository，创建本游戏独立Private仓库，不勾自动生成 README；复制仓库地址。已有仓库就复用。 - 将下面的提交提示交给 Codex。刷新仓库能看到本游戏源码，才算推送完成。
提交提示词依手册流程整理；提交说明按本仓库约定使用中文：
把当前游戏项目推送到我已创建的私有 GitHub 仓库：[实际仓库 URL]。
先检查当前目录、git status、远程地址与分支，保留我已有的修改。
新项目按 git init → 提交本站源码 → 设置 origin → git push -u origin main 执行。
依赖、构建产物、账号凭据和私有研究资料不提交；提交说明用中文。
已有 Git 仓库先核对再复用，不强推；远程空仓库不存在时先告诉我去 New repository 创建。
2
3
4
5
完成标志：本地网站能访问、内容真实、链接可点、生产构建通过，私有仓库能看到刚推送的代码。手册强调先上线再打磨，不能为了先做一套复杂自动化长期卡住首站。
# 5．部署上线，并接入 GSC 与 GA
执行顺序：取得 GA 测量 ID 并集成 → 部署代码 → 配好正式域名与 HTTPS → 验证 GSC、sitemap 和 GA。 这是手册正文与评论合并后的实际顺序；不能在网站还不能公网访问时，把索引测试失败归因于内容。
# GA 怎么操作
- 打开 Google Analytics (opens new window)。新账号点
Start measuring；已有账号从Admin → Create → Property为本站建媒体资源。账号名、媒体资源名使用自己能识别的名称，地区、时区按自身实际情况选择。 - 手册的创建示例：独立开发者公司人数选第一档；业务目标选
Other business objectives。它是作者建议，不是影响流量的开关；当前界面若已调整，按实际选项理解，不编造手册指定了某两个新选项。 - 选择
Web数据流，填写正式网站 URL 与流名称，取得G-开头的Measurement ID。首次条款由本人确认。 - 把实际 ID / 安装代码交给 Codex (opens new window)，放进全站布局，首页与内页都要统计。手册建议用环境变量
NEXT_PUBLIC_GA_ID；本地放.env.local，部署时也在平台生产环境填写同一个真实 ID。只设置变量不会自动生成统计组件，改变量后也要重新构建部署。 - 站点上线后，回数据流用
Test installation/ 安装检测检查是否找到代码；再看Reports → Realtime overview，实际访问首页和一篇攻略，确认有访问 /page_view。没有测试事件，先核对 ID、部署版本、拦截与统计同意状态，不重复安装两套代码。
手册直接讲全站接入 GA，没有规定全球访客都必须先同意再加载。当前按你选择的地区方案接入：GA 使用独立的 176 个国家/地区默认名单，加拿大另对已识别且不含魁北克的省区默认加载；日本可默认统计但广告先同意，香港、台湾、墨西哥等也在默认范围。欧洲经济区、英国、瑞士和本轮其他例外、未知地区及地区接口失败时先同意再加载。已有拒绝、GPC / DNT 优先；默认加载不是访客已明确同意。GA 的 Google signals 与广告个性化保持关闭，统计与广告分别选择。该方案属于本站适配，不是手册要求或全球合规认证；依据见 Google 同意政策 (opens new window) 与 加拿大隐私专员的退出机制条件 (opens new window)。
验收时分别用全新访问和已拒绝访问：默认地区不用点允许也应看到 GA 请求及实时事件；需同意地区先无请求，允许后才出现。拒绝后刷新、换语言不能恢复采集；接口失败不能误判默认允许。GA 只覆盖实际允许采集的访问，不等于全部访客。 GSC 搜索数据独立于 GA，可继续用于查询、排名、国家与页面分析；GSC 点击、GA 会话和广告曝光不是同一种指标，不能要求数量相等。
# Cloudflare Pages 怎么部署
手册原步骤是将私有 GitHub 仓库导入 Vercel。本篇只将托管平台适配为 Cloudflare Pages (opens new window)：
- 进入
Workers & Pages，找到 Pages 创建入口，选择连接 Git，授权本站仓库，选择main。不要误建为需要另一套运行方式的 Workers 项目。 - 对本路线的 Next.js 静态导出项目：构建命令
npm run build，输出目录out，根目录是本游戏package.json所在目录；设置项目所需NODE_VERSION=22与真实NEXT_PUBLIC_GA_ID。项目需要有output: 'export'，不是只填out就能导出。 - 部署后查看构建日志，读取实际分配的
pages.dev地址，逐页打开并刷新内页。以后推送main，平台自动重新构建；核对部署对应的 Git 提交，不能把推送成功当公网已更新。
# 正式域名、HTTPS 与跳转
手册采用 根域 → www 的 301 跳转。沿用这条路线时，正式标准地址用 https://www.你的域名；根域和 www 都先能正常访问，再设置跳转。
- 第 1 关已将 Nameservers 改到 Cloudflare (opens new window) 的，确认 zone 显示
Active。尚未绑定时按第 1 关完成，保留仍需使用的 DNS 记录。 - 在本站 Pages 项目打开
Custom domains → Set up a domain，分别关联www.你的域名和根域名，按控制台提示添加 / 核对 DNS，等证书与自定义域名显示可用。Pages 的记录用控制台实际分配值，不照抄 Vercel 的 A / CNAME；根域须位于该 Pages 账户下的 Cloudflare zone。 - 在域名
SSL/TLS → Edge Certificates开启Always Use HTTPS。手册 Vercel 示例中的Flexible不作为本 Pages 路线的通用设置；按 Pages 自定义域名的有效 HTTPS 配置验收，不为照抄旧截图关闭加密。 - 在
Rules → Redirect Rules建立仅匹配根域的 301，目标改为www，保留原路径和查询参数。例如https://你的域名/en/?test=1应到https://www.你的域名/en/?test=1，不能循环或所有内页都跳首页。来源 DNS 需满足该规则的代理与证书条件。 - 将最终标准网址交给 Codex (opens new window)，更新全站配置、canonical、hreflang、robots 和 sitemap，再构建发布。已有站若选了另一种标准域，先核对历史配置，不直接照着示例把线上域名来回迁移。
纯练手未买域名时，先用实际 pages.dev 地址练习，正式发布前再换成买好的标准域。域名、DNS 与 HTTPS 原理可查 Web 托管、域名与 HTTPS。
# GSC 怎么操作
- 打开 Google Search Console (opens new window)，左上角
Search property → Add property。你的每个正式域名默认只建一个Domain资源，只填域名，不带协议和路径；不再同时新建URL prefix。两种资源可以共存，但不会增加收录或流量，数据也不能相加。仅在明确需要按地址前缀分开看数据时额外添加。 - 域名已在 Cloudflare 时，可按界面提示用域名提供商验证；也可复制 GSC 给出的真实 TXT，在对应 DNS 中添加后回 GSC 验证。选择
URL prefix时填完整标准 HTTPS 地址，按界面选 HTML 标签等验证方式；TXT 与网页标签不是同一项配置。 - 网站公网能访问后，在顶部
URL inspection输入实际首页，点TEST LIVE URL，确认Crawl allowed: Yes / Page fetch: Successful，需要时点REQUEST INDEXING；核心攻略页同样检查。Indexing requested只是请求已受理，URL is on Google / Page is indexed才是该页面已收录。 - 先直接打开正式网址的
/sitemap.xml，确认是 XML，列出本站真实 URL、无旧域名，再到Sitemaps提交。网址前缀资源的输入框已显示域名时只填sitemap.xml；Domain 资源按实际界面填完整网址。 - sitemap 的成功标志是
Status: Success，并识别出与文件相符的页面地址；Sitemap submitted successfully只是提交受理。 地图不需要像攻略页一样进入搜索结果。 Couldn't fetch时点进该行看错误，检查实际 URL、HTTP 状态、robots、防护规则和 Google 在线抓取结果；文件缺失就让 Codex 生成并重新部署，错误修复后再提交。只有当前在线测试通过而报告仍失败时，保留两项真实结果，不能直接断定只是延迟，也不盲目反复提交或迁移平台。- 到
Indexing → Pages看内页实际收录与排除原因；不是只有首页收录就完成全部内页验收。
完成标志：正式网址能正常访问，跳转和 SEO 地址一致；GSC 验证通过，sitemap 已成功读取，首页和核心页索引状态已实际检查；GA 后台收到真实测试事件。部署、请求索引、已收录和收到统计事件分别判断。
# 6．看数据、补页面、加广告，再决定下一步
# 在哪里看数据，看到后做什么
打开 GSC (opens new window) 的 Performance（有搜索类型子菜单时选 Search results），统一日期与搜索类型；启用 Total clicks / Total impressions / Average CTR / Average position，在下方切 Queries / Pages。点击具体查询或页面，可进一步看它对应的页面或查询。
| 手册要求看的信号 | 读数含义与操作 |
|---|---|
| Impressions | 搜索曝光。结合查询和排名判断变化，不能单凭曝光上涨就认定市场总需求上涨。 |
| Clicks | 从搜索结果进站的点击；看哪些词、哪些页带来访问。 |
| Average position | 手册强调前十的重要性；排名靠后时先核对竞争、意图、内容与站内结构。 |
| Average CTR | 点击 ÷ 曝光，受排名与搜索意图影响；有曝光少点击时检查查询匹配和标题摘要。 |
| Queries | 最重要的需求线索。新表达但同意图补原页，独立新问题再建页。 |
按手册做具体动作：有流量的站先找缺什么页；表现好的页补关联内容；未收录页检查、修改、再提交。有真实 how to get character X 查询就补获取攻略，有 best build for Y 就补配装，codes 年份 属于原意图就更新已有 Codes 页，不能拿例子凭空造需求。
GA (opens new window) 中看 Reports → Realtime overview 验证实时访问；查来源用 Traffic acquisition，查热门页、浏览与停留用 Pages and screens。左侧没有时可用顶部搜索框搜报表英文名。历史报告有处理延迟，自己的测试访问也可能计入，不能当作自然流量。
# 上线后怎样定位问题（经验帖补充）
以下操作吸收自 林广恩的游戏攻略站经验帖 (opens new window)；作者的广告收入样本仍小，不作为收益保证，也不新增硬性选词门槛。
- 先统一日期。打开 GSC (opens new window) 的
Performance → Search results，优先比较完整的近 7 天与前 7 天；数据很少时拉长观察，最新 24 小时只作初步线索。打开 GA (opens new window) 的Admin → Data streams → 本站 Web stream → Configure tag settings → Show all → Define internal traffic定义自己的固定出口 IP，再在Admin → Data filters核对过滤器状态；只定义 IP 不等于已排除。先用Testing验证，再决定启用；出口常变化时注明测试访问可能混入，不猜一个固定 IP。 - 在 GSC 的
Indexing → Pages找排除原因，对具体 URL 用URL inspection查看抓取、索引与 Google 选定的 canonical。抓取失败先查状态码、内链、robots 和 sitemap；已抓取未索引再检查内容、重复与 canonical。Alternate page with proper canonical tag可以是正常重复页状态，不要求所有这种记录都消失。 - 已收录后，在
Performance → Search results → Queries点击真实查询，切Pages确认落地页，再看Countries / Devices和排名。有展示少点击：排名已靠前，检查标题摘要、语言页选择与搜索结果形式；排名靠后，优先检查答案、竞争和内链。只用总 CTR 不能决定改标题。 - 将查询翻译成任务。例如
farm layout前排主要是布局图和规划工具，而本站只有文字，先补有依据的图片或工具入口。英语查询落到其他语言页，检查 query → page、canonical、hreflang 和最近抓取时间；这只是排查方向，不能仅凭国家或语言分布认定配置错误。 - 到 GA (opens new window) 的
Traffic acquisition筛选Session default channel group = Organic Search，再用Pages and screens看自然访问的页面行为。Direct是来源无法归类，不等于自然搜索；滚动、停留和跳出率不能单独证明玩家完成了任务。确需验证导航时再配置入口 / 内链点击事件，用Admin → DebugView验证，避免一次增加大量无用途埋点。 - 每轮从 “修正错误 / 补强旧页 / 合并重复页 / 新建独立页 / 继续观察” 选少量有证据的动作。修改前记下 URL、问题、预期结果、观察期和回退提交；尽量分开内容、导航、语言和广告实验，以便解释变化。正式页已更新后，检查 GSC 的最近抓取日期，再比较完整窗口；没重抓时不要连续改标题或重复请求索引。
- 游戏更新时优先核对版本、数值、获取条件与 Mod 兼容性；每周用上述报告选 2–3 个最值得处理的问题。作者的排名分档、暂停天数和展示门槛属于个人经验，不自动变成本站的通过 / 放弃条件。
# 新站先接 Adsterra
手册路线是早期可先用 Adsterra (opens new window)，流量起来后再评估 AdSense (opens new window)。推荐 Native Banner 或 Banner，先不选 Popunder。
注册 Adsterra
Publisher账号，完成邮箱验证；已有账户直接登录。密码与条款由本人处理。进入 Adsterra 发布商后台 (opens new window) →
Websites → Add website，填本站正式域名、实际网站分类并选广告形式，提交审核。正式域名未确定时先决定是否用临时域名申请；已选择等正式域名时不要擅自提交临时地址。等后台真正批准，再打开本站对应广告单元的
Get code。手册称广告单元标识为 Key，用来组成脚本加载地址；操作时直接复制后台给出的完整嵌入代码，不让模型猜 Key 或拼接示例 URL。审核速度以后台为准，手册的 1–3 分钟是经验。把真实代码交给 Codex (opens new window)，说明广告放在哪里、各语言显示
Advertisement，要求按模板配置接入。Native Banner 的脚本和容器要配套；Banner 使用后台实际给出的另一种代码，不能直接套 Native 的容器配置。重新构建发布，普通访客环境打开首页、攻略页并刷新，核实真正看到广告；检查隐私说明及所需同意。只有后台提供了
ads.txt，才按其真实记录放到根目录。当前工作流按地区处理统计与广告（本站适配，不是手册要求）：
ads.loading_policy与analytics_loading_policy使用regional。广告扩展为 175 个国家/地区默认加载，GA 为独立的 176 个；加拿大另识别非魁北克省区，日本仅默认统计。欧洲经济区、英国、瑞士和本轮其他例外、未知地区、接口失败时先同意。国家与省份只使用 Cloudflare 连接信息，不能按网页语言猜地区。GA 与广告可单独拒绝，已有拒绝与 GPC / DNT 优先，页脚Privacy & ad choices可撤回；privacy_reviewed是维护者检查标记，不是访客同意。新站复用 Pages Function 与路由 (opens new window)，换游戏只换配置、内容与本站独立广告代码。隐私页与各语言提示必须同步。这份广覆盖名单是运营配置，尚未逐国核验全部法律依据，不是合规认证；不能把默认加载写成用户同意，也不能把 “欧洲以外” 说成全部不需要同意。依据见 Adsterra 条款 4.9 (opens new window) 和 Google 地区设置 (opens new window)。不点击自己的广告。主动点广告后到目标页，与未点广告原站自动跳走是两种情况；若确认后者，暂停该广告位并向平台排查，修复后再测。选了 Native Banner 或后台 Approved 都不保证实际体验正常。
到后台分别看广告曝光和实际收入。脚本加载、广告展示、有收益是三项结果，不能混为一谈。
经验帖补充：在 Adsterra Statistics (opens new window) 统一日期并按本站、广告位查看 Impressions / CPM / Revenue，再结合国家与设备判断。不同位置做对比时申请独立广告位代码；不同语言共用同一位置不必为了凑数量重复申请。原始嵌入代码能展示且后台有记录后，再做位置实验，不擅自加 iframe 包装。作者的横幅在一个站表现较好，在另一个站却是 Native 较好，不能据此固定某种尺寸。小样本、自己的测试展示及单日 CPM 波动不能证明长期收益；0 次点击也可能有按展示计费收入，不诱导点击。
# 什么时候评估 AdSense
手册提到日访问 500 时可关注收益表现，后面又以日访问过千作为切换建议；这是经验，不是 AdSense 统一审核门槛或收入保证。 不足这个量也可能申请，但要有真实内容、About、Contact、Privacy 等必要页面。
后续按 AdSense (opens new window) 实际流程添加站点、接验证 / 广告代码、提交审核；被拒先看原因，补内容或修正后再申请。工具表中的其他联盟按游戏与资格另行评估，不是本次广告接入的必做步骤。
手册收款段落提到电汇与虚拟货币，但不能据此认定 AdSense 支持虚拟货币收款。实际以各平台、账号地区的官方支付页面为准，不照搬示例费率或承诺收益。
# 填复盘表，作出一个判断
统计时段：
总曝光 / 总点击 / CTR / 平均排名：
前 5 个真实搜索词：
出现了哪些没做页面的独立需求：
哪些页未收录、后台给出的原因：
下一步补哪 2–3 个页面，或更新哪几个旧页：
GA 访问来源、热门页与停留表现：
Adsterra 曝光 / 实际收入、域名与工具成本：
决定：继续补站 / 调整后观察 / 换下一个游戏词；依据：
2
3
4
5
6
7
8
9
手册的继续信号：数据在涨、有曝光点击、甚至已有广告收入，继续补页并考虑模板化。换词信号：有数据但排名不理想，做了几个星期仍每天个位数访问；先检查内容是否真正回答问题，再保留模板与经验换词。不要把 “几星期” 当成保证见效期限，也不把一直维护当成必然能赚钱。
# 7．首站跑通后，把模板拆成三层
| 层 | 按手册放什么 | 换游戏时 |
|---|---|---|
| 框架层 | 布局、组件、技术栈、路由、SEO 和多语言生成逻辑 | 基本不动 |
| 配置层 | 游戏名、主题色、官方链接、导航分类、SEO 信息、支持语言 | 集中替换 |
| 内容层 | 首页各模块文案数据、独立内页文章、翻译和游戏素材 | 每站独立替换 |
按这四步改第一个站，而不是再从头重写前端：
- 将游戏名、首页文案、官方链接等从 JSX 抽到配置 / 语言文件，例如手册提到的
en.json；组件只读数据，不写死游戏。 - 内容与导航动态读取：添加 / 删除一篇文章，列表、菜单和路由自动更新。
- 主题色集中用变量，换皮只改一处。SEO 标题、结构化数据、多语言链接和 sitemap 根据配置与内容自动生成。
- 真正换另一个游戏测试：只换配置、内容、图标与素材，不改框架代码；构建后检查没有旧名、旧链接、旧域名，并验证导航、路由和 sitemap 跟随更新。
每个游戏仍是独立项目、私有仓库与部署项目，不把多个游戏混在一份内容里。手册将自动抓取、多站管理和数据日报放在更后面的进阶阶段；先把单站跑通。
# 8．先做好单篇，再批量做同类内页
批量内页就是批量生成真实内容文件，由已有框架渲染；不是批量换关键词灌水。
- 列任务表：从真实关键词反推 “页面名 + 搜索词 + 要回答的问题”，一个意图一个页面；同义词合并。
- 固定提示词：列清同类页的必备信息、写作要求、MDX 字段与标题格式；给一篇已核验样板，不每篇临时换结构。Boss 页需要真实技能与打法，角色页需要真实属性与定位，Codes 页需要真实代码与使用说明；没有素材就补查。
- 同类几个一批交给 Codex (opens new window) / ChatGPT (opens new window)，逐页输入独立材料，不能只给词让它编内容。
- 每批自己检查事实、差异、格式和来源，再放进内容目录；本地打开新增页，检查导航、SEO、多语言链接和 sitemap，构建通过再发布。
文件落点按当前框架约定，例如 content/en/某页.mdx、content/ja/某页.mdx；以已有正确页面为字段样板，并同时填写框架需要的标题 / 描述配置。文件只是放进目录而没有被路由读取，不算页面完成。
# 批量内容提示词（依手册三步整理）
按已验证的样板和相同 MDX 格式，生成本批：[同类页面清单]。
每页输入：真实搜索词、要回答的问题、该页独立的 Google / 视频字幕 / 官方素材。
沿用第 4 关内页要求：title 含词 40–60 字符，description 含词 140–160 字符，开头直接回答，H2 分节、短段落，正文约 1200 字。
忠于游戏真实设定，数值、技能、打法和兑换码不准编造；不确定项先核查，不把待确认内容当答案发布。
一页一个独立意图，不用改名字复制另一页。逐页复核后再放入内容目录，构建并实际打开检查。
2
3
4
5
自己还判断不了单篇对不对时，先把单篇做透。手册的顺序是手动流程跑顺 → 固定样板 → 小批量复核 → 再用脚本抓取、填目录、校验格式提效；脚本不能替代需求与事实判断。
# 已有工作流怎么配合使用
上面是可独立照做的操作主线。为本机另外实现的 Codex (opens new window) 工作流只是执行工具，不是手册新增的前置关卡；程序命令、证据字段和恢复规则以其 README.md 为准，不在这里重复维护。
本机工作流：/Users/apple/Desktop/project/game-site-workflow/；每站项目：/Users/apple/Desktop/project/game-sites/游戏名/。研究文件放在该游戏目录，不放进工作流源码。
在 Codex (opens new window) 直接说一句即可，不必复制整套要求或手动运行脚本：
用 $gameflow，帮我选个游戏词并上线。
已有游戏词时说：
用 $gameflow，把 XXX 做成站并上线。
XXX 换成游戏英文名，可附 Steam / SteamDB 链接。目录、模板、独立仓库、Cloudflare Pages、语言调研及数据 / 广告接入沿用工作流默认设置；只在必要的登录、域名付款、条款或额外授权时需要你参与。没有说 “上线” 时先做到本地可预览。
站点上线后需要复盘时说：
用 $gameflow，复盘 Probably Stolen 的搜索流量和广告收益，先给最值得做的 2–3 项。
工作流读取该站当前 GSC / GA / Adsterra 的真实数据，说明日期、样本和统计覆盖限制，再给具体 URL、问题与动作。只复盘时不改线上；要求优化后，才修改、构建和发布。后台读不到就指出具体缺项，不拿旧数据当今天的数据。
# 工具入口速查
账号注册与购买渠道不是建站软件依赖；不需要为了收齐工具表去购买共享账号或装完所有工具。手册的 SiteData 旧下载链接曾贴错，以上使用已核对的正确商店入口。
# 来源与核验边界
原手册：关卡 1：选词与域名 (opens new window)、关卡 2：需求 (opens new window)、关卡 3：资料 (opens new window)、关卡 4：建站 (opens new window)、关卡 5：部署 (opens new window)、关卡 6：复盘与广告 (opens new window)、关卡 7：模板化 (opens new window)、关卡 8：批量内容 (opens new window)。
本次对照八关 “具体步骤” 正文和实际加载的评论；标 “原文” 的提示词保留要求和示例，仅统一排版。不称未读取的问答或图片细节已经完整备份，也不另存一份离线手册。
平台规则核验入口：Pages 构建配置 (opens new window)、Pages 自定义域名 (opens new window)、GSC 验证 (opens new window)、GSC 在线检查 (opens new window)、Sitemaps 报告 (opens new window)、GA4 设置 (opens new window)、AdSense 收款方式 (opens new window)、Google 域名后缀说明 (opens new window)。