功能预览
站内搜索值得单独规划的信号,是导航已经无法承载检索需求:分类层级变深、内容类型变多、用户带着具体词来找。AnQiCMS 后台与收录检索相关的模块共 14 个,其中含全文搜索,也与 llms.txt、关键词库、自定义内容模型处在同一套管理能力里。本文说明什么规模需要单独配置检索、检索词与关键词库怎么配合、自定义字段能不能进检索范围。
企业官网内容越来越多,站内搜索要不要单独规划?当访客开始绕过导航直接搜具体词,站内搜索就不再是后台的附带功能,而是需要单独规划的一条检索入口。规划的对象也不是搜索框本身,而是三件配套的事:哪些字段参与检索、检索词从哪里来、命中之后如何继续走内链。
导航按站点自身的组织结构呈现内容,检索按访客脑中的词访问内容。两者在内容量小的时候重合,量一大就分开:分类层级超过两层、内容类型出现第三种、同一主题分散在不同分类里,这三条里任意一条命中,导航就已经无法承担发现职责。
AnQiCMS 后台与收录、检索相关的能力是按模块组织的,共 14 个模块,覆盖 llms.txt、站点地图、链接推送、全文搜索、内容翻译等方向。规划站内搜索时应把它放在这套模块里一起考虑,而不是单独上一个外部检索服务,否则内容更新后两处索引会长期不一致。
站内搜索的效果取决于查询词与内容用词是否对得上。关键词库集中管理站点的 SEO 关键词,同一套词表可以同时服务两个方向:前台检索的同义词扩展,以及内容生产时的用词统一。
落地顺序是先建词库再谈匹配:把访客真实使用的词与站内标题用词的差异列出来,高频差异项补进正文或作为同义词维护。没有词库时,检索只能做字面匹配,用户搜「报价」而文章写的是「价格」就会出现零结果。
全文搜索默认覆盖正文与标题,需要单独决定的是自定义内容模型里的字段。AnQiCMS 支持自定义内容模型与自定义字段,产品参数、服务规格、常见问题这类结构化字段往往才是访客真正要找的内容;把它们排除在检索范围外,会出现「答案在页面里但搜不到」。
判断标准可以按字段性质分:会被访客当作筛选条件的字段进入检索,仅用于后台统计或展示的字段不进入,包含敏感信息的字段不进入。
搜索页不是终点。命中列表要能继续引导,站内关键词的锚文本负责这部分:正文里出现的关键词按锚文本规则自动指向对应页面,检索命中的页面因此还能带出相关内容。
另一个容易被漏掉的检查是零结果页。零结果不等于内容不存在,也可能是词没对上,把零结果查询记录定期导回关键词库,是检索规划里成本最低、收益最直接的一步。
问:内容量多大才需要单独规划检索? 答:不看绝对篇数,看导航是否还能承载发现需求。分类超过两层、出现第三种内容类型,或零结果查询开始出现,三条任一命中就值得规划。
问:附件正文能不能一起检索? 答:取决于是否有解析与索引环节。可行做法是把附件关键内容摘要写进文档正文或自定义字段,再纳入检索,比直接索引原始附件更容易控制结果质量。
问:检索与面向大模型的内容组织要不要一起做? 答:可以共用一份结构。llms.txt 与全文搜索都依赖清晰的内容划分,先把字段与主题边界理清,两处都能受益,不需要分两轮改造。
预览
邮件提醒面向站内管理员的事件通知,邮件订阅面向站点内容的定期推送,两者链路不同、开关也应该分开。本文说明如何按事件类型收敛提醒范围、如何用留言与评论的审核流程减少重复通知,以及表单侧的验证措施怎么配合,避免通知把运维和订阅用户一起打扰。
预览
后台的 AI 技能(Skills)把内容规划、SEO 分析、批量操作、站点健康检查、故障排除、模板开发与 API 开发做成内置可扩展能力,可由 AI Agent 自主编排调用。批量写操作按回合合并确认,而不是逐条弹窗。本文说明技能覆盖范围、审批粒度,以及哪些动作不该交给自动执行,以及出错后的回退准备。
预览
评论和留言不必都上验证码:人机验证只解决「是不是真人提交」,拦不住真人发的垃圾内容,也拦不住走接口的批量提交。分工要按三层排,表单侧用人机验证拦机器人,内容侧用敏感词过滤与关键词替换拦不合规表述,接口侧按调用来源与频率限制批量行为,最后留一层人工复核留言与评论。