上周有个站长很肯定地跟我说：“广告一挂排名就掉，取掉就回来，试了三次。”听起来证据确凿，但“挂了广告”这四个字里其实混着好几件事：广告内容、广告数量、广告脚本、加载时机、插入位置。排名掉的真正原因往往只是其中一件，剩下的都是被冤枉的。分不清这几件事，换一家联盟照样掉。
一、先做减法：广告上线时你还改了什么
第一种要排除的情况是“同期改别的东西”。很多人上广告的时候顺手改了模板、换了统计代码、动了域名解析。排名这时候掉了，很容易算在广告头上。
对照法是唯一靠谱的办法：只加广告脚本，其它一律不动，观察两周。如果掉，说明和广告有关；如果不掉，说明是别的动作。别嫌慢，这一步省不了。
二、四种症状对应四种原因
页面打开明显变慢——大概率是同步脚本阻塞，或者广告脚本体积太大。测一下广告脚本的响应时间就能确认。
页面加载时内容上下跳——没有预留高度，广告填充的瞬间把下面的内容顶走，这是布局稳定性问题。
首屏看不见正文——广告位插在了正文之前，把内容挤出了视野。
排名缓慢下滑、收录量变少——这种慢性的下滑更可能是内容与广告比例失衡，或者用了诱导性的广告形式。
症状不同，修法完全不同。慢的可以用性能和体验工具测，快的只能靠对照观察。
三、怎么分清是“广告本身”还是“加载方式”
按这个顺序做，每步只改一个变量，每步观察两周。
第一步，把广告脚本改成异步或延迟加载，其它都不动。如果排名恢复，结论就是加载方式的问题，收工。
第二步，如果没恢复，减少广告数量，首屏只留一个。恢复了，那就是数量和位置的问题。
第三步，还没恢复，换掉广告内容或者换联盟，看是不是广告形式本身有问题（比如自动弹窗、诱导下载）。
三步走完还找不到原因，再回头看内容本身——有可能广告只是背锅的。
四、用一个脚本先定位加载问题
加载问题是可以量化的。下面这段脚本分别请求页面本身和广告脚本，对比各自的响应时间和体积，一眼能看出广告脚本是不是拖后腿的那一个：
# 对比页面本身与广告脚本：谁的响应更慢、体积更大
import time
from urllib.request import Request, urlopen
TARGETS = [
("页面本身", "https://www.example.com/article/123.html"),
("广告脚本", "https://cdn.example-ad.com/slot.js"),
]
for name, url in TARGETS:
t0 = time.time()
try:
req = Request(url, headers={"User-Agent": "Mozilla/5.0"})
resp = urlopen(req, timeout=10)
size = len(resp.read())
ms = (time.time() - t0) * 1000
print("%-8s %8.0f ms %8d 字节" % (name, ms, size))
except Exception as e:
print("%-8s 请求失败：%s" % (name, e))
如果广告脚本的响应时间超过页面本身的几倍，或者体积超过几百 KB，那基本可以确定它就是拖慢加载的主要来源。这时候的修法是延迟加载，而不是删广告。
测的时候要多跑几次取平均值，网络波动会让单次结果失真。另外注意对比的公平性——同一篇文章、同一个时间段、同一台机器上测，别拿白天和半夜的数据比。如果广告脚本偶尔超时、偶尔正常，那问题多半在广告服务器那边，这种不确定性本身就是体验隐患，延迟加载照样能兜住。
五、布局抖动的具体修法
抖动是体验指标里最容易被广告拖垮的一项。修法有三条：给广告容器写死最小高度，广告没填充时也占着位置；图片给上宽高属性，避免加载完成后重排；广告脚本用延迟加载，等用户快滚动到那个位置时再拉取，这样即使它慢，用户也看不到过程。
这三条下来，页面在加载过程中的位置基本是稳定的，用户不会遇到“点了一半按钮跑了”的情况。抖动这项指标的具体数值，可以用浏览器自带的性能面板录一次加载过程看到，改之前和改之后各录一次，对比很直观。
排名掉了别急着下结论。先用对照法确认是不是广告的锅，再把加载方式、数量位置、广告内容三件事分开测一遍。经验上看，小站遇到的九成“广告伤排名”，最后都落在加载方式和首屏位置上，真正因为广告内容被处理的是少数。先改写法，再考虑撤广告。
如果三步都试过、广告怎么调都恢复不了原来的排名，那就把广告先撤一周，看排名是不是真的回来。回来了说明确实是广告相关，再按上面的顺序逐步加回去，一次加一样，看加到哪一步开始掉；没回来，说明原因在别处，把注意力放回内容和收录上，别在广告这里钻牛角尖。
相关阅读：
A5创业网 版权所有