简介：这是一份围绕搜索引擎领域展开的竞品分析报告，以谷歌、百度及移动端玩家宜搜为主要研究对象，适合产品经理、市场运营及商业分析初学者参考。报告依次梳理了三家公司的市场战略、服务构成、功能特性与产品设计，并利用态势分析框架拆解谷歌与百度的优劣势、机会和威胁，能够帮助读者快速掌握竞品对比的常见分析维度与写作结构。资源包内共1个docx文件，大小约1.07MB，包含完整章节与图表化目录，便于直接阅读或二次编辑。当前已有409人学习，说明该案例在相关学习场景中具备参考价值。文中所引用的手机搜索市场份额、服务拼图及移动端布局等细节，有助于理解不同搜索产品的商业定位，也可作为撰写同类竞品分析报告的模板与思路示范。

1. 竞品分析报告不只是写出来的：一份 docx 背后的指标体系与复现路径

团队共享盘里经常会躺着一份命名为「竞品分析报告搜索引擎谷歌VS百度竞品分析.docx」的文件，文件名规范得像模板，打开后却是大量截图、零散的定性判断和一句“百度更懂中文、谷歌更懂技术”的笼统结论。这类报告最大的问题不是没结论，而是没有口径：指标怎么定义、查询语料怎么选、数据从哪来、三个月后谁来更新。真正可复用的竞品分析报告，应该把“怎么做”沉淀成文档本身——从指标分层、样本设计，到对比维度的判定标准，再到用脚本批量生成格式统一的 docx 文件。这篇笔记就按这个路径展开，适合做 SEO 的从业者、产品经理，以及需要替团队持续产出竞品文档的分析岗，目标是让你看完就能搭出一套自己的搜索引擎竞品分析流程，而不是拿到一份一次性的 Word。

2. 把“谁更强”拆成可量化指标：搜索引擎竞品分析的框架与数据采集方案

竞品分析最怕一上来就“论强弱”。先聊一个反直觉的事实：大多数分析报告翻车的根源，不是数据没找全，而是指标选错了维度。搜索引擎是一个极度复杂的黑匣子，但对做分析的人来说，可以直接观测的其实只有四层：用户需求层面的流量倾向、内容生态层面的收录与供给、结果质量层面的相关性语义判断、以及商业层面的排序与广告机制。把这四层拆开，每一层定一组可采集、可对比的指标，后面的分析才有骨架。

2.1 指标分层：把竞品强弱拆成四层可观测指标

我一般会把指标体系分成四层，每一层对应一类可观测数据源，也对应一类决策问题。

第一层是流量与需求。核心指标包括各引擎在目标关键词上的查询热度、需求品类分布、以及自有运营数据里的渠道来源占比。这一层回答的是“用户更愿意在哪里找答案”。第二层是内容生态。核心指标是各引擎对独立站点的收录效率、对自有生态内容的倾斜程度、结构化结果（视频、图片、知识卡）的覆盖比例。这一层回答“你发布的内容更容易被谁收走并展示”。第三层是结果质量。需要人工或模型标注相关性、时效性和语义理解能力，对应“谁的结果更贴近用户意图”。第四层是商业化，包括自然结果与广告结果的占比、广告标识透明度、以及点击路径的复杂程度。

分层的关键作用是防止拿不同口径的数据硬比。比如“谁的内容多”这种问题，如果不区分是站点级收录还是页面级收录，结论基本没法用。每层指标选定后，还要明确统计窗口和统计单位，否则三个月后的对比就会变成另一份不可复现的文档。

2.2 数据采集的三条管道：日志、抽样实验与官方指数

指标定了，接下来是数据从哪来。常见做法是走三条管道并行，我用的也是这套组合。

第一条管道是自有站点日志。如果你手上有网站或内容产品，可以从服务器日志里提取自然搜索来源的关键词与着陆页分布。这条管道的优势是真实、并且口径完全可控。一个生产环境里常见的做法是按小时滚动分析日志字段，抽出搜索引擎来源和关键词。

import re from collections import Counter # 模拟日志行格式：时间|来源|关键词|着陆页 log_line = "2025-06-01 10:00:00|baidu|竞品分析方法|/guide/competitor-analysis" def parse_search_log(log_path): source_counter = Counter() keyword_counter = Counter() pattern = re.compile(r"(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\|(baidu|google)\|([^|]+)\|(\S+)") with open(log_path, "r", encoding="utf-8") as f: for line in f: m = pattern.match(line.strip()) if not m: continue # 过滤掉格式异常的行，保证统计口径干净 source, keyword = m.group(2), m.group(3).strip() source_counter[source] += 1 keyword_counter[keyword] += 1 return source_counter, keyword_counter # 调用示例 src_cnt, kw_cnt = parse_search_log("search_access.log") print("来源占比：", src_cnt.most_common(5)) print("Top 关键词：", kw_cnt.most_common(10))

这段代码的核心是把原始日志规整成两个计数器，得到不同来源的访问量对比和关键词分布。正则里的分组顺序是“时间、来源、关键词、着陆页”，如果你们家日志格式不一样，最容易被忽略的是关键词里可能带空格或中文引号，建议先用反引号或双竖线做分隔符，否则后续统计会串行。统计窗口我会固定为一个自然周，避免周日与周一流量波动干扰对比。

第二条管道是抽样查询实验。这个后面第 3 章会完整展开，核心思路是建立一套固定的查询语料库，周期性执行相同查询，并记录结果页的完整结构。这条管道补充了日志没有的信息：日志只能看到自有站点的引流情况，看不到竞品引擎对全网内容的结果质量。第三条管道是官方指数类数据，用于观察需求热度的长期趋势，比如某个品类词的整体搜索热度是上升还是下降，这个数据要与自有日志做交叉验证，防止只盯着单一来源被趋势误导。

3. 谷歌与百度的同题对比：三种查询语料下的差异与判定标准

有了指标，下一个核心问题是：拿什么查询去做对比实验？我强调“同题对比”，是因为搜索引擎竞品分析最容易犯错的地方就是查询语料不自洽。用一个新闻词测百度、用一个口语词测谷歌，最后得到的是两种完全不同的产品逻辑。语料库要分层、固定、可复用，这一章我把整个对比实验的设计思路与判定标准完整写出来。

3.1 查询语料怎么生成：分层抽样与查询分类

设计语料库时，我会按“用户意图”分层，而不是按“关键词热度”分层。原因是热度高的词往往集中在商品和热门新闻，口语化查询和长尾问题型查询同样代表重要场景，如果语料里缺失，语义能力对比就失真。我当前配置的语料库分五类，每类维持在 20 条左右：

语料库建好之后要固定版本号，任何一次对比实验都必须注明用的是哪版语料。我见过太多报告，第一次用 20 条词，第二次换了 15 条词，结论自然没有可比性。语料库的更新走年度版本节奏，中途只增不改，改了就升版本。

3.2 结果页结构对比：从域名分布看自有生态倾斜

结果页结构对比是生态策略最直观的体现。操作方法是：对同一条查询，逐页记录结果链接，然后按域名维度做聚合统计。最基本的统计量是“前 10 条结果中的自有生态与非自有生态比例”。对于百度来说，自有生态指百科类、资讯类、经验类、文库类等自有频道；对于谷歌来说，需要看其产品矩阵（如地图、视频平台、博客平台）的占比。这里有一个容易误判的地方：单独一个域名在不同引擎的结果里可能同时出现，但它是否属于自有生态要按引擎单独维护一份域名映射表，不能两边用同一个分类清单。

import csv from collections import Counter # 结果列表样式：query,rank,url,title # 注意 URL 要清洗掉协议和参数，避免 www 与非 www 被视为两个域名 def normalize_domain(url): url = url.replace("http://", "").replace("https://", "") domain = url.split("/")[0].lower() domain = domain.replace("www.", "", 1) return domain def analyze_domain_distribution(result_csv, ecosystem_domains): domain_counter = Counter() rank_stats = {} with open(result_csv, newline="", encoding="utf-8") as f: reader = csv.DictReader(f) for row in reader: domain = normalize_domain(row["url"]) rank = int(row["rank"]) domain_counter[domain] += 1 # 只统计首页前 10 条，更贴近真实用户点击区间 if rank <= 10: rank_stats[domain] = rank_stats.get(domain, 0) + 1 total = sum(rank_stats.values()) own_ratio = sum(v for d, v in rank_stats.items() if d in ecosystem_domains) / total return rank_stats, own_ratio # 对某查询结果文件执行分析 stats, ratio = analyze_domain_distribution("query_baidu.csv", ecosystem_domains=set())

这段代码的核心逻辑是：清洗 URL 拿到规范域名，把前 10 条结果的域名分布单独统计，再按生态域名映射表计算自有生态占比。实际使用中有三个参数值得调：一是清洗规则要处理掉“m.”移动前缀，二是前 10 条的窗口可以改成 5 条和 20 条两组分别看，三是生态域名映射表要随引擎产品调整同步更新。我踩过的坑是忽略移动子域，导致同一生态内容的占比被低估，调整后数据稳定多了。

3.3 时效性与语义理解：两套判定标准的落地方法

时效性对比的可行做法是“新页面追踪法”：准备一批从未被收录的新内容页面，在同一天发布，观察两个引擎的收录时间差与收录成功率。这个实验要控制变量：内容长度、站点权重、页面质量尽量一致，否则收录速度差异不能归因于引擎策略。我一般会用同一站点下不同栏目分别投放，确保两端拿到的是同等级的页面。统计口径用“页面发布到首次被收录的分钟级时间差”，并在第 1、6、24、72 小时各记录一次状态，最终汇总成表格。

语义理解的判定则更偏主观，建议采用“意图满足度”标注法，即让标注者不关心结果来自哪边，只针对查询判断“这条结果是否真正回答了问题”，按 1-5 打分。5 分是直接给出完整答案或明确指引；3 分是信息相关但需要二次筛选；1 分是与查询意图无关。标注时要把左右两边结果打乱混合，避免标注者先入为主。一个可复现的实验至少需要 20 条语料乘以三次标注取平均值，不然单人标注的偏好会让结论变成玄学。这套方法做完，你会得到非常扎实的对比数据，足够支撑后续报告的量化结论。

4. 用 python-docx 把对比数据落成竞品分析报告：样式、表格与图表写入

分析做完，最后一步是把结论固化成 docx 报告。很多分析师的习惯是手工粘贴图表、再手工调整排版，一套流程下来半天就没了，而且报告格式不一致。我用 python-docx 把整份报告模板化之后，从数据到成品 Word 的耗时压缩在几分钟内，而且每个版本的格式完全一致。这一章给的代码就是我当时搭建报告生成脚本时沉淀出来的最小可复现版本。

4.1 文档骨架：标题、样式与中文字体

生成 docx 的第一步不是加内容，而是把文档骨架和默认样式定好。python-docx 默认样式对中文支持不理想，如果不显式设置中文字体，打开 Word 看到的可能是默认西文字体渲染出的生硬效果。这里用 qn 模块解决字体名称的映射。

from docx import Document from docx.shared import Pt, Cm from docx.enum.text import WD_ALIGN_PARAGRAPH from docx.oxml.ns import qn doc = Document() # 页面边距：标准报告使用 2.5cm 左右，避免太挤 section = doc.sections[0] section.top_margin = Cm(2.5) section.bottom_margin = Cm(2.5) section.left_margin = Cm(2.8) section.right_margin = Cm(2.8) # 全局样式：设置正文默认字体为中文宋体，西文用 Times New Roman styles = doc.styles normal = styles["Normal"] normal.font.name = "Times New Roman" normal.font.size = Pt(11) # 关键一步：把东亚字体映射到宋体，否则中文不生效 normal.element.rPr.rFonts.set(qn("w:eastAsia"), "宋体") # 标题 1 样式：用于一级章节标题 h1 = styles["Heading 1"] h1.font.name = "微软雅黑" h1.element.rPr.rFonts.set(qn("w:eastAsia"), "微软雅黑") h1.font.size = Pt(18) h1.font.color.rgb = RGBColor(0x1F, 0x3B, 0x63) doc.add_heading("搜索引擎竞品分析报告（谷歌 VS 百度）", level=0) doc.add_paragraph("报告版本：v1.0 ｜ 数据窗口：2025-05-01 至 2025-05-31 ｜ 语料库版本：Q1-2025")

这里必须强调一个细节：normal.element.rPr.rFonts.set(qn("w:eastAsia"), "宋体")这行不能省。只设置normal.font.name只会改西文字体，中文仍然走默认渲染，生成的文档打开后字体不对，这在团队协作时是最容易引起返工的问题。标题字体我倾向用微软雅黑，正文用宋体，正文大小控制在 11pt，比较接近正式报告的排版习惯。

4.2 表格与图表：把对比数据写进 docx

报告里最重的内容是对比表和图表。python-docx 的表格写入逻辑非常直接，但有一个常见问题：默认表格样式是网格线，不是正经的“表格三线表”。职场里标准的竞品报告通常用简单表格加上首行深色底纹，我一般通过table.style = "Light Grid Accent 1"这个内置样式来做基础美化。

from docx.shared import RGBColor from docx.enum.table import WD_TABLE_ALIGNMENT # 写入域名分布对比表：表头+两行数据 table = doc.add_table(rows=3, cols=4) table.style = "Light Grid Accent 1" table.alignment = WD_TABLE_ALIGNMENT.CENTER headers = ["引擎", "前10条自有生态占比", "非自有生态域名数", "广告结果数"] data_rows = [ ["百度", "42.5%", 6, 2], ["谷歌", "18.0%", 9, 4], ] # 先写表头，再写数据行 for col, h in enumerate(headers): cell = table.rows[0].cells[col] cell.text = h # 表头加粗，颜色取深灰，视觉上更聚焦 run = cell.paragraphs[0].runs[0] run.font.bold = True for r, row_data in enumerate(data_rows, start=1): for c, val in enumerate(row_data): table.rows[r].cells[c].text = str(val)

写表格时要注意：rows[0].cells[col].text = h这种方式赋值后，默认段落是纯文本，没有加粗。需要再取paragraphs[0].runs[0]操作字体属性，否则表头视觉重量不够。如果数字是百分比格式，建议在写入前统一做小数转百分比的格式化，避免某些单元格出现 “0.425” 这种原始数据，影响阅读体验。数据行超过 5 行时，我还会给首列加不同的底色区分引擎，方便快速扫读。

图表的插入稍微绕一点。python-docx 本身不生成图表，正确路径是先用 matplotlib 生成 PNG 图片，再通过add_picture插入文档。

import matplotlib.pyplot as plt from docx.shared import Inches # 统一设置中文字体，避免图中中文变成方块 plt.rcParams["font.sans-serif"] = ["Microsoft YaHei"] plt.rcParams["axes.unicode_minus"] = False engines = ["百度", "谷歌"] own_ratio = [42.5, 18.0] ad_cnt = [2, 4] fig, ax = plt.subplots(figsize=(6, 3.2)) bars = ax.bar(engines, own_ratio, color=["#4472C4", "#ED7D31"], width=0.5) ax.set_title("前 10 条结果自有生态占比对比", fontsize=12) ax.set_ylabel("占比（%）") ax.set_ylim(0, 60) # 在柱子上方标注具体数值，节省看图时的换算成本 for b, v in zip(bars, own_ratio): ax.text(b.get_x() + b.get_width()/2, v + 1, f"{v}%", ha="center", fontsize=10) plt.tight_layout() plt.savefig("compare_chart.png", dpi=200) plt.close() doc.add_picture("compare_chart.png", width=Inches(5.5)) doc.save("竞品分析报告搜索引擎谷歌VS百度竞品分析.docx")

matplotlib 的中文字体要单独处理：font.sans-serif列表里的字体名必须与系统已安装字体一致，否则会退回默认字体出现方块。我在多个环境里踩过这个坑，建议生成图片前先用matplotlib.font_manager查看可用字体列表，确认目标字体存在再画图。图片保存的 dpi 建议不低于 200，插入 Word 后放大不会糊。整个脚本跑完后，一份带封面页、数据表格、统计图表的报告骨架就落地了，剩下的工作只是在章节目录上做增删。

5. 竞品分析数据采集避坑指南：口径、抽样与编码的四个翻车现场

这套流程跑通后，我陆续遇到过不少问题，有些属于数据口径，有些属于环境配置，但每一个都会让结论直接失真。这一章写四个真实发生过、并且影响严重的坑，按“现象 → 原因 → 解决”的顺序记录。

5.1 收录量对比失效：两边口径不是一个东西

现象：某次报告里写“百度收录量高于谷歌”，结果被做 SEO 的同事当场质疑，因为基于独立站点的实测数据，两边并没有明显差距。重新核对后才发现，当时统计的百度结果包含了大量自有生态频道内容，而谷歌统计的是全网独立域名页面。两边所谓的“收录量”本身就不是同一个东西。

原因：引擎对收录的定义和统计边界不同。百度对自有生态内容有深度抓取和优先展示，所以以结果页可见条目数作为“收录量”会严重偏高；谷歌更偏重表达域名的广度。

解决：统一统计口径。要么都按“独立域名数量”统计，要么都按“前 20 条结果中可见页面数”统计。我在后续报告里固定使用“前 20 条结果中独立域名数 + 自有生态占比”两个指标并列呈现，不再单独使用“收录量”这个词。

5.2 语料单一导致结论翻车：只有“新闻词”没有“口语词”

现象：初版实验语料全部是热门新闻类查询，结论得出某个引擎时效性极强、语义理解似乎也占优。后来增加了口语化查询语料，另一个引擎的表现出现反转。

原因：新闻词本身对时效性权重敏感，几乎每个引擎都会优先展示最新内容，此时抓取和索引策略的差异被放大；而口语化查询考察的是意图归一能力，热门新闻词完全覆盖不到这个维度。语料类别单一，实验设计就带偏了。

解决：语料库按第 3 章的五个类别分层构建，每一类固定数量，结论里分场景呈现。我会在报告里单独写一个“分语料类别结论”小节，让读者看到不同场景下的强弱项，而不是一个笼统的“谁更好”。

5.3 图表中文乱码与保存空白：matplotlib 与 docx 的字体接力失败

现象：生成的柱状图插入 docx 后，标题文字显示为方块；另一次在 Linux 服务器上跑脚本，生成的 PNG 是空白图，但命令行没有任何报错。

原因：matplotlib 默认字体列表里没有中文字体，导致汉字被替换为方块；空白图一般是没有可用的字体引擎或字体缓存损坏，异常被静默吞掉。前者常见于 Windows，后者常见于服务器环境。

解决：每次画图前强制指定可用中文字体，并确认字体文件存在。服务器环境里我一般安装指定的中文字体包，同时在plt.rcParams里设置font.family并清掉 matplotlib 字体缓存目录，然后再画图。生成图片后第一时间用os.path.getsize()检查文件大小，小于 10KB 直接抛异常，避免写入空图。

5.4 结果页改版打乱采集逻辑：靠解析位置而不是语义

现象：某次引擎调整了结果页的 DOM 结构，原来的解析脚本跑出一个全空的 CSV，报告进度被迫停滞。排查原因时发现，之前解析结果列表是靠“第 3 个 div 下的第 2 个 a 标签”这类位置规则，页面一改版，位置规则直接失效。

原因：位置选择器脆弱，任何前端结构调整都会导致解析结果错乱。这不是个例，而是采集类脚本都会面临的维护问题。

解决：改成按语义化 key 解析，比如提取结果块时优先寻找代表“自然结果”的特定链接模式与标题特征，而不是依赖固定的 DOM 树层级。同时脚本要加数据完整性校验：每条查询至少应该解析出 10 条结果，少于这个数量就输出告警日志，让问题及早暴露，而不是在报告阶段才发现数据是空的。这个检查逻辑比解析本身更能节省时间。

6. 把竞品分析从“一次性报告”变成持续监测：一份打分卡的用法

报告做完就归档，是竞品分析最浪费的结局。我习惯的做法是把第 3 章里做的对比实验转化成一个“月度监测打分卡”，每个月用同一语料库、同一判定标准跑一遍，把结果填入固定模板，用一张表看长期变化。打分卡的好处是能发现算法策略调整的苗头，比如某个引擎的自有生态占比连续三个月上升、广告条数增加，这对业务决策是重要的预警信号。

打分卡的核心是固定权重和评分标准。我这边当前使用的权重是：内容生态 30 分、结果质量 30 分、时效性 20 分、商业化透明度 20 分。每一项内部再按语料类别的表现细分，最后加权得出总分。

每月执行时只做两件事：跑一遍既有语料库、更新一遍打分卡表格。趋势连续三个月明显变化时，再启动一次全量深度分析，而不是每个月都从头铺一遍。数据文件按月归档，下一月直接复制上一月的指标口径，保证可比性。这个流程稳定运行之后，哪怕中间换人也没有关系，只要按同一份语气料和打分卡走，新同学很快就能上手。我自己的教训是：早期做报告时指标没有沉淀成结构化的模板，导致半年后想对比历史数据，只能从旧文档里反推口径，费了不少力气。后来把语料库版本、统计窗口、打分标准全部钉在 docx 报告的附录里，才真正解决了这个问题。希望这套方法能帮到你，让竞品分析少一些玄学，多一些可复现的确定性。

本文还有配套的精品资源，点击获取