搜索框必须置于<header>内，因HTML规范明确定义<header>为唯一承载页眉内容（含站点标题、导航、搜索）的语义容器；放错位置会导致屏幕阅读器无法识别其导航功能、Google结构化数据解析失败，且Lighthouse会报无障碍错误。
搜索框本身不决定文档结构，但它的位置、语义标签和上下文嵌套方式，直接暴露页面结构是否合理——尤其当它被塞进 <header> 之外的任意位置时，SEO 和可访问性风险就已产生。
为什么搜索框必须放在 <header> 里
不是“建议”，而是语义强制要求：<header> 是唯一被 HTML 规范定义为“包含页眉内容（如站点标题、导航、搜索）”的容器。放错地方会触发两个实际问题：
- 屏幕阅读器无法将搜索框识别为“全局导航工具”，用户需额外跳转才能定位
- Google 的结构化数据解析器在提取
<WebSite>schema 时，只信任<header>内的<form>或<input type="search">作为“网站搜索入口” - 若用
<div class="search-box">替代语义标签，Lighthouse 的 “Accessibility” 审计项会明确报错Form element has no associated label
<input type="search"> 比 <input type="text"> 多什么
表面看只是 UI 差异，实则影响行为逻辑：
- 原生支持清除按钮（×），无需 JS 实现；
type="text"必须手动加contenteditable+ 清除图标逻辑 - 移动端键盘自动唤起“搜索”回车键（而非“完成”或“下一步”），用户操作路径缩短 1 步
- 部分浏览器（如 Safari）对
type="search"应用特殊样式重置（如圆角、内边距），type="text"需额外重置 - 若未配
name属性，提交时参数名默认为q（搜索引擎友好），而type="text"默认无 name，提交为空字段
搜索表单要不要包裹 <form>
要，且必须带 role="search" 和 method="get"：
立即学习“前端免费学习笔记（深入）”；
- 不包
<form>→ 无法按回车提交，只能靠 JS 绑定事件，破坏基础可用性 - 缺
role="search"→ 屏幕阅读器无法告知用户“这是一个搜索区域”，仅读作“输入框” - 用
method="post"→ 搜索结果页无法被书签收藏、无法后退刷新，违反搜索场景本质 - 遗漏
action→ 提交时 URL 变成当前页路径 +?q=xxx，虽能工作，但不利于 SEO 路由控制（比如你想导向/search?q=xxx）
<main> 里塞搜索框是常见错误
几乎所有 CMS 主题模板都犯这个错：把搜索框渲染在 <main> 开头，理由是“用户一进来就要搜”。后果很实在：
-
<main>必须只包裹“页面核心内容”，搜索框属于“全局导航辅助”，不属于正文 - Google 抓取时会把搜索框文本（如 placeholder “搜教程、API、错误码…”）误判为主内容关键词，稀释真实正文权重
- 当页面是搜索结果页时，
<main>内又出现一个搜索框，形成“搜索页里再搜”，结构循环混乱 - 正确做法：搜索框只在
<header>，搜索结果页的<main>里只放结果列表和分页
真正容易被忽略的是 placeholder 文本的语义处理——它不是标签替代品，必须配 <label> 或 aria-label，否则 WCAG 2.1 AA 级别直接不达标。这点连很多成熟框架的默认组件都没做全。
