本文约 4,072 字，预计阅读 11 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：用户点进来还没看到正文，先被弹窗糊了一脸
移动端流量占多数的内容站，最容易在弹窗上翻车。运营为了拉新，在移动端加了「关注公众号领资料」的全屏浮层，还要求点击「继续阅读」必须下载 APP；技术按需求实现，弹窗在 DOMContentLoaded 就弹出，关闭按钮做成一个 24×24 像素的灰色小叉，位置还和正文第一行的链接重叠。上线两周后，移动端流量掉了一半，资源平台的索引量没变，但移动搜索来的点击断崖式下滑。这不是收录问题，是落地页体验问题——百度会把这类页面在移动搜索结果里降权或直接限制展现。
原理分析：百度判定落地页体验的几个维度
百度针对移动搜索落地页体验推出过冰桶算法，重点打击的正是「主体内容被遮挡、强制用户操作」这一类行为。结合《百度搜索落地页体验规范》，判定维度可以归纳为四点：可访问性（主体内容是否在首屏直接可见）、干扰程度（弹窗面积、出现时机、是否可一键关闭）、强制行为（是否要求下载 APP、关注账号、填写信息后才能看到内容）、一致性（点进来的内容是否与搜索结果摘要一致）。其中强制下载类最严重，属于明确的负面因子；可关闭的延时弹窗通常只是轻微影响。
| 行为 | 严重程度 | 说明 |
|---|---|---|
| 不下载 APP 无法阅读 | 极高 | 明确打击对象 |
| 全屏插屏且关闭键极小 | 高 | 主体内容被遮挡 |
| 立即弹出（0 秒） | 高 | 用户尚未看到内容 |
| 3 秒后弹出、可一键关闭 | 低 | 可接受 |
| 底部悬浮条（不遮正文） | 低 | 可接受 |
| 顶部通知条（可关闭） | 低 | 可接受 |
| 正文内嵌 1–2 个广告位 | 低 | 见广告密度规范 |
注意一个误区：百度移动搜索的抓取与体验评估是分开的。页面照样能被收录，但会在展现层被压制，所以表现为「收录正常、流量暴跌」。这种症状一看就知道该往体验方向排查，而不是去查内容质量。
保姆级实操
步骤 1：先自查移动端的实际表现。 用手机或浏览器的移动端模拟器访问自己的页面，把「首屏是否直接看到正文」「弹窗能否一指关闭」「关闭后是否反复弹出」三点记录下来。
步骤 2：把弹窗改成可关闭、延时、非全屏。 下面是一个合规的移动端引导条实现：延时 3 秒出现、底部悬浮不遮挡正文首屏、一键关闭、7 天内不再打扰：
<div id="guide-bar" class="guide-bar" hidden>
<p class="guide-bar__text">关注公众号可获取本文配套配置文件</p>
<button type="button" class="guide-bar__close" aria-label="关闭引导">
<svg viewBox="0 0 24 24" width="20" height="20" aria-hidden="true">
<path d="M6 6l12 12M18 6L6 18" stroke="currentColor" stroke-width="2" fill="none"/>
</svg>
</button>
</div>
步骤 3：用 JS 控制出现时机与频次。 关键点是延时、可关闭、关闭状态持久化、以及不给未关闭的用户反复弹：
(function () {
var KEY = 'guide_bar_closed';
var bar = document.getElementById('guide-bar');
if (!bar) return;
function daysToMs(d) { return d * 24 * 60 * 60 * 1000; }
function readClosedAt() {
var m = document.cookie.match(new RegExp('(?:^|; )' + KEY + '=([^;]*)'));
return m ? Number(decodeURIComponent(m[1])) : 0;
}
function writeClosedAt(ts) {
var d = new Date(Date.now() + daysToMs(7));
document.cookie = KEY + '=' + ts + '; expires=' + d.toUTCString() + '; path=/; SameSite=Lax';
}
if (Date.now() - readClosedAt() < daysToMs(7)) return;
// 延时 3 秒，且只在用户已经开始滚动（说明看到了正文）时出现
var shown = false;
function show() {
if (shown) return;
shown = true;
bar.hidden = false;
bar.classList.add('is-visible');
}
setTimeout(show, 3000);
bar.querySelector('.guide-bar__close').addEventListener('click', function () {
bar.classList.remove('is-visible');
bar.remove();
writeClosedAt(Date.now());
});
})();
步骤 4：用 CSS 限定面积与位置。 引导条固定高度、不覆盖正文、关闭按钮达到可点击尺寸（建议不小于 44×44 CSS 像素）：
.guide-bar {
position: fixed;
left: 0;
right: 0;
bottom: 0;
z-index: 9999;
display: flex;
align-items: center;
gap: .75rem;
padding: .75rem 1rem;
max-height: 15vh; /* 不超过视口高度的 15% */
background: #fff;
box-shadow: 0 -2px 12px rgba(0, 0, 0, .12);
transform: translateY(100%);
transition: transform .25s ease;
}
.guide-bar.is-visible { transform: translateY(0); }
.guide-bar__text {
flex: 1;
margin: 0;
font-size: .875rem;
line-height: 1.5;
}
.guide-bar__close {
flex: 0 0 auto;
width: 44px; /* 满足最小可点击区域 */
height: 44px;
display: grid;
place-items: center;
border: 0;
background: transparent;
color: #666;
}
/* 已关闭状态不占位，避免影响首屏高度计算 */
.guide-bar[hidden] { display: none; }
步骤 5：撤掉一切强制下载逻辑。 如果曾经做过「下载 APP 才能继续阅读」，必须彻底移除，包括后端的拦截判断，不只是隐藏前端弹层。
步骤 6：对照规范复核并提交反馈。 在资源平台用抓取诊断确认移动端渲染正常，若体验问题已修复但展现仍未恢复，可通过反馈中心提交说明。恢复周期通常在一到四周。
常见踩坑
- 关闭按钮做成文字链接「跳过」，字号 12px，用户根本点不中，等于没有关闭入口。
- 案例： 某下载站做了「不安装 APP 无法查看下载地址」的拦截，一周内移动端流量从日均 9000 掉到 1100，索引量几乎没动；移除拦截后第三周开始回升，但完整恢复到原水平用了近两个月。
- 弹窗关闭后 5 秒又弹，用户每次滚动都触发一次。
- 只在移动端加了弹窗，PC 端没有，结果 PC 收录正常、移动展现被压，误判为移动适配问题。
- 用
window.onload之前的同步脚本插入弹窗，直接拖慢首屏，同时触发闪电算法的负面评价。 - 引导条用
position: fixed; top: 0覆盖在标题上，首屏主体内容被判定为不可见。 - 把弹窗做成
z-index: 99999且pointer-events覆盖全屏，即使视觉上只占底部，实际点击被整个浮层拦截。
总结
判断移动端弹窗是否合规，看三件事：用户能不能在不做任何额外操作的前提下读到正文、弹窗能不能一指关掉、关掉后会不会再来。三条全满足基本安全，任意一条不满足就该改。行动清单：移动端实测首屏 → 弹窗改延时+底部+可关闭+7 天不重复 → CSS 限定面积与点击区 → 移除所有强制下载拦截 → 抓取诊断复核 → 等待一到四周观察展现恢复。广告本身的密度边界见 页面广告比例与百度体验评价，首屏速度的影响见 移动端首屏加载优化。
