Click here for our Australian shared web hosting FAQ.

Why choose Australian hosting?

Where a website is hosted can make a real difference to how quickly it responds to visitors. When most of your audience is in Australia, placing the site in a Sydney data center gives requests a shorter journey before they reach the server. That can help pages and other website content load more quickly for people across Australia and nearby regions.

Server location is only one part of the performance equation. Image sizes, caching, website code, and other forms of optimization matter too. Even so, they cannot completely remove the effect of network distance. For an Australian business serving local customers, having the server nearby is a practical advantage.

The same principle applies whether you are running a company website, a store, a blog, or something much smaller. Hosting provides the underlying environment your website depends on, so it needs to be stable without becoming difficult to manage. Our cloud platform is designed with both of those needs in mind.

Perfect for Australian businesses and individuals

There is no single type of website that these plans are intended for. A local business can use one to establish its online presence, a freelancer can present services and work, a blogger can publish regularly, and an online store can use the same platform to serve customers.

When most of your visitors are in Australia or New Zealand, a Sydney location can be a sensible choice because the server is geographically closer to them. That shorter network path can contribute to faster responses, which may make browsing feel more comfortable and keep visitors moving through the site rather than waiting for each page.

Your audience does not have to be entirely Australian for Sydney to make sense. The right location depends on where your visitors are concentrated. If a substantial portion of your traffic comes from Australia and surrounding countries, a local data center can be a practical part of your hosting setup.

Built for today's websites

A modern website needs more than a place to store its files. It may also depend on email, databases, backups, domain settings, security controls, and other services. These are brought together in our custom control panel so that routine account management can be handled from one place instead of being scattered across different tools.

For supported applications such as WordPress, installation is designed to be straightforward. Already have a site somewhere else? Our migration service can handle the transfer of your existing files, databases, and other required content, reducing the amount of technical work involved in changing providers.

You also do not have to make a final decision about capacity on day one. A small site can start with a modest plan, while a growing project can move to a larger package when its requirements change. That gives you room to expand without having to rebuild everything around a completely different hosting setup.

Reliable cloud infrastructure

The Australian platform runs on cloud infrastructure intended to provide dependable service without making the customer responsible for maintaining the underlying system. SSD storage, daily backups, security features, and managed infrastructure are combined to create the environment your website runs on.

That matters because hosting is supposed to support the website, not become a constant technical distraction. With the platform and support team handling the hosting side, you can devote more attention to your content, customers, and day-to-day business.

Why host your website in Sydney?

Sydney is an important technology and connectivity center in the region, making it a natural location for websites whose visitors are concentrated in Australia and New Zealand. A nearby server can reduce network latency, allowing requests to travel a shorter distance between the visitor and the website.

That can be especially useful for businesses whose websites are part of their normal daily operations. A company site, booking system, or online store needs to remain accessible and responsive while customers are using it. Choosing a data center close to that audience can support a more consistent experience.

Ideal for WordPress and business websites

WordPress can be used for everything from a simple personal site to a large online store, which is one reason it is so widely adopted. Our Australian plans provide the hosting environment needed for WordPress projects of different sizes, provided the site's resource requirements remain within the selected package.

Running a business website also involves plenty of routine administration that has little to do with creating content. Domains, mailboxes, databases, website files, and security settings can all be managed through the same control panel, making those everyday tasks easier to keep track of.

There is also no need to move providers simply because the website becomes more demanding. When additional capacity is needed, you can move to a larger plan while keeping the same hosting environment.

Security you can depend on

Any website connected to the internet faces unwanted attention. Automated scanners, bots, malicious software, and attempts to exploit vulnerabilities are an ongoing reality, so security needs to be considered as part of the hosting environment rather than as an afterthought.

No host can guarantee protection against every possible attack, but several layers can make the environment more resilient. Daily backups provide a recovery option if something goes wrong, while SSL support, ModSecurity, and protected account access add further safeguards around the website and its data.

Simple migration from your current host

Changing hosting providers may sound like a complicated project, but much of the work can be handled for you. Our migration service can transfer the website files, databases, and other necessary content from the previous provider to your new Australian account.

Once the new copy has been checked and is working properly, the final step is to update the domain so that it points to the new account. Because the website address can remain unchanged, visitors often have no reason to realize that anything happened behind the scenes.

How to choose the right Australian hosting plan

The right package depends mainly on what your website needs now and where you expect it to go. A new website with limited traffic can usually start with an entry-level plan, while a site that is already established or growing quickly may need more resources from the beginning.

For many personal sites, blogs, and smaller business websites, the Economy and Regular plans provide a practical starting point. Larger sites, multiple websites, online stores, and projects expecting heavier traffic may be better matched to one of the higher plans. The packages run on the same cloud platform, with the main difference being the resources and allowances available to your account.

There is no need to guess completely on your own. Tell our support team what you are building, how established the site is, and what you expect it to do, and they can help point you toward a suitable package.

Why website speed matters

People are generally less patient with slow websites than they were years ago. Even a modest delay can be enough to interrupt the browsing experience or cause someone to leave before the page has finished loading. Hosting cannot determine every aspect of performance, but server location is one factor you can control from the outset.

Actual loading times are influenced by many things: the site's code, images, caching, application configuration, and the hosting environment all contribute. Combining a cloud platform with a Sydney data center gives a website aimed at Australian visitors a solid foundation for responsive delivery, while the site's own optimization still plays an important role.

Why choose Hostiful?

We take a straightforward view of web hosting. You should be able to understand what you are buying, manage your account without unnecessary complexity, and get assistance when something goes wrong. The goal is not to bury everyday tasks under technical language or complicated interfaces.

Your account includes the tools and services needed to run a modern website, including the control panel, daily backups, SSD storage, website migration, one-click application installation, and professional email hosting. That gives you a practical starting point whether the site is brand new or you are moving an established business online.

And the arrangement does not have to change just because the website gets bigger. You can upgrade the plan as your requirements increase, adding room for more storage, bandwidth, or domains without having to start the hosting process all over again.

Serving visitors throughout Australia and Oceania

A Sydney data center is an obvious choice when Australia is your primary market, but its usefulness extends beyond Australia's borders. Websites serving customers and visitors in New Zealand and other parts of Oceania can also benefit from having infrastructure located within the region.

For audiences located elsewhere, the closest available location may be a better fit. We offer additional international data center options, so you can choose an environment that makes sense for where most of your visitors are located. Getting that choice right can help reduce latency and provide a more responsive experience for the people who matter most to your website.

FAQ

This FAQ covers shared web hosting in Australia from the point of view of someone actually running a website in a shared environment. It focuses on the practical issues that matter when the account, data centre location, control panel, software, email, security, performance and day to day maintenance all have to work within the limits of a shared platform.

1. Understanding the shared environment

1. What does shared web hosting mean?

Your website runs on a physical or virtual server that also serves websites belonging to other customers. The operating system, web server, hardware and many underlying services are shared, while your account is kept separate from other accounts at the software and permission level.

2. Why is it called shared hosting?

The important point is that several accounts use the same underlying computing resources. You are not being given an entire machine for your website alone, which is why the service can cost considerably less than a dedicated setup.

3. Is an Australian shared account suitable for a small business website?

It can be a very practical choice for a brochure site, business website, blog, portfolio, local service business or modest online shop. The deciding factors are the site's traffic, software requirements and resource usage rather than the size of the business itself.

4. What is physically shared between customers?

Customers may share CPU capacity, memory, storage devices, network connections and operating system resources. The exact design differs between providers, so two services described as shared can have noticeably different performance characteristics.

5. Does sharing a server mean other customers can see my files?

Proper account isolation is intended to prevent that. File permissions, user separation and other security controls should stop one account from reading another customer's private files, although no hosting environment should be treated as immune from security flaws.

6. Does everyone on the machine use the same IP address?

Often they do, although the provider may offer dedicated or additional addresses in some plans. A common address is not normally a problem for ordinary websites, but it can matter for certain mail, DNS or application requirements.

7. Does another customer's website affect mine?

It can, because the underlying resources are shared. Well designed platforms use limits and monitoring to reduce the effect of unusually busy or badly behaved accounts, but performance can still vary with the overall load on the machine.

8. Are there limits on how much a single account can use?

Almost always. Providers may impose limits or practical thresholds for CPU time, memory, processes, database activity, storage, files, mailboxes and other resources. The precise rules need to be checked in the plan documentation.

9. Is shared hosting less secure than a dedicated server?

Not automatically. A properly managed shared platform can have strong security controls. The difference is that you have less control over the underlying operating system and cannot isolate your website from the wider machine in the same way as you can with an entire server.

10. Can I install anything I want?

No. Your account normally allows applications and scripts that fit within the provider's supported environment, but you will not have unrestricted operating system access. Software requiring system level packages, custom daemons or root privileges may not be possible.

Back to FAQ menu

2. Choosing a suitable Australian setup

11. Does the physical location of the server matter?

It can. A machine located in Australia may reduce network distance for visitors in Australia and nearby regions. The effect on real world loading time depends on the visitor's location, the network route, the page itself and how efficiently it is served.

12. Is a server in Australia important for an Australian audience?

It can be useful, particularly when most visitors are in Australia. However, server location is only one part of performance. Caching, page size, image optimisation, DNS response time and the quality of the network connection also have a significant effect.

13. Should I choose a provider with an Australian data centre?

That can make sense when a large proportion of your audience is local or when keeping information inside Australia is an important business requirement. Check the actual location of the infrastructure rather than relying only on the provider's company address.

14. Does an Australian data centre guarantee fast loading?

No. A nearby machine can still be slow because of overloaded resources, inefficient software, poor database queries or heavy pages. Location helps with network distance, but it does not fix problems inside the website.

15. Is a local support team necessary?

Not necessarily. What matters more is whether support can understand your problem, investigate the account and respond effectively. Australian based support can be convenient because of time zones and local business hours, but support quality is more important than geography alone.

16. What should I check before buying a plan?

Look at storage limits, database support, PHP versions, backups, SSL arrangements, email limits, resource restrictions, control panel access, scheduled tasks and migration options. Also check the terms for renewal pricing and account suspension when resources are exceeded.

17. Is unlimited storage meaningful on a shared plan?

It may not mean unlimited use for every purpose. Plans marketed that way can still have acceptable use rules, inode limits, backup exclusions or restrictions on large archives, media collections and other high storage uses.

18. Is unlimited bandwidth meaningful?

It should not be interpreted as unlimited access to every other resource. A site can transfer a large amount of data while still being constrained by CPU, memory, simultaneous processes or database activity.

19. Should I choose a plan based mainly on disk space?

Usually not. A modest site can run comfortably with limited storage while being held back by CPU or database limits. Consider what the site actually does rather than choosing the largest storage figure on the comparison table.

20. When does a shared account stop being a sensible choice?

A move to a larger environment becomes more reasonable when traffic, background processing, database activity, custom software or reliability requirements consistently exceed what the account can comfortably handle. The trigger is sustained workload, not simply having an important website.

Back to FAQ menu

3. Domains, DNS and website setup

21. Can an Australian shared account host a .au web address?

Yes, provided the account supports the necessary domain configuration. The registration of the address and the web hosting itself are separate services, even when purchased from the same company.

22. Can I use a .com domain on an Australian server?

Yes. The extension of the address does not determine where the website must physically be hosted.

23. Can I host a .com.au site outside Australia?

Technically, a website can be served from many locations, subject to the requirements of the particular domain registration and provider. Hosting location and domain eligibility are separate issues.

24. Can I point my existing domain to a new account?

Yes. The usual process involves changing DNS records or nameservers so that the address resolves to the new service. The correct records depend on how the provider has configured the account.

25. What happens when I change nameservers?

DNS information is updated across the wider internet rather than changing instantly everywhere. Some visitors may reach the old service while others reach the new one until cached DNS information expires.

26. Can I keep my domain registrar separate from my web host?

Yes. There is no general requirement to register the address and buy the website service from the same company.

27. Can one account host several websites?

Many plans support multiple sites, but the number and the way they are configured vary. Separate sites can also increase storage, database, email and security management requirements.

28. What is an addon domain?

In control panels that use this terminology, it normally means another domain served from the same account. The exact implementation can differ, so the provider's control panel documentation is the authoritative source.

29. Can I create a subdomain for a separate part of a site?

Most shared platforms support subdomains when DNS and the control panel are configured accordingly. A subdomain can point to a different folder or, depending on the setup, to another service.

30. Can I use external DNS while keeping the website on the account?

Yes. DNS can be managed by a separate provider while the website, email or both remain on the hosting account. You then need to maintain the necessary records at the external DNS service.

31. What DNS records are commonly needed for a website?

A website normally needs an address record such as A or AAAA, or a CNAME in some configurations. Email requires additional records, and verification services may require their own entries.

32. Can DNS changes break email even when the website still works?

Yes. Website records and mail records are related but not identical. A change to nameservers or mail-related records can leave the website functioning while incoming or outgoing mail stops working.

33. How do I point only a subdomain to another system?

Create the appropriate DNS record for that subdomain rather than changing the main domain's records. This allows the primary website and the separate service to remain on different systems.

34. Can I use www and non-www addresses?

Yes. The two forms can be configured to reach the same site, with one set as the preferred version through redirects or application settings.

35. Should I use a temporary URL before changing DNS?

That can help during a migration, but temporary addresses can cause problems with applications that generate absolute URLs. A hosts file override or staging address is sometimes safer for testing a real site before the public DNS is switched.

Back to FAQ menu

4. Files, accounts and control panels

36. What control panel is normally used?

There is no single control panel required for this type of service. Providers may use cPanel, Plesk or another management interface, so instructions should always be matched to the actual platform.

37. Can I manage files without command line access?

Usually. A web based file manager and FTP or SFTP access may be provided. The exact combination depends on the account.

38. Is FTP the same as SFTP?

No. SFTP operates through SSH and provides encrypted transfer. Traditional FTP does not provide the same protection and should not be treated as equivalent.

39. Why are file permissions important?

They determine who can read, modify or execute files. Incorrect permissions can either break the website or expose sensitive information, so changes should be made carefully rather than simply making everything writable.

40. Why should I avoid giving every file full write access?

Broad write permissions make it easier for a compromised script or account process to alter files that should be protected. The safest arrangement is the least access required for the application to function.

41. Where should website files normally be uploaded?

The correct document root is determined by the control panel and domain configuration. Uploading files into the wrong directory can result in a blank page, directory listing or the wrong site appearing.

42. What is a document root?

It is the directory associated with a particular website or domain from which the web server serves files. Different domains or subdomains may have different document roots within the same account.

43. Can I create separate FTP users?

Many platforms allow additional users with restricted access to particular directories. This can be useful when a developer or contractor needs access to one site without access to the entire account.

44. Should I keep configuration files outside the public directory?

Where the application supports it, that can reduce accidental exposure. Some software requires certain configuration files to remain inside the web root, so the application's own documentation should take priority.

45. What happens if I delete an important file?

The result depends on what was removed and whether a usable backup exists. Some applications may stop immediately, while others may continue until a particular feature is requested.

46. Can I use symbolic links on a shared account?

That is provider and filesystem dependent. Some platforms restrict them for security reasons, while others permit limited use. Do not assume that behaviour from one provider applies to another.

47. Can I create hidden files such as .htaccess?

On environments using Apache, such files are common, although their availability and permitted directives depend on server configuration. Other web server software may use a different mechanism.

48. Why is my .htaccess file not behaving as expected?

The server may not allow a particular directive, the syntax may be invalid, or the account may not be using Apache. A single incorrect rule can also cause a site wide error.

49. Can one bad script use resources belonging to other accounts?

Isolation mechanisms are intended to prevent that. Resource controls may also stop a single account from consuming unlimited processing capacity, although the actual protection varies between hosting platforms.

50. Should I keep old files on the account?

Old scripts, forgotten test installations and unused backups can become security and storage liabilities. Removing material that is no longer needed makes the account easier to manage and reduces the number of files that could become vulnerable.

Back to FAQ menu

5. PHP, databases and applications

51. Can I choose the PHP version?

Many shared platforms allow customers to select from several supported versions, but the available choices are provider specific. Older versions may be removed when they are no longer supported.

52. Why should I keep PHP reasonably current?

Current supported versions generally receive security fixes and improvements. Remaining on an obsolete release can leave an application exposed or make newer plugins and themes incompatible.

53. Can I run WordPress on an Australian shared account?

Yes, when the account provides the PHP, database and web server features required by the version you intend to use. The application itself still needs to be maintained properly.

54. What database system is commonly available?

MySQL or a compatible MariaDB setup is common, especially on plans aimed at PHP applications. The exact version and supported features vary between providers.

55. How many databases can I create?

The allowance depends on the plan. A package may have a fixed number, while others may allow more within account limits.

56. Can several websites share one database?

Technically, some applications can do this, but separating databases can make security, troubleshooting, backups and restoration easier. Whether sharing is sensible depends on the applications involved.

57. What does a database user do?

The database user provides credentials that allow an application to connect to its database with defined permissions. Keeping those privileges limited helps reduce unnecessary exposure.

58. Why does a site show a database connection error?

Common causes include incorrect credentials, a changed database name, a damaged database, exhausted database resources or a service problem. The exact error message is often the best clue.

59. Can I import a large database through a web interface?

Possibly, but browser based imports are often subject to upload and execution limits. Larger databases may need a command line tool, provider assisted import or a more suitable method available in the control panel.

60. What is a PHP memory limit?

It is the amount of memory a PHP process is allowed to use. Applications that exceed it can produce errors even when the underlying server still has free memory.

61. Can I increase PHP memory on a shared account?

Sometimes, within a limit set by the provider. Some settings can be changed at account level while others are fixed by the server administrator.

62. Why would a plugin work on one account but fail on another?

The two environments may use different PHP versions, extensions, memory limits, file permissions, security rules or database versions. Compatibility is always a property of the application and the specific environment together.

63. Can I install PHP extensions myself?

Normally not at the operating system level. Shared customers generally depend on the extensions compiled or enabled by the provider.

64. What if my application requires an extension that is missing?

First confirm that the application really requires it rather than merely recommending it. If it is genuinely necessary, ask whether the provider supports and enables the extension or whether another compatible approach exists.

65. Can I run a custom PHP framework?

Many frameworks can run in a shared environment if they do not require unrestricted system access. Requirements such as command line tools, background workers, custom services or special server modules can make some deployments unsuitable.

66. Can I run Laravel on shared hosting?

Some Laravel applications can be deployed successfully on shared accounts, particularly modest sites. The difficulty comes with projects that rely heavily on queues, workers, scheduled jobs, shell access or other features that may be restricted.

67. Can I use Composer?

That depends on whether command line access and Composer are available. Some providers allow it, some offer limited tooling, and others expect dependencies to be built before uploading the application.

68. What is the public directory in a PHP application?

It is the directory intended to be directly accessible through the web server. Applications that support this arrangement can keep sensitive configuration and application code outside the publicly served area.

69. Can I run a Python or Node.js application?

Not simply because the website is on a shared account. The provider must support the required runtime and application model. Some shared platforms are built primarily for PHP and do not provide the process management needed by other technologies.

70. Why can a database become slow even when the site is small?

Poor queries, missing indexes, large tables, inefficient plugins and repeated background tasks can create heavy database activity. Visitor count alone does not determine database load.

Back to FAQ menu

6. Email and mail-related issues

71. Can I host email on the same account as my website?

Many plans include mailboxes associated with the hosted domain, but this is not universal. Some customers deliberately keep email with a specialist mail provider instead.

72. Is website mail affected by the location of the web server?

Mail delivery depends on the mail systems involved rather than simply the physical location of the website. An Australian website can use mail infrastructure elsewhere.

73. What is an MX record?

An MX record tells other mail systems where to deliver messages for your domain. It is one of the most important DNS records when email is hosted separately from the website.

74. Why did my email stop after moving the website?

A migration can accidentally change MX records, nameservers or related DNS entries. The website may be working correctly while mail is still pointed at the old provider or at an invalid destination.

75. Should email and the website use the same provider?

There is no technical requirement for that. Keeping them together can simplify management, while separating them can provide more specialised mail features or independent redundancy.

76. What is SPF?

SPF is a DNS based policy that identifies systems authorised to send mail for your domain. It can help receiving systems detect messages sent from unauthorised servers.

77. What is DKIM?

DKIM adds a cryptographic signature to outgoing messages so the receiving system can verify that authorised mail infrastructure signed the message and that key parts of the message were not altered.

78. What is DMARC?

DMARC builds on mechanisms such as SPF and DKIM and tells receiving systems how to handle messages that fail authentication checks. It also provides reporting mechanisms.

79. Can a shared IP affect email reputation?

It can. Where several accounts send mail through the same address, reputation is influenced by the activity associated with that address. Providers therefore need controls to limit abuse and spam.

80. Why do messages sometimes go to spam?

There is no single cause. Sender reputation, authentication, message content, recipient behaviour, DNS configuration and the reputation of the sending infrastructure can all contribute.

81. Is webmail included?

It depends on the mail service attached to the account. Some control panels provide webmail automatically, while separately hosted mail may use a completely different interface.

82. Can I use Outlook or Apple Mail with a mailbox?

Usually, when standard IMAP and SMTP access is provided. The exact server names, ports and security settings must come from the mail provider.

83. Why is my mailbox full even though the website has plenty of storage?

Mailboxes and website files may be subject to separate quotas. Large attachments and years of stored messages can fill a mailbox independently of the rest of the account.

84. Should I keep years of email on the hosting account?

That is a management decision rather than a technical requirement. Large mail stores increase storage usage and can complicate migration and backup operations, so retention should match your actual needs.

Back to FAQ menu

7. SSL, access and security

85. Do I need an SSL certificate?

For a modern public website, HTTPS should be considered essential. It protects traffic between the visitor and the website and is especially important when logins, forms or payment related activity are involved.

86. Can I use a free SSL certificate?

Many providers support automated certificates such as those issued through Let's Encrypt, although the exact arrangement depends on the platform.

87. What happens when an SSL certificate expires?

Visitors can receive browser warnings and secure connections can fail certificate validation. Automated renewal is therefore preferable where supported.

88. Does an SSL certificate make the website secure?

No. HTTPS protects data in transit, but it does not prevent vulnerable software, stolen passwords, malicious plugins or insecure code.

89. Why does a website show a mixed content warning?

That normally means the main page is loaded over HTTPS but one or more resources are still being requested over HTTP. Scripts, images, stylesheets and embedded content can all cause the problem.

90. Should I redirect HTTP traffic to HTTPS?

For a public website that is intended to run securely, redirecting visitors to the HTTPS version is generally appropriate. The exact redirect method depends on the web server and application.

91. Can I install security software on a shared account?

Application level security tools may be available, but you normally cannot install operating system security software yourself. Provider level protection sits beneath your account and is outside your direct control.

92. Should every website have a web application firewall?

A firewall can be useful, but the exact benefit depends on how it is implemented. It is an additional layer rather than a replacement for keeping software, passwords and permissions secure.

93. Why are login limits useful?

Rate limiting can make automated password guessing more difficult. It is especially useful for applications that expose public login pages.

94. Is two factor authentication useful on a shared account?

Yes. Protecting the control panel, email, registrar and other administrative accounts with a second authentication factor can reduce the damage caused by a stolen password.

95. Should I use the main account password for FTP and email?

Using separate credentials where supported reduces the impact of a compromise. A contractor who only needs access to one directory should not automatically receive credentials for the entire account.

96. How can I tell whether a website has been hacked?

Unexpected redirects, unfamiliar administrator accounts, modified files, injected code, unexplained outbound mail and sudden search engine warnings are common signs. File and access logs can provide useful evidence.

97. What should I do after finding malicious files?

Do not simply delete random files and assume the problem is solved. Identify the entry point, restore clean files where appropriate, change credentials and check the rest of the account for persistence or additional compromise.

98. Can one infected website infect another site in the same account?

Shared accounts can increase the risk when several applications are placed together and permissions are poorly controlled. Separating sites and maintaining each application carefully can reduce the blast radius of a compromise.

99. Are backup files safe inside the public directory?

They should not be assumed to be safe there. A database dump or archive containing credentials can become publicly downloadable if it is placed somewhere the web server can serve directly.

100. Should I remove old installers after setting up an application?

Yes. Installation scripts, temporary archives and unused setup files have no useful purpose once deployment is complete unless the application's documentation specifically requires them.

Back to FAQ menu

8. Performance and resource usage

101. Why can a site be slow even when traffic is low?

Slowdowns can come from inefficient code, a slow database query, external services, oversized images, excessive plugins or temporary resource contention. Visitor numbers are only one source of load.

102. What does CPU usage mean on a shared account?

It reflects how much processor time your account's processes are consuming. Reaching a provider's CPU threshold can result in slower execution or temporary restrictions.

103. What does memory usage mean?

It refers to the RAM consumed by running processes. A site that repeatedly hits its memory limit may produce application errors, failed jobs or incomplete requests.

104. What are entry processes?

On some control panels, this refers to the number of simultaneous web requests that are actively being handled for an account. The terminology and exact limit vary by platform.

105. What are inodes?

An inode represents a filesystem object such as a file or directory. A site can therefore reach an inode limit even when it still has plenty of storage capacity available.

106. How can thousands of tiny files affect an account?

They consume inode capacity and can make backup, scanning and file management more demanding. Cache directories, generated thumbnails and old development files can create surprisingly large counts.

107. Does using a CDN help an Australian website?

It can. A CDN can serve static assets from locations closer to visitors, reducing the amount of work done by the origin machine. The benefit depends on the site's audience and the CDN's coverage.

108. Is page caching useful on shared plans?

Often. Caching can reduce repeated PHP execution and database queries, which can improve response times while also lowering resource consumption.

109. What is object caching?

It stores frequently requested application data so it does not need to be calculated or fetched repeatedly. Whether a persistent object cache is available depends on the platform.

110. Can a caching plugin cause problems?

Yes. Incorrect rules can serve stale content, interfere with logins or conflict with another caching layer. A caching tool should be configured for the particular application rather than treated as a universal speed switch.

111. Why are image sizes important?

Large images increase download time and can consume bandwidth and browser resources. Resizing images to sensible dimensions before delivery can make a noticeable difference.

112. Can too many plugins slow down a website?

They can, particularly when plugins perform repeated database queries, create background jobs, load large scripts or duplicate functionality. The number alone is not a reliable measure; what each plugin does matters more.

113. Why can the administration area be slower than public pages?

Administrative screens often perform more database work and may load many widgets or background checks. A site can therefore have a reasonable public response time while its control area remains heavy.

114. How can cron jobs use too many resources?

A scheduled task can trigger a large import, backup, report or queue process. If tasks overlap or run too frequently, they can consume CPU, memory or database capacity long after the visitor leaves the site.

115. Is a cache enough for a badly coded website?

No. Caching can hide some inefficiency but does not solve every problem. Uncached requests, administrative actions, database operations and background tasks can still be expensive.

116. When should I investigate a resource warning?

Repeated warnings are more important than an isolated spike. Look for a pattern and identify what was running at the time, especially if visitors experienced slow pages or errors.

Back to FAQ menu

9. Backups, recovery and data protection

117. Does the provider automatically back up my website?

Many do, but the frequency, retention period, scope and restoration process differ considerably. A statement that backups exist does not tell you whether they are suitable for your needs.

118. Is a provider backup the same as my own backup?

No. A provider controlled copy is useful, but independent backups give you another recovery option. They should ideally be stored separately from the account being protected.

119. Should databases be backed up separately?

For many dynamic sites, yes. The database can contain orders, users, settings and other information that is not stored in the site's ordinary files.

120. How often should I back up a busy website?

The right interval depends on how much information could be lost without serious consequences. A site that changes daily may need more frequent copies than a brochure site that changes once a month.

121. Why should I test backups?

A backup that cannot be restored is not a dependable recovery plan. Testing confirms that the files are readable, the database is usable and you understand the restoration process before an emergency occurs.

122. Can a backup consume a lot of shared storage?

Yes. Several full copies of a large website can quickly use substantial space. Keeping only sensible retention points helps avoid turning backups into the largest part of the account.

123. Should backup archives be stored in public folders?

No. Archives may contain databases, configuration files, user information or credentials. They should be stored outside the publicly accessible document root whenever the backup method permits it.

124. Can I restore only one file?

Sometimes. Some backup systems support granular restoration while others restore larger portions of the account. The provider's recovery tools determine how precise the process can be.

125. Can I restore only a database table?

That depends on the backup and database tools available. A full database restore may be easier than reconstructing a single table, but selective recovery is possible in some situations.

126. What is the difference between backup and redundancy?

A backup is a recoverable copy of data. Redundancy means having more than one working component or copy available so that a failure does not immediately stop service. They solve related but different problems.

127. Can a provider lose both the live site and its backup?

It is possible if backups are stored on the same infrastructure or are affected by the same incident. That is one reason independent copies can be valuable.

128. What should I back up before making a major update?

For a dynamic site, that generally means both the application files and the database. Configuration information and other provider specific settings should also be preserved when necessary.

Back to FAQ menu

10. Moving an existing website

129. Can I move an existing website to an Australian shared account?

Yes, provided the application is compatible with the target environment. Migration normally involves copying files, transferring the database, adjusting configuration and testing before changing DNS.

130. Should I change DNS before testing the new copy?

It is better to test the new installation first. That reduces the chance of visitors being sent to a site that still has unresolved errors.

131. How do I move a WordPress website?

A typical migration requires the WordPress files, database and configuration to be transferred, followed by checks on URLs, permissions and the PHP environment. DNS can then be changed after the new copy has been tested.

132. Can I migrate without significant downtime?

Often, yes. A common approach is to copy the site while the old version remains live, test the new installation and then perform a final data synchronisation immediately before switching traffic.

133. What can go wrong when moving a database?

Common problems include incorrect character settings, incomplete imports, missing tables, changed credentials and application URLs that still point to the old system.

134. Do file ownership and permissions need to match the old server?

Not necessarily. The new environment may use a different account structure. Permissions should be correct for the target setup rather than copied blindly from the old host.

135. What should I test before changing the domain?

Check the homepage, internal links, forms, logins, media, database driven features, HTTPS, email and any important application functions. A simple homepage test is not enough for a full migration.

136. Can email be moved separately from the website?

Yes. Website migration and mail migration can be carried out independently, which can reduce the risk of changing both systems at once.

137. How long should I keep the old account after migration?

Keeping it temporarily can provide a fallback while DNS caches expire and the new site is monitored. Once the new setup has been confirmed and independent backups exist, the old account can be retired.

138. Should I lower DNS TTL before a planned migration?

Reducing TTL ahead of time can help legitimate DNS changes propagate more quickly after the switch. It is only useful when done sufficiently in advance and when the DNS provider honours the requested value.

Back to FAQ menu

11. Scheduled tasks, staging and development

139. Can shared accounts run scheduled tasks?

Many do, often through cron jobs or a control panel scheduler. The provider may impose limits on frequency, execution time or the commands that can be used.

140. How often should a cron job run?

Only as often as the application needs. Running a resource intensive task every minute when it only needs to run hourly can waste processing capacity and create unnecessary database activity.

141. What is the difference between a visitor triggered task and a real cron job?

A visitor triggered task runs when someone accesses the site or when the application checks for work. A real cron job is scheduled independently by the hosting environment, which can make timing more predictable.

142. Can cron jobs overlap?

Yes. If one run has not finished when the next begins, two instances may operate at the same time. Applications with long running tasks need safeguards against this where necessary.

143. Can I run background workers continuously?

That is often where shared environments become restrictive. A process that needs to remain running continuously may require process supervision or server level control that a normal shared account does not provide.

144. Is staging useful on a shared account?

It can be. A separate copy lets you test updates, configuration changes and application modifications without immediately changing the public site.

145. Should a staging site be publicly accessible?

Not unless there is a reason for it. Login protection, IP restrictions or another access control can prevent search engines and unwanted visitors from reaching an unfinished copy.

146. Can a staging site use the same database as production?

It is generally safer to keep them separate. Sharing one live database can cause test changes to affect real data and makes troubleshooting much harder.

147. How can I prevent a staging site from being indexed?

Access protection is stronger than relying only on a robots.txt file. Search engines cannot crawl a properly protected private site in the same way they can a publicly accessible one.

148. Can I use Git on a shared account?

That depends on whether the platform provides Git or shell access. Even where Git is available, deployment workflows may need to be simplified to fit the permissions of the account.

Back to FAQ menu

12. Troubleshooting common problems

149. Why does my website show a 500 error?

A 500 response is a broad server side error. Common causes include PHP fatal errors, invalid configuration, unavailable extensions, permission problems and application faults. Error logs are usually the best starting point.

150. What causes a 403 error?

A 403 means access has been refused. Possible causes include permissions, security rules, blocked requests, directory restrictions or a misconfigured application.

151. Why do I get a 404 page after changing permalinks?

The application may need its rewrite rules refreshed, or the relevant web server configuration may be missing or incorrect. Cached routes can also complicate testing.

152. Why is only one page of my site broken?

That often points toward the application rather than the entire hosting environment. A specific template, plugin, database query, missing file or URL can fail while the rest of the site continues to work.

153. Why does the site work on one device but not another?

Browser cache, DNS cache, local security software, network routing or stored cookies can make the same website appear different. Testing from another network can help establish whether the problem is local or server side.

154. Why does a newly uploaded file return the wrong content?

The domain may point to a different document root, a cache may be serving an older version, or the file may have been uploaded to the wrong directory.

155. Why do recent DNS changes seem inconsistent?

DNS information is cached at multiple levels. Different networks can therefore continue using older answers until their cached records expire.

156. What should I check when a site suddenly becomes slow?

Look at application logs, resource usage, recent updates, scheduled jobs, database activity and external services. A sudden change after a plugin update or content import can be particularly revealing.

157. Why can a site work in one PHP version and fail in another?

PHP versions can remove old functions, alter behaviour or expose previously hidden coding problems. Applications and extensions need to be compatible with the selected release.

158. Why does an update cause a blank page?

A fatal application error may have occurred before content could be rendered. Plugin or theme incompatibility, memory exhaustion and PHP changes are common causes.

159. Why can a database table become corrupted?

Several things can contribute, including interrupted writes, software faults or storage problems. The database engine's own diagnostics are more useful than assuming the entire website is damaged.

160. What should I do before changing technical settings while troubleshooting?

Record the current configuration and change one thing at a time. That makes it easier to identify what actually fixed or caused the problem.

Back to FAQ menu

13. Updates and long term maintenance

161. How often should the software on the account be updated?

Security updates should not be ignored for long periods. The exact timing depends on the severity of the release and how critical the application is, but leaving known vulnerabilities unpatched creates avoidable risk.

162. Should I update everything as soon as a new version appears?

Not blindly. Review compatibility, keep a usable backup and test important changes where practical. Major releases deserve more caution than routine security fixes.

163. Why does an old plugin become a hosting problem?

An outdated plugin can consume excessive resources, contain security flaws or become incompatible with the current PHP version. The problem may appear as a website failure even though the underlying machine is functioning correctly.

164. Should I remove inactive plugins?

Unused software still needs maintenance and can remain vulnerable. Removing anything that is genuinely unnecessary reduces the amount of code that has to be managed.

165. What about unused themes?

Keeping a small number of maintained themes is generally easier to manage than retaining every old version ever installed.

166. Can old PHP versions remain on a shared account indefinitely?

No assumption should be made about this. Providers eventually retire unsupported releases, and the timeline differs between platforms.

167. What happens when the provider upgrades the underlying server software?

Your application may continue normally, or something relying on older behaviour may stop working. Providers often manage these changes centrally because individual customers do not control the operating system.

168. Should I monitor storage usage?

Yes. Watching storage helps you catch growing mailboxes, backups, logs, cache files and media collections before the account reaches its limit.

169. Should I monitor database size?

It can be useful, especially for busy applications. Rapid growth may indicate retained logs, excessive revisions, sessions, analytics data or other information that needs housekeeping.

170. How can I tell whether an application is becoming too demanding for the account?

Look for repeated resource warnings, long response times, failed cron jobs, database timeouts and periods when the site becomes unstable under ordinary activity. A pattern over time is more meaningful than one isolated incident.

171. Should I periodically review DNS records?

Yes. Old verification entries, forgotten subdomains and records pointing to retired services can create confusion and unnecessary exposure.

172. What is a good long term maintenance routine?

Keep software updated, test backups, review accounts and access credentials, remove unused files, monitor resource usage and document important DNS and configuration details. Routine maintenance is much easier than trying to reconstruct the setup during an outage.

Back to FAQ menu

14. Australian considerations

173. Is Australian server location the same as Australian data residency?

Not necessarily. The location of the web server is one part of the picture. Backups, logs, support systems, monitoring services, payment systems and third party services may be located elsewhere.

174. Should a business confirm where backups are stored?

Yes, when the location of stored information matters to the organisation. The important question is not just where the live website runs, but where copies and related operational data are kept.

175. Does using an Australian data centre help visitors in New Zealand?

It can. Australian and New Zealand networks are relatively close compared with many overseas routes, although the actual result depends on the visitor's ISP, routing and the particular data centre.

176. Is an Australian location useful for visitors in Asia?

It can be, but the benefit varies widely by country and network. A location that is excellent for Sydney visitors is not automatically the best possible location for every visitor across the region.

177. Can an Australian website serve customers overseas?

Absolutely. Website location does not restrict the geographic area you can serve. A business with international visitors can also use a CDN to improve delivery outside Australia.

178. Should an Australian business use a .au domain with an Australian server?

There is no technical requirement that the two match, although using both can fit a locally focused business. Domain choice and infrastructure location serve different purposes.

179. Is latency important for customers in Sydney and Melbourne?

Yes, especially for interactive pages that require several round trips. A well connected local data centre can help, but page design, caching and application performance still matter.

180. Does the state or city of the Australian data centre matter?

It can influence network routes, redundancy arrangements and proximity to particular customers. A nearby city is not automatically superior if the service has weaker connectivity or infrastructure.

181. Should I ask where the actual machine is located?

Yes, when physical location matters to your decision. A provider may operate in Australia while some services or infrastructure used by the account are located elsewhere.

182. Does local hosting automatically mean local technical support?

No. A company can provide Australian infrastructure while support staff are located in another country, or the reverse. These are separate questions.

183. Does local infrastructure improve SEO in Australia?

Location can contribute to site performance for a local audience, but it is not a substitute for a technically sound, useful website. Search visibility depends on many factors beyond the physical location of the server.

184. Is Australian hosting useful when most visitors are overseas?

It may still be appropriate for business, operational or data location reasons. From a purely performance perspective, however, the best origin location depends heavily on where the visitors actually are.

185. Should I use a CDN with Australian shared hosting?

A CDN can be worthwhile when visitors are spread across Australia and other countries, particularly for static assets. It is less important when the audience is very small and concentrated in one area.

186. Can extreme Australian weather affect the website?

Well designed data centres use power, cooling, network and other resilience measures intended to keep services operating through local disruptions. Reliability depends on the facility and provider's infrastructure rather than the country's weather alone.

187. What should I ask about data centre redundancy?

Ask about power resilience, network connectivity, cooling, backup systems and the provider's approach to hardware and facility failures. Marketing labels such as "enterprise" or "premium" do not explain the actual arrangements.

188. Does physical distance affect Australian visitors equally?

No. Someone in Perth may experience a different network path from someone in Sydney, even when both are connecting to an Australian facility. Internet routing is not simply a straight line on a map.

189. Is local DNS hosting necessary when the website is in Australia?

No. DNS can be operated in another location without preventing the website from being hosted locally. What matters is that the records are correctly configured and the DNS service is reliable.

190. Should an Australian business keep its email in Australia too?

That is a separate architectural and governance decision. If local data location is important, examine the mail provider, backups, logging and related services rather than assuming the website location determines everything.

191. Does an Australian IP address prove that the website is hosted in Australia?

It provides useful information but should not be treated as proof of every part of the infrastructure. A website can use multiple services, proxies, CDNs or external systems.

192. Is shared web hosting in Australia a good long term choice?

It can be, when the website remains comfortably within the account's resource and software limits. A well maintained business site does not need a larger platform simply because it has existed for many years.

193. What is the clearest sign that I have outgrown the shared environment?

Repeated resource constraints, application requirements that cannot be supported, growing background workloads or a need for operating system level control are stronger indicators than age or prestige. When the limitations consistently interfere with normal operation, a different architecture may be justified.

Back to FAQ menu