A website redesign can make your services clearer and your enquiry process easier. But without an NDIS SEO migration plan, it can also remove the pages, content and links that help participants and referrers find you through Google.

The risk is not the new design itself. It is what changes underneath: page addresses, service descriptions, navigation, indexing settings and tracking. A website can look better while becoming harder to find.

This guide explains what to protect before, during and after a redesign, whether you are changing platforms, moving to a new domain or simply rebuilding an outdated provider website.

Why NDIS SEO needs a place in your redesign brief

A redesign and an SEO migration are related but different jobs. The redesign improves how your website looks and works. The migration preserves useful search signals as pages and technology change.

For example, your existing community participation page might attract people searching for that support in your service area. Replacing it with a short paragraph on a general “Our Services” page could weaken its relevance, even if the new layout looks cleaner.

Before approving a proposal, ask who is responsible for:

• Recording existing pages and their search performance.
• Deciding which content stays, changes or disappears.
• Mapping old page addresses to new destinations.
• Checking that Google can access the live website.
• Testing enquiries and monitoring performance after launch.

Give each task a named owner. Do not assume that “SEO-friendly website” includes migration work.

1. Record what your current website is doing

Before anyone deletes pages, build a simple baseline. You need to know which pages people find through search and which ones help generate relevant enquiries.

Export search and enquiry data

Use Google Search Console to export search queries and landing-page performance. Review several months where possible, rather than judging a page by one quiet week.

In your analytics platform, check which pages receive organic search visits and which are associated with enquiry actions. Distinguish a completed enquiry from a phone-link click: clicking a number does not confirm that a conversation happened.

Record:

• Organic clicks and impressions for important pages.
• Queries associated with your services and locations.
• Enquiry submissions and other tracked contact actions.
• Known links from directories, community organisations and referrers.
• Seasonal changes or service availability that could affect demand.

A page with modest traffic may still matter if it helps people find a specialised support. Do not make removal decisions on traffic alone.

2. Build a page inventory before changing the structure

Create a spreadsheet listing your existing page addresses. Your developer can use a website crawler, but also check your sitemap, Search Console and any pages used in referral materials.

For each page, record its service or purpose, proposed action, new address and person responsible. Use four actions: keep, improve, merge or remove.

Keep useful pages focused

Distinct services usually need enough space to explain what support involves, who it may suit, where it is delivered and how to enquire. Avoid combining unrelated services purely to make the navigation shorter.

If two pages genuinely serve the same need, merging them may make sense. Preserve the useful information and choose one clear destination.

Remove outdated information carefully

Do not retain an inaccurate service page just because it receives visits. If you no longer offer a support, decide whether there is a genuinely relevant replacement or whether the page should be removed.

Likewise, verify registration wording, service areas and availability before carrying content across. A redesign should not give outdated claims a fresh coat of paint.

3. Create a redirect map for every changed address

A redirect sends someone visiting an old address to its replacement. It also helps search engines understand where content has moved.

For permanent page moves, your developer should generally implement server-side permanent redirects, commonly called 301 redirects.

Your redirect spreadsheet should pair each changed old address with the closest relevant new page. For example, an old personal care service page should lead to its updated equivalent, not automatically to the homepage.

• Keep addresses unchanged where practical: a redesign does not require every URL to change.
• Redirect directly: avoid sending visitors through several intermediate addresses.
• Match the purpose: the destination should answer the same need as the old page.
• Handle removals honestly: where no suitable replacement exists, a proper 404 or 410 response may be more appropriate than an unrelated redirect.

Test the redirects before launch where possible and again on the live site. Keep useful redirects in place long term, especially where old addresses appear in printed material or external links.

4. Preserve the information people need to choose

New layouts often favour short headings and large images. That can work, but not if useful service explanations disappear.

Compare old and new versions of your priority pages side by side. Check that the new page still answers:

• What support do you actually provide?
• Where and how is it delivered?
• What should someone know before enquiring?
• What happens after they contact your team?

Keep clear page titles, descriptive headings and relevant internal links. Write naturally rather than inserting “NDIS” into every sentence.

Protect accessibility too. Use readable text, meaningful link labels and properly labelled forms. Important information should not exist only inside an image or a downloadable brochure.

If copy, design and search work are being handled separately, agree on one review process. Coordinated NDIS marketing services can help align those decisions with your actual service offering and enquiry process.

5. Check the technical settings before launch

Development websites are often kept out of search results while work is underway. That is sensible, but those restrictions must not accidentally carry over to the live website.

Ask your developer to confirm:

• Indexing settings: live pages intended for search do not contain unintended noindex instructions.
• Crawling access: robots.txt does not unintentionally block important pages or resources.
• Canonical tags: preferred-page references point to the correct live addresses, not the development domain.
• XML sitemap: it lists the intended live, indexable pages.
• Internal links: menus and content links lead directly to working live pages.
• Mobile performance: key pages and forms work comfortably on a phone.

Keep the development site protected appropriately; robots.txt alone is not a privacy measure. Avoid copying participant information into test forms or demonstration content.

6. Treat launch day as a checklist, not a finish line

Choose a launch time when your developer and intake team can respond to problems. Avoid launching immediately before everyone becomes unavailable.

Once the website is live, test your main service pages, old addresses, navigation, contact details and enquiry forms. Send a clearly labelled test enquiry and confirm that the right team receives it.

Check that analytics still records the intended actions without collecting sensitive form answers. Confirm Google Search Console access, submit the updated sitemap and inspect important pages using its URL inspection tool.

If you are also changing domains, add a separate domain-migration checklist. This should cover domain ownership, redirects, Search Console requirements and updates to key external listings. Keep control of the old domain so existing links can continue to work.

7. Monitor the pages that matter after launch

Some search fluctuation can happen while Google processes changes. That does not mean every decline is harmless, and no migration plan can guarantee unchanged rankings.

Check technical issues frequently during the first week, then review search and enquiry performance weekly over the following weeks. Compare equivalent periods and allow for changes in demand or service availability.

Investigate specific patterns:

• One service loses clicks: review its content, redirect, indexing and internal links.
• Many pages disappear from search: check site-wide technical settings first.
• Traffic holds but enquiries fall: test forms, contact options and tracking.
• Old addresses show errors: revisit the redirect map and missing pages.

Keep backups, the original page inventory and a record of launch changes. These make troubleshooting easier than trying to remember what moved.

Make search protection part of the project scope

A successful redesign should make your website easier to use without casually discarding the work that already helps people find you. Put the inventory, redirects, testing and monitoring into the project scope before development begins.

Planning a provider website rebuild? book a free strategy call with NDIS Advertising to discuss your migration priorities.

Frequently asked questions

Will a website redesign affect my NDIS SEO?

It can. Changes to page addresses, content, internal links and indexing settings can affect search visibility. A migration plan helps manage those risks, although temporary fluctuations may still occur and unchanged rankings cannot be guaranteed.

Should I keep my existing page addresses during a redesign?

Where they remain accurate and useful, keeping existing addresses avoids unnecessary migration work. If an address must change, redirect the old page to its closest relevant replacement and update internal links.

Can I redirect every deleted service page to my homepage?

That is generally not a good approach. Redirects should lead to relevant replacement content. If a service has been discontinued and there is no suitable replacement page, returning a proper 404 or 410 response may be more appropriate.

What should I check if organic enquiries fall after launch?

First test your enquiry forms, contact links and tracking. Then compare page-level search performance in Google Search Console and inspect redirects, indexing settings and content changes. A fall in recorded enquiries may reflect a tracking fault, a contact problem or reduced search visibility.