Filing Isn't a One-Off Registration
A filing binds three things together: the entity, the website, and the access provider. The access provider is whoever supplies the server or network access, and it's obliged to verify the filings recorded under its name. When you move the site elsewhere, that provider cancels the access record — because the site genuinely isn't with them any more.
The problem is that this completes only half the process. The filing also needs access filed with the new provider to reconnect the relationship. Skip that step and the filing sits with an entity and website on record but no access provider at all — a shell website.
| Cause | How it happens | Any warning? |
|---|---|---|
| Shell website | Host changed, old access cancelled, none filed with the new | None — the site keeps working |
| Shell entity | Every service under the entity has been cancelled | Only the entity record remains |
| Verification found inaccurate data | Entity or site details don't match reality | A remediation notice with a deadline |
| Content violation | The site carries prohibited content | Handled according to severity |
| Voluntary cancellation | No longer needed; owner applies | Normal procedure |
The table lists the cancellation causes. The first is both the commonest and the easiest to miss entirely.
Three Ways Filings Lapse Unnoticed
All three share a property: everything looks fine at the time, and the problem surfaces months later.
- A migration completed halfway You move from cloud A to cloud B, the site comes up, DNS is switched, and the migration feels done. But the filing's access relationship is still registered with A, and A cancels it once it confirms the site has gone. The site runs perfectly on B while the filing hangs unattached — the commonest case, and entirely invisible from the user side.
- Changing IPs or reworking the architecture Even without switching providers, substantially reworking the architecture or changing IPs can trigger the access provider's verification process. If recorded details no longer match reality, the same remediation or access cancellation follows. Introducing a CDN or load balancer makes this especially likely.
- The remediation notice went to an unwatched inbox When verification finds something non-compliant, a notice with a deadline usually comes first — there is a chance to fix it. But it goes to the contact details recorded at filing time, and that address or phone number is often years old and long unwatched. By the time anyone notices, the deadline has typically passed.
Verification and the Remediation Window
Administrations run periodic verification comparing filing records against reality. Being found non-compliant usually doesn't mean immediate cancellation — a notice comes first, requiring updated details or content changes within a deadline. Cancellation or access removal follows only if that passes unanswered.
So the remediation window is the crucial buffer. Receiving the notice means there's still time; missing it means going through cancellation and a complete re-filing instead, at considerably greater cost in time.
Also worth knowing: verification is periodic and sampled rather than continuous. A problem can therefore exist for months without your knowing, until a round happens to include you. The timing is unpredictable, which makes self-checks more reliable than waiting for notices.
What to Do If It's Already Cancelled
Establish the state first. Query the domain in the ministry's filing system to see whether the record still exists and what state the entity is in. That determines the route — whether filing access with a new provider suffices, or the whole record has gone and a fresh application is needed.
If only access was cancelled while the entity and site records remain, filing access with the new provider generally restores it without starting over. If the whole filing is gone, it's a new application on the same timeline as the first one.
Three Levels of Prevention
In order of importance:
1. Put access filing on the migration checklist
When moving hosts, "file access with the new provider" belongs alongside DNS cutover and data transfer as a required step. The site loading doesn't mean the migration finished — the filing is a separate thread, and it won't reconnect itself.
2. Keep contact details current and independent
The email and phone on the filing must be ones you still use, and the mailbox shouldn't sit on the domain itself. A remediation notice is your only early warning; missing it skips you straight to cancellation.
3. Self-check rather than waiting for notices
Log in quarterly and confirm the state — entity details, site details, and whether the access provider is correct. Verification is sampled, so a problem may have existed for a long time. Checking yourself is the only way to find it deliberately.
Three Things to Check Before Taking Over a Domain
If you're acquiring a domain that already carries a filing, these decide how difficult it gets:
- Which entity currently holds the filing Query the ministry's system. If it's in someone else's name, you can't file under your own entity until the existing record is dealt with.
- The access provider state Whether a valid access relationship still exists or the filing is already a shell. This decides whether you need access filing or a complete new application.
- Whether domain real-name data matches the filing entity Registries require the two to agree. If they don't, the application gets rejected at review even when everything else is in order.
In Summary
Filings are most often cancelled because access wasn't filed with a new host, not because anything went wrong with content. The mistake is widespread precisely because it produces no symptoms — the site runs normally until a verification round reaches you.
Prevention is cheap: put access filing on the migration checklist, confirm notices can reach you, and self-check quarterly. If you're planning a China launch or taking over an existing domain, tell us the situation and we'll help assess it.