移动端代理 SEO 排名跟踪
谷歌已于2025年9月停用了num=100参数，因此现在生成同一份排名报告所需的请求量增加了十倍。本指南将介绍具体有哪些变化、如何正确还原搜索者的位置和设备信息，以及如何确保排名序列的连续性。
- num=100 已不复存在 —— 自 2025 年 9 月起，Google 每页返回 10 个搜索结果，因此同一份前 100 名报告现在需要 10 次请求，而不是 1 次。
- 并不存在单一的排名——只有约11%的关键词在移动端和桌面端排名相同，因此设备是一个维度，而非细节。
- 位置比 uule 参数更重要 — uule 仅提供坐标提示，但最终获取的页面仍取决于出口 IP 地址。
- 一致性就是产品的全部 —— 存在缺口的持仓系列无法告诉你何时发生了变动。
测量使用手机的客户实际看到的搜索结果页面（SERP）。
Exit IP 和 uule 指向同一个位置。
SEO 排名跟踪面临的挑战
排名追踪看似是一个已解决的问题，直到你试图精确地去做时，两个尴尬的事实便浮出水面。首先，根本不存在所谓的“关键词排名”——谷歌会根据搜索者的位置和设备作为主要依据，为每位搜索者生成个性化的搜索结果页面。 其次，从2025年9月起，收集这些搜索结果页的成本大约增加了十倍。
当月，谷歌停用了“num=100”搜索参数。在此之前，单次请求最多可返回100条结果，排名追踪工具正是通过这种方式以较低成本全面掌握整个竞争格局。如今，谷歌每页仅返回10条结果。 排名本身并未发生任何变化，但测量成本却成倍增加：同一份原本只需一次请求即可生成的前100名报告，现在需要十次分页请求才能完成。
这种连锁反应让很多人感到困惑。变更后，分析发现约87.7%的网站在搜索控制台中记录的总展示量有所减少，77.6%的网站记录的独特关键词数量也有所减少。但这并非可见度崩溃。 此前，批量查询百条结果时，页面上的每个列表都会被计为一次展示，这种现象多年来一直在悄无声息地推高深位排名的计数。移除这些查询纠正了测量结果——这也是为什么平均排名往往在同一时间得到提升的原因。
| 发生了什么变化 | 2025年9月之前 | 现在 |
|---|---|---|
| 每次请求的結果数 | 使用 num 参数时，最大值为 100 | 10，分页 |
| 关于“前100名”报告的请求 | 一 | 十 |
| Search Console 展示次数 | 因在深位的大量买盘而被推高 | 更贴近人类现实 |
| 实际追踪深度 | 默认包含前100名，无需额外付费 | 逐页审视预算决策 |
设备差异是问题的另一半，其影响程度比大多数报告所承认的更为严重：只有约11%的关键词在移动端和桌面端的排名位置相同。页面并非仅仅是重新排序，而是以不同的方式进行组装。 在移动端，AI概览通常占据所有内容之上的位置，本地搜索结果块紧随其后，将传统的自然搜索结果挤到了很靠下的位置。如果您的客户使用手机搜索，那么仅针对桌面端的报告所描述的页面，正是他们从未见过的。
在决定分析深度之前，先确定要衡量什么。追踪多个地点和两种设备上的前十名，比从单一视角追踪前一百名更能反映业务状况，而且在数据量减少后，成本也会更低。
用于搜索结果页面（SERP）抓取的移动代理
搜索结果页面是网络上防护最为严密的页面之一，其防护措施主要针对自动化数据采集。触发防护机制的往往并非某个突出的错误，而是来自单一IP地址的请求频率、与来源地址不匹配的浏览器指纹、未处理的同意弹窗，以及步调一致的可预测参数模式。
运营商IP地址的作用在于结构层面的考量，而非表面形式。 移动网络将成千上万的真实用户置于同一个运营商级NAT网关之后，因此一个出口地址承载着大量与您无关的普通用户流量。直接封锁这些流量对目标服务器而言成本高昂，这使得您的请求能获得比代表单台机器的IP地址更大的容忍度。
此外，还有一项针对此工作的特定一致性问题。衡量移动端排名意味着需要模拟移动客户端，而来自托管IP范围的移动用户代理，这种矛盾在接收端是立即可见的。来自移动运营商的移动用户代理，则仅仅是一部手机。
# Page one, then paginate in tens with start= https://www.google.com/search?q=mobile+proxy&gl=fr&hl=fr https://www.google.com/search?q=mobile+proxy&gl=fr&hl=fr&start=10 https://www.google.com/search?q=mobile+proxy&gl=fr&hl=fr&start=20 # gl sets the country edition, hl the interface language. # Neither one places the searcher anywhere -- that is what uule and # the exit IP are for.
两点实用提示。在解析任何内容之前，请先处理同意弹窗，因为在某些地区，您首先收到的“结果页面”其实根本不是结果页面。此外，在单次测量过程中请保持会话标识的稳定性：如果从十个不同的地址分页浏览十页内容，会生成十个互不相关的快照，而非一个连贯的排名结果。
如果请求开始失败而不是返回结果，请在更改代理之前先查看响应—— 每个区块的实际含义是什么 将速率问题与指纹问题区分开来，而这两者的解决方法截然相反。
基于地理位置的排名数据
位置是大多数排名跟踪工作悄然出错的地方，因为那三个看似可以互换的机制其实并不相同。要想获得真正本地化的搜索结果，就必须弄清楚它们各自的作用。
| 信号 | 它控制什么 | 它不做什么 |
|---|---|---|
| gl | 您获得的成绩属于哪个国家的版本 | 将搜索者放置在任意位置。这是一个乡村场景，而非具体地点。 |
| hl | 界面语言，以及间接地涉及部分结果选择 | 对地理产生任何影响 |
| uule | 对坐标进行编码，以便将搜索视为从该点开始 | 覆盖所有设置。出口地址仍然会影响您收到的页面 |
| 出口IP | 默认位置、同意处理、显示哪些插页广告 | 仅凭自身即可实现街道级精度——而固定线路定位的精度最多只能达到城市级 |
可行的方案是让这些信号相互协调，而不是相互冲突。将你关心的坐标编码到 uule 中，将 gl 和 hl 设置为该市场，并从该市场内的出口 IP 发送请求。 当这三者指向同一个位置时，Google 无需进行任何协调。当它们不一致时——例如坐标在里昂，而地址在法兰克福——你所测量的其实是 Google 如何解决这种矛盾，而这并不是任何人所需要的指标。
这也正是移动技术体现其价值之处。手机报告的位置精度远高于固定线路地理定位所能推断的，而且目标市场中的运营商地址所承载的网络信号，与真正身处该地的用户所产生的信号一致。 对于本地搜索结果的追踪而言，两个郊区的细微差异就可能彻底改变搜索结果集，而这种一致性正是决定一个数据是否具有实际应用价值的关键所在。
利用代理服务器扩展排名跟踪
排名追踪中的计算是算术运算，在购买任何服务之前先进行这笔计算，可以节省一大笔钱。将关键词、地理位置、设备类型和页面深度相乘，即可得出单次运行的请求量。
requests_per_run = keywords x locations x devices x pages_of_depth # 500 keywords, 4 cities, mobile and desktop, top 30 (3 pages): # 500 x 4 x 2 x 3 = 12,000 requests per run # # Same job tracking the top 100 instead (10 pages): # 500 x 4 x 2 x 10 = 40,000 requests per run
将该计数值分散到你能承受的窗口范围内，那么地址池只需大到足以让每个地址保持在可接受的速率即可。这是大多数团队理解错误的地方：节奏比地址池的大小更重要。 一个规模适中但耐心使用的地址池，其持续时间会比一次性全量发出的庞大地址池更长，因为防御机制针对的是每个地址的请求频率，而非存在多少个地址。
- 优先考虑切削深度，其次才是切削范围 — 失去一个位置或一个设备会导致该答案完全消失。失去第4至第10页的内容，只会导致那些几乎没人点击的位置消失。
- 每个测量值对应一个标识符 — 在单次会话中对一个关键词进行分页，使这十页内容反映同一排名结果。应在不同关键词之间轮换，而非在同一关键词内轮换。
- 在信号方面放宽要求，而不是在时间表上 — 当遇到困难时，请放慢节奏，让该地址恢复正常。如果立即使用一个新的地址重新尝试，会让目标认为这种模式无论如何都会持续下去。
- 错开运行时间 — 每个在午夜发出的追踪器都会形成一个明显的模式。将一次运行分散在几个小时内进行既不需要任何成本，看起来又像是正常流量。
- 将集合健康状况作为一项指标进行跟踪 — 每个地址的挑战率和空结果率会在数据序列出现缺口的前几天就向您发出预警。位置序列中的缺口事后无法恢复。
关于代码方面的实现——包括会话管理、重试以及遵循 Retry-After 规则的退避机制（而非不断返回 429 错误）——该 Python 数据抓取指南 涵盖了这些模式，并且 数据抓取最佳实践 涵盖了在不耗尽资源池的情况下批量运行它们的方法。
来自关键市场的赛道排名
PXM2实时位置——选择您需要获取SERP数据的国家，并从该国境内的真实运营商IP地址收集数据：
法国
印度
新加坡
常见问题解答
当谷歌移除了 num=100 时，发生了什么变化？
在2025年9月之前，包含该参数的单次请求最多可返回100条结果，正因如此，排名追踪工具才能以较低成本全面掌握竞争格局。谷歌随后禁用了该功能，将每页结果数限制为10条。 排名本身并未发生任何变化，但测量成本却发生了变化：现在要获取同样深度的结果，需要进行十次分页请求。任何需要跟踪多个关键词深度排名的人，其请求量都在一夜之间成倍增长。
为什么我的 Search Console 展示量在同一时间下降了？
因为其中很大一部分从未被视为人类。变更后的分析显示，约87.7%的网站记录的总展示量减少，77.6%的网站记录的唯一关键词数量减少。此前，批量查询100条结果时，页面上的每条列表都会被计入展示量，导致多年来低排名位置的计数被虚高。 这一下降是对测量结果的修正，而非曝光度的损失——出于同样的原因，平均排名往往有所提升。
仅设置 uule 参数就够了吗，还是需要在该位置配置一个代理？
仅靠这一点还不够。将位置编码到 uule 中会告诉谷歌将该搜索视为来自这些坐标，这对本地搜索结果和明显的本地搜索意图非常有效。 但退出IP仍会影响页面——包括国家/地区默认设置、语言、同意处理以及向您展示的插页广告。将uule值与同一市场的退出IP配对，可以消除这两个信号之间的冲突，而无需让谷歌来解决。
移动端排名真的存在足够大的差异，需要单独进行追踪吗？
是的。只有约11%的关键词在移动端和桌面端的位置完全一致，且页面布局也不同：在移动端，AI概览通常占据所有内容之上的位置，本地搜索结果块紧随其下，导致传统的自然搜索结果被大幅挤到下方。如果您的客户使用的是手机，那么仅针对桌面端的报告所描述的页面，正是他们从未见过的。
排名跟踪需要多少个代理？
不要靠猜测，而要根据实际工作情况来推算。将关键词、位置和设备数量相乘，再乘以所需的页面深度，就能得到每次运行的请求数量。将这个数量分摊到你能容忍的时间窗口内，这样请求池只需大到足以让每个IP地址以一个可信的速率发送请求即可。 大多数团队发现，真正能突破验证码限制的其实是请求节奏，而非请求池大小——一个规模适中但耐心使用的请求池，比一个一次性用尽的大型请求池更能持久。
相关移动代理指南
排名跟踪是一项基于爬虫引擎的监测工作，因此这两部分内容都值得一读。