A website update should not leave participants wondering whether a service is still available, a support coordinator searching for the right referral information, or a family member unable to read a contact form on their mobile. A Classic Editor migration is often treated as a small WordPress administration task. For an NDIS provider, it is also a continuity and accessibility task.
If your website team is moving from the Classic Editor to the block editor, or restoring the Classic Editor while a site is being rebuilt, plan the change around the people who rely on your information. The editor is only the tool. Clear service details, accessible pages and accurate contact pathways are the outcome.
Start the Classic Editor migration with a clear decision
WordPress offers two main writing experiences. The Classic Editor works much like a traditional document field, with one main editing area and a familiar formatting toolbar. The block editor, often called Gutenberg, builds pages from separate blocks for paragraphs, headings, images, buttons, columns and other content.
Neither option is automatically right for every organisation. The block editor can give staff more flexibility when creating structured pages, such as service information, referral guidance or event notices. It can also make reusable page sections easier to manage. However, that flexibility can create inconsistencies when several people edit a site without agreed templates.
The Classic Editor may suit a small team that already has a stable website design and mainly updates news posts, contact details and straightforward service pages. It reduces the number of layout controls available to casual editors. That can be helpful where staff need to make a safe change quickly without accidentally moving a button, deleting a heading or altering a page layout.
Before changing settings, identify what you are actually migrating. You may be moving content into blocks, changing which editor opens by default, or returning to the Classic Editor because an older theme or plugin does not work well with blocks. These are different jobs, with different risks.
Check what people depend on before you switch
Create a copy of the website in a staging environment first. A staging site is a private test version, not the public site that participants and referrers use. Make the editor change there and ask the people who regularly update the site to test it.
The pre-migration check should cover more than page appearance. Review these four areas:
- Service information: Verify eligibility details, service areas, contact numbers, referral instructions, opening hours and emergency information.
- Accessible content: Check heading order, meaningful image descriptions, readable text size, colour contrast, keyboard access and link wording.
- Essential functions: Test enquiry forms, downloadable documents, newsletter sign-ups, maps, booking tools and any participant portal connection.
- Editorial workflow: Confirm who can publish changes, who checks accuracy, and how urgent updates are approved outside usual business hours.
For disability service websites, a page can look correct and still be difficult to use. A button that says simply “Click here”, for example, does not explain where it leads when read out of context by a screen reader. A migration is a useful opportunity to replace vague links with clear wording such as “Read our support coordination information”.
Also check content created by page builders or custom fields. These may appear outside the normal WordPress editor. Switching editors will not necessarily damage them, but editing the page without understanding its structure can. Leave complex pages to the person who built them until the team has tested the process.
How to configure the editor safely
A Classic Editor plugin can restore the older writing screen and, depending on its settings, allow users to choose between editors. After it is installed and activated by a site administrator, go to the WordPress Settings area and open the Writing settings. The exact labels can differ slightly between plugin versions, but the key choices are usually the default editor and whether users may switch editors.
Setting the Classic Editor as the default gives all authorised editors the familiar screen when they create or amend content. Allowing users to switch editors is more flexible. It is often best during a transition, when a web administrator is converting selected pages to blocks while other staff continue making routine updates in the Classic Editor.
There is a trade-off. Giving every user a choice can make troubleshooting harder. One staff member may edit a page in blocks while another opens it later in the Classic Editor, creating confusion about what can safely be changed. If your website has several editors, use a written rule: identify which editor is used for posts, simple pages, complex landing pages and documents.
For a small provider, the practical configuration may be simple: keep the Classic Editor as the default, limit publishing permission to trained staff, and allow the web administrator to test block-based pages on staging. Just activate, configure, test and document the decision. Do not make the public site the test environment.
Keep a rollback option
Take a full backup before changing plugins, themes or editor settings. A useful backup includes website files, the database and uploaded documents. Check that it can actually be restored, preferably on staging. A backup that has never been tested is only a hopeful plan.
Record the existing WordPress version, active theme, active plugins and editor settings. Take screenshots of key pages before the migration. If an issue occurs, this record helps a developer identify whether the editor change caused it or exposed an older compatibility problem.
Avoid updating WordPress core, changing themes, replacing several plugins and migrating editors all on the same day. Combining changes may save time initially, but it makes faults far harder to trace. Make one controlled change, check the result, then move to the next.
Move content without losing its meaning
When converting a Classic Editor page to blocks, WordPress may place existing content into a Classic block. That is not necessarily a problem. It preserves the content while giving you time to convert sections gradually. Do not feel pressured to rebuild every page immediately.
Prioritise high-use pages first: contact details, supports offered, referral pathways, complaints information, privacy information and any current announcements. Review each converted page on a desktop, tablet and mobile. Check the published page, not only the editing screen.
Be careful with copied content. Text pasted from a PDF, email or Word document can bring odd spacing, unnecessary formatting and inaccessible headings. Clean it as you go. Use proper heading levels rather than making text bold and larger to look like a heading. Use numbered or bulleted lists only where the information is genuinely a list. Keep paragraphs short enough to be read comfortably.
Images need equal care. Add alternative text that describes useful information, not decorative details. For example, “Support worker and participant discussing a weekly plan at a table” may assist understanding. An image used only as decoration may not need alternative text at all. Do not write “image of” before every description.
Set simple publishing safeguards
The safest website process is one that staff can follow when they are busy. Build a short checklist into your publishing routine: confirm the information is current, preview the page, test every button or form, check the page on mobile, and have another person review significant service changes where possible.
Use roles carefully. Contributors can draft content without publishing it. Editors can review and publish. Administrators should be limited to people responsible for technical settings, plugins and user accounts. This separation supports accountability and reduces the chance that an everyday content update changes a critical configuration.
If several people receive requests to update the site, use one agreed channel for those requests. Include the exact wording required, the page to change, who approved it and the deadline. This is especially useful for temporary changes to availability, group programs or contact arrangements. It protects both accuracy and staff time.
Holy Care Support Services can also use this approach when reviewing local service information across Adelaide: keep pages easy to update, but make sure each change remains clear, respectful and checked before publication.
Measure whether the migration is working
A successful migration is not measured by whether the new editor looks modern. It is measured by whether staff can publish accurate content confidently and whether visitors can find and understand what they need.
After the change, ask editors what slowed them down. Look for repeated formatting mistakes, abandoned drafts, support requests and pages that take too long to update. Ask a trusted person outside the website team to find a service, submit an enquiry and locate complaints information using only a mobile. Their experience will reveal more than an internal technical check alone.
Keep reviewing the setup as WordPress, themes and plugins are updated. The right editor choice can change as your team, website and participant needs change. A careful, reversible process leaves you free to improve the site without putting essential information out of reach.
