So Outside Technology Security CMS
AnQiCMS
Online Demonstration

On the day of replacing the host, the domain resolution needs to be moved, and how long in advance should the cache time be reduced to be safe.

📅 2026-11-01 👁️ 0

To switch hosts, you need to migrate the domain name resolution. How long in advance should you lower the DNS cache time to be safe? The safe approach is to start one to two days in advance. The migration guidelines issued on the day recommend setting the DNS cache time to three hundred seconds, and requiring it to be changed at least 24 to 48 hours before the switch; after the switch, let the old environment continue to run for two to three days, because the propagation window of resolution globally is itself from a few minutes to 48 hours. The significance of lowering it is not to make the change take effect across the entire network immediately, but to shorten the time for the old and new systems to say different things, reducing the window for visitors and crawlers to return to the old host based on old records.

Why lower it in advance?

The domain record change will not take effect immediately across the entire network. The recursive servers and operators continue to answer the old addresses according to the cache time set previously, and the larger the cache value, the longer the old answer survives. Pre-maturely reducing it is equivalent to trimming the tail first: on the actual day of switching, the old records can be referenced for the shortest possible window. The order is easy to get wrong; if you change the record first and then reduce the cache value, the change itself is also cached, making the convergence slower. You also need to pay attention to the boundary of effectiveness; reducing it only takes effect for new queries initiated afterwards, and the old records that have been cached will still expire according to their old values. This is why the old environment cannot be taken down on the day of switching.

Switch to the timing table of the day

Arranged in three segments, each with clear actions and acceptance criteria, the risk of skipping a segment will accumulate later.

Timing point The things to do How to inspect
One or two days before the switch Adjust the parsing cache time to three hundred seconds, stop writing on the front or change it to read-only Multi-region detection confirms that the cached values returned by the new and old queries are consistent
Switch to the day The host records point to the new environment, first configure the certificate and pseudo-static rules Directly access the homepage and multi-level deep pages to see if the status is normal
Two to three days after the switch Keep the old environment, configure the old address to point to the new address with a 301 redirect Check the access logs and search engine inclusion, confirm that there is no fallback to the old host

The three sections are linked. If the first section is omitted, the risk is all on the day of switching; if the third section is omitted, the risk is on inclusion and external links, and when the problem is found, the old environment has been unsubscribed, and the remedy is more expensive.

How long to keep the old environment

A window of two to three days is a common safe period, with three reasons. First, the propagation itself is uncertain, and forty-eight hours is often cited as the upper limit, with some operators' caches lasting longer.Second, the addresses captured by the search engine are also cached, and within the window, they will still visit the old addresses. If the old environment directly returns a server error, this failure will be recorded in the crawling log.The third, the asynchronous tasks within the site, such as form notifications, scheduled publications, and interface callbacks, may trigger only after switching, and stopping them prematurely may cause these actions to fail.During the retention period, make the old environment read-only, no longer write new content, and only provide access to the new address. The time point for removal should be after the logs and collections of the new environment are stable, and it should not be on the same day as the next change.

How to hand over the redirection and map

The address has changed, inclusion and weight are based on redirection and sitemap integration. The first step is not to cancel the 301 redirect of the old address early, all requests under the old domain and path should be redirected to the new address with 301, and if it is canceled early, the old links cached out will become invalid links.Step two, the site map needs to be regenerated and submitted with the new domain name, and the site map on the old domain name will be retained for a period of time to allow the addresses within it to follow the 301 redirect to the new site.AnQiCMS is maintained at these two places, after changing the domain name, the system automatically generates the sitemap according to the new address, and the redirect rules are checked one by one for the old addresses with and without suffixes.Step three, after switching, check the inclusion in each search engine one by one, first to see if the new domain has been indexed, and then to see if the index of the old domain has been replaced by the new address. The parsing records related to email are easiest to miss, and they are also affected by caching time. It needs to be verified separately on the day of the switch.

Common questions

What is the appropriate cache parsing time to be considered stable? Answer: It is common to switch to three hundred seconds before the switch, and it should be changed one or two days in advance. The larger the window, the cleaner the old cache will be cleared; changing only the number and switching on the same day will slow down the convergence instead.

How long after the old host can you unsubscribe? Answer: At least two to three days should be left, waiting for the resolution to spread and the search engine to visit to stabilize before withdrawing. During the retention period, let the old address be redirected to the new address with 301, and do not return an error directly from the server.

Ask: Do I need to resubmit the sitemap? Answer: Yes. The domain has changed, all addresses in the sitemap must be the new domain names, and they must be regenrated and submitted according to the new addresses. At the same time, confirm that robots allow crawling of the new site.

Ask: After switching, some pages cannot be opened. What should you check first? Answer: First, check if the pseudo-static rules and address mapping in the new environment are consistent with the old site, and then check if the 301 redirect covers the paths with old suffixes. It's faster to replace missing old addresses with redirects than to change external links one by one.

Related articles

The page shows that it has been crawled but not indexed, is it a broken link or a quality demotion?

Being crawled means the crawling link is working, and not being indexed is often the result of quality judgment: the system may reduce the number of indexed pages when it is worried about the quality of the entire site. The handling is in order, first分流batch pages by subject, then decide to rewrite, merge, or withdraw, while cleaning up the low-quality content collected, converging the repeated carrying pages and anchor text in the keyword library, and finally resubmitting and keeping a record for observation.

2026-11-01

The active push protocol is only supported by a few search engines, does another one count as a push?

The active push protocol informs search engines about which URLs have changed, requests priority crawling, but only a few participate. The one that does not participate will not change the crawling and inclusion judgment just because you have sent a notification. You need to separate discovery and inclusion, follow the engine's分流 actions, let the sitemap be responsible for the bottom line, push for incremental, and then use each result to check whether it has really entered the index after the push.

2026-11-01

When the sitemap exceeds the limit, it can only be split into files, and before splitting, you need to clear which type of address.

The site map exceeds the single file limit and must be split into multiple files using an index file for aggregation, but before splitting, it is necessary to clean up three types of addresses: pages with error status codes, redirect addresses, and pages with屏蔽 marks that are written into the map. The cleaning order is wrong, and the each file after splitting is still wasting crawling quota, the collection efficiency will not improve.

2026-11-01

Several thousand articles need to be moved, should it be imported using a compressed package or a table?

When moving thousands of articles, the basis for choosing between compressed package import and table import is not the quantity but the material form: batch import using ZIP compression packages for text with attachments and rich text, and batch import using Excel tables for neatly organized fields. First align the content model and custom fields, and then use the import interface for title duplication check to control duplicates, and only the failed batches can be safely rerun.

2026-11-01

When starting a site with a container image, should the default port and background address be changed together?

When starting a station using a container image, whether to change the default port and backend address at the same time depends on where the traffic comes from: After the site is behind the reverse proxy, the container listening on port 8001 only needs to match in the mapping, the default port does not need to be changed; what needs to be received is the exposed surface of the backend address. Before going online, enable the built-in protections such as JWT authentication, sensitive word filtering, captcha, and rate limiting first, and then verify it once from the external network.

2026-11-01

How to plan the column structure and classification for a single backend to manage multiple sites without conflict

When managing multiple sites with a single backend, the place where column structure and classification are most likely to interfere with each other is when reusable definitions and isolated data are mixed together. This article explains by separating the shared layer and the isolation layer: the definition of the content model can be reused across multiple sites, the classification tree, column aliases, and visibility range should be planned independently for each site, batch operations at the whole-site level are disabled by default and explicitly enabled per site, and a landing sequence and a corresponding table are provided.

2026-11-01

Can deleted articles be retrieved, and how are drafts, pending publication, and recycling stations divided?

Deleted articles can usually be retrieved: In the AnQiCMS backend, deleting formal documents is not a physical deletion, but moving them to the recycle bin, from which they can be restored. Each of the four document statuses has its own boundaries - formal documents are visible to the public, drafts are only in the background and preview links contain the preview tag, pending publication waits for the set time to take effect, and the recycle bin accommodates deleted content. This article explains the appropriate operations for each and the safe sequence for bulk cleaning.

2026-11-01

How to import articles from the old station table once, if the fields do not match

The order of handling the mismatch of fields when importing the exported table of the old station to the new system is: first select the channel and then discuss mapping, the three columns of fixed title, alias, and category must be mapped, then determine the default value strategy for custom fields, and finally use title search to check if it already exists to avoid repeated imports and sample check the import results

2026-11-01