Does My Website Need ICP Filing? China, Subdomains, and Police Registration

Does My Website Need ICP Filing? China, Subdomains, and Police Registration

A personal site often begins as a simple blog. You publish notes, show a few projects, and provide a way to contact you. Then you prepare to launch an app. Suddenly you need a separate product home page, privacy notices, terms, account-deletion instructions, support information, and an API. The blog and the product website may use different infrastructure and deployment processes while sharing a registered domain. That raises several practical questions: Which website filing obligations apply? How are ICP filing and public-security filing different? Does each subdomain require a separate record? Can a product website’s approved filing badge also appear on the main blog?

Start by separating the domain name, the actual hosting and access path, and the filing systems. A domain is an address. Hosting and network access determine where and how the website is delivered. An ICP filing and a public-security internet filing are different administrative processes. One owner and one registered domain do not automatically mean that every separate website can display every filing number associated with that owner. Choose an architecture for real user, security, performance, and maintenance needs—not to avoid applicable filing obligations. Separating a blog and product website can make releases and privacy policies easier to manage, but only if routes, deployment, analytics, and public information stay consistent.

Start with the service, filing category, and approved website scope

Website filing decisions should begin with the service actually offered, the real hosting and network access arrangement, the filing subject, and the competent authority’s requirements. A public service using mainland China infrastructure generally needs to verify and complete applicable ICP filing before opening. Other infrastructure arrangements must also be assessed for ICP, public-security filing, and any service-specific approvals; neither an overseas CDN nor a hosting brand proves that a website has no filing obligations. Alibaba Cloud’s ICP filing scenarios and Tencent Cloud’s filing FAQ help identify questions for the provider and authority. They are not instructions to move a website in order to bypass registration.

A related misconception is that every host name needs a separate ICP number. ICP administration generally considers the filing subject, the registered domain, website information, and access provider; it does not mechanically allocate a distinct public ICP identifier to every www, products, and api DNS label. But a newly added website, a materially different site or service, or a changed access provider may still require an amendment or an additional website record. A public-security filing is not automatically interchangeable with the ICP record: whether an approval covers the blog and a distinct product website depends on the actual approved website record. Do not copy a police filing badge from one site to another just because both names end with the same parent domain.

Scenario	ICP filing consideration	Public-security filing consideration
Personal blog using a particular hosting and access arrangement	Determine ICP requirements from the actual service, origin, access provider, and official record; do not rely on geography alone	Check the public-security filing obligation and the scope of any existing approval
Product website served from a mainland China server	Appropriate ICP filing normally required before opening	Follow the approved website’s public-security filing and badge requirements
Main site and product subdomain on different infrastructure	Verify the filing subject, registered domain, website and access information	Check whether both sites are actually covered; do not assume they share one number
API-only endpoint with no public web page	Analyze host location and access conditions	Some platform guidance describes limited exceptions; do not assume universal exemption
CDN or hosting migration	Check whether the change modifies regulated access information	Reconcile approved details with actual service and deployment

These are technical decision aids, not legal advice. Requirements vary with the service, jurisdiction, filing subject, hosting arrangement, and whether regulated or commercial services are provided. An ICP filing is not equivalent to approval for every type of business, nor does the absence of a mainland hosting requirement settle every public-security question.

What documents are needed, and how do ICP and police registration work?

Start with a record of the actual service and the operator: the legal person or individual responsible for the site, its domain and web addresses, responsible contact, actual network access provider, service categories, and whether additional sector-specific approvals apply. Domain ownership, ICP filing, public-security website registration, and a license for regulated commercial activities are not interchangeable. Article 8 of the current Regulation on Internet Information Services identifies operator and website-responsible-person details, website addresses, service categories, and applicable prior approvals as foundational information for noncommercial service filing. Exact identity-verification materials depend on the operator, access provider, and competent authority.

For an ICP filing, first determine the rules that apply to the service and its actual access configuration. When filing is required, work through the actual network access provider’s authorized registration process, submit the operator and site data, complete authenticity checks, and verify the authority’s result. If the operator already has a record and is adding a distinct product website, ask the provider whether the process is a new-website addition, a filing update, or an access-provider change. Do not assume a new legal entity is required. The MIIT filing service guide describes the role of network access providers and the accuracy obligation.

Public-security registration is a separate workflow. Use the National Internet Security Management Service Platform, sign in under the actual responsible operator, and open the website application appropriate to the case. Supply the real website and responsible-party/security-contact information, together with whatever supporting documents the service currently requests. Requirements for an individual must not be copied uncritically from a corporate checklist. Following approval, obtain the number, original emblem and official link for the specific approved website, rather than borrowing a badge from another domain. The current Tencent Cloud process guide explains submission and badge display, but the authoritative platform and local authority determine what is required.

Task	Information to check	How to confirm completion
Initial noncommercial ICP filing	Actual operator, site contact, address, services, access-provider verification	A matching official record and a correctly displayed number
Additional product website	Existing operator record, distinct site and service, access configuration	Confirm whether addition, update, or access filing is required
Public-security website registration	Real website, operator, responsible security contact and current platform documents	Approval for that website and its own downloadable badge and query link
Later site changes	Old and new addresses, service categories, operator/access details	Registration records and public footer accurately reflect approved changes

How long does filing take? Do not promise a universal number of days. Preparing documents, provider verification, authority review and corrections are different stages. Check the current official processing status and any applicable published time limit for the specific request. In particular, guidance about applying for public-security registration within a period after site activation is not a guarantee of approval within that period. Verify milestones from the applicable MIIT noncommercial filing rules and public-security registration guide.

How do you check a registration number or update website details?

Use the MIIT registration lookup to verify the actual ICP record, operator and domain, and the public-security portal to verify the website and domain associated with a police registration number. A number shown in a footer does not independently prove that a different website is covered. If a portal is temporarily unavailable or shows an unexpected mismatch, document the uncertainty and contact the provider or relevant authority rather than inventing a registration scope.

When an operator changes a website address, service category, organizational information or network access, determine whether a filing amendment, access filing, additional website application, or separate public-security update is needed. Article 11 of the Internet Information Services Regulation prescribes advance procedures for changes to a website address or service category, while the detailed public-security change process follows that platform and the local authority. The compliant response to a mismatch is to correct the underlying records and display, not to copy a registration number from a different site.

Should a blog and a product website be separate?

The more useful question is not “which URL structure ranks higher?” but “what job does each site need to perform?” A personal blog supports discovery, long-form explanations, evidence, projects, and repeat visits. A product website needs to explain an application, identify what is available today, show supported platforms, and provide reliable support and legal pages. It may have release cycles, user account flows, and privacy obligations that are unrelated to the blog’s editorial schedule. An independent subdomain creates a clearer operational boundary when these needs really are different.

But a subdomain is not an automatic SEO upgrade. Google treats domain and subdomain home pages as possible distinct units for site-name presentation, according to its site-name documentation, yet that is not a ranking advantage guarantee. Publishing related material within a single established site may be simpler when the audience, release cadence, ownership, and content are shared. A separate domain or subdomain is valuable when it makes users’ next steps, legal ownership, and operational responsibility clearer. Independent developers should choose the architecture they can actually maintain.

XBSTACK provides a concrete example. Its writing and technical research site is served at www.xbstack.com, while the independently deployed product website at products.xbstack.com contains introductions and support information for Lunest and Recalia. On November 4, 2026, the product site was updated to display its confirmed public-security filing information using the original supplied icon and official lookup link. The deployment used a dedicated release path and retained rollback capability. A post-deployment check verified 22 out of 22 public product and legal-information routes for the expected filing display and related technical checks. That is an actual website release verification, not evidence that the two apps have launched publicly or that every regulatory matter has been resolved.

What should www, products, and api actually do?

One registered domain can host many services. The www host might publish articles and an about page; products can contain app landing pages and public policy links; api can provide authentication and data services. DNS records and CDN configuration determine how those names resolve, but a DNS answer alone does not describe the whole deployment. You also need to understand the origin server, TLS termination, reverse proxy routes, cookie scopes, server credentials, release pipeline, and network access controls. Sites on different infrastructure should not silently share assumptions about latency, privacy, security requirements, or their registered operating scope.

Four boundaries are especially useful. Routing means a product link actually reaches the product site and an editorial citation still reaches the blog. Deployment means publishing a blog post cannot overwrite product policy pages or their runtime assets. Data processing means the product’s account, waitlist, or API information does not leak into the blog’s generic analytics. Public/legal information means each site displays the policies and filing details that actually correspond to its service. These are architectural decisions, not merely marketing or branding choices.

One real XBSTACK build check caught a surprisingly common mistake: the exported product site contained root-relative links to engineering articles such as /ai/agent-memory-system/. On the original blog that path made sense. When the same page moved to the products host, the browser would interpret it as products.xbstack.com/ai/agent-memory-system/, which that product site did not serve. The correct remedy was to point intentional cross-site references back to the full blog URL, rather than copying the entire blog route tree into the product deployment. This is why a good standalone-site build should audit not only missing assets but also internal links that accidentally refer to routes on another host.

A product home page is not enough for a real app

A product website should tell visitors what the application does, which platforms and versions are genuinely available, how to get assistance, and what happens to their data. If the product supports accounts, subscriptions, personal documents, or health-related information, the site should provide the public disclosures required by the actual app behavior and applicable store or legal rules. Privacy, terms, account deletion, and support are user tasks, not decorative footer links. If there are two products on one website, their data flows may differ enough that they need separate, accurate explanations.

For an application still under development, distinguish capabilities that work now from plans and invitation-only tests. A login or download button should not claim to be ready before the relevant service is usable. An account-deletion page must explain a real process, not an invented support pathway. The XBSTACK standalone-site verification covered Chinese and English entry pages, both product introductions, and the applicable privacy, terms, support, and deletion routes—22 public routes in that deployment. Passing that check does not mean the policy texts can never change; an app’s actual data behavior must continue to determine the content.

Separate-site SEO: canonical URLs, redirects, and analytics

First, give each real page a stable canonical URL. A blog article belongs canonically to its www address, and a product page to its products address. Do not point every product page’s canonical at the blog home page simply because both belong to one brand. Google describes canonicalization as a preference among duplicate or similar URLs, not a guaranteed command. If a single page genuinely moved, use a correct redirect or canonical strategy rather than leaving two competing copies across hosts. See Google’s official canonicalization documentation for the available signals and their limitations.

Second, let each deployment own its sitemap, robots policy, language signals, and route tests. A product sitemap should point to publicly indexable product addresses; the blog sitemap should represent its own article URLs. Chinese and English pages need consistent language versions and references. A publicly required privacy URL should remain accessible even if its indexing policy differs from a marketing page. Do not copy noindex rules mechanically between sites, and do not pretend a site has routes that were never exported.

Third, use cross-site links to help readers, not manufacture an internal link network. A development article can link to its actual product home page; a product explanation can point back to a detailed engineering write-up. Marketing UTM parameters can help attribute referral traffic, but UTM-tagged links should not become canonical URLs. In GA4, validate how visits between subdomains are attributed and whether they create unwanted self-referrals or duplicate events. Never pass email addresses, verification codes, API keys, imported documents, or health data as generic tracking parameters.

Fourth, test old URLs when moving from a directory to a subdomain. If an app formerly appeared at /products/lunest/ and the new standalone product URL is /lunest/, verify the source hostname, 301 behavior, canonical URL, sitemap, and actual public response. Blind string replacement can leave valid-looking but broken routes. A migration audit should include browser navigation, not just a successful application build.

Can a product website’s filing number be copied to the main site?

Do not assume so. An ICP identifier should be displayed consistently with the actual registered subject, domain, and hosting access where required. A public-security filing number and its officially supplied icon should be displayed for the website covered by the approved filing record, with the proper lookup destination. Two sites beneath one registered domain may represent distinct public services and access arrangements. Before reusing a number, check the actual approval’s website name and domain coverage. If a separate site is not covered, follow the competent authority’s process for an additional or amended registration instead of making the footer match by copying another site’s badge.

ICP and public-security filing must be assessed as separate processes. Alibaba Cloud’s filing-scenario FAQ describes different access arrangements, while Tencent Cloud’s public-security FAQ addresses new sites, amendments, and specific cases. These provider instructions are not a site-specific regulatory ruling and must not be read as advice to relocate hosting to evade registration. If a blog and product site serve different users, jurisdictions, or infrastructures, confirm the actual obligations and approved site records with the relevant provider or authority.

XBSTACK applied this principle by displaying the confirmed product-site public-security filing on the independently filed product website, without copying that badge onto the writing site. Its deployment check verified the original icon and lookup URL on the product routes. That choice prevents a common form of accidental misrepresentation: presenting one site’s approval as if it necessarily applied to a second site. A main site’s existing ICP footer should likewise be checked against the current official record rather than treated as proof of coverage merely because it appears in HTML.

How can one developer maintain two sites without duplicating everything?

You do not need two unrelated technology stacks. You can maintain a shared repository or two clearly bounded projects while keeping independent configurations, build outputs, environment variables, deployment credentials, and release procedures. Each site should have its own post-deploy checklist: home page, navigation, API origin and CORS where relevant, canonical URLs, sitemap, language routes, privacy links, public legal information, and rollback status. The product site should not be redeployed by accident during a normal blog publication, and an app policy update should not depend on unrelated editorial files being ready to ship.

The definition of “done” also needs to be precise. A green build means the build passed; it does not mean all links work. A successful deployment means files were activated; it does not mean the live site shows the new version. A 22/22 route check proves those 22 specified checks passed in that release; it is not proof of search ranking gains, downloads, store approval, or universal compliance. Keeping this distinction visible is one of the most valuable practices for an independent developer running more than one public service.

Frequently asked questions

Does my personal website need filing in China? Determine this from the actual service, operator, network access and applicable rules. Noncommercial internet information services provided within mainland China are subject to filing requirements.

How is ICP filing different from police registration? They are separate regulatory processes. An ICP record does not automatically establish a completed public-security website registration, or vice versa.

Do www and product subdomains need separate filings? Do not assume one filing number per hostname. Review the registered operator, domain, actual websites, and access information; a distinct website may require an addition or amendment.

What documents does a personal website filing need? Core information includes the operator, site contact, web addresses and service categories. Identity verification and sector-specific approvals depend on the actual case and provider.

Where do I apply for website filing in China? When ICP filing applies, use the actual network access provider and competent authority process. Public-security website registration has a separate national portal and local review.

How long does website filing take? There is no single guaranteed timeline for every site. Provider verification, authority review, document corrections and case type differ. Check the current case status and official processing rules.

Where can I check my ICP and police registration numbers? Use the MIIT filing lookup for ICP information and the national public-security portal for the matching registered website. A number shown in a footer is not enough.

Do I need to update filing records when my website changes? A changed website address, service category, operator or access configuration may require an amendment, additional website application, or access update under the relevant authority.

Can my product website and blog share one police registration number? Only if the actual approved record and authority guidance cover both. Common ownership or the same parent domain alone does not establish that scope.

How do I show the approved filing number and emblem? Use the number, original emblem, and official query link issued for the approved website, and verify their display on the actual public pages.

This is an engineering and operational case study, not legal advice or a determination that any particular domain has satisfied every filing obligation. Hosting and domain choices should support real operational needs, not serve as a filing-avoidance strategy. Actual approval records, the service provider, and the competent authority govern the applicable process.