Can the content built by the page builder be exported completely, and which one should be checked before switching to the new system?
Can the content built by the page builder be fully exported? Generally not. What can be exported is the content record of the data layer, such as blog articles; the page layout, component style, and interaction configuration generated by the builder usually need to be rebuilt when switching to another system, and most of the time, it depends on manual sorting when migrating from a closed platform like Weebly. So what should you look at first when switching systems? The first thing to look at is not 'whether there is an export button', but 'whether the exported content is structured data': if you can get the export package of articles and fields, the migration cost is controllable; if you can only get screenshots or visual effects of the page, it is equivalent to rewriting the content.
Why is export capability a selection criterion
The value of the page builder is to quickly create a good-looking page, at the cost of content being tied to a specific component system. The same text, in the builder, is arranged in ten or more components, and in another system, it may be a completely different template structure. There is no common intermediate format between the two, and the export can only be degraded to plain text.
This should be confirmed during the selection, not during the migration. The judgment method is very direct: require the other party to provide an export list, to see if it includes the full text of the article, title, publication time, category, tags, custom fields, and media files; if only
The three levels of evaluating the export
| Level | What to investigate | Exportability | The actual cost of migration |
|---|---|---|---|
| Data layer | Full text of the article, title, time, category, tags, and fields | High, usually able to export structurally | Batch import can handle it |
| Structure layer | Page layout, component style, navigation, and block location | Low, mostly private format | Rebuild according to the template in the new system |
| Link layer | Correspondence between old URL and new URL | Depends on whether the address rule is retained | 301 redirect and replacement processing |
In the three layers, the data layer is most easily promoted as 'one-click migration', the structure layer is most easily ignored, and the link layer is most likely to expose problems after going online. When evaluating, ask the three layers separately: Can the data be taken away, do you need to redo the page, and will the old address fail?
Who will take over after migrating to the self-hosted system
Data layer handling relies on batch import. AnQiCMS supports batch import in two forms: ZIP compressed packages and Excel spreadsheets, and the articles package and table exported from the old station can be directly imported into the background; programmatic production or continuous synchronization goes through the document content import interface/api/import/archiveIt supports querying whether the title already exists to avoid duplicate import of the same batch of content.
The structure layer handling relies on the content model and template. Custom content models and custom fields determine whether the expanded fields of the old station can be matched one by one. If the field names do not match, either sort them before import or adjust the values in the template.
The link layer is supported by two places: the static rules determine whether the new address format can be consistent with the old address, if consistent, it can save half the work; when inconsistent, use 301 redirect to point the old address to the new address, and use the full site replacement tool to batch replace keywords or links, and clean up the addresses pointing to the old domain name in the text once.
Checklist before taking action
First export a small sample: export the content of 10 articles, product pages, and special topic pages, check if the fields are complete, and whether the image addresses in the text can be parsed.
Please double-check the category mapping: The old columns correspond to new categories, and there should be a fallback rule for columns not listed, to avoid the imported content being scattered in a default category.
Then plan the address and redirection: Organize the old URL format into a table, indicating which can be retained as is and which must be redirected with 301, so that the redirection table takes effect on the day of launch rather than after the launch.
Finally, confirm the rollback path: Make a full backup before migration, including data and static files, so that you can roll back to the original state and investigate in case of import exceptions rather than continuing to overwrite on incomplete data.
Common questions
Is there no export method at all on the builder page?The visual layout cannot be exported basically, only the text and images within can be exported. The practical approach is to export the text and materials and rearrange them in the new system, do not expect the component structure to be restored as it is.
How to determine if the exported package from the old site is usable?Check three things: whether the field has a title and publication time; whether the main text is directly parseable marked text; whether the media files are provided with the package or a list of downloadable addresses is provided.
Is it okay to handle it after going online?Not recommended. After the old address becomes invalid, external links and search收录 will point to dead links, the later the handling, the greater the loss, and the jump rules should be launched with the content.