[{"data":1,"prerenderedAt":809},["ShallowReactive",2],{"blog-log-analysis-tool-choice":3,"blog-prev-log-analysis-tool-choice":98,"blog-next-log-analysis-tool-choice":193},{"id":4,"title":5,"author":6,"body":7,"canonical":82,"category":83,"cover":82,"date":84,"description":85,"draft":86,"extension":87,"keywords":82,"meta":88,"navigation":89,"noindex":86,"ogImage":82,"path":90,"seo":91,"seoDescription":82,"seoTitle":82,"stem":92,"tags":93,"updated":82,"__hash__":97},"blog\u002Fblog\u002Flog-analysis-tool-choice.md","日志分析工具选型：小站别买贵的那套","元析智能",{"type":8,"value":9,"toc":72},"minimark",[10,14,19,22,25,29,32,35,38,42,45,48,51,54,57,60,63,66,69],[11,12,13],"p",{},"日志分析工具的价格差距很大，从零成本到一个月几百美元都有。选错的代价不是钱，是数据没人看。我们的判断标准只有一个：你的站每天多少行日志。按这个分三档，基本不会选错。",[15,16,18],"h2",{"id":17},"一天一万行以下命令行就够","一天一万行以下：命令行就够",[11,20,21],{},"这个量级用 awk 加 grep 就能解决。筛出 Googlebot 和百度蜘蛛的请求，按路径统计次数，按状态码分布看一眼，二十分钟出结果。",[11,23,24],{},"写成一个脚本存下来，以后每次跑同一条命令。小站做日志分析的目的通常只有两个：确认蜘蛛来没来、看哪些页面被抓得多。这两个问题不值得买工具。",[15,26,28],{"id":27},"十万到一百万行goaccess-或桌面工具","十万到一百万行：GoAccess 或桌面工具",[11,30,31],{},"GoAccess 是开源的，命令行跑完直接输出一个 HTML 报表，状态码、路径、UA、时间分布都有。它的优点是快，一百万行几分钟跑完。",[11,33,34],{},"Screaming Frog 的日志分析模块更长于 SEO 视角的解读，能把日志和爬取结果对上，看蜘蛛抓的页面和站内实际页面差多少。缺点是贵，而且大文件要预处理。",[11,36,37],{},"我们现在的做法是两者都用：GoAccess 看整体分布，桌面工具看具体页面对不上在哪。",[15,39,41],{"id":40},"一百万行以上上云端","一百万行以上：上云端",[11,43,44],{},"这个量级本地方案开始吃力，几十 G 的文件解压、合并、查询都要等。云端日志服务按量计费，写完 SQL 就能查，还能做看板。",[11,46,47],{},"一个客户每天 80 万行日志，用云端方案一个月两百美元左右。听着不便宜，但比养一个人天天导数据便宜。",[15,49,50],{"id":50},"预处理比工具重要",[11,52,53],{},"多台服务器的日志要先合并，时区统一到东八区，压缩包先解开，蜘蛛 UA 要先筛出来。这一步不做，什么工具都白搭。",[15,55,56],{"id":56},"一个更实际的做法",[11,58,59],{},"2025 年 12 月我们停掉了所有付费日志看板，改成每个月第一周跑一次固定脚本，输出一份 3 页的 PDF，直接发给客户。里面的内容就四块：蜘蛛请求量趋势、路径分布前 20、状态码分布、和上月的对比。",[11,61,62],{},"客户不看后台，他们看结论。你把一个可交互的看板给他，他打开两次就不看了。一份 3 页的 PDF 反而每次都有人读。",[11,64,65],{},"我们写了一个预处理脚本，输入原始 access.log，输出只含蜘蛛请求的 CSV，附带时间、路径、状态码、UA。后面换什么工具都能直接用。",[15,67,68],{"id":68},"我的立场",[11,70,71],{},"别为了看蜘蛛抓了多少买一套 BI。日志分析是诊断动作，不是日常报表。一个月看一次够了，平时盯着 GSC 的抓取统计就行。工具越重，越容易变成买了不用。",{"title":73,"searchDepth":74,"depth":74,"links":75},"",2,[76,77,78,79,80,81],{"id":17,"depth":74,"text":18},{"id":27,"depth":74,"text":28},{"id":40,"depth":74,"text":41},{"id":50,"depth":74,"text":50},{"id":56,"depth":74,"text":56},{"id":68,"depth":74,"text":68},null,"工具评测","2026-01-27","每天 80 万行日志，云端方案一个月两百美元，本地方案零成本。这篇按日志量分三档给方案，写清 GoAccess、桌面工具和云端各自的适用边界。",false,"md",{},true,"\u002Fblog\u002Flog-analysis-tool-choice",{"title":5,"description":85},"blog\u002Flog-analysis-tool-choice",[94,95,96],"日志分析","工具选型","抓取","qJasfDliJpH3W69-Y8Q4bLS1t8h6rpg_VgiB3nBK8Rg",{"id":99,"title":100,"author":6,"body":101,"canonical":82,"category":181,"cover":82,"date":182,"description":183,"draft":86,"extension":87,"keywords":82,"meta":184,"navigation":89,"noindex":86,"ogImage":82,"path":185,"seo":186,"seoDescription":82,"seoTitle":82,"stem":187,"tags":188,"updated":82,"__hash__":192},"blog\u002Fblog\u002Findexnow-worth-it.md","IndexNow 值不值得接：我们接了 11 个站后的结论",{"type":8,"value":102,"toc":173},[103,106,109,112,115,118,122,125,128,131,134,137,140,143,146,149,152,155,158,161,164,167,170],[11,104,105],{},"IndexNow 值得接，但它只解决\"发现\"，不解决\"收录\"，更不影响百度。我们 11 个站接了大半年，Bing 的抓取时间从平均 26 小时降到 4 小时，Google 和百度的数据没有任何变化。2025 年 7 月接入，到现在跟了大半年。",[15,107,108],{"id":108},"它到底解决什么问题",[11,110,111],{},"IndexNow 是一个推 URL 的协议，站点主动告诉搜索引擎\"这个页面变了\"，搜索引擎不用等 sitemap 或者爬虫周期。",[11,113,114],{},"支持它的是 Bing、Yandex、Naver、Seznam 这几家。Google 2021 年参与过讨论，后来明确没采用；百度也没接。所以它的作用范围很窄，只对 Bing 系有效。",[11,116,117],{},"理解这一点很重要：它不是\"收录加速器\"，是\"发现加速器\"。页面被发现了，收不收还是搜索引擎自己的判断。",[15,119,121],{"id":120},"我们-11-个站的实际数据","我们 11 个站的实际数据",[11,123,124],{},"接入前，新页面被 Bing 抓到的平均时间是 26 小时；接入后 4 小时。这个提升在英文站上最明显，中文站大概是 18 小时降到 6 小时，因为 Bing 对中文站的抓取本来就慢。",[11,126,127],{},"收录率的变化不大：接入前 100 个新页面 30 天内收录 62 个，接入后 64 个。涨了 2 个点，可以说基本没变。",[11,129,130],{},"所以别指望它解决收录问题。今年 1 月我们专门抽了一个站做对照，100 个页面里主动推和不推各 50 个，30 天收录数只差 3 个。它解决的是\"发布当天就要被看到\"的需求，比如版本发布、活动页、新闻稿。",[15,132,133],{"id":133},"什么情况下没用",[11,135,136],{},"内容本身不行。被抓和收录是两回事，页面质量差的，抓得再快也不会收。",[11,138,139],{},"页面被 robots 屏蔽，或者返回 4xx，推了也白推。我们有个客户推了两周没反应，查出来是测试环境的 robots.txt 没删。",[11,141,142],{},"站点验证失败。Bing 后台验证不过，IndexNow 的 key 校验也会失败。这种情况先修验证，别怀疑协议。",[15,144,145],{"id":145},"怎么接",[11,147,148],{},"三步。第一步，在站点根目录放一个 key 文件，文件名就是 key 本身。第二步，提交一次批量请求，把现有 URL 推一遍。第三步，在发布流程里加一个 POST，新页面生成时自动推。",[11,150,151],{},"请求体是 JSON：host、key、keyLocation、urlList。一次最多 10000 条，我们一般一次推 1 到 20 条，发布即推。",[11,153,154],{},"Hugo、WordPress 都有现成插件，自建站写 20 行脚本。我们所有站都接在发布流程里，人工零操作。",[15,156,157],{"id":157},"我们踩过的一个坑",[11,159,160],{},"有个客户把 IndexNow 当成万能药，页面质量没改，只推 URL。推了一个月，Bing 的抓取是快了，收录没涨，排名也没动。这件事说明协议解决不了内容问题。",[11,162,163],{},"还有一次 key 文件放错目录，推了 200 条全部失败，日志里只有一行 403，查了一下午。现在我们的脚本会先自检 key 文件能不能访问，再推。",[15,165,166],{"id":166},"结论",[11,168,169],{},"如果你的客户或产品在 Bing 上有曝光需求，接，成本低。如果只做百度和国内，不用接，它帮不上忙。",[11,171,172],{},"我们接它的真实原因不是 SEO 效果，是省事：版本发布后不用等人手动提交，也不用担心 sitemap 延迟。这件事的价值在流程，不在排名。",{"title":73,"searchDepth":74,"depth":74,"links":174},[175,176,177,178,179,180],{"id":108,"depth":74,"text":108},{"id":120,"depth":74,"text":121},{"id":133,"depth":74,"text":133},{"id":145,"depth":74,"text":145},{"id":157,"depth":74,"text":157},{"id":166,"depth":74,"text":166},"技术SEO","2026-01-26","IndexNow 值得接，但它只解决“发现”，不解决“收录”，更不影响百度和 Google。我们 11 个站从 2025 年 7 月接起，Bing 抓取时间从 26 小时降到 4 小时，百度数据没任何变化。接法和无效场景都写了，如果你只做国内，看完能省下两小时接它的时间。",{},"\u002Fblog\u002Findexnow-worth-it",{"title":100,"description":183},"blog\u002Findexnow-worth-it",[189,190,191],"IndexNow","Bing","收录","w3rBRelrE_Kh3ytP1qV5E9KYrMAyuuVhF4Rr9u4WK9k",{"id":194,"title":195,"author":6,"body":196,"canonical":82,"category":797,"cover":82,"date":798,"description":799,"draft":86,"extension":87,"keywords":82,"meta":800,"navigation":89,"noindex":86,"ogImage":82,"path":801,"seo":802,"seoDescription":82,"seoTitle":82,"stem":803,"tags":804,"updated":82,"__hash__":808},"blog\u002Fblog\u002Fseo-technical-audit-checklist.md","软件公司 SEO 技术检查清单:15 个常见问题",{"type":8,"value":197,"toc":766},[198,201,205,208,213,241,245,273,277,297,301,304,308,343,347,373,377,400,404,423,427,430,434,461,465,485,489,513,517,520,524,579,583,602,606,609,613,659,663,682,686,705,708,711,714,717,720,723,726,731,734,739,742,747,750,755,758,763],[11,199,200],{},"软件公司的站技术问题特别多,因为产品页经常是 SPA(单页应用),文档站结构复杂,动态参数一堆。技术问题不修,内容做得再好也排不上去——搜索引擎根本抓不到。这份清单列我们诊断时最常见的 15 个技术 SEO 问题,按类分组,每条写清楚查什么、怎么查、怎么修。照着过一遍,基本能覆盖软件公司站的主要技术坑。",[15,202,204],{"id":203},"一渲染问题spassr","一、渲染问题(SPA\u002FSSR)",[11,206,207],{},"软件公司最常踩的坑。React、Vue 做的 SPA,默认客户端渲染,搜索引擎抓到的是空 HTML。",[209,210,212],"h3",{"id":211},"_1-spa-客户端渲染内容抓不到","1. SPA 客户端渲染,内容抓不到",[214,215,216,224,235],"ul",{},[217,218,219,223],"li",{},[220,221,222],"strong",{},"查什么",":页面内容是不是 JS 执行后才出现",[217,225,226,229,230,234],{},[220,227,228],{},"怎么查",":用 Google Search Console 的\"网址检查\"工具,看\"已呈现的页面\"。或者直接 ",[231,232,233],"code",{},"curl"," 你的页面 URL,看返回的 HTML 里有没有正文内容。如果 HTML 是空的壳子,内容全靠 JS 填,就是这个问题",[217,236,237,240],{},[220,238,239],{},"怎么修",":改成 SSR(服务端渲染)或 SSG(静态生成)。React 用 Next.js,Vue 用 Nuxt.js。如果改造成本高,至少把首屏内容和 SEO 关键内容做服务端渲染",[209,242,244],{"id":243},"_2-js-和-css-资源被-robots-屏蔽","2. JS 和 CSS 资源被 robots 屏蔽",[214,246,247,255,268],{},[217,248,249,251,254],{},[220,250,222],{},[252,253],"robots",{},".txt 是不是屏了 \u002Fjs\u002F \u002Fassets\u002F 这类路径",[217,256,257,259,260,263,264,267],{},[220,258,228],{},":打开 ",[231,261,262],{},"yourdomain.com\u002Frobots.txt"," 看有没有 ",[231,265,266],{},"Disallow: \u002Fjs\u002F"," 之类的规则。再在 Google Search Console 的\"网址检查\"里看渲染是否完整",[217,269,270,272],{},[220,271,239],{},":搜索引擎现在需要执行 JS 才能渲染页面,JS 资源必须允许抓取。robots.txt 里删掉对 JS\u002FCSS 路径的 Disallow",[209,274,276],{"id":275},"_3-关键内容-js-动态加载延迟出现","3. 关键内容 JS 动态加载,延迟出现",[214,278,279,284,289],{},[217,280,281,283],{},[220,282,222],{},":重要内容(标题、正文、内链)是不是页面加载后通过 AJAX\u002F接口请求才填充",[217,285,286,288],{},[220,287,228],{},":禁用浏览器 JS,看页面还有多少内容。或者在 Google Search Console 看渲染快照,关键内容在不在",[217,290,291,293,296],{},[220,292,239],{},[294,295],"seo",{}," 关键内容(标题、正文、H1、内链)放进初始 HTML,不要靠 JS 异步加载。非关键内容(评论、推荐)可以异步",[15,298,300],{"id":299},"二收录问题","二、收录问题",[11,302,303],{},"收录是基础,页面没被收录,后面什么都谈不上。",[209,305,307],{"id":306},"_4-robotstxt-屏蔽了重要页面","4. robots.txt 屏蔽了重要页面",[214,309,310,317,334],{},[217,311,312,314,316],{},[220,313,222],{},[252,315],{},".txt 是不是误屏了文档站、博客、产品页",[217,318,319,321,322,325,326,329,330,333],{},[220,320,228],{},":看 ",[231,323,324],{},"robots.txt",",特别留意 ",[231,327,328],{},"Disallow: \u002F"," 这种全站屏蔽(测试环境漏改到生产是常见原因),以及 ",[231,331,332],{},"Disallow: \u002Fdocs\u002F"," 这种局部屏蔽",[217,335,336,338,339,342],{},[220,337,239],{},":删掉误加的 Disallow。测试环境用 ",[231,340,341],{},"noindex"," meta 标签或 HTTP 认证,不要用 robots.txt 屏蔽——robots.txt 屏蔽的页面搜索引擎还是会爬,只是不索引,而且会阻止发现内链",[209,344,346],{"id":345},"_5-误用-noindex","5. 误用 noindex",[214,348,349,357,365],{},[217,350,351,353,354,356],{},[220,352,222],{},":重要页面是不是被加了 ",[231,355,341],{}," meta 标签",[217,358,359,361,362,364],{},[220,360,228],{},":用 Screaming Frog 爬全站,筛 ",[231,363,341],{}," 页面。重点看产品页、文档页、博客文章有没有被误标",[217,366,367,369,370,372],{},[220,368,239],{},":去掉误加的 ",[231,371,341],{},"。常见原因:开发环境用了 noindex,上线忘改;CMS 模板默认 noindex 没改;某些插件自动加 noindex",[209,374,376],{"id":375},"_6-canonical-标签错误","6. canonical 标签错误",[214,378,379,387,395],{},[217,380,381,383,386],{},[220,382,222],{},[384,385],"canonical",{}," 标签指向对不对,有没有指向自己(等于没用)、指向错误页面、或者循环指向",[217,388,389,391,394],{},[220,390,228],{},[392,393],"screaming",{}," Frog 爬取,看每个页面的 canonical 指向。重点查:canonical 是不是指向自己(正常情况应该指向规范版,如果只有一个版本就指向自己,但有多个 URL 版本时要指向规范版),有没有指向 404 或错误页",[217,396,397,399],{},[220,398,239],{},":每个页面 canonical 指向它的规范 URL。分页、参数变体、移动版都要正确指向规范版。不要用 canonical 解决跨语言或跨设备问题,那是 hreflang 的事",[209,401,403],{"id":402},"_7-孤立页面没有内链指向","7. 孤立页面(没有内链指向)",[214,405,406,411,418],{},[217,407,408,410],{},[220,409,222],{},":站内有没有没有任何内链指向的页面",[217,412,413,415,417],{},[220,414,228],{},[392,416],{}," Frog 爬取后,看\"Inlinks\"为 0 的页面。这些页面搜索引擎很难发现,权重也传不进去",[217,419,420,422],{},[220,421,239],{},":给孤立页面加内链。从相关文章、分类页、面包屑导航链接过去。软件公司常见孤立页:旧版文档、特定版本的功能页、历史博客",[15,424,426],{"id":425},"三速度问题","三、速度问题",[11,428,429],{},"百度和 Google 都把速度作为排名因素。软件公司站 JS 重,速度问题尤其多。",[209,431,433],{"id":432},"_8-首屏加载慢lcp-超过-25-秒","8. 首屏加载慢(LCP 超过 2.5 秒)",[214,435,436,444,452],{},[217,437,438,440,443],{},[220,439,222],{},[441,442],"largest",{}," Contentful Paint(最大内容绘制)时间",[217,445,446,448,451],{},[220,447,228],{},[449,450],"google",{}," PageSpeed Insights 或 Lighthouse 跑一遍,看 LCP 数值。超过 2.5 秒就是差",[217,453,454,456,457,460],{},[220,455,239],{},":首屏内容服务端渲染,关键 CSS 内联,图片懒加载(但首屏图片不要懒加载),字体用 ",[231,458,459],{},"font-display: swap",",减少首屏 JS 阻塞",[209,462,464],{"id":463},"_9-js-包过大","9. JS 包过大",[214,466,467,472,480],{},[217,468,469,471],{},[220,470,222],{},":页面加载的 JS 体积",[217,473,474,476,479],{},[220,475,228],{},[477,478],"chrome",{}," DevTools 的 Network 面板,看 JS 资源总大小(传输后)。超过 500KB 就偏大了",[217,481,482,484],{},[220,483,239],{},":代码分割(code splitting),按路由懒加载,Tree shaking 去掉没用的依赖,把第三方库(分析、聊天)改成异步加载",[209,486,488],{"id":487},"_10-图片未优化","10. 图片未优化",[214,490,491,496,504],{},[217,492,493,495],{},[220,494,222],{},":图片体积和格式",[217,497,498,500,503],{},[220,499,228],{},[501,502],"page-speed",{}," Insights 会列出未优化的图片。或者手动看图片大小,单张超过 200KB 的要查",[217,505,506,508,509,512],{},[220,507,239],{},":用 WebP 或 AVIF 格式(比 JPEG\u002FPNG 小 30%-50%),图片压缩,设置合适的宽高属性(避免布局偏移),用 ",[231,510,511],{},"loading=\"lazy\""," 懒加载非首屏图片",[15,514,516],{"id":515},"四结构化数据","四、结构化数据",[11,518,519],{},"结构化数据帮搜索引擎理解你的内容,软件公司尤其要标 SoftwareApplication、FAQ、Article。",[209,521,523],{"id":522},"_11-没有任何-schemaorg-结构化数据","11. 没有任何 Schema.org 结构化数据",[214,525,526,531,542],{},[217,527,528,530],{},[220,529,222],{},":页面有没有结构化数据标记",[217,532,533,535,537,538,541],{},[220,534,228],{},[449,536],{}," Rich Results Test 工具,输入 URL 看有没有结构化数据。或者看页面源码有没有 ",[231,539,540],{},"application\u002Fld+json"," 的 script 标签",[217,543,544,546,547],{},[220,545,239],{},":软件公司至少标这几种:\n",[214,548,549,555,561,567,573],{},[217,550,551,554],{},[231,552,553],{},"SoftwareApplication",":产品页,标名称、描述、价格、评分",[217,556,557,560],{},[231,558,559],{},"FAQPage",":FAQ 内容页",[217,562,563,566],{},[231,564,565],{},"Article",":博客文章",[217,568,569,572],{},[231,570,571],{},"BreadcrumbList",":面包屑导航",[217,574,575,578],{},[231,576,577],{},"Organization",":关于页\u002F首页",[209,580,582],{"id":581},"_12-结构化数据错误或与页面内容不符","12. 结构化数据错误或与页面内容不符",[214,584,585,590,597],{},[217,586,587,589],{},[220,588,222],{},":结构化数据格式对不对,内容跟页面实际是不是一致",[217,591,592,594,596],{},[220,593,228],{},[449,595],{}," Search Console 的\"增强型报告\"会列出结构化数据错误。Rich Results Test 看具体警告",[217,598,599,601],{},[220,600,239],{},":常见错误——必填字段缺失(如 SoftwareApplication 缺 name)、数据对不上(标记了 rating 但页面没有评分组件)、嵌套层级错。按 Search Console 报的错误逐条修",[15,603,605],{"id":604},"五url-问题","五、URL 问题",[11,607,608],{},"URL 结构影响收录和权重传递,软件公司站尤其乱。",[209,610,612],{"id":611},"_13-url-不语义化","13. URL 不语义化",[214,614,615,623,640],{},[217,616,617,619,622],{},[220,618,222],{},[620,621],"url",{}," 是不是有意义的词,还是一串 ID",[217,624,625,627,628,631,632,635,636,639],{},[220,626,228],{},":看你的 URL 长什么样。",[231,629,630],{},"\u002Fproducts\u002Fcrm"," 是好的,",[231,633,634],{},"\u002Fp\u002F12345"," 或 ",[231,637,638],{},"\u002F?id=12345"," 是差的",[217,641,642,644,646,647,650,651,654,655,658],{},[220,643,239],{},[620,645],{}," 用语义化路径,包含关键词。产品页 ",[231,648,649],{},"\u002Fproducts\u002F产品名",",文档页 ",[231,652,653],{},"\u002Fdocs\u002F功能名",",博客 ",[231,656,657],{},"\u002Fblog\u002F文章标题","。改 URL 要做 301 重定向,旧 URL 权重传给新 URL",[209,660,662],{"id":661},"_14-url-参数导致重复内容","14. URL 参数导致重复内容",[214,664,665,670,677],{},[217,666,667,669],{},[220,668,222],{},":同一内容是不是有多个 URL 版本(参数不同)",[217,671,672,674,676],{},[220,673,228],{},[392,675],{}," Frog 爬取,看有没有大量 URL 只是参数不同但内容相同。常见:排序参数、筛选参数、追踪参数(utm)",[217,678,679,681],{},[220,680,239],{},":对参数 URL 用 canonical 指向规范版。或者用 Google Search Console 的\"网址参数\"工具告诉 Google 哪些参数不影响内容。追踪参数(utm_source 等)最好在服务端处理,不要让搜索引擎索引带参数的版本",[209,683,685],{"id":684},"_15-重定向链过长","15. 重定向链过长",[214,687,688,695,700],{},[217,689,690,692,694],{},[220,691,222],{},[620,693],{}," 是不是经过多次重定向才到最终页",[217,696,697,699],{},[220,698,228],{},":用 Redirect Checker 工具,或者 Screaming Frog 看\"重定向链\"。超过 2 次跳转就是问题",[217,701,702,704],{},[220,703,239],{},":把重定向链改成直接跳转。常见原因:HTTP → HTTPS → www → 非 www → 新 URL,层层跳。改成 HTTP 直接 301 到最终 URL。重定向链过长会浪费抓取预算,权重传递也会衰减",[15,706,707],{"id":707},"怎么用这份清单",[11,709,710],{},"建议按顺序过一遍:先解决渲染问题(第一类),这是基础,不解决后面都白搭。再查收录(第二类),确保该收录的页面都收录了。然后是速度和结构化数据(URL 问题随时修)。",[11,712,713],{},"每类查一遍大概半天到一天。全站完整技术审计我们一般用 2-3 天。这份清单是自查版,自己能上手查。如果查出来问题多,或者改不动(比如 SPA 改 SSR 工程量大),再找专业团队。",[15,715,716],{"id":716},"总结",[11,718,719],{},"软件公司站最常踩的 15 个技术 SEO 问题:渲染(SPA 客户端渲染、JS 被屏、内容异步加载)、收录(robots 误屏、noindex 误用、canonical 错、孤立页)、速度(LCP 慢、JS 大、图片没优化)、结构化数据(没有、有但错)、URL(不语义化、参数重复、重定向链长)。工具用 Google Search Console、Screaming Frog、PageSpeed Insights 这三个就够自查。",[11,721,722],{},"查出来问题不知道怎么改,联系我们聊聊。",[15,724,725],{"id":725},"常见问题",[11,727,728],{},[220,729,730],{},"Q: 自查需要什么工具?",[11,732,733],{},"A: 三个就够:Google Search Console(免费,看收录和抓取)、Screaming Frog(免费版能爬 500 个 URL,够小站用)、PageSpeed Insights(免费,看速度)。专业诊断还会用 Ahrefs Site Audit 或 Sitebulb,但自查上面三个够用。",[11,735,736],{},[220,737,738],{},"Q: SPA 一定要改 SSR 吗?",[11,740,741],{},"A: 几乎一定要。Google 现在能执行 JS 渲染,但有延迟,且不是所有 JS 内容都能抓到。百度对 JS 渲染支持更差。SPA 不改 SSR,SEO 效果会打很大折扣。如果 SSR 改造工程量太大,退一步用预渲染(prerender)也比纯客户端渲染强。",[11,743,744],{},[220,745,746],{},"Q: 技术问题修了多久见效?",[11,748,749],{},"A: 渲染和收录问题修了,一般 2-4 周搜索引擎重新抓取后开始见效。速度和结构化数据是慢功夫,1-2 个月体现在排名上。URL 改动要做 301,权重传递需要 1-3 个月。",[11,751,752],{},[220,753,754],{},"Q: robots.txt 和 noindex 有什么区别?",[11,756,757],{},"A: robots.txt 是告诉搜索引擎别爬这个 URL(但其实搜索引擎可能还是会爬,只是不索引,且会阻止发现内链)。noindex 是允许爬,但不索引。一般用 noindex 控制索引,robots.txt 只用来屏掉真正不想被抓的资源(如后台、API)。",[11,759,760],{},[220,761,762],{},"Q: 结构化数据对排名有影响吗?",[11,764,765],{},"A: 不直接影响排名,但影响展示效果。标了 FAQ 会有展开式结果,标了 BreadcrumbList 会有面包屑,标了 SoftwareApplication 会有价格等信息展示。展示效果好,点击率高,间接提升排名。Google 官方说结构化数据不是排名因素,但做了比不做好。",{"title":73,"searchDepth":74,"depth":74,"links":767},[768,774,780,785,789,794,795,796],{"id":203,"depth":74,"text":204,"children":769},[770,772,773],{"id":211,"depth":771,"text":212},3,{"id":243,"depth":771,"text":244},{"id":275,"depth":771,"text":276},{"id":299,"depth":74,"text":300,"children":775},[776,777,778,779],{"id":306,"depth":771,"text":307},{"id":345,"depth":771,"text":346},{"id":375,"depth":771,"text":376},{"id":402,"depth":771,"text":403},{"id":425,"depth":74,"text":426,"children":781},[782,783,784],{"id":432,"depth":771,"text":433},{"id":463,"depth":771,"text":464},{"id":487,"depth":771,"text":488},{"id":515,"depth":74,"text":516,"children":786},[787,788],{"id":522,"depth":771,"text":523},{"id":581,"depth":771,"text":582},{"id":604,"depth":74,"text":605,"children":790},[791,792,793],{"id":611,"depth":771,"text":612},{"id":661,"depth":771,"text":662},{"id":684,"depth":771,"text":685},{"id":707,"depth":74,"text":707},{"id":716,"depth":74,"text":716},{"id":725,"depth":74,"text":725},"SEO","2026-01-28","软件公司网站常见的 15 个技术 SEO 问题,按渲染、收录、速度、结构化数据、URL 五类整理。每个写清楚查什么、怎么查、怎么修,照着这份清单逐条过一遍,基本覆盖主要技术坑。",{},"\u002Fblog\u002Fseo-technical-audit-checklist",{"title":195,"description":799},"blog\u002Fseo-technical-audit-checklist",[181,805,806,807],"SEO检查","网站诊断","软件公司","V-yKYGQTmQONKHOmvPibM6xelo1d8NRq5qCX0n4NaSo",1794088108862]