So Outside Technology Security CMS
AnQiCMS
Online Demonstration

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

📅 2026-11-01 👁️ 0

When managing multiple sites with a single background, how to plan the column structure and classification so that they do not interfere with each other? The key is to separate the 'reusable definition' and 'data that must be isolated': the definition of the content model can be shared among multiple sites, and the classification tree, column alias, and access scope must be maintained separately for each site; batch operations that affect the entire site are high-risk capabilities, which are closed by default and need to be opened separately for each site as needed.

What things are inherently shared in multi-site management

AnQiCMS's multi-site management capability is to hang multiple independent sites in the same background, with each site having its own domain name, template and content library. What is shared is the program layer and definition layer: the same program code, the same set of content model definitions, and the same batch of administrator roles; what is independent is the data layer: each site's articles, categories, tags, sitemap, and access logs are counted separately.

Determine whether a configuration should be shared or isolated, you can ask a question: Will it affect the content seen by readers on another site after modification? If so, isolate by site; if it only reduces the editor's repetitive labor, it can be shared.

Three ways to split the category tree by site

The first is to split by brand. Each site has an independent tree, and the same column name is allowed to exist because the scope has been isolated by the site. It is suitable for the coexistence of the main site and sub-brand sites.

The second type is segmented by language. Multi-language sites share the same theme structure, and column names use different language versions of the same set of theme words to avoid the number of columns in the translated site being inconsistent with the main site, leading to incorrect classification of the main text.

The third type is segmented by business isolation. The corporate website and information site share the same backend, but the categories of the information site are not allowed to appear in the navigation of the corporate website. In this case, in addition to checking the category itself, you also need to check the column alias and address prefix to prevent the two sites from growing into identical URLs.

Configuration item Suggested attribution Reason
Content model definition common Consistent field structure can reduce redundant maintenance
Classification tree and hierarchy Independent by site If the site theme is different, forcing unity will force out empty categories.
Column alias and address prefix Independent by site Alias collision will directly affect the pseudo-static address
Tag Independent by site Tags will be referenced by anchor text and recommended positions
Site map Generated separately by site The scope of collection must be consistent with the site content
Full site replacement, batch change columns Default closed, opened by site One wrong operation will affect all sites

Which layer can the content model be shared on

Custom content models support flexible content structures, and it is a common practice to define a model that can be reused across multiple sites. The reusable part is the collection of fields, such as 'products', 'help documents', and 'cases', and which custom fields they each have; the non-reusable part is the filling strategy and display rules of the fields, as the depth of columns and navigation positions differ between sites.

In practice, it is recommended to retain a 'site-level coverage' layer: the model definition is unified, and when it comes to a specific site, it is allowed to enable only a part of the fields. Do not display empty fields, and do not force a site to fill in meaningless columns for the sake of a unified structure.

Why the standalone operation for the entire station

The risk of cross-site batch operation lies in the easy to ignore scope. Backup and recovery, upgrade, and switching between multiple sites all belong to the entire station operation, such high-risk capabilities are not exposed by default on the interface and automation side, and need to be explicitly enabled; still need to confirm the scope of the selected site before execution, don't take the 'selected site' as 'all sites'.

A rule that can be implemented: any action that will change multiple text or column structures at one time, first run on one site, check the results before expanding to the second site.

Implement the plan in this order.

First, determine the list of sites and the boundaries of each site, then define the common model, and then build the classification tree and alias rules for each site one by one, and finally configure the navigation and site map. After each step is completed, check three things: whether the new address is duplicated with another site, whether the navigation only appears in the classification of this site, and whether all addresses in the site map belong to this site.

Common questions

Can the column names of two sites be the same?Yes, the scope of the classification name is within the site, but the addresses generated by the column alias should avoid cross-site duplication.

Should a separate set of categories be built for multilingual sites?It is recommended to continue to use the same thematic structure, only changing the language writing, which is convenient for the translation of the entire page, so that the text can still match the location.

How to converge after it has been disorganized?First, list the correspondence between the categories to be retained and the articles in a table, use the site-wide replacement tool to batch change the existing expressions, and then inspect, backup, and navigate separately by site after the changes are made.

The content model has changed fields, will it affect another site?The shared definition means that the field structure changes at the same time, confirm that both sites can accept the new fields before making changes, and then fill in the data separately.

Related articles

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

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

Set the article for timed publishing to be released on time, and check whether the main content page, list and home page cache, and sitemap are in sync. Static generation and state transition are two steps, the cache of the list page is often behind the detail page, and the new address also needs to enter the sitemap and cooperate with link push, so that the timed publishing can truly be seen.

2026-11-01

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

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

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

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