Who should do the full site replacement and 301 redirect first when multiple site groups are revised together

When a group of multi-site versions is updated, the 301 redirect is performed first, followed by the full site replacement. The reason is not habit, but rather that the two actions modify different objects: the 301 redirect modifies the URL ownership relationship, which needs to be established within the time window when the old address can still be accessed and the new address has already gone live; the full site replacement modifies the keywords in the text and link text, which belongs to the content layer. If the order is reversed, the replacement will write the new path into the text, while the redirect table is still empty, and the search engine will see both the old address and the new address in the same round of crawling, causing the inclusion to fluctuate back and forth.

The two actions modify different objects.

The redirection solves the problem of 'who owns this address now'. If the old address is deleted instead of being redirected, all external entries referencing it - search results, external links from other sites, user favorites - will end up on an empty page, and the accumulated weight from history will also be lost. The redirection table is a one-to-one correspondence between the old URL and the new URL, belonging to the site structure layer.

The website replacement solution is 'How to change that sentence on the page.' Navigation copy, product names in the text, and internal link text scattered in many documents, it is not realistic to change them one by one manually. AnQiCMS provides a website replacement tool for batch keyword or link replacement, covering a batch of documents in one task. It changes the content data, but does not change the address structure, so it will not replace the old links with the corresponding new links for you.

The difference between the two is that redirection is responsible for external references, and replacement is responsible for the reader's reading. The revision needs to be done at the same time, but the order is fixed.

Determine the URL rules first, then move the content.

The content of the redirect table depends on what the new address looks like, so the new rules must be established first. The static rule management is responsible for this: determining the path forms of category pages, document pages, and tag pages, confirming the file extension, hierarchy, and whether to include a trailing slash. Once the rules are switched, the internal link text written in the site-wide replacement has a target address to refer to.

This common mistake is to change rules while publishing articles. The new rules are not finalized and the main text is replaced, then the rules change again, and all the links previously replaced point to non-existent addresses, resulting in a larger amount of rework than not doing anything. This is more obvious in a multi-site environment: a set of rules is applied to multiple sites at the same time, and errors will occur together.

The redirect table must be set up before the switch.

It is recommended to establish a fixed order of four steps:

First step, export the old addresses in full, group them by category, mark which correspond to pages in the new structure, which should be merged, and which are ready to be retired.

Step two, when the new template is deployed but the traffic has not been cut yet, add the redirect table to the 301 redirect management, verify it once with a small number of addresses to confirm that the returned status code is a permanent redirect and not a temporary redirect.

Step three, cut the traffic, observe the crawling and collection logs, and confirm that the requests for the old addresses are all received.

Step four, do a full site replacement, change the old copy and the internal link text in the body at one time, and check several pages after replacement to see if there are any incorrect replacements.

The benefit of redirecting before replacing is that the old address can always reach the content at any time, and the switch is gradual rather than cliff-like.

Inspection points for batch verification of multi-site verification

Multi-site management allows a single backend to manage multiple sites, which brings a unique trap of the redesign: when five sites are cut and observed simultaneously, it is impossible to determine which site's rules are incorrect when a problem occurs.

The batch approach is to queue sites. First, choose the site with the smallest traffic to redesign, complete the jump table and full-site replacement, and then wait for a round of crawling cycle to pass. Confirm that the inclusion and new address are correct, and then push the next site. After each site is redesigned, leave three checkpoints: the return status code of the old address, whether the new address renders normally, and whether the address in the site map has been changed to the new rules.

Replace tasks need to confirm an additional matter: does the replacement range exceed other sites? The full-site replacement is executed based on conditions, and if the conditions are written broadly, it is easy to change the content of unrelated sites. It is safer to run a small-scale trial on a single site first compared to executing it across the entire site.

Sequential reference table

Common questions

Should we back up the old address before the revision?Yes. The full site replacement is an irreversible batch write, so make a backup before the revision. If it goes wrong, it can be restored directly, which is much faster than rolling back article by article.

Can the jump be made for the old address that has been invalid for a while?Yes, but you need to confirm first that these addresses still exist in external links and search caches. The jump is only meaningful for addresses that are still being visited, and adding them for addresses that no longer are does not create value.

Can we only replace and not jump?It only applies to the main text. Not creating a jump when the address changes is equivalent to leaving all external references in place, with the old page going from 200 to 404. The time saved by replacing it will be doubled in the loss of inclusion.

What should be done when the rules of multiple sites are inconsistent?Set up jump tables separately and verify them. The unified management of multiple sites is the backend entry, not the address rules. Forcing inconsistent rules to merge will make it harder to trace.