结论先行：拖拽建站保住 SEO（Search Engine Optimization）的关键，不是关键词密度，而是让搜索引擎在"不执行 JavaScript"的情况下也能拿到完整内容。三条硬线：商品详情页与分类页走服务端渲染（SSR）或构建期预渲染（Pre-render），保证首屏 HTML 里有商品名、价格、库存与正文；页面输出 Product 与 BreadcrumbList 结构化数据；URL 可读、可被 sitemap 完整覆盖。三条缺一条，收录量与长尾词覆盖都会明显缩水。

SPA、SSR 与预渲染的差别

单页应用（SPA）把页面渲染交给浏览器：服务器返回的是一个近乎空的 HTML 壳，内容等 JS 执行后才出现。搜索引擎的抓取能力在进步，但"先抓 HTML、再排队执行 JS"的两段式流程仍存在延迟与不确定性。

• SPA：开发最省事，首次抓取可能只拿到空壳，索引延迟以天计。
• SSR：每次请求在服务端拼出完整 HTML，内容最稳，代价是需要常驻渲染服务与缓存策略。
• 预渲染：构建时把每个 URL 生成为静态 HTML，适合页面量可控、更新频率中等的电商站，成本最低。

实践中的组合通常是：商品详情页与分类页用 SSR 或预渲染，活动页与专题页用预渲染加定时重建，个人中心、购物车这类无需收录的页面保持 SPA。

渲染方式同样决定首屏成本，指标见拖拽生成的电商页面性能怎么保障。

结构化数据怎么标

结构化数据（Structured Data）帮助搜索引擎理解"这是一个商品"，而不只是"一页文字"。电商最常用的三类是 Product、Offer 与 BreadcrumbList，用 JSON-LD 写在页面 head 里。

必须覆盖的字段：

• Product：名称、图片、描述、品牌、SKU 编码。
• Offer：价格、币种、库存状态（有货、缺货、预售）、销售链接。
• AggregateRating：评分与评价数，仅在有真实评价时标注，虚构评分属于违规。
• BreadcrumbList：首页、分类、商品的三级路径。

价格与库存必须与页面展示一致，结构化数据里写"有货"而实际下单失败，会直接触发人工处罚。

URL 与 sitemap

URL 规则要满足三点：短、含语义、稳定。推荐形态是"分类拼音 + 商品 ID"的组合路径，避免出现多层查询参数拼接的长链接。参数页（筛选、排序、分页）要么收敛到 canonical，要么在 robots 规则里排除，不要让同一份内容生成几十个 URL。

sitemap 的硬规则是：单个文件不超过 5 万条 URL 且不超过 50MB，超出就拆成多个子文件并用索引文件（sitemap index）汇总。分页列表与低质量筛选页不要进 sitemap，只放详情页、分类页与重要专题页。sitemap 需要随内容更新重建，新商品上线后 24 小时内应出现在里面。

可索引文本量

拖拽页面最典型的 SEO 事故，是把整段文案做成一张图片。图片里的文字不进索引，等于没写。

可执行的底线：商品详情页正文（卖点、参数、售后说明）不少于 300 字；首屏可见区域内纯文本占版面比例不低于 30%；所有商品图与场景图都配描述性 alt 文案，而不是"图片 1"。标题与描述按"品类词 + 属性词 + 品牌"组合，不堆砌重复词。

上线前检查清单

小程序端的差异

小程序页面不进入通用搜索引擎，但会进入平台内搜索。此时重心得换成：页面标题与关键词字段填写完整、服务类目与商品信息一致、页面路径可被平台索引。把 H5 的 SEO 思路直接搬到小程序，方向就是错的。

FAQs

Q1：拖拽出来的页面能不能做 SEO？

A：能，但前提是渲染层支持 SSR 或预渲染。页面由 DSL 描述不影响 SEO，影响 SEO 的是"最终输出的 HTML 里有没有内容"。设计器怎么做不重要，发布产物必须是可被直接读取的 HTML。

Q2：结构化数据标了没效果怎么办？

A：先确认两件事：字段是否完整、数据是否与页面一致。常见失败原因是价格字段缺失或库存状态写错。补齐字段后通常需要 1~4 周才能反映到搜索结果展示。

Q3：活动页值得做 SEO 吗？

A：短期活动页价值有限，但可复用的专题页值得。判断标准是"这个页面会不会持续存在 3 个月以上且有人搜索"，符合就按正式页面做收录，不符合就只做投放落地页。

延伸阅读

• 电商小程序页面怎么拖拽搭建
• 低代码和建站工具是一回事吗？搭页面与搭系统的本质差异
• 一套 DSL 多端渲染的实现原理：小程序、H5 与 APP