Technical SEO Before a New Zealand Website Changes CMS

Key Insights

• A CMS change can alter URLs, rendering and index controls even when the design appears unchanged.
• Inventory the current site and preserve its important search destinations before approving the migration plan.
• Release checks need saved content, real public responses and an owner who can act when a critical route fails.

The new website looks ready. Its templates are cleaner, the content team can edit pages and the launch date is approaching. Then someone notices that the new CMS has changed the URL format, removed a group of product downloads and added an index-control setting inherited from staging.

For a New Zealand business, a CMS migration can put established search demand at risk while the project still appears to be progressing well. Technical SEO needs to enter the migration before the old site is replaced. A late review may find problems the team no longer has time to resolve properly.

The migration plan should explain what the business is preserving, what is changing and how each change will be checked. That gives developers, content owners and the commercial team a shared basis for the release decision.

Establish the site you’re moving from

Create an inventory of the current public URLs, including pages, downloads and other destinations that attract search visits or support customer journeys. Use the sitemap, a crawl and available Search Console or analytics data together. No single source is guaranteed to contain every important route.

Identify pages with commercial significance even if their traffic is modest. A specification, service page or customer-support document may serve a narrow audience that matters to the business. Don’t discard it simply because it doesn’t appear in the top traffic report.

Save the current titles, descriptions, canonicals and indexability alongside the URLs. Keep the page content and important internal links available for comparison. The migration team needs a reference for the public result, not just a list of CMS records.

Agree which pages will remain, merge or retire. A deleted route needs an intentional response. Redirect it to a genuinely relevant replacement where one exists; don’t send every removed page to the homepage because that is easier to configure.

Keep URL changes deliberate

Changing the CMS doesn’t always require changing public URLs. Ask whether the new system can preserve the established route before accepting a new format. Avoid combining several changes merely because the platform makes them convenient.

Google’s site-move guidance recommends changing major elements in stages where possible. For a project changing platform, design and domain, that is a reason to assess which changes need to happen together and which can be separated.

Where URLs must change, create an explicit old-to-new map. Include case differences, trailing slashes and important file routes. Test redirects for both their status and destination, checking that they lead directly to the intended replacement rather than through a chain.

Ask content owners to review merged pages. Two pages can appear similar to a migration script while serving different buyer questions. The replacement should retain the material needed by the people who used the original routes.

Check what the new CMS actually renders

Inspect the public page produced by the new CMS, including its initial response and rendered content. A correct field in the admin interface doesn’t prove that the template uses it. Check H1s, body text, metadata, canonicals, images and links against the approved source.

Review index controls in the deployment configuration as well as the CMS. Staging may be blocked intentionally, but that restriction must not reach the production release by accident. Confirm the production robots settings and page-level directives independently.

Test the templates that behave differently. A product page, article, location page and gated download can have separate code paths. One successful homepage check doesn’t establish that the rest of the site renders correctly.

This is where technical search verification should work with the development team. Search requirements need concrete public checks that can fail before the launch decision, while there’s still time to correct the result.

Preserve the journeys that produce enquiries

Open the internal links from important pages and follow the customer route. Check enquiry forms, booking tools and download links. A migration can preserve the article text while breaking the action a buyer needs to take next.

Submit approved test enquiries and confirm their destination. Check the information passed to the CRM, the product or service context and the confirmation received by the visitor. Keep test records identifiable so they don’t enter real sales reporting.

Verify analytics and campaign tags in the new environment. Historical comparisons become difficult when event names, conversion definitions or tagging coverage change without a record. Note intentional measurement changes and keep the commercial team informed.

Review mobile behaviour on representative templates. Navigation, tables and forms may pass a desktop inspection while preventing a phone user from completing the same journey. Test the interactions buyers use, not just whether the page fits inside a narrow screen.

Give launch day a decision owner

Agree who can stop or reverse the release if a critical condition fails. Identify the pages and customer routes that must pass before launch, and distinguish those from lower-priority corrections the team can make afterwards.

Have the rollback route ready before it’s needed. Restoring a prior deployment may not restore migrated content or database state, so the technical team must describe what recovery actually involves. Keep the decision proportionate to the failure and its commercial impact.

After release, repeat the public checks on the canonical production domain. Review old URLs, redirects, sitemaps and the content from each key template. Use Search Console to watch crawl and indexing observations as Google encounters the changed site.

Expect search data to take time to reflect the migration. Investigate concrete failures promptly, while avoiding an unsupported explanation for every short-term fluctuation. Preserve the evidence needed to tell a configuration problem from a change that requires further observation.

Make Technical SEO Part of the CMS Release Decision

Before the switch, establish the current site, approve the route map and test the new public output. Give the release owner clear pass conditions and a recovery plan. Those steps protect the customer journeys the new platform is supposed to improve.

If a CMS change is approaching without a verified search migration plan, bring Digital Squad into the technical review. We can help prioritise the routes, content and checks that need to survive the move.