Website Rescue & Redesign in Newcastle & the Hunter

There are three versions of this conversation. The site is ageing — the design has dated, the framework is behind, editing anything is a nervous exercise, and it is slowly drifting out of step with what the business actually sells. Or the site is fine and everything around it is not: a builder plan that renews at a number nobody can justify, a host that is slow or oversold, a platform that will not do the thing you now need it to do. Or nobody supports it. The person who built it has moved on, the agency wound up, the logins are with someone who left, and nobody has touched it in two years because nobody can.

What all three share is that nothing forces a decision. The site still loads. It is not visibly broken, so it stays fourth on the list, and the risk underneath it compounds quietly. A component with a publicly known vulnerability is exploitable by anyone who scans for it, whether or not a person ever decided to target your business. A certificate that lapses takes the site down with a browser warning that looks worse than an outage. An unsupported platform stops receiving fixes and the gap only widens. None of that announces itself.

So the first thing worth doing is not a redesign — it is an assessment. What do you actually control, what is genuinely wrong, and what would a fix cost against a rebuild? That answer sometimes comes back as "your site is fine, your hosting is the problem, and this is a migration rather than a project". We would rather tell you that than sell you a redesign you did not need, and if the honest answer is that the site should be rebuilt, we would rather say so before you spend money maintaining something that is not worth maintaining.

The risk in a redesign is not the design. It is the addresses. Every ranking your site holds, every link anyone has ever made to it, and every bookmark and QR code in circulation points at a specific URL. Change those addresses without mapping them and the history attached to them has nowhere to land — visitors and search engines both arrive at a 404, and the page's accumulated standing does not transfer to the new page just because the content did.

Redirects preserve what a page has already earned. They do not create rankings a page never had.

So the first artefact of a redesign is not a mockup. It is a URL map: every existing page, its current address, whether it survives the redesign, and exactly where it goes if it does not. We build it from a crawl of the live site rather than from the sitemap, because the two diverge more than anyone expects, and we cross-check it against Search Console and analytics data where that access exists, because the list of pages actually earning traffic is not always the list anyone inside the business has in mind.

The content side deserves the same care. A page that ranks does so partly because of what is on it: the headings, the depth, the specific words a customer typed. Redesigns lose rankings when a 900-word service page becomes a 90-word panel because the new template looked better with less text in it. Where a page is performing, we treat its content as a constraint on the design rather than the other way round.

One honest limit. Redirects preserve what a page has already earned; they do not manufacture anything it never had. A redesign will not make a page that ranks nowhere start ranking, and a rebuild on its own is not a search strategy — lifting visibility past the technical floor is ongoing SEO work, content and optimisation over time, which is a separate job with a separate budget. What a well-executed rebuild does is remove the technical drag — speed, structure, crawlability, accessibility, markup — that was holding the site back, and stop the redesign itself from costing you ground.

• →A full crawl of the existing site, so the map covers what exists rather than what the sitemap claims exists
• →Every URL mapped to a destination — kept as-is, redirected, or deliberately retired with a reason
• →Permanent server-side redirects, resolving in a single hop rather than through a chain
• →Content, headings and page titles preserved on pages that are earning traffic
• →Canonical tags, structured data and the XML sitemap rebuilt to match the new structure
• →Analytics and Search Console baselined before launch, so any change afterwards is measurable rather than argued about
• →A post-launch crawl for broken links and redirect errors, and Search Console checked for coverage errors once the new structure has been indexed

The reasons to move are ordinary enough: a builder subscription that renews at a figure disconnected from what it delivers, a host where pages are slow because your site is sharing a machine with a large number of others, a platform that cannot do the integration your business now depends on, or simply wanting to own the site rather than rent it from a company that can change the terms.

The website comes back in minutes. Mail flow is what costs a business its week.

Set expectations on what actually moves. Your content moves — text, images, documents, and in many cases a workable page structure. The build does not. An export from a hosted website builder gives you content, not a website: the templates, the platform's own features and anything relying on its app ecosystem exist only inside that platform and cannot come out of it, because there is nothing to export them into. That is not a reason to stay. It is a reason to scope the move as a rebuild with your content carried across, priced that way from the start rather than discovered halfway through.

Then there is the part that has nothing to do with the website. A migration ends at DNS, and DNS is not only the website. The record pointing your domain at a web server sits in the same zone as the MX records routing your mail, the SPF, DKIM and DMARC records that decide whether the rest of the world trusts mail from your domain, and the verification records tying your domain to a Microsoft 365 or Google Workspace tenant. Move the domain to a new provider and it will cheerfully populate that zone with its own defaults. The website comes up perfectly. The mail stops.

This is the clearest reason we think website work belongs with whoever runs the rest of your technology. It is not a question of carelessness. It happens because the website and the mail share one DNS zone while sitting with two different suppliers, and whoever is making the change can only see their own half of it. We run email, DNS, backups and security for clients, so on our migrations the mail records are recorded before anything moves, carried across as a deliberate step, and tested in both directions after the cutover. That is a standard part of the job for us rather than a favour, because they are records we already manage.

The rest is sequencing, and the sequencing is what separates a migration you notice from one you do not. Build on a temporary address. Lower the DNS time-to-live values a day or two before, so a wrong record can be corrected in minutes rather than propagating for two days. Move at a time when the business can absorb a problem, which is rarely 4pm on a Friday. Verify rather than assume. And leave the old hosting running and paid until you are certain, because a cancelled account is one of the few mistakes in this process with no undo.

• →The entire DNS zone recorded before anything moves — MX, SPF, DKIM, DMARC, autodiscover, tenant verification and anything else the domain is carrying
• →Time-to-live values lowered ahead of the cutover, so a mistake is reversible in minutes rather than days
• →The site built and tested on a temporary address before the domain is pointed at it
• →Certificates issued and confirmed on the destination, so the move does not land visitors on a browser security warning
• →Mail tested in both directions after the switch, and authentication checked as it is received rather than as it is configured
• →Redirects in place from the old structure if the URLs change during the move
• →The old hosting kept running until the move is confirmed, then cancelled deliberately rather than on the day
• →The domain registered to your business, with the registrar account in your name and MFA on it

We audit and remediate accessibility on sites we did not build, and the value of it is concrete rather than abstract. A site a keyboard-only user or a screen reader user cannot get through is not a matter of design taste. It is a booking form that cannot be submitted, a checkout that cannot be completed, and a customer who goes elsewhere without telling you why.

An overlay widget does not change the markup underneath it. Remediation means fixing the site.

The standard is WCAG 2.2, published by the W3C, and Level AA is the conformance level we audit and remediate against. The underlying Australian obligation does not come from the guidelines themselves — it comes from the Disability Discrimination Act 1992, which applies to the provision of goods and services, with the Australian Human Rights Commission's web access advisory notes pointing to WCAG as the practical measure. We are not lawyers and none of this is legal advice; if you need a compliance position for a tender, a contract or a complaint, get it from someone qualified to give one. What we can give you is a site remediated to the technical standard those positions are written against, and anything that cannot be fixed stated in writing rather than left for you to find. That second half is not a formality: on a site we did not build, some failures live inside components we cannot change, and those are recorded as documented exceptions rather than quietly counted as passes.

An audit is a scan plus the work a scan cannot do. Automated tooling catches a real and worthwhile portion of failures — missing alternative text, contrast below threshold, form fields with no label, invalid ARIA — and it is genuinely fast at it. What it cannot judge is whether alternative text actually describes the image, whether the focus order makes sense, whether an error message tells a screen reader user which field is wrong, or whether the whole booking flow can be completed without a mouse. That part is manual: keyboard-only traversal of every interactive path, screen reader testing, zoom and reflow at 400%, and checking the criteria WCAG 2.2 added — focus not obscured by sticky headers, minimum target sizes, an alternative to dragging, consistent help placement, and not making a customer re-enter what they already typed.

Remediation is then three different jobs wearing one name. Some failures are content-level and cheap: alternative text, heading order, link text that says where it goes, captions on video. Some are template-level: contrast, focus styling, semantic markup, labels and error handling, landmark structure. And some are structural, where the failure is baked into a theme, a page builder or a third-party widget. That last category has a limit and we would rather state it up front than bill you to discover it: where a failure lives inside a hosted script or a plugin's own markup — a booking widget, a chat bubble, an embedded map, an old PDF — the options are to configure it differently, replace it with something accessible, or record it as a documented exception. We cannot patch code that is served from someone else's server.

One thing worth saying plainly. An accessibility overlay — the JavaScript widget promising compliance in one line of code — does not change the markup underneath it. It layers a control panel on top of the same inaccessible page. Remediation means fixing the site.

• →Automated testing across the site to find the machine-detectable failures quickly and at scale
• →Manual keyboard-only traversal of every interactive path — navigation, forms, menus, modals, checkout
• →Screen reader testing, because valid markup and a usable experience are not the same test
• →Colour contrast, text resizing and reflow at 400% zoom
• →Form labelling, error identification and error suggestion — the failures that cost you enquiries directly
• →Heading structure, landmarks, link text and document order
• →WCAG 2.2 additions: focus visibility and obscuring, target size, dragging alternatives, consistent help, redundant entry
• →A written report of every issue against the specific success criterion it fails, ranked by user impact and by cost to fix
• →Remediation of what can be fixed, and a documented, honest exception for anything that cannot be without replacing the component

This one arrives with a familiar shape. The developer has stopped answering. The agency wound up. The person who set it all up left in 2021 and set it up under a personal email address. The domain renews on a card that has been cancelled. Nobody knows who the host is, and the only clue is a monthly charge on a statement that nobody has questioned in years.

If no backup was ever taken, there is no backup. Nothing we do afterwards creates a copy that was never made.

The first job is not the website — it is establishing what you actually control, because that decides everything after it. The anchor is the domain. Control of the domain registration is the thing genuinely worth fighting for, because with it a site can be rebuilt and mail can be re-established even if every other artefact is gone. Registrars have recovery processes for exactly this, and they turn on proving that the business is the registrant: company records, historic invoices, the ABN, identification. It takes time and paperwork, but it is a defined process rather than a dead end.

Now the part that is easier to leave off a web page. If nobody can get into the hosting and there are no backups, some things are genuinely gone, and nothing done afterwards brings them back. While a site is still being served, what it serves publicly can be captured — the rendered pages, the text, the images, and archived copies where a public archive happens to hold them. That is the output, not the build, and it depends on the site still being up: once a host suspends or removes it, even the public version is gone unless an archive holds a copy. The database behind it, the custom code, the unpublished drafts, and the admin-side records that never appear on a public page — form submissions, orders, customer accounts, historic enquiries — are not in the public output and cannot be reconstructed from it. If the host will not release the account, and there is no backup anywhere, those are not delayed. They are lost.

The same honesty applies elsewhere. A domain that lapsed and has been re-registered by someone else may not be recoverable at any price. Analytics history lives inside a Google account rather than inside your domain, so if nobody can open the account, that history may not come back — though a Search Console property can be re-verified from DNS once the domain is yours, which restores the search-side reporting for as far back as Search Console's own retention window reaches rather than for the whole history of the site. A theme or system a departed developer built and licensed to themselves may leave nothing to hand over at all. We will not tell you everything is recoverable, because sometimes it is not. What an access audit gives you is a clear statement of which category each thing falls into, which is worth knowing before you spend anything on the site itself.

Where the site is already compromised, a different sequence applies. Cleaning the visible symptom and carrying on is the mistake, because a site that was compromised through an unknown route is a site of unknown provenance. The assumption has to be that credentials are exposed, so everything gets rotated — hosting, CMS, database, FTP, and critically the mailbox, because a password reused between the CMS and email turns a website incident into a business email incident. Then the mechanical work: finding injected pages and spam content, checking whether the domain has been used to send mail and landed on a blocklist, checking whether search engines have flagged it, and getting the framework and plugins current. Where we cannot establish what was changed, rebuilding on known-good code is the safer answer, and we will tell you when we think that is the case rather than hand back something we cannot vouch for. If personal information may have been exposed, the Notifiable Data Breaches scheme may apply to your business and that is a question for your privacy or legal adviser — we will flag it, we will not assess it for you.