通过审核后，很多人会直接把广告代码贴进八个位置，然后等钱进来。实际发生的是：Cumulative Layout Shift 飙升、跳出率上涨，RPM 反而掉——因为页面太吵，没人滑到那些真正值钱的广告位。下面是我们自己用的投放流程：让广告能挣钱，同时把每一项 Core Web Vitals 都压在 Good 区间。
TL;DR
长文先放三个预留好的手动单元：正文开头之后一个、篇中一个、篇末一个。每个广告位都设固定 min-height，让晚加载的广告无法把内容往下挤。AdSense 脚本用 async 加载，首屏以下的位 lazy-load。投放前后都用 PageSpeed Insights 测一遍，把 CLS 压在 0.1 以下、LCP 在 2.5 秒以内、INP 在 200 毫秒以内（这是 2026 年的阈值，按真实访客的第 75 百分位判定）。某个位把任意指标顶出 Good 就拿掉。每季度复测一次。
广告到底给页面带来什么成本
一个 AdSense 单元就是一段在运行时注入 iframe 的 JavaScript。每个单元都增加网络延迟，如果没预留空间还会引发布局偏移，再加上一次视觉打断。收益与体验的取舍是真实可量化的：单元越多，单访客收益上升到某个点；再往上密度拖垮停留时间和搜索排名，实际收益也跟着掉。
2026 年 6 月，有两条政策决定了这个上限在哪：
- Google 废除了老的「每页最多三个广告」上限。 取而代之的是 Valuable Inventory（有价值的库存）政策：广告量不能超过实际内容，否则 Google 可能限制甚至停掉该页的广告投放。现在没有魔法数字，只有一个必须守住的内容与广告比例。
- Better Ads Standards 针对桌面端和移动端做了更新，合规评估从 2026 年 5 月 14 日起执行。 硬线是移动端广告密度：广告占主内容垂直高度不得超过 30%。Chrome 直接执法，可以在违规页面上过滤广告。
所以独立内容站现实中的甜区仍然是每篇长文三到四个有讲究的单元——不是因为有数字上限，而是因为这个量级才能既守住 30% 密度线，又让 Core Web Vitals 全绿。
出现这些症状，说明你看对文章了
- 刚通过审核，想稳妥地加广告，而不是一把丢给 Auto Ads。
- 开了 Auto Ads 或叠了一堆手动单元，Core Web Vitals 报告变红。
- 读者说网站「全是广告」。
- 页面 RPM 低于这个主题的正常区间，怀疑是位置而不是需求的问题。
广告必须守住的 Core Web Vitals 数字
Google 按 CrUX 真实用户数据的第 75 百分位判定，也就是说至少 75% 的访客拿到 Good，这个 URL 才算过关。
| 指标 | 测什么 | Good（截至 2026 年 6 月） | 广告在哪里伤它 |
|---|---|---|---|
| LCP | Largest Contentful Paint（加载） | 低于 2.5 秒 | 广告脚本在主图加载前抢带宽和主线程 |
| INP | Interaction to Next Paint（响应） | 低于 200 毫秒 | 点击/滚动时广告 JS 正在执行，拖慢下一帧渲染 |
| CLS | Cumulative Layout Shift（稳定性） | 低于 0.1 | 没预留的广告位填充时把内容往下顶 |
INP 在 2024 年 3 月取代 First Input Delay 成为 Core Web Vital，所以别再看那些还让你盯 FID 的旧文了。INP 是 2026 年最多网站没过的一项，而广告脚本是常见元凶——它恰好在用户想滚动或点击的那一刻占住主线程。
实操步骤
-
先选策略：手动、Auto Ads 还是混合。 多数独立站从手动起步：位置、预留空间、密度都你说了算。2026 年的最佳实践是混合——先放两到三个测过的手动单元，再开 Auto Ads 并打开「使用现有广告单元」，让 Auto Ads 在你的锚点周围补位，而不是跟它们打架。
-
在 AdSense 后台建三个命名清楚的手动单元： in-content（自适应展示）、篇中、篇末。命名要让后面看表现报告时一眼能认出来（比如
art-incontent-top、art-mid、art-end）。 -
广告加载前，先给每个位预留固定高度的容器。 就这一步决定了 CLS 能不能压在 0.1 以下。每个单元用一个带
min-height的 div 包起来，高度对齐预期广告尺寸：<div class="ad-slot" style="min-height:280px"> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-0000000000000000" data-ad-slot="0000000000" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push(\{\});</script> </div>预留的高度在广告填充时把它吃掉，内容就永远不会跳。中矩形大概要
min-height:280px，横幅位约min-height:110px。 -
第一个单元放在前两三段之后，绝不放在
h1上面。 标题上方的广告会杀停留时间，还会触发 Google 的「ads above content」关注。首屏内的 in-content 没问题，但盖在标题上的 anchor 或 vignette 不行。 -
延迟并 lazy-load 广告脚本。 AdSense 库用
async加载。首屏以下的手动单元加loading="lazy"，Auto Ads 则用data-ad-frequency-hint="30s"放慢注入。这样既保护 LCP（库不再跟主图抢跑），也保护 INP（早期交互时主线程的活更少）。 -
前后都测。 用 PageSpeed Insights 跑一遍，等真实流量积累后再看 Search Console 的 Core Web Vitals 报告。LCP、INP 或 CLS 任一掉出 Good，就拿掉表现最差的位再测。以现场数据（CrUX）为准，实验室分数只能抓出明显的退化。
一个有据可查的混合测试把取舍讲得很清楚：某站从纯 Auto Ads 切到两个手动锚点加「现有单元」Auto Ads，PageSpeed 分数从 81 回到 89，而收益只掉了约 3%。可控性胜过省事。
容易踩的坑
- 把 300x250 塞在
h1上面「最大化曝光」。访客直接划过，跳出率上升，还触发 ads-above-content 问题。放到正文开头之后。 - 容器不预留高度。 广告晚加载、内容下移，CLS 一帧之内从 0.05 跳到 0.40。永远设
min-height。 - 移动端一屏超过一个广告。 两个叠在一起既是 UX 问题，也把你顶向 Chrome 现在执法的 30% 移动端密度线。
- 开着 auto-refresh。 它虚增 impressions，但会让 RPM 崩、读者烦。默认关掉。
- set-and-forget（设完就不管）。 每季度复测位置。第一版几乎不是最优，而且 AdSense 的广告强度和 fill rate 会随时间漂移。
这篇适合谁，什么时候跳过
适合：刚通过审核、要加第一批单元的发布者，以及加完广告后 Core Web Vitals 崩了的发布者。跳过：还在申请阶段的站（通过前绝不挂真广告），或者真正的瓶颈是流量而非变现的站。一个一天只有 50 访客的页面，放三四个广告也挣不到什么——先修流量。
FAQ
- Auto Ads 还是手动？ 求可预测就手动，求两全就混合。先放两到三个测过的手动锚点，再开 Auto Ads 并打开「使用现有广告单元」。纯 Auto Ads 省事，但位置质量参差，更难把 Core Web Vitals 守在 Good。
- 页面上限取消后，多少广告算太多？ 规则是密度而不是数量。移动端一屏不超过一个广告，广告占主内容垂直高度别超过 30%（Better Ads Standards 的线，Chrome 执法），广告量也别超过实际内容（AdSense 的 Valuable Inventory 政策）。长文三到四个单元是个稳妥目标。
- 广告会直接伤 SEO 吗？ 广告本身不会，但它的副作用会：CLS 退化、LCP 变慢、INP 变差，都进入 Google 的 page experience 信号。把三项 Core Web Vitals 都保持 Good、密度合理，SEO 影响就很小。
- 我到底要达到哪些阈值？ LCP 低于 2.5 秒、INP 低于 200 毫秒、CLS 低于 0.1，都按真实访客的第 75 百分位判定。INP 是 2026 年最多站没过的一项，广告 JavaScript 是常见原因。
- 桌面端和移动端的 fill rate 为什么差这么多？ 多半是位置而非需求。常见的缺口是 anchor 或 vignette 格式只在移动端触发，或桌面端用了移动端无法渲染的 sticky 单元。参考移动端 vs 桌面端 fill rate 差距。
- 每页都要放广告吗？ 不要。首页、About、Contact、搜索页通常不放，Privacy Policy 必须不放。文章页、分类页可放。有些发布者还会把转化率最高的页面整个豁免。