AnqiCMS (AnqiCMS) Template Tag Manual
Anchor text is the segment of text within an internal link, which determines how a search engine understands the theme of the page being pointed to. This article explains how to establish a keyword library, automatically add anchor text links to in-site keywords, control duplicate anchor text and link density, let the weight pass along with content relevance, and provide the steps and self-checking method for over-optimization of AnQiCMS anchor text management.
Static URL determines how the URL looks and whether it can be reliably indexed, while 301 redirect determines the weight of the old link and whether visitors will lose after the address changes. Enterprises consider these two items as infrastructure because once the address rules change after the growth of columns and articles, the impact is the entire site rather than a single page. It is recommended to first define the static URL rules, then converge the historical addresses, and finally check whether the sitemap and push are synchronized.
AnQiCMS provides four available deployment options: Baota panel one-click deployment, overseas version aaPanel, traditional LNMP command deployment, and directly pulling the Docker image anqicms/anqicms. The program listens on port 8001 by default, with the 80 and 443 ports forwarded by the reverse proxy. When choosing, mainly look at three things - whether there is already a panel hosting environment, whether containerized publishing is needed, and who is responsible for backups and rollbacks.
Scheduling is solved by time factors, error tolerance by the recycle bin: AnQiCMS divides documents into four states: formal documents, drafts, pending release, and recycle bin. Timely publication allows content to automatically become formal at the agreed time. Deleted formal documents can be recovered by entering the recycle bin, and drafts with the link preview=true can be previewed. With the cooperation of both, the content team does not need to rely on manual monitoring, and publication accidents can be rolled back within a few minutes.
The scheduled release at 2 o'clock in the morning cannot rely on human guards. The time factor is only responsible for going online on time, not for the quality of the content; the real control is the status transition and content review before release: drafts are responsible for writing, to be released for review, sensitive word filtering and keyword replacement are supported at the system level, and then the authority decides who can put the manuscripts into the to be released queue.
There are two ways to batch import articles: the background batch import of manually organized ZIP archives and Excel spreadsheets, suitable for one-time content migration; the document content import interface /api/import/archive is suitable for programmed content production and scheduled synchronization, you can check whether the title already exists before writing to avoid duplication. Check the title, category, tags, and fields before migration, and review the landing pages and links by category after migration.
Announcement of the test version written by oneself, 'Only suitable for test and development environments', means that a pre-release site with the same version, configuration, and data form as the official site is needed to carry out verification. The method is four steps: copy data副本 from the official library, replicate the environment according to the configuration of the official site, isolate the verification content with drafts and pending release status, and synchronize the conclusion to the official site after acceptance.
Before going live, use the online trial site to verify the function, which can help to discover three types of real problems in advance: the background action path is inconsistent with expectations, the function has an entry but lacks key configuration, and it is impossible to judge the scope of impact of batch operations. The trial site verifies the function and interaction, while deployment, data migration, and backup recovery require a separate test instance to be run independently, with two people responsible for a section of verification each.
When multiple site groups are redesigned together, first determine the new site's pseudo-static rules and set up the 301 redirect table, and then perform the full site replacement. The two actions modify different objects: redirection manages URL ownership, and replacement manages keywords and link text in the main text. The wrong order will allow the same round of crawling to see both old and new addresses at the same time, causing collection to fluctuate back and forth, and batch verification by site is the key to closing the mouth.
When multiple site groups share a set of scheduled release schedules, the impact of simultaneous online launch falls on the crawling and indexing queues: at the same time, a large number of page changes occur, the marginal benefits of crawling decrease, and the inclusion pace actually slows down. Peak-shaving is divided into three steps: group by site to open up time windows, give up the whole points, and reserve time slots for revision and backup; the order of priority is arranged according to the impact of inclusion, not according to the size of the site, and the status of pending release is used to carry the schedule instead of as a draft.
