50个站怎么一次性查出哪些页面的标题是空的？描述超了160字的有多少？关键词堆了30个的有几个？
TDK三个字母看起来简单，Title、Description、Keywords，每个做过SEO的人都知道要写。但当你手里管着二三十个站、每个站少说几百个页面的时候，问题就来了：哪些页面的标题是空的？哪些页面的描述超了字数被搜索引擎截断了？哪些页面的关键词字段堆了三四十个词自欺欺人？
一个站手动翻一遍都要半天，几十个站翻完眼睛都花了，更别说还得把数据拉出来对比、排序、标注问题。TDK检测这件事，量少的时候不觉得是问题，量一上来就是纯体力活。但好消息是，批量检测TDK的工具和方法比想象中成熟，在线工具、浏览器插件、Python脚本、Screaming Frog爬虫，几套方案搭配起来，一个下午能把几十个站的全部页面TDK状态拉清楚。
TDK批量检测要回答的四个核心问题
| 1 | 缺失检测：哪些页面的Title、Description字段是空的或默认模板值 |
| 2 | 长度合规：Title是否超过60字符被截断？Description是否超过160字符被省略号替代 |
| 3 | 重复率排查：同一站点内有多少页面共享了相同的Title或Description（这是搜索引擎明确反对的） |
| 4 | 关键词堆砌：Keywords字段是否塞了太多词（百度早已不参考Keywords，但很多人还在堆） |
一、先搞清楚检测什么，比找工具更重要
很多人上来就搜"TDK批量检测工具"，找到一个工具就开始跑，跑出来一堆数据也不知道看什么。TDK检测不是把数据抓下来就完事了，关键是你知道要看什么指标、每个指标的阈值是多少。
Title是搜索引擎结果页里最显眼的元素，也是排名权重最高的字段之一。Title检测的核心就三件事：有没有、多长、是不是每个页面都不同。百度对Title的截断线大约在30个中文字左右（60个英文字符），超过就被省略号替代。Google稍微宽松一点，大约600像素宽度，折算过来也是60-70个字符。但这个截断不是绝对的，搜索引擎会动态调整——如果你的Title里堆满了关键词，它可能整条都不取，直接从页面H1标签里摘一段当标题。
Description虽然不直接影响排名，但直接影响点击率。搜索结果摘要里那个灰色的小字就是它。Description的检测重点是：超过160个中文字（或320个英文字符）会被截断，等于白写；空值的话搜索引擎会自己从页面内容里随机摘一段，往往摘得莫名其妙。
| 检测项 | 合规标准 | 红线（必须改） | 检测优先级 |
|---|---|---|---|
| Title长度 | 25-35个中文字，关键信息靠前 | 超过35字或被截断 | 最高 |
| Title唯一性 | 每个页面独立Title | 存在重复Title | 最高 |
| Title缺失 | 所有页面均有Title | 空白或"Untitled" | 最高 |
| Description长度 | 80-160中文字，自然描述 | 超过160字被截断 | 高 |
| Description缺失 | 每个页面均有Description | 空白 | 高 |
| Keywords堆砌 | 3-5个精准词，或留空 | 超过10个词 | 低（百度已不参考） |
有个容易被忽略的点：Keywords字段在百度搜索里已经不参与排名计算了。2015年之后百度就明确表示Keywords权重极低甚至为零。但很多人还在堆，一方面是习惯，一方面是"万一有用呢"的心态。实际检测时可以顺带看一眼，但不值得花太多时间在这上面。真正的精力应该放在Title的缺失/重复/截断、Description的空值和长度上。
二、免费在线工具：单页检测和批量检测分开用
在线TDK检测工具分两类：单页检测（输入一个URL看结果）和批量检测（一次提交多个URL）。两类工具解决的问题不一样，别混着用。
单页检测适合快速诊断——比如你怀疑某个页面TDK有问题，直接丢URL进去，秒出结果。像聚查的TDK查询、UU在线工具、98ce这些，功能都差不多：输入URL→返回Title/Description/Keywords+字数统计+SEO评分。这类工具的优势是快、不用注册、随手就能用。
聚查 jucha.com
单页TDK查询，支持检测缺失、重复、过长问题，附带SEO评分和优化建议。界面简洁，不需要注册。
测罗 celu.com
批量TDK提取，一次最多50个URL。自动修复编码乱码，模拟百度/谷歌爬虫User-Agent。免费够用。
SEO查 seocha.net
批量TDK查询，强调唯一性检测——"极致的SEO是不允许不同页面拥有相同标题的"。思路对，但工具稍老。
熊猫SEO工具 xiongmaotool.com
批量查TDK+IP+状态码，信息维度多。适合做全站体检时一起跑，不止看TDK。
在线工具的好处是零门槛、免费、不用安装。但短板也很明显：大多数免费版有URL数量限制（50-100条），站点多了得反复提交；而且跑的是你提交的URL列表，如果你的网站有500个页面，你得先拿到这500个URL才行。
所以在线工具更适合"已知问题页面"的快速抽查和小站点（100页以内）的全量检测。大站得用爬虫类的方案。
三、浏览器插件：打开页面就能看，调试阶段最顺手
浏览器插件不是用来批量跑的，但它在调TDK的时候效率极高——打开一个页面，点一下插件图标，Title、Description、Keywords、H1-H6、Canonical、OG标签全列出来，哪里不对一目了然。
SEO META in 1 CLICK
Chrome插件，点击图标弹出当前页所有Meta信息。支持高亮显示字数超标的字段，一眼看出Title/Description是否被截断。
SiteTDKs
国产插件，专做TDK查看。支持多浏览器，界面中文，对国内站长更友好。
Detailed SEO Extension
功能最全的SEO浏览器插件之一，不止TDK，结构化数据、Open Graph、Twitter Card、H标签层级全部展示。重度SEO用户的标配。
插件在调试新页面或修改完TDK后验证效果时特别顺手——改完刷新页面，点一下插件，确认Title字数没超、Description没被截断、OG标签同步更新了。三步操作不超过10秒。
插件看的是渲染后的DOM，不是源HTML。如果你的TDK是JavaScript动态插入的（比如React/Vue的SPA页面），插件能看到但搜索引擎爬虫看不到。这种场景下插件检测结果≠实际SEO效果，必须查看网页源代码确认。
四、Screaming Frog：几千个页面的TDK批量检测，半小时跑完
如果你要检测的页面超过100个，Screaming Frog SEO Spider是绕不开的工具。免费版支持500个URL，付费版不限数量。它不是专门做TDK的，但因为它是全站爬虫，跑完一遍网站之后，Title、Description、Keywords的数据天然就在报表里。
具体怎么用：把网站首页URL输入Screaming Frog，点Start，等它爬完。然后在顶部菜单切到"Page Titles"标签页，你会看到所有页面的Title列表，并且自动标注了：Missing（缺失）、Duplicate（重复）、Over 60 Characters（超过60字符）、Below 30 Characters（少于30字符）、Same as H1（与H1相同）等状态。Description同理，切到"Meta Description"标签页就能看到缺失/重复/超长/过短的标注。
Screaming Frog的TDK检测能一键回答的问题：
· 全站有多少个页面Title为空？→ 点"Missing"筛选，数量直接显示在右下角
· 多少个页面Title重复？→ 点"Duplicate"，按Title排序，相同Title的页面排在一起
· 哪些页面Description超长？→ "Over 160 Characters"筛选，导出Excel
· 哪些页面Description太短？→ "Below 70 Characters"筛选，批量标注
· 每个页面的Title像素宽度是多少？→ 内置Pixel Width列，Google截断阈值约600px
更关键的是Screaming Frog支持导出全量数据为Excel。跑完后把所有页面的URL、Title、Description、Keywords、H1、字符数、像素宽度一起导出，然后用Excel的筛选和条件格式快速定位问题页面。Title列为空的标红、Description重复的标黄、长度超标的标橙——十分钟能梳理完几千条数据。
如果你是管多个站点的，可以建一个Excel总表，把每个站Screaming Frog导出的TDK问题汇总到一张表里：站点A缺失Title 12个、站点B重复Description 35个、站点C Title超长 8个。这样一眼看出哪个站TDK问题最严重，优先排期修复。
五、Python脚本：几十个站同时跑，三行代码批量抓TDK
在线工具和爬虫软件解决的是单个站内部的TDK检测。但如果你是做站群的，几十个域名要同时检测，一个一个用Screaming Frog跑效率还是低。Python脚本可以一次把所有域名丢进去，自动遍历每个站的关键页面抓TDK，输出一个总表。
import requestsfrom bs4 import BeautifulSoupimport pandas as pdurls = ["https://site1.com", "https://site2.com", "https://site3.com"] # 替换成你的站点列表results = []for url in urls:try:r = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=10)soup = BeautifulSoup(r.text, "html.parser")title = soup.title.string if soup.title else "MISSING"desc = soup.find("meta", attrs={"name": "description"})desc = desc["content"] if desc else "MISSING"kw = soup.find("meta", attrs={"name": "keywords"})kw = kw["content"] if kw else "MISSING"results.append({"url": url,"title": title,"title_len": len(title),"description": desc,"desc_len": len(desc),"keywords": kw,"kw_count": len(kw.split(",")) if kw != "MISSING" else 0})except Exception as e:results.append({"url": url, "title": f"ERROR: {e}", "title_len": 0, "description": "", "desc_len": 0, "keywords": "", "kw_count": 0})df = pd.DataFrame(results)df.to_excel("tdk_batch_report.xlsx", index=False)print(f"检测完成，共{len(results)}个站点，结果已导出到 tdk_batch_report.xlsx")这段脚本做的事情很直接：遍历URL列表→请求每个首页→提取Title/Description/Keywords→计算长度→输出Excel。跑完一个30个站的列表大概两三分钟。
脚本方案的限制：
· 上面这个脚本只抓首页TDK，如果你要抓每个站内所有内页，需要配合sitemap或爬虫逻辑
· JavaScript渲染的页面（SPA）用requests抓不到，得换Selenium或Playwright
· 部分网站有反爬机制（Cloudflare、验证码），需要加cookie或调整请求头
· 编码问题——有些老网站用GBK编码，BeautifulSoup自动检测可能出错，需要手动指定
如果站点数量在50个以上、且每个站都需要检查多个内页，建议把脚本扩展一下：先读取每个站的sitemap.xml拿到所有URL，再批量抓TDK，最后按站点分组输出多张Sheet。这样一次跑完所有站点，Excel里每个站点一个Sheet页，方便横向对比。
六、TDK检测结果出来后，怎么排修复优先级
检测只是第一步。真正有价值的是根据检测结果排出修复顺序——不可能一次性把所有问题都改了，得知道先改哪个、后改哪个。
| 优先级 | 问题类型 | 影响程度 | 修复建议 |
|---|---|---|---|
| P0 | Title缺失 | 搜索引擎无法判断页面主题，排名严重受损 | 立即补全，当天完成 |
| P0 | Title重复 | 多个页面竞争同一关键词，内部消耗排名 | 逐一差异化，本周完成 |
| P1 | Title超长被截断 | 搜索结果展示不全，点击率下降 | 精简到35字以内 |
| P1 | Description缺失 | 搜索引擎自动摘取摘要，效果不可控 | 重点页面优先补全 |
| P2 | Description重复 | 搜索结果摘要雷同，用户体验差 | 批量差异化，按月排期 |
| P2 | Description超长 | 超出部分被截断，但不影响排名 | 有空就改，控制在160字内 |
| P3 | Keywords堆砌 | 百度已不参考，对SEO无实质影响 | 顺手清理即可，不必专门排期 |
有个经验法则：Title的问题优先级永远高于Description，Description的问题优先级永远高于Keywords。因为Title直接影响排名和点击，Description只影响点击，Keywords基本没影响。
还有一个容易被忽略的角度：不是所有页面的TDK都需要花同样精力去优化。把页面分成三类来排优先级：核心转化页面（产品页、落地页）→ TDK要精雕细琢，每个词都值得斟酌；内容聚合页面（列表页、分类页）→ 保证不缺失、不重复即可；长尾内容页面（博客、资讯）→ 用模板批量生成，控制长度和唯一性。这样精力分配最合理。
七、站群场景：多站TDK的四个常见坑
单站TDK检测和站群TDK检测，难度不在一个量级。站群场景有几个特别容易踩的坑：
坑一：所有站用同一套TDK模板，改个公司名就上线
"XX地区装修公司|XX装修报价|XX装修哪家好"——把城市名一换，20个站全用这个Title模板。Screaming Frog一跑，每个站内部Title可能是唯一的，但20个站之间的Title结构一模一样。搜索引擎的反作弊系统对跨站TDK模式匹配的敏感度在持续提高。建议每个站的Title采用不同的句式结构，而不是简单的变量替换。
坑二：Description直接从第一段复制粘贴
很多CMS默认把文章第一段当Description，导致Description和正文开头一模一样。搜索引擎虽然不惩罚这个，但浪费了一次差异化展示的机会。Description应该是一段独立撰写的、吸引点击的摘要，不是正文的机械截取。
坑三：只查首页TDK，不管内页
一个站真正的流量入口往往是内页——长尾关键词排上来的是具体文章页、产品详情页，不是首页。如果只检测首页TDK而放任几百个内页Title缺失或重复，等于把80%的SEO机会扔掉了。批量检测一定要覆盖全站页面，至少覆盖sitemap里的所有URL。
坑四：改了TDK之后不追踪效果
很多人检测完、改完TDK就结束了，过两个月才发现排名没变化。TDK修改后的效果需要持续追踪：改Title后关键词排名有没有变化？改Description后点击率有没有提升？建议建一个TDK修改日志，记录每次修改的时间、页面、改动内容，然后对比修改前后7天、30天的排名和点击数据。
站群场景的TDK管理，核心难点在于量。一个站几百个页面要检查，20个站就是几千个页面。所以工具选型和流程设计比单个TDK的写法更重要——你要想的不是"这个页面Title怎么写"，而是"怎么让2000个页面的Title不出问题"。
八、把TDK检测变成持续监控，而不是一次性项目
TDK检测最大的误区是把它当成一次性工作——"我今天把所有站TDK查一遍，改完就完事了"。但实际上，每次新增页面、每次修改模板、每次批量发布内容，都可能引入新的TDK问题。
比较务实的做法是建一个定期巡检流程：
每周
新增页面TDK
本周发布的新页面，跑一遍插件或脚本确认TDK不缺失、不超长
每月
全站TDK巡检
Screaming Frog全站爬一遍，导出报表检查Title/Description缺失和重复
每季度
TDK策略复盘
分析TDK修改前后的排名和点击率变化，优化Title写法策略
如果你在用UC建站系统管理多个站点，这套流程可以更自动化一些。UC的多站看板本身就监控着每个站的索引量和排名波动，把TDK检测的结果关联进去：某个站突然掉索引了，先跑一遍TDK检测，看是不是最近批量发布的页面Title大面积重复导致的。TDK问题导致索引异常的情况比想象中多，但因为是基础配置，很容易被忽略。
不同规模的TDK检测方案怎么选
| 规模 | 推荐工具组合 | 预估耗时 |
|---|---|---|
| 1-3个站，单站100页内 | 在线工具（测罗/聚查）单页+批量 | 1-2小时 |
| 1-3个站，单站500页以上 | Screaming Frog全站爬取+Excel分析 | 半天 |
| 5-20个站，中小规模 | Python脚本批量抓首页 + Screaming Frog抽检重点站 | 1天 |
| 20个站以上，大规模站群 | Python脚本+UC多站看板+定时巡检SOP | 脚本自动化，人工复核2-3天 |
说穿了，TDK检测这件事不复杂——提取Title、Description、Keywords，比长度、比重复、标缺失。但它的价值在于持续做。一个站TDK全部合规可能看不出明显效果，但一个站有20%的页面Title缺失、30%的页面Description重复，搜索引擎对你网站的质量判断一定会打折。TDK是SEO里最基础的地基，地基不牢，上面再花哨的策略都站不稳。
