App 和小程序内嵌 WebView 页面的备案归属

App 备案完了，里面的 H5 页面算谁的

移动应用备案推行之后，很多团队把 App 的备案手续办完就认为合规工作告一段落了。但只要这个 App 采用了混合开发模式——也就是部分页面不是原生实现，而是用内嵌浏览器组件（WebView）加载一个网页——就会遇到一个容易被忽略的问题：这些被内嵌的 H5 页面，在备案层面算什么。

直觉上会觉得"页面是在我的 App 里显示的，App 都备案了，页面自然也算合规"。但这个推论跳过了一个关键事实：内嵌只是这个页面的展示方式，不改变页面本身是通过某个域名在互联网上提供服务这个性质。换句话说，判断依据不是"用户在哪里看到它"，而是"这个页面挂在什么域名下、由谁提供"。App 备案和网站备案的整体区别见 App 备案和网站备案的区别。

关键要点

• 内嵌页面的备案归属看的是这个页面所在的域名由谁提供、是否已备案，而不是它被嵌在哪个 App 里。
• 自有域名内嵌和第三方域名内嵌是两种完全不同的情况，责任归属和需要做的事也不同。
• App 备案和网站备案是两套独立的登记体系，各自解决各自的问题，不能互相替代。
• 混合开发模式下，最容易被遗漏的是那些"看起来像原生页面"的内嵌页，以及活动页、帮助文档这类低频页面。

判断依据：页面挂在什么域名下

内嵌场景	备案归属	需要做什么
内嵌自己名下域名的页面	该域名需要正常完成网站备案，和是否被 App 内嵌无关	按正常流程为该域名办理 ICP 备案
内嵌第三方提供的页面（如合作方的服务页）	该页面的备案责任在提供方，不在 App 运营者	确认合作方的域名已完成备案，在合作协议里明确责任
内嵌纯本地资源（不通过网络域名加载）	不涉及域名，不构成需要备案的互联网信息服务	无需额外备案处理

最直接的判断方法是看这个 WebView 加载的地址：如果它是一个指向公网域名的网址，那这个域名就需要符合正常的备案要求；如果加载的是打包在 App 安装包里的本地文件，不经过网络域名，则不涉及备案问题。

这个判断标准和纯网页场景下的逻辑是一致的——备案关注的是"通过域名提供互联网信息服务"这件事本身，公众号跳转的 H5 页面也遵循同样的判断思路，见 公众号跳转的H5页面要不要单独备案。

自有域名 vs 第三方域名：责任归属不同

内嵌自有域名的页面，是实践中最常见的情况：App 里的活动页、商品详情页、帮助中心往往用 H5 实现，挂在自己公司的域名下。这种情况下，该域名需要按正常流程完成网站备案，不能因为"这些页面只在 App 内部打开、不对外公开访问"就省略——只要这个域名在公网上可以被访问到，就落在备案要求的范围内。

内嵌第三方页面的情况不同：比如 App 里接入了合作方的服务页面、第三方的支付或客服页面，这些页面挂在合作方的域名下，备案责任归属于合作方这个运营主体。作为 App 运营者需要关注的是：

• 确认合作方的域名确实已经完成备案，可以用 ICP 备案查询 自行核实，而不是仅凭合作方口头说明。
• 在合作协议里明确内容合规的责任划分，如果内嵌的第三方页面出现内容问题，责任边界在协议层面应该是清楚的，这类平台与第三方的责任划分思路和多租户场景类似，见 同一实际控制人名下多个无股权关联主体分别备案的审核风险 中关于责任边界的讨论。
• 保留技术上快速下线某个内嵌页面的能力，一旦合作方的页面出现问题，能及时切断而不是只能整个功能下线。

App 备案和网站备案：两套独立的体系

一个常见的误解是把这两者当成"同一件事的不同叫法"，实际上它们是面向不同对象的两套独立登记：

维度	移动应用备案	网站 ICP 备案
登记对象	App 这个应用本身	域名及其对应的网站服务
解决的问题	这个 App 由谁提供、谁负责	这个域名提供的互联网信息服务由谁负责
能否互相替代	不能——App 备案不覆盖其内嵌页面所在域名的备案要求	不能——网站备案不替代 App 本身的备案要求

两者并行存在、各管各的事。一个采用混合开发的 App，理论上需要同时满足：App 本身完成移动应用备案（流程见 App 备案办理流程），以及其内嵌页面所在的自有域名完成网站备案。只做其中一项，另一项的要求并不会被自动豁免。

混合开发下最容易被遗漏的页面

实务中遗漏往往不是因为不知道规则，而是因为没人完整梳理过这个 App 到底内嵌了多少个 WebView 页面：

• 看起来像原生页面的内嵌页：现在的混合开发技术能把 H5 页面做得和原生界面几乎无法区分，产品和合规人员看着界面根本意识不到这其实是一个网页。
• 低频但确实存在的页面：用户协议、隐私政策、帮助文档、关于我们——这类页面很多团队用 H5 实现并挂在某个域名下，但在合规梳理时完全不会被想起来。
• 临时活动页：运营临时上线的活动页面常常挂在一个临时域名或子域名下，活动结束就忘了，但域名可能还在解析，临时活动页的备案要求见 临时性活动页面短期上线要不要备案。
• 历史遗留的旧版本页面：老版本 App 里内嵌的页面地址，如果老版本仍有用户在使用，这些页面和域名依然在提供服务。

务实的做法是让技术团队直接从代码里导出所有 WebView 加载的域名清单，这比靠产品经理回忆或者手动点击 App 排查要可靠得多。

常见坑

• 以为 App 完成备案，内嵌页面就自动合规了：两套登记体系互不替代，内嵌页面所在的自有域名仍需正常备案。
• 认为"只在 App 内打开、不对外公开"就不用备案：只要域名在公网上可访问，就落在备案要求范围内。
• 内嵌第三方页面却没核实对方域名是否已备案：仅凭合作方口头说明，出问题时才发现对方根本没备案。
• 合规梳理时完全漏掉用户协议、帮助文档这类 H5 页面：低频页面最容易被忘记，但它们确实挂在域名下提供服务。
• 老版本 App 内嵌的页面域名被忽略：只要老版本还有用户在用，这些页面和域名依然在提供服务。

常见问题

我的 App 里的 H5 页面都挂在自己公司已备案的域名下，还需要额外做什么吗？

如果这些页面所在的域名已经完成了网站备案，且备案信息（主体、网站内容类型等）与实际提供的服务一致，通常不需要额外的备案手续。需要留意的是，如果内嵌页面的业务性质和原备案登记的网站内容差异较大，可能涉及备案信息的内容类型更新，相关范围见 备案信息变更涉及哪些内容。

内嵌的是合作方的页面，出了内容问题谁负责？

该页面所在域名的备案主体通常是首要的责任方，也就是提供这个页面的合作方。但作为内嵌方，在选择合作对象、核实其合规状态方面也应当尽到相应的注意义务，并在协议中明确责任划分，同时保留技术上快速下线的能力。

WebView 加载的是打包在 App 里的本地 HTML 文件，需要备案吗？

如果这些文件完全打包在安装包内、不通过任何网络域名加载，不构成通过域名提供的互联网信息服务，通常不涉及网站备案的要求。但如果页面虽然是本地的，却会向某个域名发起接口请求，那个提供接口的域名本身的备案要求仍然存在，接口服务的备案判断见 小程序后端接口服务器要不要办理备案。

怎么系统地排查自己 App 里到底内嵌了哪些页面？

最可靠的方式是让技术团队从代码层面导出所有 WebView 组件加载的地址清单，包括配置文件里的地址、动态下发的地址，以及历史版本中仍在使用的地址。靠手动点击 App 界面排查容易遗漏那些低频入口和外观做得像原生界面的内嵌页。

资料来源

工业和信息化部关于移动互联网应用程序备案和互联网信息服务备案的公开规定。本文为一般性说明，仅供参考，具体要求以属地通信管理局的最新规定为准。