Business email is the one service most companies never think about until it stops working. Moving it to a new provider can feel risky, because your invoices, customer conversations and supplier contacts all live in those mailboxes. With a little planning, the move is straightforward, and the steps below cover what to do before, during and after the switch.
The reasons are usually practical. You are changing hosting providers anyway, your current mailbox is running out of space, or you want your email hosted somewhere with better support and security. Sometimes the move is about having your email, website and domain under one roof so there is a single provider to call when something goes wrong.
Start by taking stock of what is actually in your email system. Beyond the messages themselves, most businesses hold contacts, calendar appointments and rules or filters that have been built up over years. Export copies of your contacts and calendar from your current provider, and note any shared mailboxes or aliases such as info@ or sales@, because those are easy to forget in a migration.
Keep your old service running until the move is complete. The goal is to copy your data across, not to delete it at the source. Once the new mailboxes are working and you have verified the content arrived, you can close the old account at your own pace.
Tell your team what is happening before the cutover. Everyone should know the date the switch happens, whether their email address stays the same, and what to do if they cannot connect on the morning of the move. If your staff use email signatures, prepare the updated versions in advance, because a signature that still carries the old provider's settings is a small detail that looks unprofessional after a migration.
Your new provider will usually offer a way to bring your old mail across. Many providers offer a migration tool that connects to your old mailbox and copies the folders and messages into your new one. If no tool is available, a standard IMAP connection can do the same job: your email app connects to the old server, downloads everything, and uploads it into the new account.
Large mailboxes take time, so start the copy well before your switchover date rather than on the morning you planned to cut over. Check afterwards that your folders arrived intact, including the sent items, because a migration that copies only the inbox has not copied everything.
The moment that actually moves your email is the change to your MX records. The MX record in your domain's DNS tells other mail servers where to deliver messages for your domain. Until it changes, mail keeps flowing to your old provider. When it changes, new mail starts arriving at your new provider instead.
Because the MX record lives in DNS, the cutover usually takes effect within a few hours as the change spreads. During that window, some senders may still deliver to the old server while others go to the new one. That is normal, and it is exactly why the old mailbox should stay active for a while. Messages sent during the overlap can be forwarded or copied over afterwards.
Once the MX record has updated, test the basics before you announce anything. Send a message to your own address from an external account such as a personal email and confirm it arrives in the new mailbox. Send a message out and confirm it is delivered, ideally to a couple of different providers. Update your phone, tablet and desktop mail apps with the new server settings, and check that shared mailboxes and aliases are working.
If you have email authentication records, confirm they were carried across correctly. SPF and DKIM records are tied to the server that sends your mail, so a new mail server may need new records, and a missing record is the classic reason a freshly moved business suddenly lands in spam folders. Your provider should check these for you as part of the move.
Plan to keep the old mailbox active for at least a week after the cutover, longer if your industry deals in slow-moving correspondence. Automatic replies, old invoices and system notifications can arrive days later, and it is much easier to forward stragglers from a live mailbox than to recover them from a closed account. Set a reminder to close the old service once nothing has arrived for several days.
Hosting Australia includes free migration of your website and email when you move to our hosting, and the team handles the mailbox copies, the MX cutover and the record checks as part of the process. If you are planning to move your business email, contact us first and we can confirm what needs to be exported, what the cutover involves and how to keep your mail flowing through the change.
At some point most businesses think about moving a domain name to a different provider. The reasons vary: better prices, a support team that answers, or simply having everything in one place. A domain transfer sounds technical, but it is a routine process that runs every day. The key is understanding what a transfer actually does, because it is not the same as changing your website or your email.
A domain transfer moves the management of your domain name from one registrar to another. The registrar is the company that holds your domain's registration and handles renewals. After a successful transfer, your new registrar manages the domain, sends the renewal reminders and deals with changes to its details.
Importantly, a transfer does not move your website or your email. Those services are controlled by DNS records, and the records stay exactly where they are unless you change them. If your hosting stays where it is, your website and email keep working through the transfer without interruption. This is the detail that surprises most business owners, and it is also the detail that makes transfers safe.
Transferring is worth considering when you want to consolidate your domains with one provider, when your current registrar charges more for renewals, or when you simply do not trust the company holding your most important digital asset. Moving your domains to the same provider as your hosting can also simplify things, because renewals, invoices and support all live in one place.
Many businesses transfer when they move their hosting, even though the two processes are separate. It is a good moment to review your domain portfolio, update contact details and decide which names you actually need.
If your goal is to point your domain at a new website, or to change where your email is delivered, you do not need a transfer at all. Those changes are made with DNS records, usually nameserver changes, and they can be done through your current registrar in minutes. Transferring the domain instead would change nothing about your website or email, and it would add an unnecessary step. If you are not sure which process you need, ask your provider before starting anything.
To transfer a domain you typically need three things: the domain must be unlocked at your current registrar, you need an authorisation code (sometimes called an EPP code), and you need access to the registrant email address on the account. The code is a password that proves you control the domain, and it is generated by your current registrar.
For Australian domains there is an extra layer. A .au domain can only be transferred if the registrant remains eligible under auDA rules, so the ABN or ACN linked to the domain must be current and match the registrant. If your business details have changed since the domain was registered, fix them before you start the transfer, or the new registrar's checks can fail.
Once you have requested the transfer with your new provider, the process usually runs like this. Your new registrar submits the transfer request to the registry using the authorisation code, and your current registrar sends a confirmation email to the registrant address. You approve the request, and the transfer completes, typically within a few days. Most transfers include at least a year of renewal at the new provider, which is why the fee can look higher than a standard renewal.
Do not start a transfer when your domain is about to expire. Renew it first at your current registrar, or time the transfer so there is plenty of room before the expiry date. Domains that were registered or transferred very recently may also be locked for a short period, so check before you begin.
Most transfer problems come from the same handful of mistakes. The confirmation email goes to an old address nobody checks, so the request lapses. The domain is still locked at the old registrar. The registrant details no longer match the current business, which matters for .au domains. Or the transfer is started during a busy period and forgotten, leaving the domain with no provider actively managing its renewal. Each of these is avoidable with a quick check beforehand.
A transfer is a good excuse to look at every domain your business holds. Businesses often accumulate names over the years: an old brand, a project that never launched, or a defensive registration that has been renewing quietly. Decide which ones you still use, which ones protect your main name from confusion, and which ones can be allowed to lapse. Consolidating a handful of domains onto one registrar, with one renewal date and one invoice, is easier to manage than tracking them across several accounts, and it reduces the chance that a forgotten domain expires without anyone noticing.
Domain transfers are an everyday task for the Hosting Australia team. We can check whether your domains are ready to move, confirm the registrant details are correct for .au eligibility, handle the transfer request and make sure renewals land in the right place afterwards. If you would like your domains consolidated onto one account, contact us and we can walk you through what is involved.
Many small business owners assume their website belongs to them because they paid for it. The reality is more complicated. A website is made of separate parts, and each part has its own owner. If the details were not set up correctly at the start, you can discover years later that the person who built your site also holds the keys to it. This guide explains how ownership works and how to check yours in a few minutes.
Your website is really three services working together. The domain name is your address, such as yourbusiness.com.au. The hosting is the service that stores your website files and serves them to visitors. And the design and content are the pages, text and images that make up the site itself. These can be owned, controlled and billed by different people, and they often are.
That separation is normal and useful, but it becomes a problem when the people who control each part are not the people who should. The safest arrangement for a business is simple: the business owns the domain and the hosting account, and any designer or developer works on them with permission rather than owning them.
Every domain name has a registrant, the person or organisation legally registered as its owner. In Australia the registrant for a .com.au domain must be a commercial entity, and the name must match the registered business details. Whoever is listed as the registrant makes the important decisions: renewing the domain, changing its details, transferring it to another provider or selling it.
If a web designer registered your domain under their own name because it was convenient at the time, they are the registrant, not you. That works while the relationship is healthy, but if the designer closes their business, disappears or the relationship ends badly, you can be locked out of your own address. Customers who type your domain could land on a parked page or a competitor, and recovering the name can take weeks of paperwork.
Your hosting account is controlled by whoever opened it. The account holder receives the login details, the invoices and the support access, and they decide who else can get in. If your website was built on the designer's hosting account, the designer controls your files, your databases and your email, and you may have no way to reach any of them if the relationship ends.
Hosting accounts should be opened in the business's name, with the business's own contact details and a business email address that the business controls. The designer can still be added as a user with the access they need to build and maintain the site, but the account itself stays yours.
Design and content are covered by copyright, which means ownership depends on who created the work and what your agreement says. Work created by a designer for a client does not automatically belong to the client unless the agreement assigns it. Most professional designers license the finished website to the business, and some keep the rights to templates or code they reuse across clients. A written agreement should state clearly what the business owns and what the designer retains, so there are no surprises later.
Ownership rarely gets tangled on purpose. It drifts through small decisions: registering the domain on the spot during a meeting using the designer's account, hosting the site under the developer's plan because it was cheaper, or using the developer's email address for renewal notices. Each decision seems harmless at the time, and each one moves a piece of your online presence out of your control.
You can check where things stand right now without any technical knowledge:
If any of those checks fail, fix the issue while the relationship is still friendly. Updating a registrant or moving hosting to an account in your name is straightforward paperwork when everyone cooperates, and it becomes much harder after a dispute or a closure. If your domain details no longer match your current business, correct them now, because .au renewals are checked against active ABN and ACN details.
Your website should work for your business, not hold it hostage. If you are unsure who owns your domain or hosting, or you would like help moving them into your name, the Hosting Australia team can check the current setup with you and make the change safely.
A business website can look polished and still fail at the moment a customer needs it. If the site cannot be reached, visitors cannot read your services, submit an enquiry, make a booking or complete a purchase. That is why website uptime deserves attention from business owners, not only from technical teams.
Uptime describes the proportion of time a website is available and responding as expected. It is often presented as a percentage, but the practical question is simpler: can customers use the site when they need it? Understanding what affects availability, how it is measured and what happens after an alert helps you make better hosting and maintenance decisions.
At its simplest, an uptime check sends a request to a web address and records whether it receives a valid response. Repeating that check over time creates a record of availability. A monitoring service can then alert the nominated person when repeated checks fail.
That basic result is useful, but it does not tell the whole story. A home page may respond while a contact form, customer login, product search or checkout is unavailable. A cached page may also load even when the database behind other parts of the site has a problem. For a small brochure website, checking the home page and contact page may be enough. For an online store or booking system, important customer journeys should be checked as well.
Uptime is also different from speed. A site can technically be online but respond so slowly that visitors abandon it. Availability monitoring and performance monitoring answer related but separate questions, so both deserve a place in a practical website plan.
Hosting infrastructure is one part of availability, but it is not the only part. A website depends on a chain of services that includes the domain name, DNS records, the hosting server, the application, the database, security certificates and sometimes external platforms.
An expired domain or incorrect DNS change can make a healthy server unreachable. A failed plugin update can break WordPress while the hosting platform continues to operate normally. A full storage allocation, traffic surge, configuration mistake or malicious attack can also interrupt service. Third-party tools such as payment gateways, booking systems and embedded forms may fail independently of the website itself.
Start with the parts of the site that support real business activity. That normally includes the home page, a key service or product page, the contact page and any login, booking or checkout path. If email enquiries are important, regularly submit a test form and confirm the message reaches the correct inbox. A page loading successfully does not prove that form delivery is working.
Alerts also need a clear destination. Sending notifications to an old developer, a former employee or an inbox that nobody checks defeats the purpose of monitoring. Use a business-controlled address, nominate a backup contact and document who should respond.
Monitoring tells you there is a problem. A response plan determines what happens next. Keep the hosting provider's support details, account access and website contacts somewhere authorised staff can find them without relying on the unavailable site.
The plan should identify recent changes because they are often useful clues. Record plugin updates, content deployments, DNS changes and new integrations. When an incident occurs, note what visitors see, which pages are affected and whether the issue appears on more than one device or network. Clear information helps a support team investigate without repeating basic discovery work.
Backups are part of recovery, not a substitute for uptime. Confirm that both website files and the database are included, understand where copies are stored, and know how a restore would be requested. Hosting Australia's current business hosting information lists secure off-server backups and a JetBackup control panel among its package features, but every business should still confirm that the backup arrangement matches its website and recovery needs.
An uptime statement is useful only when you understand what sits behind it. Ask a prospective provider how availability is monitored, how incidents are communicated and what support channels are available when something goes wrong. Check whether planned maintenance is excluded from reporting and whether different services, such as email and websites, are measured separately.
Responsibility should be clear. Hosting providers manage infrastructure and services within the scope of the selected plan, while website owners or developers may be responsible for application updates, plugins, content and external integrations. Knowing where each responsibility begins prevents important work from being assumed rather than assigned.
If you are unsure whether your current hosting and monitoring arrangements match the way your website is used, contact Hosting Australia. The team can discuss your site, its workload and the support options available so you can make a practical decision based on business needs.
Shared hosting is a sensible starting point for many small business websites. It keeps server management simple, suits common brochure sites and blogs, and lets a business focus on its customers rather than infrastructure. A virtual private server, or VPS, becomes worth considering when the website's workload, control requirements or growth plans no longer fit comfortably within a shared environment.
Moving too early can add cost and administration without solving a real problem. Moving too late can leave a busy website struggling during the moments when it matters most. The right decision starts with evidence: what the site does, where its limits are appearing, and who will manage the new environment.
On shared hosting, many customers use the same server platform. The provider manages the underlying system and gives each account access to an allocated set of features and resources. This arrangement can work well for sites with straightforward requirements and predictable activity.
A VPS still runs on shared physical hardware, but virtualisation gives it an isolated portion of resources and its own operating environment. Depending on the service, that can provide more control over software, configuration, memory and processing capacity. Hosting Australia's VPS range, for example, offers dedicated portions of server resources and a choice of operating systems.
That extra control also brings responsibility. With an unmanaged VPS, someone needs to handle operating system updates, security configuration, monitoring, backups and troubleshooting. A managed option can reduce that burden, but it is important to confirm exactly what management includes. A VPS is not automatically faster or safer simply because it is a VPS. It still needs suitable configuration and ongoing care.
One slow page does not prove that a hosting plan is the problem. Large images, inefficient plugins, external scripts, database queries and poor caching can make a website slow on any server. Before upgrading, test important pages, review recent changes and ask the host whether the account is regularly reaching resource limits.
A move may be worth discussing when there is a repeatable pattern rather than a one-off incident. Useful warning signs include:
These signs should begin a technical review, not trigger an automatic migration. A well-optimised site on an appropriate shared plan may perform better than a poorly configured VPS. Ask for measurements and identify the actual bottleneck before choosing a solution.
A small brochure site with occasional updates may have little to gain from VPS-level control. Shared hosting can remain the practical choice when traffic is steady, the application is standard and the provider's platform already supplies the features the site needs.
Workloads become more demanding when pages must be generated for each visitor. Online stores process searches, carts, customer accounts and checkout activity. Membership systems, booking platforms and busy WordPress sites can also place heavier demands on PHP, memory and databases. If those demands are sustained, isolated resources may make capacity easier to plan.
Growth should be considered in practical terms. Think about expected campaigns, new site features, additional stores or portals, and whether traffic arrives steadily or in bursts. Do not choose a server only for a distant possibility. Choose enough capacity for the current workload and near-term plans, with a clear upgrade path if demand changes.
The server is only one part of the service. Before moving, decide who will monitor it, apply security updates, review logs and respond when something fails. Clarify whether the host manages the operating system only, the hosting control panel, or the applications running inside it. WordPress updates and server updates are different jobs, and neither should be assumed.
Backups also need a written plan. Confirm what is backed up, how often copies are created, how long restore points are kept and whether a copy is stored away from the VPS. The Australian Cyber Security Centre recommends regular backups of important information. For a website, a usable recovery set normally needs both site files and the database.
Ask how a restore is requested and how it can be tested. A backup that exists but cannot be restored in the required timeframe may not meet the business need. Take a fresh backup before migration, keep the old hosting available during validation, and avoid changing DNS until the new site has been checked.
Start by documenting the problem you want to solve. Record when slowdowns occur, which pages or tasks are affected, whether resource limits are being reached, and what changes are planned. This gives your hosting provider useful information and helps separate server capacity issues from website optimisation work.
Then compare the complete operating model. Shared hosting usually offers a simpler managed platform. A VPS can offer isolated resources and greater control, but it needs appropriate administration. Dedicated hosting may suit specialised or much larger workloads, yet it should not be treated as the automatic destination for every growing website.
The best hosting plan is the one that fits the real workload, the available technical support and the level of control the business needs. If your website is outgrowing its current environment, contact Hosting Australia for a practical review of the site, its resource use and the options available before planning a move.
A fast website feels easier to use. Visitors can move between pages, read content and complete forms without waiting for the site to catch up. Speed can also affect how confidently people use a business website. When pages hesitate, even clear content and a polished design can feel less reliable.
Hosting matters because every page begins with work on a server. However, hosting is only one part of the result. Images, themes, plugins, code, database queries, third-party scripts, caching and the visitor's own location and network all contribute. The useful question is not whether hosting controls all speed, but whether it gives the website a sound foundation.
When someone requests a page, the hosting server receives that request and begins preparing a response. For a WordPress site, this can involve running PHP, checking the database, loading plugin and theme code, and assembling the page. The browser cannot finish displaying useful content until that process has started.
Server response can be affected by available processing power, memory, storage performance and the amount of work required for each request. A simple brochure site may have different needs from a busy online store, membership platform or site with complex searches. This is why the right hosting setup depends on the workload rather than the website's appearance alone.
Shared hosting can be entirely suitable for many websites. It is often a practical choice for smaller sites and predictable traffic. The important point is that workloads vary. If a site regularly performs heavy database work, runs demanding plugins or receives sudden traffic bursts, its resource needs may be different.
Without caching, WordPress may need to rebuild similar page output for many visitors. Caching can store reusable results so the server does not repeat every step for every request. This can reduce unnecessary application and database work, especially for pages that do not change for each visitor.
There are several layers of caching. Page caching can serve prepared page output, while browser caching can let a visitor reuse files already downloaded. Object caching may reduce repeated database work. The appropriate setup depends on the site, particularly when pages contain logged-in, personalised or frequently changing information.
Caching is helpful, but it is not a reason to ignore inefficient code or an overloaded application. A slow uncached request may still matter when content changes, a cache expires or a visitor needs a dynamic page. Good performance comes from combining suitable hosting with sensible WordPress maintenance.
Visitor location can influence loading time because data must travel across networks. A content delivery network, or CDN, can place copies of static files such as images, stylesheets and scripts closer to visitors. That can reduce the distance those files travel and make delivery more consistent across regions.
A CDN does not automatically fix a slow origin server or a slow WordPress application. If the hosting server takes too long to generate the original page, or a plugin creates expensive database queries, the CDN may still be waiting for that work. It should be treated as one layer in the performance setup, not a replacement for a responsive origin.
For an Australian business, consider where the main audience is located and whether the hosting and CDN arrangement suits that audience. Also remember that the visitor's device, connection and local network conditions remain outside the host's control.
Moving to a more capable server can help when hosting resources or response time are the constraint. It will not make oversized images small, remove unnecessary scripts or rewrite inefficient plugin code. Before changing plans, it helps to identify which parts of the loading process are actually slow.
These steps also make hosting resources more effective. A leaner site asks the server and browser to do less work, while a suitable hosting platform gives that work an appropriate place to run. Treating both sides together is usually more useful than looking for a single speed switch.
Use PageSpeed Insights to test important pages on both mobile and desktop. The report can highlight different parts of the experience, while Core Web Vitals can help diagnose loading, responsiveness and visual stability. These measurements are diagnostic tools, not promises that every visitor will receive the same result.
Test more than the home page. Product pages, service pages, blog posts, forms and logged-in areas can behave differently. Run tests after meaningful changes and compare like with like. A single result can be affected by temporary conditions, so look for repeatable patterns and relate them to what real pages are doing.
When reviewing hosting, ask practical questions: Does the plan provide resources that fit the workload? Is server-level caching available and configured appropriately? Is the software stack suitable for WordPress? Can support help distinguish a hosting issue from an application issue?
Hosting Australia's WordPress hosting page describes a platform using LiteSpeed, caching and HTTP/3. Those features can form part of a speed-focused setup, but the website still needs well-sized images, maintained code and sensible configuration.
Website speed is the result of several connected layers. Hosting matters because it supports the server response and resources behind every visit, while optimisation work controls how much the site asks the server and browser to do. If you are unsure whether your current hosting suits your WordPress workload, contact Hosting Australia for a practical discussion about the site and its requirements.
Choosing web hosting can feel more technical than it needs to be. Plans are often presented with long feature lists, while the information that matters to a small business is spread across storage, resources, support, backups and the type of website you want to run.
The right plan is not simply the cheapest option or the one with the biggest numbers. It is the service that fits what your website does today, leaves sensible room for growth and gives you a clear path when your needs change. This practical checklist will help you compare plans without getting lost in the terminology.
Begin with the purpose of the website. A simple site that introduces your business and lists contact details has different needs from an online store, booking system, membership portal or busy publication. Write down the functions that are important to daily operations before looking at hosting packages.
Consider whether the site uses WordPress or another content management system, whether it needs a database, and whether staff will create email accounts through the hosting service. Note any forms, payment tools, customer logins, large image galleries, video, integrations or scheduled tasks. These features can affect storage, processing, memory and support requirements.
It also helps to identify which parts are business-critical. If a brochure page is briefly unavailable, the impact may be limited. If customers rely on the site to place orders or make bookings, reliability, monitoring, recovery and responsive support deserve more weight in the decision.
Storage is easy to compare, but it is only one part of hosting capacity. A website may use modest disk space while still requiring more processing power or memory because it runs an online store, searches a large database or handles several tasks at once.
Ask what resources are included and what happens when a limit is reached. Useful areas to compare include CPU, memory, database availability, the number of websites allowed and any limits applied to files, processes or email. The exact mix matters more than any single figure.
Bandwidth describes the data transferred when people use your site, but a generous allowance does not automatically make a site fast. Page size, caching, image optimisation, application code and the server's response all influence performance. A plan should provide enough capacity, but the website itself still needs to be built and maintained well.
Shared hosting is often suitable for small business websites that have straightforward requirements. Multiple customers use the underlying server, while the provider manages the platform. It can be a practical starting point when you want familiar tools and do not need to administer a server.
A virtual private server, or VPS, provides a more isolated environment and greater control. It may suit custom applications, heavier workloads or teams that need specific server software. That extra control also brings responsibility. With an unmanaged VPS, someone must handle configuration, security, updates, monitoring and troubleshooting.
Dedicated hosting gives one customer access to a physical server. It is intended for requirements that justify that level of capacity, isolation or control. Most small businesses should choose based on evidence rather than assuming a more complex hosting type is automatically better.
If you are unsure, describe the website and its busiest tasks to the provider. A good recommendation should connect the proposed service to your actual workload and explain who will manage each part.
Support becomes most important when something is not working. Check how you can contact the provider, when assistance is available and what the support team will help with. There is a difference between managing the hosting platform and repairing a website, so ask where that boundary sits.
Backups also need more than a tick in a feature list. Find out what is backed up, how often copies are created, where they are stored, how long they are retained and how a restore is requested. Keep an independent backup for important business data and make sure you understand the recovery process before you need it.
If you are moving an existing site, ask what the migration service includes. Confirm whether website files, databases, email accounts and DNS changes are covered, and who will test the result. Plan the move around business activity, preserve the old service until the new site is checked, and avoid changing several systems at the same time.
Your website may gain products, traffic, staff accounts or new software over time. Look for a clear upgrade path and ask whether moving between plans requires downtime or technical work. This is more useful than buying a much larger plan based on a vague idea of future growth.
Review the plan when the website changes, not only when renewal arrives. A new online store, marketing campaign, customer portal or large media library may alter the workload. Regular reviews also help identify old files, unused plugins and abandoned email accounts that should be cleaned up instead of simply adding capacity.
Before choosing, compare the full service rather than the introductory headline. Check the ongoing billing period, included resources, renewal terms, support channels, backup arrangements and any optional services. Keep a copy of the plan details so you know what was agreed.
A suitable web hosting plan should make sense when measured against your website, your team's technical skills and the importance of the service to your business. Start with the workload, compare resources in context, understand who manages the platform, and confirm support and recovery arrangements before making the move.
If you would like help matching a website to an appropriate service, contact Hosting Australia. Our team can discuss how your site is used and help you consider a cPanel hosting option without relying on guesswork.
When you choose a website address for your Australian business, the ending matters more than most people expect. The letters after the dot tell customers what kind of organisation you are, and in Australia they also come with rules about who can register them. If you are setting up a new domain, or checking that the one you already hold is still on solid ground, this guide explains the options in plain English.
Australia has several domain endings, each run under licensing rules set by auDA, the organisation that administers the .au namespace. The ending you can register depends on your legal structure and how the name you want connects to your business or activity:
Most Australian businesses register a .com.au because it is the address customers expect to see on a sign, a business card or an email footer. To hold one you need a commercial entity, such as a business registered with an ABN or a company with an ACN, and the name must match or be closely connected to your registered business name, company name or Australian trade mark.
The practical effect is simple: a business trading as Coastal Cleaning Pty Ltd can register coastalcleaning.com.au, but it cannot register a name belonging to an unrelated business. Your ABN details and your domain need to tell the same story, because both are checked against auDA rules at registration and can be reviewed later.
The .net.au ending also requires a commercial entity, and the name must match your registered details in the same way. It was traditionally aimed at network and technology providers, but any eligible business can use it. If your first-choice .com.au is already taken by someone else, a .net.au version can work as an alternative, even though most customers will still look for the .com.au version first.
The .org.au ending is different because it is reserved for non-profit organisations and incorporated associations. That makes it a good fit for a charity, a community group or a sporting club that does not hold a business ABN but still wants a credible Australian web address of its own.
The .au direct namespace opened in 2021, allowing shorter addresses such as yourbusiness.au without the com or net in the middle. Eligibility is broader: you need a verifiable Australian connection, which can be citizenship, residency, or a business presence with an active ABN or ACN.
Existing holders of longer .au names had first access during the launch period, and the shorter names have been available on the open market since. Many businesses keep their .com.au as the main address and also register the matching .au name so nobody else can take it, then point the shorter version to the same website. A few dollars a year can save a lot of confusion later.
Australian domain eligibility is not a once-only check. auDA can review registrations at any time, and since May 2026 registrars are required to verify that the ABN or ACN linked to a domain is still current and active when that domain comes up for renewal.
This matters more than business owners realise. If you restructured and cancelled an old ABN, that number will no longer pass the check, and your renewal can be blocked, which eventually puts the domain at risk of deletion. It is worth reviewing your details once a year: look up your domain on the auDA WHOIS service, confirm the ABN or ACN shown there matches the one that is active today, and fix any mismatch with your domain provider well before the renewal window closes.
Start with the ending your customers expect: .com.au for almost every business, .org.au for a not-for-profit, and .id.au or .au direct for a personal site. Then check whether your exact business name is available, along with the common variations customers might type.
If the .com.au you want is held by an unrelated party, weigh up whether a .net.au or .au version is worth using, or whether a small change to the name is cleaner. Register only the versions you genuinely need, and point any extras at your main website so a confusingly similar address cannot be used against you later.
A domain is a small decision with long-term consequences, and it does not need to be complicated. If you are unsure which ending you qualify for, or whether the details on your current domain are still correct, your hosting provider can check availability, walk you through the eligibility rules and keep your renewals on track. The Hosting Australia team helps Australian small businesses with domain registration every day, so contact us if you would like a hand.
A website can feel like one product, but several services work together behind the scenes. Two of the most important are your domain name and web hosting. They are connected, but they are not the same thing.
Understanding the difference makes it easier to launch a site, move providers and troubleshoot problems. It also helps you avoid a common business risk: assuming that paying for one service automatically keeps every part of your online presence active.
Your domain name is the address people type to reach you, such as yourbusiness.com.au. Registering it gives you the right to use that name for a set licence period, provided you continue to meet any applicable rules and renew it when required.
Web hosting is the service that stores and serves the website itself. This can include your pages, images, WordPress files, databases and other data needed to display the site. When someone visits your domain, their browser ultimately needs to connect to the server that holds those files.
A useful comparison is a shop and its street address. The domain is the public address, while the hosting is the premises containing the business. Having an address does not create the shop, and renting premises does not tell customers where to find them. The two must be connected correctly.
You can often register a domain and buy hosting from the same provider, but that is not compulsory. A domain can remain with one provider while the website is hosted elsewhere. Keeping them together may simplify administration, while keeping them separate may suit an existing setup. Either approach can work when access, renewals and DNS are managed carefully.
The Domain Name System, or DNS, links readable domain names with the technical destinations used by internet services. For a website, DNS records can direct visitors to the server where the site is hosted. This avoids asking people to remember a numerical IP address.
Nameservers identify where the authoritative DNS records for a domain are managed. Inside that DNS zone, different record types handle different jobs. An A record can point a name to an IPv4 address, an AAAA record can point to an IPv6 address, and a CNAME can make one hostname refer to another name.
Email uses the same domain but may have a different destination. MX records direct incoming email towards the relevant mail service, while TXT records are commonly used for email authentication and service verification. This is why changing website hosting does not always mean changing email hosting.
Imagine that your website is moving to a new server but your email is staying with Microsoft 365 or another mail provider. The web records may need to change, while the MX and supporting email records should remain in place. Replacing the whole DNS zone without checking it can interrupt services that were not meant to move.
DNS answers can also be cached. After a record changes, some visitors may briefly receive the previous answer until the cached information expires. The practical approach is to prepare the correct records, allow for caching and test the website and email separately.
Moving a website normally involves more than copying files. The new hosting environment must be ready, the website and database must be transferred, and the domain's DNS must direct visitors to the new destination. Any required SSL setup, redirects and application configuration also need to be checked.
The domain registration does not have to move just because the hosting moves. You may only need to update selected DNS records or change which nameservers are authoritative. Likewise, transferring a domain to another registrar does not automatically move the website files to new hosting.
Before changing DNS, make a simple service map. Record where the domain is registered, where DNS is hosted, where the website lives and where email is delivered. Also note any subdomains used for booking systems, customer portals, newsletters or third-party tools. This turns a risky guess into a controlled change.
Test the new website before directing normal traffic to it where possible. Check important pages, forms, images and logins. After the DNS change, confirm that the public domain reaches the intended site, HTTPS works and email continues to send and receive through the expected provider.
A reliable setup is not only about technical records. Your business should know which company manages each service and who can access each account. Store account details securely, use a business-controlled contact address and remove access for people who no longer need it.
Keep domain contact information current so renewal and account notices reach the right person. Treat domain renewal and hosting renewal as separate checks, even when they appear on the same invoice or in the same customer portal. If a domain expires, the website and domain-based email can stop working even if the hosting account is still active.
Document the current nameservers and important DNS records before making changes. If a web developer, marketing platform or email provider asks for a DNS update, confirm the exact record name, type and value. Avoid deleting unrelated records simply because their purpose is not immediately obvious.
Domains, hosting and DNS are separate building blocks, but together they create a working online presence. Know where each part is managed, renew each service on time and review the full service map before a move. If you would like help connecting a domain to suitable hosting, contact Hosting Australia for practical guidance.
A business website rarely goes from healthy to unusable without warning. More often, the clues arrive gradually: pages feel slower, customers report intermittent errors, or routine tasks in the dashboard take longer than they used to. Those symptoms do not automatically mean your hosting is at fault, but they do mean it is time to investigate.
The useful question is not simply, "Is my hosting bad?" It is, "What has changed, where is the delay or failure happening, and does my current service still fit the website?" Here are three signs that deserve attention, plus a safe way to collect evidence before making changes.
A slow website is frustrating, but inconsistent performance is often the more useful warning sign. A page may load normally early in the day, then crawl when more visitors arrive. The public site may seem acceptable while the WordPress dashboard, checkout or booking form becomes difficult to use.
Hosting is only one possible cause. Oversized images, an overloaded theme, inefficient plugins, third-party scripts and a poorly configured cache can all add delay. That is why a single speed test should not be treated as a diagnosis. Test several important pages, on both mobile and desktop, at different times. Record the page, time and result so you can see whether there is a pattern.
Google's Web Vitals guidance focuses on loading, interactivity and visual stability because each affects the experience of a real visitor. Tools such as PageSpeed Insights can highlight what users encounter, but the report still needs interpretation. If the same server-response delay appears across otherwise different pages, or performance becomes worse under normal demand, ask your hosting provider to review the server side as well as the website itself.
Occasional errors can come from many places. Repeated server errors, timeouts, failed form submissions or unavailable checkout pages are different, especially when they appear during promotions, busy periods or automated tasks such as backups. They may point to a software fault, a database problem or a resource limit being reached.
Do not start changing plugins, PHP settings or DNS records on a live site just to see what happens. First, capture the exact error message, the affected URL and the time it occurred. Ask staff whether they saw the same problem, and note whether it affected the public site, administration area, email or only one function. Screenshots are helpful, but timestamps are even more useful because support can match them against logs.
If your hosting uses cPanel, its Metrics area may provide error, bandwidth and resource information. WordPress also includes Tools > Site Health, where the Status tab flags critical issues and recommended improvements, while the Info tab summarises the site and server configuration. These tools do not prove that hosting caused the problem, but they give your provider a much stronger starting point than "the website was down".
A hosting plan that suited a simple brochure site may not suit the same business after it adds online sales, bookings, membership features, larger media libraries or regular marketing campaigns. Growth can increase storage, database activity, background jobs and the number of people using the site at once. The change may be gradual enough that nobody notices until everyday work becomes unreliable.
Look for practical friction. Are uploads failing because storage is tight? Does the administration area slow down during imports or updates? Do backups struggle to finish? Are resource warnings becoming common? Has the site gained business-critical functions that need closer monitoring or a more suitable recovery process? These questions are more useful than choosing a plan based only on a label.
Moving to a larger service is not always the answer. An inefficient plugin or damaged database can waste resources on any plan. Your provider should help separate a website problem from a capacity problem, explain the evidence, and recommend the smallest sensible change rather than assuming that more resources will fix everything.
Start with a short record covering several normal business days. List slow pages and errors with timestamps, note recent website changes, and gather relevant reports from cPanel, WordPress Site Health or your monitoring service. Test from more than one device or connection so a local network problem is not mistaken for a hosting issue.
Before any update, optimisation or migration, confirm that a current backup exists and that the recovery process is understood. Then share the evidence with support and ask clear questions: Was a resource limit reached? Do the logs show a recurring application error? Is the current plan appropriate for the website's actual workload? What should be tested first, and how will the result be checked?
This approach avoids guesswork and risky changes. It also creates a baseline, so you can tell whether a fix genuinely improved the site rather than relying on how it feels immediately afterwards.
Slow performance, recurring errors and a plan that no longer matches the workload are signals to investigate, not reasons to panic. Collecting a few useful details can turn a vague complaint into a focused technical review.
If your website is showing these signs, contact Hosting Australia. Our team can review the symptoms with you, help identify whether the website or hosting needs attention, and discuss a cPanel hosting option that fits the way your business uses its site.
