Moving from WordPress starts with understanding what the website does for your business and what needs to improve. Content, URLs and functionality then need a clear place in the new setup. You can replace the entire platform or retain parts of WordPress and make the transition in stages.
We launched Astro as the new frontend of faerdermarketing.no on 24 October 2026. The frontend is the part visitors see and use. Here we use our own transition to explain the decisions involved, from planning to follow-up. It demonstrates a completed technical migration, without establishing any long-term SEO impact.
Decide what the move should achieve
Is it difficult to edit content, maintain functionality or connect the website to customer follow-up? Describe the task precisely. A slow form or outdated copy can often be improved within the existing setup. Consider changing platforms when the combined needs justify the work and ongoing responsibilities.
For us, custom code means being able to shape pages and functionality around how we work. We can review changes, build a new version and check it before publishing. We explain the reasoning in our article on WordPress, Astro and AI. This guide focuses on making the transition.
Our transition: Astro in front, WordPress for specific tasks
We kept the faerdermarketing.no domain and used the published content and existing URLs as our starting point. The Astro content lives in files with version history. WordPress remains in the background, but it is not the editing tool for the articles you are reading here.
| Part of the website | Our decision during the transition | What we checked |
|---|---|---|
| Public pages and articles | Astro displays content from project files. | Content, dates, languages, links and mobile layout. |
| Older images and documents | WordPress media stayed at their existing URLs. | Whether the files still opened from the new pages. |
| Enquiries and consent | Specific receiving functions stayed in WordPress. | Actual email delivery, error states and consent choices. |
| Old URLs | Retained where relevant, otherwise assessed individually. | Direct redirects to the right page and genuine error responses for unknown URLs. |
| Rollback | Previous configurations and backups were retained. | A documented route back if the launch failed. |
This gave us a transition with a defined scope. The WordPress part still needs updates, access controls and backups. Another option is to keep WordPress as the content management system and retrieve its content in Astro. Astro’s migration guide covers both retaining WordPress and moving to content files. The choice needs to suit the people maintaining the website.
1. Map content and functionality before building
Create one inventory recording each old URL, its purpose, the intended action and the person responsible. Include articles, services, projects, categories, author archives, images and downloads. Add pages found in search reports, advertising and important external links. An exported post count does not tell you whether every public URL has been covered.
Also record what happens after a click: who receives the form, and where does an order go? Is there search, login, booking or any integration? Describe the function rather than just naming a plugin. You can then decide what to retain, replace or retire.
Agree the editing workflow at the same time. A finished page is of little use if nobody knows how to change a price, contact person or opening hours. Use our guide to editing an Astro website to choose an approach and try everyday tasks before launch.
2. Protect the content, files and route back
The standard WordPress content export creates an XML file containing posts, pages and content information, among other data. It is not a complete copy of the website’s files and configuration. WordPress’s backup guide distinguishes between the database and files; both are needed to restore the entire site.
Check images, PDFs, captions and usage rights separately. Page-builder content may need manual work before it fits new templates. Preserve original publication dates and clearly identify historical information. Keep drafts, personal data and internal documents out of the public content.
Ask for a restoration to be tested in an isolated environment. Also establish who owns the domain, project files and required accounts. Refer to the guide to ownership and handover when agreeing these responsibilities.
3. Preserve useful URLs and plan any changes
Moving from WordPress to Astro does not in itself require new page URLs. We recommend keeping established URLs when the page still serves the same purpose. For URLs that change, record the old address, final destination and reason. Also update links in articles, menus, advertising and resources you control.
For a permanent move, Google recommends permanent redirects, such as 301 or 308. Send the old URL straight to a relevant replacement. Google’s site migration guide warns against sending many retired pages to an unrelated homepage and recommends retaining redirects for at least a year. Pages without a relevant replacement can return a genuine 404 or 410 response.
Check that public pages can be indexed, the sitemap contains the right URLs and each page declares the correct preferred address, known as its canonical. On a multilingual website, language versions need to reference each other. Test old links without logging in. An attractive error page with an “OK” status is not a correct error response.
4. Test the complete enquiry flow and its measurement
Our launch checks included a labelled test enquiry and confirmed receipt in the inbox. That is a different check from seeing a thank-you message on screen. For your setup, also confirm the correct recipient, reply address, any entry in the customer system and the person responsible for follow-up.
Try invalid fields, interruptions and rejected submissions, and check that visitors receive clear messages without unnecessarily losing their text. Test consent behaviour before and after acceptance, rejection and withdrawal. Check what actually loads and is sent, and make sure measurement does not count the same action more than once.
We retained the existing Google Analytics property but changed the consent and measurement setup. The launch therefore marks a change in measurement method. Enquiries in the inbox and recorded conversions are not identical measures. Preserve reporting history and document changes so a difference in the figures is not automatically interpreted as a change in demand.
5. Agree when to launch and when to roll back
Build and test the new setup before it takes over the public website. Agree who approves the content, who carries out the switch and who is available afterwards. Set a point for the final content synchronisation so changes made in WordPress during development are included.
- Before the switch: Check content, images, important URLs, languages, forms, access and backups. Decide which failures should block the launch.
- Immediately afterwards: Clear relevant caches and test the public website without logging in, on mobile and a larger screen. Confirm the most important actions.
- If a serious fault occurs: Have one responsible person who can restore the previous working version. Agree the threshold in advance, such as enquiries failing to arrive.
Rollback needs to preserve information received after the switch. An online shop needs a separate plan for new orders, payments, stock and customers; an old database copy can overwrite newer data. If the domain or hosting changes, email and its configuration also need separate attention. Our transition of an informational website is not a complete recipe for migrating WooCommerce.
We use ChatGPT and Claude to support ideas, coding and review. This makes it easier to explore solutions, but it does not replace checks of content, access, personal data and actual functionality. The same applies if parts of the new setup are created with Lovable or other AI tools.
6. Follow up once the new site is public
First check that important pages and enquiries work. Then monitor broken URLs, indexing, search performance and actual enquiries over time. Google describes how visibility can fluctuate during a migration. Thorough technical checks are useful, but they do not guarantee particular rankings.
Assign the ongoing work with the guide to follow-up after launch. Retire the old setup only once you know which tasks have moved, what is still in use and how necessary historical material will be preserved. Any system left running in the background needs a named owner.
What to bring when requesting a proposal
Bring your URL inventory, the functions that must work, who will edit the site and what you want to improve. Ask for migration, testing, training, maintenance and rollback to be described in the proposal. The guide to a new website helps you organise the requirements.
When we assess a website for your business, we look at which parts to improve, retain or rebuild. You do not need to choose Astro in advance. A clear objective and an inventory of what you already have provide a better basis for choosing the setup.
