[{"data":1,"prerenderedAt":268},["ShallowReactive",2],{"blog-sitemap-submit-no-response":3,"blog-prev-sitemap-submit-no-response":97,"blog-next-sitemap-submit-no-response":177},{"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__":96},"blog\u002Fblog\u002Fsitemap-submit-no-response.md","sitemap 提交了没反应，先查这 5 个地方","元析智能",{"type":8,"value":9,"toc":71},"minimark",[10,14,19,22,26,29,32,36,39,43,46,50,53,56,59,62,65,68],[11,12,13],"p",{},"sitemap 只是发现工具，不是收录开关。搜索引擎读它是为了知道有哪些 URL，至于收不收，看 URL 本身。提交后没反应，先按下面 5 个点查，不用急着改页面。",[15,16,18],"h2",{"id":17},"_1-sitemap-本身的-http-状态和类型","1. sitemap 本身的 HTTP 状态和类型",[11,20,21],{},"访问 sitemap 地址必须是 200，Content-Type 是 application\u002Fxml 或 text\u002Fxml；gzip 压缩的要命名为 .xml.gz 且服务器正确返回 gzip。返回 403 最常见，多半是被 WAF 或登录鉴权挡了。我们见过一个客户的 sitemap 挂在需要登录的后台，蜘蛛每次都被 302 到登录页，提交了半年没读过一次。",[15,23,25],{"id":24},"_2-里面的-url-是不是可索引的-200","2. 里面的 URL 是不是可索引的 200",[11,27,28],{},"这是最容易忽略的一条。sitemap 里放 301、302、404、noindex 的页面，等于告诉搜索引擎\"这些地址别当真\"。2025 年 7 月一个开发者工具站，sitemap 自动生成了 8500 条，其中 3200 条是带 utm 参数、302 到规范页的链接。清理后重新提交，两周内\"已编入索引\"从 1.1 万涨到 1.9 万，同期他们还改了模板，两件事一起见效。",[11,30,31],{},"生成规则要过滤：只放 canonical 自指、返回 200、没被 noindex 的 URL。",[15,33,35],{"id":34},"_3-lastmod-是不是全填了当天","3. lastmod 是不是全填了当天",[11,37,38],{},"有些 CMS 每次生成都把 lastmod 写成当前时间。搜索引擎发现这个字段不可信就忽略它，等于你主动放弃了\"告诉蜘蛛哪些页刚更新\"的机会。只在内容真正改动时更新，格式用带时区的完整时间。",[15,40,42],{"id":41},"_4-有没有超限有没有用索引文件","4. 有没有超限、有没有用索引文件",[11,44,45],{},"单个 sitemap 上限 5 万条 URL、50MB（未压缩），超过要拆成多个，再用 sitemapindex 汇总。我们经手的站里，多数其实不需要把全站塞进去，产品页、文档页、博客文章三类核心页面够了，剩下的交给内链发现。",[15,47,49],{"id":48},"_5-提交入口和域名是否一致","5. 提交入口和域名是否一致",[11,51,52],{},"robots.txt 里的 Sitemap 声明要用绝对地址；GSC 里提交的 sitemap 必须和资源同源，www 和非 www 别混，百度搜索资源平台同理。多语言站每个语言版本单独一个 sitemap，混在一个文件里对收录没有帮助。",[15,54,55],{"id":55},"我们现在的生成方式",[11,57,58],{},"站点一旦超过两三百个 URL，靠手写 sitemap 一定会漏。我们通常让后端按模板生成：取数据库里\"已发布、未删除、status 为 published\"的内容，拼出规范 URL，再按内容类型拆成三个子文件，用 sitemapindex 汇总。生成任务挂在内容发布之后跑，只对刚改动的那几条更新 lastmod。",[11,60,61],{},"有个容易踩的细节：文档站经常有中英文两套路径，英文路径如果只是中文页面的机翻版本，别往同一个 sitemap 里塞，按语言分开，各自声明对应的语言版本。混着放会让搜索引擎搞不清哪个是主版本，最后两边都收得很浅。",[11,63,64],{},"改完 sitemap 别指望当天见效。Google 一般几天内重读，百度慢一些，一到两周都正常。这期间去 GSC 的\"sitemap\"报告看\"已发现的网页数\"有没有涨，涨了就说明读到了，收录交给时间。",[15,66,67],{"id":67},"一个判断",[11,69,70],{},"5 条都过了还是不收录，问题就不在 sitemap，回去查抓取日志和页面质量。sitemap 能做的到此为止，别再在这上面耗时间。",{"title":72,"searchDepth":73,"depth":73,"links":74},"",2,[75,76,77,78,79,80,81],{"id":17,"depth":73,"text":18},{"id":24,"depth":73,"text":25},{"id":34,"depth":73,"text":35},{"id":41,"depth":73,"text":42},{"id":48,"depth":73,"text":49},{"id":55,"depth":73,"text":55},{"id":67,"depth":73,"text":67},null,"技术SEO","2025-09-29","提交 sitemap 不等于收录。我们用 2025 年 7 月一个 8500 条 URL 的站点复盘，其中 3200 条是 302 追踪链接。下面 5 个检查点按顺序过一遍，能排掉九成\"提交无效\"的情况。",false,"md",{},true,"\u002Fblog\u002Fsitemap-submit-no-response",{"title":5,"description":85},"blog\u002Fsitemap-submit-no-response",[94,95,83],"XML sitemap","收录","qvxT1_nEL2yhm3B3Q0J6vhrm-9AUktbGapTMhodJZo8",{"id":98,"title":99,"author":6,"body":100,"canonical":82,"category":165,"cover":82,"date":166,"description":167,"draft":86,"extension":87,"keywords":82,"meta":168,"navigation":89,"noindex":86,"ogImage":82,"path":169,"seo":170,"seoDescription":82,"seoTitle":82,"stem":171,"tags":172,"updated":82,"__hash__":176},"blog\u002Fblog\u002Fga4-seo-events-setup.md","GA4 里看不出自然搜索的效果，问题在埋点",{"type":8,"value":101,"toc":158},[102,105,108,111,115,118,121,124,127,130,133,136,152,155],[11,103,104],{},"GA4 的默认报告能告诉你自然搜索来了多少会话，但告诉不了你这些人注册了没有。想看 SEO 带来的注册和试用，必须自己埋事件、自己搭报表。我们给一个客户配一套两小时能配完，配错的话后面每个月都在解释数据为什么对不上。",[15,106,107],{"id":107},"先确认自然搜索这一组是对的",[11,109,110],{},"GA4 的默认渠道分组只认搜索来源。三个常见错：站内 UTM 乱标，把 organic 覆盖成 other；子域没做跨域衡量，来源断掉变成 referral；Google Ads 自动标记没开，付费流量掉进 organic。检查方式很直接，进流量获取报告，按会话默认渠道组看 organic 占比，软件官网通常在 20% 到 45% 之间，明显偏离就是这个环节出了问题。",[15,112,114],{"id":113},"key-events-只留三到五个","key events 只留三到五个",[11,116,117],{},"注册、试用开始、预约演示、文档下载、加企业微信，五个里挑三到五个标成 key event。别把每次按钮点击都算转化，那样报表全是噪音。软件公司的转化往往发生在注册后 7 天内，所以事件要带用户 ID，或者用注册完成页的事件，不能只看点击顶部的按钮。",[15,119,120],{"id":120},"报表这么搭",[11,122,123],{},"新建一个探索报告，维度选会话默认渠道组、落地页、查询参数，指标选会话数、key events、关键事件转化率、互动会话数。把自然搜索筛出来，按落地页排序，就能看到哪篇文章带来了注册。这份报告存下来每周一刷新，比默认报告有用。",[15,125,126],{"id":126},"埋点最容易崩的三处",[11,128,129],{},"单页应用只在首屏发一次 page_view，路由切换不发，站内行为全丢；表单放在 iframe 里，跨域拿不到 submit 事件；事件名一会儿 Signup 一会儿 sign_up，报表直接分裂成两行。",[15,131,132],{"id":132},"我们会固定下来的四个参数",[11,134,135],{},"配置之前先把四件事定死，写进文档，后面新人接手不用猜：",[137,138,139,143,146,149],"ul",{},[140,141,142],"li",{},"落地页统一用 page_location 字段，去掉 UTM 参数，否则同一篇文章会裂成十几行；",[140,144,145],{},"渠道组只保留 organic、paid、referral、direct 四类，营销活动靠 UTM 标记，不新建渠道；",[140,147,148],{},"事件名全小写加下划线，比如 signup_complete、trial_start、demo_booked；",[140,150,151],{},"转化回传带 user_id，注册后 7 天内的试用行为才能串起来。",[11,153,154],{},"这四行看起来琐碎，但它决定这份报表半年后还能不能读。我们 2025 年 9 月给一个安全工具站重配过一次，光把落地页里的 UTM 去掉，报表行数就从 4300 降到 900，终于能看清楚了。",[11,156,157],{},"我们接手过一个站，光是统一事件名，注册数就从 40 变成 63。不是真涨了，是之前漏了三分之一。所以别急着分析数据，先把埋点校一遍，花半天时间比看三个月脏数据划算。",{"title":72,"searchDepth":73,"depth":73,"links":159},[160,161,162,163,164],{"id":107,"depth":73,"text":107},{"id":113,"depth":73,"text":114},{"id":120,"depth":73,"text":120},{"id":126,"depth":73,"text":126},{"id":132,"depth":73,"text":132},"工具评测","2025-09-28","默认报告只给会话数，给不了注册和试用。我们配一套能看 SEO 转化的 GA4 报表要两小时，配错的话后面每个月都在解释数据为什么对不上，这里写清步骤。",{},"\u002Fblog\u002Fga4-seo-events-setup",{"title":99,"description":167},"blog\u002Fga4-seo-events-setup",[173,174,175],"GA4","转化追踪","SEO数据","OP72nWUrS89o55mo9CZ0EIyi9I7Jq_dtSAOpBqxCqoE",{"id":178,"title":179,"author":6,"body":180,"canonical":82,"category":83,"cover":82,"date":257,"description":258,"draft":86,"extension":87,"keywords":82,"meta":259,"navigation":89,"noindex":86,"ogImage":82,"path":260,"seo":261,"seoDescription":82,"seoTitle":82,"stem":262,"tags":263,"updated":82,"__hash__":267},"blog\u002Fblog\u002Flcp-element-diagnosis-steps.md","定位 LCP 元素的三步查法，找错了改什么都白费",{"type":8,"value":181,"toc":250},[182,185,189,192,195,199,202,213,216,220,223,226,229,232,235,238,241,244,247],[11,183,184],{},"软件站做 LCP 优化最常见的浪费，是把首屏最大的那张产品截图当成 LCP 元素，压了半天，其实真正的 LCP 元素是上面那个大标题。先定位元素再动手，三步，十分钟能定下来。",[15,186,188],{"id":187},"第一步看实验室里的-lcp-元素","第一步：看实验室里的 LCP 元素",[11,190,191],{},"PageSpeed Insights 的诊断区块里有 LCP 元素截图和它的选择器；Chrome DevTools 的 Performance 面板录一段加载，时间轴上会标出 LCP 候选和最终元素。这一步能解决八成站点。",[11,193,194],{},"有个坑要注意：如果截图里 LCP 元素是空白，或者显示的是一个 div，多半是图片没下载完就记录了，直接跳到第二步。",[15,196,198],{"id":197},"第二步把元素和请求对上","第二步：把元素和请求对上",[11,200,201],{},"LCP 元素告诉你\"是谁\"，请求瀑布图告诉你\"为什么慢\"。两个数必须对得上：",[137,203,204,207,210],{},[140,205,206],{},"元素是图，看那张图的发现时间和下载时间",[140,208,209],{},"元素是文字，看字体文件加载和阻塞的 CSS",[140,211,212],{},"元素是容器背景，顺着 CSS 依赖链往下查",[11,214,215],{},"我们上周查一个站，LCP 元素是 h1 文字，请求里排第一的却是一张 1.2MB 的 banner。原因不复杂：字体加载晚于图片，h1 一直用回退字体渲染，等字体到位才记录 LCP。这种情况下你压缩 banner 是无效的，要去修字体加载路径。",[15,217,219],{"id":218},"第三步用真实用户数据交叉验证","第三步：用真实用户数据交叉验证",[11,221,222],{},"实验室是固定网络、固定设备，真实用户不是。GSC 的 Core Web Vitals 报告和 CrUX 数据能按设备、按国家分组，能看出移动端和桌面端是不是同一个元素。",[11,224,225],{},"我们见过移动端 LCP 元素是首图、桌面端是 h1 的站——两个端布局不同，移动端首图占满整屏。这种站只按桌面端优化，移动端等于一点没动。那家客户移动端 P75 是 3.8 秒，桌面端 2.1 秒，差了 1.7 秒，而移动端流量占了他们总访问的 64%。按桌面数据做决策，优化的方向从一开始就是偏的。",[15,227,228],{"id":228},"常见问题",[11,230,231],{},"Q：同一个页面，LCP 元素每次测都不一样怎么办？",[11,233,234],{},"先关掉自动轮播、先别加载 AB 测试和个性化推荐。这三个东西都会让首屏内容变来变去，测出来的元素自然不稳定。关掉之后再测三轮，取出现次数最多的那个元素，那才是你该改的目标。",[11,236,237],{},"Q：实验室数据和真实用户数据差一倍，信哪个？",[11,239,240],{},"都信，但动手术看实验室，验收看真实用户。实验室能告诉你瓶颈在哪，真实用户告诉你改了有没有用。只看实验室容易优化出一个漂亮分数，只看真实用户又不知道从哪里下手。",[15,242,243],{"id":243},"一个判断标准",[11,245,246],{},"三步走完，如果 LCP 元素和那个最慢的请求对不上，先别优化，去查优先级和发现时机；对上了，路径就很清楚：减体积、提前发现、去掉阻塞。",[11,248,249],{},"还有一个顺序问题：软件站的首屏经常有轮播图或者动态文案，LCP 元素会来回跳。遇到这种站，先关掉自动轮播再测，别拿一个每次都不一样的结果去做决策。",{"title":72,"searchDepth":73,"depth":73,"links":251},[252,253,254,255,256],{"id":187,"depth":73,"text":188},{"id":197,"depth":73,"text":198},{"id":218,"depth":73,"text":219},{"id":228,"depth":73,"text":228},{"id":243,"depth":73,"text":243},"2025-09-30","软件站 LCP 优化的常见浪费，是把首屏产品截图当成 LCP 元素，其实真正的是标题。实验室看元素、瀑布图看请求、真实数据看设备差异，三步十分钟定下来。",{},"\u002Fblog\u002Flcp-element-diagnosis-steps",{"title":179,"description":258},"blog\u002Flcp-element-diagnosis-steps",[264,265,266],"LCP","性能诊断","调试方法","E2bLu4HOKFv77RJPfhZHZHgYofDm20Fnnto9nQC-zZk",1794088112043]