After batch link replacement, do we need to rebuild the static pages that have already been generated?

After replacing the link with the full-site replacement in the background, should the statically generated pages be rebuilt? The only criterion is whether the site has turned the page into a static file. For a purely dynamic rendering site, the content is retrieved from the database for each request, and the refreshed page can be seen after replacement; for a site with staticization turned on, the front-end accesses the previously generated file, and changes in the data layer will not be automatically synchronized. It must be rebuilt to take effect.

What layer does the site-wide replacement modify

AnQiCMS's site-wide replacement supports keyword and link replacement for bulk editing, the scope of which includes the text, title fields in the database, as well as the content in navigation settings and single-page management. That is to say, it modifies 'data', not 'files that have already been written out.' This step is easy to misunderstand: some people think that the front-end changes after the replacement is completed, but in fact, there are two stages of staticization and caching between data and visibility.

If the replacement is the menu text in the navigation, and the navigation is read through a template during rendering, then the front-end will immediately display the new text; but if this set of navigation is also staticized into the page file, the old text will still remain in the file until it is rebuilt and will disappear.

Why can the old link still be seen on the front-end after the change

There are usually three situations with different handling methods.

The first is that the page itself is staticized. The address format is determined by the pseudo-static rules. When the rule matches a certain path, the server can directly return the previously generated static file. In this case, both the browser and the spider get the old content. In this situation, it needs to be rebuilt, not just clear the cache.

The second one is the caching layer in the middle. When the whole page cache or object cache hits, even if the data layer has been updated, the returned result is still the old one in the cache. This clearing the cache will be good, no need to rebuild the entire site.

The third one is the replacement that is not covered. Batch replacement works according to the matching string, and links with different formats (missing a slash, with a domain prefix, written in the template instead of the text) will be missed. After the replacement, check a sample of twenty to thirty pages, which is more reliable than flipping a few pages after the replacement.

Should we choose a time slot for the static page reconstruction?

The reconstruction is the process of regenerating each page individually, and when executed in bulk for the entire site, it will continuously occupy server resources. The reasonable approach is:

First, verify the replacement results in a small range, confirm that all new addresses can be opened normally, and then trigger the entire site reconstruction; schedule the reconstruction during the low-traffic period, avoid business hours, and reduce resource competition with normal access; after the reconstruction is completed, inspect the list pages, detail pages, and category pages of the three types of addresses, and the pagination address of the list page is most likely to be overlooked.

Make a backup before reconstruction. In case of reconstruction failure or incorrect replacement string, backup and recovery is the way to return to the state before the change, which is much more convenient than manually changing each page afterwards.

Two things to be done when changing the address

If the replacement is not just text, but the entire article address is replaced, the old address will become invalid directly. In this case, two steps should be taken.

First, set up a 301 redirect for the old address, pointing the old path that has been passed through external links and indexed by search engines to the new address, to avoid traffic interruption on the day of the switch. The redirect rules should be written in batch correspondence, and it is easy to miss one by one manually.

Secondly, clean up the internal references. If any old links remain in the text, navigation, and single-page, and are not replaced or covered, they will still point to invalid addresses after reconstruction, forming internal dead links. After the modification, check again from the site map entry, and confirm that the address submitted to the search engine is new.

Common questions

Should I rebuild even if I only change the keyword text and not the address?Pure dynamic rendering is not used; if staticization is turned on, a rebuild is required, otherwise the old text will still be in the file. If unsure, clear the cache first to see if there is any change, if there is a change, it is the cache layer, and if there is no change, it is the static file.

Will the rebuild affect users who are currently accessing it?During the reconstruction period, the server load increases, it is recommended to execute it during off-peak hours. Complete the backup before reconstruction, so that it can be restored if a problem occurs.

Can I undo the replacement if I made a mistake?There is no entry for step-by-step undo in batch replacement, and the undo needs to be restored by the backup before replacement, which is also the reason for making a backup before reconstruction.

After changing the address, should I notify the search engine?The old address retains the 301 redirect site, allowing the crawler to follow the redirect to find the new address; at the same time, update the in-site references and the addresses submitted to the search engine, to avoid the coexistence of two sets of addresses for a long time.