一个客户曾给我发来一个被"专业代理商 SEO 优化了 18 个月"的网站。排名停滞不前。流量同比下降。代理商的报告有 47 页，其中包括"品牌语音一致性"的部分。它没有包括的是 3,400 个页面返回 200 状态码但元标签中嵌入了 noindex 标记。三千五百个页面。消失了。不可见。代理商从未真正爬过该网站。
我在一周内修复了它。使用 Screaming Frog 和 Google Search Console。
技术性 SEO 的妙处在于——它奖励那些真正查看数据而不是谈论数据的人。老实说，对于我通过 Seahawk 审计的 90% 的网站，我不需要 Ahrefs、Semrush 或任何大型平台来找到真正影响性能的问题。两个工具。一个流程。就是这样。Seahawk, I don't need Ahrefs, Semrush, or any of the big platforms to find the problems that are genuinely hurting performance. Two tools. One process. Here it is.
---
爬取任何东西之前，正确设置 Screaming Frog
大多数人打开 Screaming Frog，粘贴一个 URL，然后点击开始。对于 50 页的博客来说还不错。但对于更大的网站，你要等 40 分钟才能得到错误的数据。
配置比爬取速度更重要
我做的第一件事是进入 Configuration > Spider，确保我爬取的是正确的协议。如果网站使用 HTTPS（应该这样），我从规范的 HTTPS 主页开始。我还会关闭某些文件类型的爬取——PDF、图像、视频——除非我特别想审计那些。这样可以将爬取时间减半。Configuration > Spider and make sure I'm crawling the correct protocol. If the site is on HTTPS (it should be), I'm starting from the canonical HTTPS homepage. I also turn off crawling of certain file types — PDFs, images, videos — unless I specifically want to audit those. It halves the crawl time.
然后我将 Configuration > Respect Canonical Tags 设置为关闭。我知道这有点反直觉。但我想看到每个规范化的 URL，这样我可以审计规范化是否真的正确。如果 Screaming Frog 跳过规范化的页面，你永远不会知道它们存在。Configuration > Respect Canonical Tags to off. Counter-intuitive, I know. But I want to see every canonicalised URL so I can audit whether the canonicalisation is actually correct. If Screaming Frog skips canonicalised pages, you'll never know they exist.
还有一件事：在 Configuration > Custom Extraction 下，我设置了一个提取规则，直接从 HTML 源代码中提取原始 <title> 和 meta description。为什么？因为一些 WordPress 网站——特别是同时运行 Yoast 和页面构建器的网站——会输出两个 title 标签。Screaming Frog 的默认列只显示第一个。提取规则会显示所有内容。Configuration > Custom Extraction, I set up an extraction rule to pull the raw <title> and meta description directly from the HTML source. Why? Because some WordPress sites — particularly ones running Yoast alongside a page builder — output two title tags. Screaming Frog's default column only shows you the first one. The extraction rule shows you everything.
---
第一遍：我在爬取数据中查找的内容
爬取完成后，我不会从损坏的链接开始。每个人都从损坏的链接开始。我从 Response Codes 标签开始，筛选 3xx 重定向。Response Codes tab and filter for 3xx redirects.
早在 2021 年，Seahawk 接手了一个电商客户——中型家具零售商，约 8,000 个 URL。他们的开发团队已经临时处理重定向两年了。我们发现了 19 条重定向链，其中一些长达四跳。页面 A 重定向到页面 B，页面 B 重定向到页面 C，页面 C 重定向到页面 D。Google 说它可以跟踪多达 10 跳，但在实际操作中，超过两跳会浪费爬取预算并稀释链接权益。我们将所有内容简化为单跳重定向。仅这一点——没有内容更改，没有链接建设——就在六周内将三个类别页面从第 3 页移到了第 1 页。Google says it follows up to 10 hops, but in practice, anything beyond two hops wastes crawl budget and dilutes link equity. We collapsed everything to single-hop redirects. That alone — no content changes, no link building — moved three category pages from page 3 to page 1 within six weeks.
我处理标签的顺序
- 响应代码 → 3xx — 重定向链和循环 — redirect chains and loops
- 响应代码 → 4xx — 损坏的页面（按内链数量过滤以优先处理） — broken pages (filter by inlinks to prioritise)
- 可索引性 → 不可索引 — noindex、指向其他位置的规范标签、被robots.txt阻止 — noindex, canonicals pointing elsewhere, blocked by robots.txt
- 页面标题 — 缺失、重复、超过60个字符 — missing, duplicated, over 60 characters
- 元描述 — 缺失或重复（不是排名因素，但点击率很重要） — missing or duplicated (not a ranking factor, but click-through matters)
- H1 — 缺失、重复或每页多于一个 — missing, duplicated, or more than one per page
- 图片 → 缺失Alt文本 — 快速优化项，特别是对产品网站 — quick win, especially for product sites
- 指令 → 规范标签 — 检查这些是否与实际可索引URL匹配 — check these match the actual indexable URL
这个顺序是有意的。我从结构问题（重定向、损坏的页面）开始，然后到页面内问题。修复一条损坏的重定向链会帮助该链中的每个页面。修复一个缺失的元描述只能帮助一个页面。
---
在Search Console中分层：有趣的地方开始了
Screaming Frog告诉你网站上有什么。Search Console告诉你Google认为网站上有什么。这两个数据集之间的差距就是真正的问题所在。
打开Coverage（或在新界面中的Indexing → Pages）。你要查看四件事：Coverage (or Indexing → Pages in the newer interface). You're looking at four things:
- Error — Google尝试索引但失败的页面 — pages Google tried to index and couldn't
- Valid with warnings — 通常是"Submitted URL not selected as canonical"，这是你需要理顺的混乱局面 — often "Submitted URL not selected as canonical," which is a mess you need to untangle
- Excluded — Google选择不索引的页面（已抓取但未索引、noindexed等） — pages Google chose not to index (crawled but not indexed, noindexed, etc.)
- Valid — Google已索引的页面 — pages Google has indexed
"Excluded"这个类别被严重低估了。大多数人忽视它。我直接去那里。按"Crawled — currently not indexed"筛选。这是Google在说：我找到了这个页面，我读过了，我决定它不值得索引。这几乎总是内容单薄的问题。或者是一个本身不错但与另一个页面太相似的页面——这是分面导航或标签归档的典型问题。I found this page, I read it, and I decided it wasn't worth indexing. That's almost always a thin content problem. Or it's a page that's genuinely fine but is too similar to another page — a classic issue with faceted navigation or tag archives.
将GSC排除与你的Screaming Frog抓取相对应
将你的Screaming Frog抓取导出为CSV。从Search Console导出"Excluded"网址。将两者加载到Google Sheets中并运行VLOOKUP。任何出现在Screaming Frog抓取中且出现在GSC排除列表中的网址都是优先调查对象。and in the GSC excluded list is a priority investigation.
我知道人们会为此编写Python脚本。但你不需要。Sheets中的VLOOKUP只需四分钟，能给你同样的答案。
---
爬虫预算：只有在你的网站真正很大时才重要
好吧，说实话吧。如果你的网站页面数少于1,000个，爬虫预算不是你的问题。你可以停止担心这件事了。
但一旦你超过大约10,000个URL——很多WooCommerce或Magento商店仅因为产品变体和过滤URL就会达到这个数字——爬虫预算就开始产生影响。Google Search Central关于爬虫预算的文档实际上是他们写过最清楚的内容之一。值得认真阅读。Google Search Central documentation on crawl budget is actually one of the clearer things they've written. Worth reading properly.
你在Search Console中有两个控制杆：爬虫统计报告和URL检查工具。爬虫统计显示Google在90天内的爬虫活动：每天爬取的页面数、响应时间、响应代码。如果你在某个特定日期看到404错误激增，那是部署出了问题。如果平均爬虫响应时间超过2秒，问题在你的服务器，不在你的SEO。Crawl Stats report and the URL Inspection tool. Crawl Stats shows you Google's crawl activity over 90 days: pages crawled per day, response times, response codes. If you see a spike in 404s on a specific date, that's a deployment that went wrong. If average crawl time is above 2 seconds, your server is the problem, not your SEO.
---
内部链接：代理商总是忽视的东西
我在Seahawk为超过一百个网站做过审计，这些客户花了真金白银在链接建设上——访客文章、数字PR等等——但却有孤立页面，没有内部链接指向它们。Google无法优先考虑它无法通过你的网站结构找到的东西。orphaned pages that no internal link pointed to. Google can't prioritise what it can't find through your site structure.
在Screaming Frog中，按Inlinks = 0过滤爬虫结果。任何没有内部链接的页面都是孤立页面。将其与Search Console的索引页面交叉参考。如果该页面已被索引但没有内部链接，这意味着Google是通过XML网站地图或外部反向链接找到它的。这很脆弱。从一个相关页面给它添加一个内部链接，你就是在向Google传递一个结构信号，表明这个页面很重要。Inlinks = 0. Any page with zero internal links is an orphan. Cross-reference it against Search Console's indexed pages. If the page is indexed but has no internal links, it means Google found it through an XML sitemap or an external backlink. That's fragile. Give it an internal link from a relevant page and you're giving Google a structural signal that this page matters.
我注意到的内部链接的几个问题
- 分页页面链接到产品/文章页面，但这些页面没有链接回分类页面
- 2019年发布的博客文章从未被任何较新的内容链接过
- 有大量入站内部链接但在GSC中流量很低的页面——通常表示页面本身有问题，而不是链接问题
---
Core Web Vitals：读懂数据，别慌张
Search Console有一个Core Web Vitals报告。它来自真实用户Chrome UX Report数据，这是字段数据——实际用户在实际设备上的行为，而不是实验室模拟。这比单次Lighthouse运行的结果更有意义。Core Web Vitals report. It pulls from real-user Chrome UX Report data, which is field data — actual users on actual devices, not a lab simulation. This is more meaningful than what you'd get from a one-off Lighthouse run.
报告根据LCP、FID（现已被INP取代）和CLS将URL分组为"良好"、"需要改进"和"差"三类。不要试图一次性修复所有问题。按"差"组排序，看哪个URL模式有最多失败的页面。通常是单个模板——所有产品页面CLS失败，或所有分类页面LCP缓慢。修复模板，一次性修复数百个页面。
我辛苦学到的一件事：有广告或cookie横幅的网站上的CLS问题几乎总是来自于首屏后初始绘制后注入的元素。Screaming Frog抓不到这个。你需要看实际的页面。在Chrome DevTools中启用Rendering里的Layout Shift regions。
---
Robots.txt 和网站地图检查（耗时 10 分钟，节省数周）
访问 yourdomain.com/robots.txt 。逐行阅读。我亲眼见过一个运营中的生产网站在 robots.txt 中设置了 Disallow: / 。不是测试网站。是生产网站。一个运营了七年的企业。他们的开发者在迁移时复制了测试环境的 robots.txt，之后再也没有检查过。在他们发现问题之前，这个网站已经对谷歌基本不可见了四个月。yourdomain.com/robots.txt . Read every line. I have seen, with my own eyes, a live production site with Disallow: / in the robots.txt. Not a staging site. Production. A seven-year-old business. Their developer had copied the staging robots.txt during a migration and never checked it. They had been essentially invisible to Google for four months before they noticed.
在 Search Console 中，进入网站地图。检查已提交的内容。检查谷歌上次抓取的时间。如果网站地图在超过一周内没有被抓取，说明出了问题。同时比较已提交的网址数量与已索引的网址数量——如果你提交了 4,000 个网址，但只有 1,200 个被索引，那你需要讨论的是内容质量问题，而不是技术问题。Sitemaps. Check what's been submitted. Check the last time Google fetched it. If the sitemap hasn't been fetched in over a week, something is broken. Also check the submitted URL count vs the indexed URL count — if you've submitted 4,000 URLs and only 1,200 are indexed, that's a conversation you need to have about content quality, not about technical fixes.
---
常见问题
我需要购买付费版本的 Screaming Frog 吗？
免费版本的上限是 500 个网址。对于超过这个数量的网站——大多数值得审计的网站都会超过——你需要付费许可证。截至编写时，价格是每年 £259。相当于一个小时的代理服务费用。买吧。£259 per year as of writing. That's about the price of a single hour of agency time. Buy it.
我应该多久运行一次技术审计？
对于定期发布内容或产品频繁变化的活跃网站，我建议每季度一次。对于较小的、更新较少的网站，一年两次就可以了。运行一次审计然后把它当作"完成"，就像给汽车换一次油然后期待它永远正常运转一样。
Screaming Frog 显示状态码 200，但谷歌搜索控制台显示该页面未被索引——为什么？
几乎总是这三种情况之一：noindex meta标签、noindex HTTP响应头，或指向其他地方的canonical标签。在Search Console的URL检查工具中运行该URL，它会告诉你确切发现了什么。这个工具被严重低估了——它显示Google最后一次爬取的页面版本，包括渲染后的HTML，这能捕捉JavaScript注入的noindex标签，而基本的HTTP请求无法看到。last crawled version of the page, including the rendered HTML, which catches JavaScript-injected noindex tags that a basic HTTP request wouldn't see.
那JavaScript渲染的网站呢？
Screaming Frog在Configuration > Spider > Rendering下有JavaScript渲染模式。对于JS繁重的网站，把它打开。它会慢很多——慢得很厉害——但这是捕捉初始HTML加载后由JavaScript注入的内容或链接问题的唯一办法。对于React或Next.js网站，始终在JS渲染模式下爬取。Configuration > Spider > Rendering. Turn it on for JS-heavy sites. It's slower — significantly slower — but it's the only way to catch issues with content or links that are injected by JavaScript after the initial HTML loads. For a React or Next.js site, always crawl in JS rendering mode.
Google Search Console对关键词研究够用吗？
要找你现有页面排名的查询词，是的，它很好用。要发现新的关键词机会，不够——你需要其他工具。但那超出了技术审计的范围。existing pages rank for, yes, it's excellent. For discovering new keyword opportunities, no — you'll need something else. But that's out of scope for a technical audit.
---
两个工具。一个电子表格。几个小时。这真的就是全部了。昂贵的平台有其用处——我不反对它们——但我见过太多网站所有者假设花更多钱意味着发现更多。问题几乎总是出在基础部分。他们只需要有人真正去看看。