Website accessible in China — filing, host, clean deps
Making a website accessible in China needs entity and ICP where required, Mainland China termination, clean deps, and China vantage tests — not a global CDN checkbox.
How to make your website accessible in China is an architecture project, not a DNS tweak. You choose whether Mainland China users hit a filed in-country path or an overseas path with known limits; you remove blocked dependencies; you prove the journey from a China vantage. “Turn on Asia CDN” alone usually yields a slower overseas site, not a website accessible in China.
Preconditions
Before any provider console work, these must exist. Missing any of them stops honest DIY.
| Precondition | Why DIY stalls |
|---|---|
| Intent — China marketing site, product app, or both; which hostnames | Wrong scope buys the wrong hosting and filing path |
| Organizing-entity path for ICP when you claim Mainland China hosting | No entity / agency rail → filing cannot start |
| Clarity on termination (overseas-only vs Mainland China origin) | Global CDN ≠ in-country delivery |
| Chinese-language ops capacity (or a partner who has it) | Provider onboarding, content questionnaires, and tickets are not English-first |
| Plan for China vantage proof (broadband + mobile) | HQ monitors prove overseas reachability only |
| Owner for third-party allowlist on the China hostname | Marketing tags silently re-break access after launch |
If you are still diagnosing a website not working in China rather than designing access, start with Website not working in China. For domain DNS → Mainland China IP filing duty, see ICP filing — domain DNS to Mainland China IPs. For ICP then PSB sequence, see China ICP and PSB filing.
Core path
| Gate | Outcome you need | Owner |
|---|---|---|
| 1. Intent | China marketing site, product app, or both — and which hostnames | Product + legal |
| 2. Entity & filing | Chinese organizing-entity path; ICP filing/license when hosting in Mainland China | Compliance |
| 3. Termination | HTML (and critical APIs) terminate on approved Mainland China infra when you claim an in-country site | Platform |
| 4. DNS for China users | Records that send production traffic to that termination — not a leftover overseas A record | Platform |
| 5. Dependency clean | Fonts, tags, auth, and APIs reachable in China or replaced | Web eng |
| 6. Prove & control | China vantage checks + change control before migrations | Ops |
Architecture patterns that stay honest
A) Full Mainland China site — Origin and CDN in Mainland China under the filing provider. Best when China is a primary market and you accept local ops.
B) China front door + global product — cn. or localized hostname filed and fast in China; global app remains offshore with explicit limits for China users (or a separate China app stack).
C) Overseas-only with expectations managed — No China hosting; accept cross-border latency and dependency risk. Useful for early probes; weak as a “we launched in China” story.
Ship-blocking dependency moves on a China hostname: self-host fonts; gate or replace Tag Manager / ads pixels that call blocked domains; ensure auth and session APIs have a China-reachable path; mirror or replace US-only asset buckets; confirm CAPTCHA, chat, and status widgets from Mainland China; prefer domestic or dual-stack analytics if measurement must work in-country.
Launch proof (minimum): from at least one Mainland China broadband and one mobile network — DNS dump, TLS OK, field timing or waterfall, and a recorded pass of login + primary CTA. Keep artifacts next to the release ticket. If any box is unchecked, call it a beta with an explicit risk note — not silent GA.
Linked reasoning
ICP approval while DNS still points overseas → access and compliance both fail. Packets must match paperwork. A filing number in the footer with overseas termination is not a China-accessible site.
Mainland China origin + overseas design-system CDNs → shell still breaks. Component libraries that pull fonts, icons, or runtime config from Google hosts or overseas object stores fail China shells even when HTML terminates locally. Audit the design system, not only the homepage repo.
Single hostname for global + China → forced compromise. When China needs different DNS, CDN, or origin, a dedicated China hostname (or explicit dual path) beats silent geo magic. Half-migrated link graphs send China users back to the slow global site.
VPN-based QA green → wrong sample. Corporate egress is not Mainland China ISP reality. Accessibility without non-VPN China checks in release gates regresses silently.
CDN onboarding without certificate coverage → China-only TLS failures. Exact SAN coverage for every China hostname is part of termination, not a later cleanup.
Accessibility without ops owners → “works on day one, unstable thereafter.” Content approval queues, Chinese-mobile-reachable security contacts, local logging expectations, and change control for the China hostname sit beside the network path.
Difficulty and blockers
- Filing without traffic alignment — ICP done; production DNS leftover overseas. Fix DNS and host bind together.
- Global design system hard-coding overseas CDNs — Audit shared packages, not only the marketing repo.
- Mini Program / app WebViews — Inherit the same dependency constraints; sometimes stricter. Test inside the real container.
- Certificate and hostname sprawl — Missing SANs show up as China-only TLS failures.
- No owner for China regressions — Marketing adds a heatmap script; China conversion collapses. Name an allowlist owner.
- Over-promising “same stack everywhere” — Some global platforms cannot place true Mainland China PoPs on your plan tier. Read the contract path before sales decks claim parity.
- Security and privacy late — New CDN vendors, certificate automation, WAF, and logging regions belong at entity/filing intent — not after the China URL is announced.
- SEO folklore driving hosting — A China-accessible site is not the same as ranking on every domestic search property. Make load and convert work first; then decide Baidu/bing motion. Do not let SEO myths break compliance.
Budget honestly: a realistic first China-accessible marketing site often includes filing path, host/CDN bind, certificate work, dependency rewrite, and measurement hardening — not a half-day DNS change. Product apps with auth and realtime cost more. Put that in the roadmap so sales does not promise “next Friday” against physics and paperwork.
Dual-hostname details when used: align cookies and login carefully — or accept separate sessions; localize absolute URLs in emails and QR codes; keep sitemap/robots and analytics properties distinct enough to debug; document which legal entity operates which hostname.
China landing partner
Most product teams need a China landing partner to clear entity, ICP host bind, Chinese-language provider onboarding, and Mainland China vantage proof — not another longer CDN checklist. Your team still owns architecture and dependency decisions; the partner path makes filing, termination, and cutover executable when Mainland China ops rails are not already in-house.
What we can offer?
This Guide’s decision is which honest China access pattern you will run — full Mainland China site, China front door + global product, or overseas-only with managed expectations — then clear the gates that make that pattern real: entity/ICP when required, termination that matches DNS, clean deps, and Mainland China vantage proof. Chinaready helps your team execute those gates (usually with a landing-partner rail), not “turn on Asia CDN”:
- China Readiness Assessment — Choose pattern A/B/C with you, lock hostnames and intent, and say whether ICP + Mainland China hosting is required or whether an overseas-only probe is the honest story — before sales claims “launched in China.”
- China Access Acceleration — Make the China hostname work end-to-end: DNS to the right termination, dependency allowlist (fonts, tags, auth, CAPTCHA), certificate SAN coverage, and launch proof from Mainland China broadband + mobile.
- China Product Hosting — For patterns A/B, place HTML and critical assets on Mainland China origin/CDN under the filing provider so packets match paperwork — not an overseas origin with an Asia PoP and an ICP number in the footer.
- Mobile App Distribution — When the China site feeds WebViews, Mini Programs, or a companion app, keep those containers on the same dependency and API reachability rules so a “website accessible” win does not leave the product shell broken.
Contact us when you need that pattern chosen and the gates owned before you publish a China URL.
Frequently asked questions
What does “accessible in China” mean for a website?
Mainland China users can resolve your hostname, complete TLS, load the document and critical assets in acceptable time, and complete core journeys — without depending on blocked overseas third parties.
Do I always need ICP filing?
If you host or formally operate an internet information service on infrastructure in Mainland China, Internet Content Provider (ICP) filing (or a license where applicable) is generally required. Pure overseas hosting with no China footprint is a different architecture with different performance trade-offs. See the ICP domain-DNS Guide for the resolution trigger.
Is a China CDN enough?
A licensed Mainland China CDN helps only when origins, hostnames, and filing records line up. CDN in front of an unfiled or overseas-only design is not a complete accessibility plan.
Should we use one global site or a China-specific site?
Many product teams win with a dedicated China hostname or localized front door that terminates in Mainland China, while the global product stays offshore. One hostname for both audiences is harder to keep honest.
How often should we re-test from China?
After every DNS, CDN, origin, or third-party tag change that affects China users — and on a recurring cadence. Accessibility regresses silently when marketing adds a blocked script.
Can our team finish this from an overseas console alone?
Usually no. Entity path, Chinese-language provider consoles, ICP host bind, and Mainland China vantage proof are rails most product teams lack in-house.
