So Outside Technology Security CMS
AnQiCMS
Online Demonstration

For articles sent at scheduled times, should the page cache be refreshed again?

📅 2026-11-01 👁️ 1

After setting up a scheduled article release, whether the static page cache needs to be manually rebuilt depends on whether the site has attached the generation action to the release event. The safe approach is to check three places separately: whether the main content page has been generated, whether the list and home page cache has been updated, and whether the site map has included the new address. The scheduled release solves the problem of 'when to enter the formal state', and the static generation solves the problem of 'which file the visitor actually reads', and the two steps are separated in the system, so what needs to be done after the time comes is to check instead of waiting.

Check the main content page first after the time comes.

The first verification action is very simple: directly open the address of this article and see if it returns new content or old placeholder results. If the main page is correct, it means that the publication event has triggered the static generation of the page; if it is still old, first confirm whether the article status has really changed from pending publication to formal document.

The document status is divided into formal document, draft, pending publication and recycle bin, and scheduled publication goes through the pending publication to formal section. The draft can be previewed using the link with the preview tag, but the preview only proves that the content itself is correct, not that the static file has been generated - these two conclusions should be taken separately.

The cache of the list and homepage is most likely to lag behind

The detail page only affects one file, while the list page and homepage aggregate the sorting results of multiple articles. Their cache rebuild often lags behind that of the detail page. The most common phenomenon is that the article can be accessed directly, but the entry in the category list and homepage cannot be found.

In this case, it is necessary to confirm three things in order: whether the cache of the list page has been rebuilt; whether the classification of the article is correct; and whether the sorting rules have placed it outside the first screen. The third point is particularly prone to misjudgment as a cache problem - if the list is sorted in reverse chronological order, and the time of the scheduled publication is within the expected range, it should be on the first screen.

Should the sitemap and push be followed up

Yes. The entry of the new address into the sitemap is a prerequisite for inclusion, and the finalized sitemap is usually generated on a periodic basis, and the new articles published on a timed basis may fall into the next generation cycle. The verification method is to open the sitemap file to confirm that the address has appeared.

If this batch of timed release is time-sensitive content, don't just wait for the sitemap: cooperate with link push and active push, and directly hand over the new address to the search engine to align the discovery speed with the release time. This is particularly important for time-sensitive columns, as the value of timed release is to hit the timing point, and the slower the inclusion, the lower the value.

The sequence of batch timing release checks

When performing batch operations, it is not realistic to check each item one by one, and it can be sampled in a fixed sequence: first confirm the time settings of the release batch, then check the list page and homepage after the time comes, then check the proportion of the appearance of the batch address in the site map, and finally check the position of some articles in the category page.

Another experience is to place the backup before the batch operation. The backup and recovery cover data and static files, make a backup before the batch timed release, in case of incorrect time setting or sorting exception, you can roll back the whole section instead of manually repairing each article. This point is more important in multi-site operations: the same operation will affect multiple sites, and the rollback capability determines the cost of trial and error.

Common questions

Is there a difference between scheduled release and manual release?

The release action is the same, but the triggering method is different. Scheduled release is a time factor mechanism, at the scheduled time, the system will convert the content to formal status; manual release is decided by humans. The subsequent verification items of both are consistent.

Do I need to rebuild the entire site cache every time I schedule a release?

Not necessary. First, confirm whether the release event automatically generates related pages; only rebuild the targeted pages when the list page is actually lagging. Leave the full site rebuild for batch changes and template adjustments later.

What should I do if the article does not appear in the list after the time has come?

Investigate in three layers: whether the article status is already a formal document, whether the category attribution is correct, and whether the list page cache has been rebuilt. Most cases fall into the third layer.

Is it normal that the newly released article does not appear in the site map?

It depends on the generation cycle of the site map. If it does not appear within the cycle, it is normal, but it can be triggered manually once, or the address can be submitted out first using a link push.

Related articles

After the translation of the multilingual site is completed, should the page address of each language be generated separately?

After the full-page translation of a multilingual site is completed, each language should have a stable and accessible independent page address, and a sitemap should be generated separately by language for easy verification. Language tags solve the problem of displaying the correct version of search and AI retrieval, but do not improve ranking. This article gives the verification sequence and common mistakes after going online.

2026-11-01

How to see the default switch of a new site placed in a back-end system?

When multiple sites share the same backend, the default switch of a new site only checks three things: which batch of sites the default value of the site status affects, whether the access entry and content structure are properly matched, and the difference between closing and deleting. This article provides the check sequence for a new site and explains the fallback role of the recycle bin and backup in the multi-site scenario.

2026-11-01

How to queue for site upgrades when the security minor version is released on the same day and the major version is scheduled for December?

The short-cycle security minor version and the end-of-year major version should be queued in two channels: the security version enters the maintenance window on the same day, and the major version is first verified in the test environment for templates and data, and then灰度切量并可回退。This article provides the queuing rules, steps within the window, and observation indicators for the gray period for the two types of versions.

2026-11-01

Which item should be inspected first for backup and recovery before merging multiple sites into a batch of domain names?

Before merging multiple sites into a new domain batch, backup and recovery must be accepted first to ensure clean recovery: Confirm that the backup covers the database and static files, and then perform a real recovery drill in an isolated environment before discussing address switching, 301 redirects, and site map reconstruction.

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

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 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

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