---
name: iLang AdSense Auditor
slug: ilang-adsense-auditor
category: Quality
description: Structured audit tool that evaluates a website against 29 Google AdSense requirements using judgment vectors. Helps webmasters diagnose eligibility, rejection reasons, or content readiness before applying or re-applying.
github: "https://github.com/adsorgcn/iLang-Adsense-Auditor/tree/main/skill"
language: Python
stars: 24
forks: 9
install: "npx degit https://github.com/adsorgcn/iLang-Adsense-Auditor/tree/main/skill ~/.claude/skills/skill"
installs_to: ~/.claude/skills/skill
source_path: skill/SKILL.md
collection_size: 1
category_size: 1354
added: 2026-08-11T07:22:05.772Z
last_synced: 2026-08-11T07:22:05.772Z
canonical_url: "https://dirskills.com/skills/ilang-adsense-auditor"
---

# iLang AdSense Auditor

Structured audit tool that evaluates a website against 29 Google AdSense requirements using judgment vectors. Helps webmasters diagnose eligibility, rejection reasons, or content readiness before applying or re-applying.

**Install:**

```bash
npx degit https://github.com/adsorgcn/iLang-Adsense-Auditor/tree/main/skill ~/.claude/skills/skill
```

## README

# iLang AdSense 审核器

## 核心规则

Google 官方 AdSense 与发布商政策文档是唯一事实来源。本 skill 把这些文档转化为一套结构化、判断向量式的审核,但**无法保证过审**——Google 的审核包含人工判断和未公开标准。每份报告都必须诚实说明这一点。

正式审核前,若能联网,先刷新 `references/requirements.md` 中列出的官方文档。**如果实时 Google 文档与本 skill 冲突,以实时文档为准。**

## 这套审核与众不同之处

两个协议层面的保证,不是文风偏好:

1. **判断向量,而非标签。** 每条要求产出一个 `AUDIT_JUDGE_v1` 记录(见 `references/judgment-schema.md`):五个维度在 `[0.00, 1.00]` 区间——合规度、证据、确定性、过审影响、修复成本,外加一个判定。每个判定背后的「为什么」都是可量化、可争议的数字。

2. **完整性由代码强制,而非靠自觉。** 审核不是「觉得查完了」就结束,而是 `validator/audit_validator.py --check` 通过才算完成。它读取要求清单,确认每个 ID 恰好被覆盖一次,校验每个向量,并验证站点结论确实由各条判定推导而来。跳过一条要求是一个非零退出码,不是一次疏忽。

## 审核前必读

- `references/requirements.md` —— 29 条要求清单,含 ID、官方依据、默认严重度。**通读全文。每个 ID 都必须评估。**
- `references/judgment-schema.md` —— `AUDIT_JUDGE_v1` 向量、判定集合、屏障聚合规则。
- `references/usage.md` —— 调用与请求模板(用户问怎么用本 skill 时读)。

## 审核流程

1. **确认审核目标。**
   - 线上 URL/域名、代码仓库路径,或两者兼有。
   - 审核类型:申请前、被拒后、或广告投放清理。
   - 站点类型:普通站、CMS/博客、目录站、电商、工具/应用、UGC、视频站、或登录墙产品。这决定了哪些要求判 `NA`。

2. **从清单出发,而非凭直觉。** 先生成骨架,让任何 ID 都无法被悄悄漏掉:
   ```bash
   python3 validator/audit_validator.py --template > report.json
   ```
   现在每条要求 ID 都是一行、等待被判断。

3. **逐条收集证据。**
   - 抓取首页与代表性内容页。
   - 检查 `robots.txt`(尤其 `Mediapartners-Google`)、sitemap、canonical URL、跳转、HTTP 状态、登录墙,以及主内容是否无需 POST 状态即可渲染。
   - 检查隐私政策、关于/联系/所有权信号、导航、内容深度与原创性、广告/联盟密度、纯嵌入页,以及违禁/受限内容风险。
   - 若有仓库访问权,检查模板/路由/内容来源,而不仅是渲染后的首页。

4. **把每条要求判成一个向量。** 对每个 ID,填一条 `AUDIT_JUDGE_v1` 记录:
   - 诚实设定五个维度。证据 `evd` 低或确定性 `cer` 低时,判定必须是 `UNKNOWN`,并说明缺什么访问权——绝不能给一个心存侥幸的 `PASS`。
   - 判定要与向量自洽(`PASS` 不能带 `cmp < 0.5`;`BLOCKER` 不能带 `cmp > 0.5`)。
   - 仅当要求确实不适用时才用 `NA`,并说明是何种站点条件使其无关。

5. **按屏障规则推导站点结论**(不要用平均):
   - 有任何 `BLOCKER` → `NOT_READY`。
   - 有任何 `HIGH`/`MEDIUM`/`UNKNOWN`(无阻断项) → `READY_AFTER_FIXES`。
   - 全部 `PASS`/`NA` → `READY`。

6. **交付前先校验。**
   ```bash
   python3 validator/audit_validator.py --check report.json
   ```
   若非零退出,审核就是不完整或不自洽的。先修好,再写给人看的报告。

7. **产出报告。给站长的顺序,不是给机器的顺序。**

   报告开头必须是**一段人话结论**,让一个不懂技术、第一次申请 AdSense 的站长立刻看懂。这一段里**不出现向量数字、不出现字段名**,只回答三个问题:
   - **能不能现在申请?**(能 / 修完再申请 / 先别申请)
   - **卡在哪几个地方?**(用大白话点出阻断项,几个就是几个)
   - **按什么顺序修?**(先修哪个、再修哪个——排序规则见下)

   这一段之后,才是给想深入的人看的技术明细:
   - 发现列表,按严重度排序(先阻断项、再高危、再中危),每条含:要求 ID、问题、证据、官方依据、精确修复方案,以及它的判断向量。
   - 最后一张表覆盖全部 29 条要求 ID,含判定与向量。

   **修复顺序怎么排(这是判断向量对新手的真正价值):** 不是按严重度机械排,而是按「性价比」——`imp`(过审影响,越低越致命)高、`fix`(修复成本,越高越省事)也高的**先修**。也就是「既卡审核、又好修」的问题排最前面,让站长用最小的力气先搬走最挡路的石头。判断向量在这里不是哲学摆设,是一张**修复排期表**。

   **如果结论是 `NOT_READY`,报告结尾必须包含一句被拒后节奏提醒**(依据见 `requirements.md` 的「审核机制背景」,注意那是社区经验归纳、非官方规则,表述时不得冒充 Google 官方说法):劝站长把问题修完再提交,并明确警告——不要在没有实质修改的情况下立即点「重新审核」,反复无修改重交只会让后面每一次审核都更难过。一次交对,胜过交十次。

## 实施指引

优先给出具体的、锚定证据的发现,而非泛泛而谈:

- `robots.txt 第 3 行 Disallow 了 Mediapartners-Google` —— 而非「爬虫问题」。
- `文章页大多是抓取来的片段,没有任何原创评述` —— 而非「内容单薄」。
- `/reviews 页首屏之上的联盟广告块超过了主内容` —— 而非「广告太多」。
- `隐私政策完全没有提及 Google/第三方广告 cookie` —— 而非「隐私政策不完整」。

只要还有任何 `BLOCKER` 未解决,或任何 `HIGH` 既未修复也未被站长明确接受,就不要建议提交申请。

## 审完之后:主动提出帮站长改(代修闭环)

能用到这个 skill 的人,几乎都是**还没过审的新手站长**——他们要的不是一份诊断书,是把网站改到能过。所以审核报告不是终点。

**在任何拥有文件或服务器访问权的运行环境里**(比如 Claude Code、Codex、OpenClaw、WorkBuddy 这类能读写站长代码仓库或 VPS 的 agent),给出报告后,**必须主动问一句:「需要我直接帮你改好吗?」** 然后按上面那张修复排期表的顺序动手:性价比最高(既卡审核又好修)的先改。

- 每改一处,对应一条要求 ID,说清楚改了什么、为什么这样改能解决对应的判断。
- 改完可以重跑一遍审核,让站长看到判定从阻断项变成通过——这比任何解释都直观。
- 涉及删内容、改主题、动 robots.txt 这类有风险的操作,先讲清后果、征得同意再动手。

**如果运行环境没有文件/服务器权限**(比如纯聊天窗口),就把每处修复写成站长能照着做的具体步骤:改哪个文件、加哪几行、放在什么位置。给的是「怎么改」,不是「哪里错」。

## 跨平台运行:能跑校验器就跑,不能跑就诚实降级

本 skill 的完整性闸门靠 `audit_validator.py`(纯 Python 标准库)。不同 agent 平台的执行能力不一样:

- **能执行 Python 的环境**(Claude Code、Codex、OpenClaw、Hermes、WorkBuddy、Claude 网页版的代码执行等):正常跑 `--check`,闸门是硬性的。
- **不能执行代码、只能读文档的环境**(如飞书 aily 的部分技能形态):无法运行校验器。此时**降级为模型自查**——对照 `requirements.md` 的 29 条 ID 逐条核对,确认每一条都被评估、没有遗漏。但必须在报告里**诚实标注这是降级模式**:「本次审核未经过 `audit_validator.py` 的代码级完整性校验,29 条要求由模型逐条自查覆盖。」

绝不能在降级模式下假装闸门通过了。诚实标注降级,本身就是这个 skill 的诚实原则的一部分。

## 完整性闸门(不可妥协)

在能执行代码的环境里,审核只有在 `audit_validator.py --check` 通过后才算完成。这是把本 skill 与「模型可以偷偷少填的清单」区分开的结构性保证。绝不要在一份未通过闸门的报告上给出过审结论。