For authorised website owners and technical reviewers
Use current plan details, site evidence and supported documentation. The generated images illustrate hosting concepts; they do not show Call IT Mate infrastructure or measured results.
Step 1 of 9
In this guide
Define the site workload and current problem
Define the site workload and current problem
Record the website address, business owner, platform and important tasks, such as reading information, logging in, booking or purchasing. Note the intended audience locations, normal traffic and known busy periods. A small brochure site and a busy transactional application can have different capacity, caching and recovery needs.
If the site is currently unavailable, record the time, affected pages/actions and exact error, then use the known website/hosting support process. A certificate warning, account suspension, application error, exhausted resource and suspected attack need different responses. Do not bypass a warning or immediately buy a new plan before establishing the cause.
For a planned comparison, write down the required functions and actual problem to solve. Separate web hosting from domain registration, DNS, email, website maintenance and content delivery; one supplier may handle several, but they remain distinct services. A hosting move is not automatically a domain transfer, email migration or fix for every slow page.
Define real tasks, audience and symptoms, and use urgent support for a current outage. Keep website hosting, domain, DNS, email and application maintenance distinct.
Next: Record the plan, owners and current evidenceRecord the plan, owners and current evidence
Record the plan, owners and current evidence
Privately record the current hosting account owner, plan, renewal details, included services and support contact. Confirm which party manages the application, updates, certificates, DNS, email, backups and incident response. Keep credentials, secret keys and internal server details out of comparison documents and general enquiries.
Collect relevant existing evidence through authorised access: usage/limit warnings, outage timestamps, error messages, representative page timings and recent support cases. Redact visitor information, tokens and confidential request details before sharing a small example. A marketing statement or one speed-test score is not proof of current capacity or a provider fault.
Before a potentially disruptive change, confirm recoverable site files and data, who can restore them and the necessary acceptance/rollback plan. For WordPress, the official backup guidance distinguishes files and database; downloading the site folder alone usually does not include the database. Do not place exports in a publicly accessible folder or assume a host snapshot is an independent, complete recovery arrangement.
Establish owners, actual plan scope and dated evidence, with private recovery arrangements. Marketing, a single score or a folder copy does not establish performance, responsibility or complete recovery.
Next: Identify the actual capacity or transfer limitIdentify the actual capacity or transfer limit
Identify the actual capacity or transfer limit
Read the actual plan limits and usage for the relevant time period. Storage, monthly data transfer, database size, file-count limits, CPU/memory and concurrent application work can be measured and constrained differently. Ask the host which limit, if any, was reached and what evidence connects it to the observed failure. “Unlimited” may still have resource or acceptable-use conditions.
Check what is using the resource with the website/hosting owner. Logs, duplicate backups, large media, application queries or abnormal traffic can have different causes and remedies. Do not delete uploads, database rows, logs or the only useful backup to clear a warning, and do not raise arbitrary runtime limits on a production site as a trial.
Agree whether the cause needs a scoped cleanup with retention, application work, delivery/caching changes or a plan adjustment. Compare the actual new limits, recurring/overage charges and dependencies before approval. More disk does not automatically fix a slow query or a concurrency limit, and buying capacity does not establish that an attack or broken application is resolved.
Identify the particular limit and its evidence before cleanup or upgrade. Preserve required records and backups; different resource constraints require different actions.
Next: Investigate traffic spikes without a live load testMore checks6 detailed checks
Investigate traffic spikes without a live load test
Investigate traffic spikes without a live load test
Correlate the interruption with actual request volume, affected actions, host/application errors and available resource evidence. A promotion, background job, expensive dynamic page, external dependency, bot traffic and malicious activity can all change demand. Traffic counts alone do not identify the cause or show every request was a genuine visitor.
Have the responsible technical owners assess the bottleneck and suitable controls. Caching may reduce repeated work for eligible public content, while logged-in, cart, checkout and personalised responses need appropriate exclusions and testing. Do not turn caching on for everything or disable security/rate controls simply to improve a test result.
Plan any capacity or load exercise separately with authority, limits, monitoring and a safe environment. Do not generate heavy traffic against the live site or another provider’s system from a public guide. If an attack is suspected, follow the host/security incident process; a paid upgrade or restarted service is not proof the wider problem has ended.
Correlate requests, errors and resource evidence before selecting a remedy. Use a controlled authorised exercise if needed; do not stress the live site or treat every spike as ordinary growth.
Next: Compare Australian performance with representative evidenceCompare Australian performance with representative evidence
Compare Australian performance with representative evidence
Compare representative pages and tasks from relevant Australian visitor locations and, where useful, another region. Record device/network conditions, login state, cache state and timing so results are comparable. One test over office Wi-Fi or a distant test location cannot establish how all Australian visitors experience the site.
Time to first byte includes connection and server-response delays; it is different from complete page rendering or interaction readiness. Distance to the responding server can matter, but application/database work, redirects, cache behaviour, large assets and third-party requests can also affect results. An Australian domain or business address does not prove the origin server is in Australia.
Ask where the actual origin and any content-delivery caching operate, what content is cached and what reaches the origin dynamically. A content delivery network can help eligible cached content reach users nearer its edge, but does not automatically remove slow dynamic processing or make every action fast. Use evidence to choose the affected layer rather than promise a local server alone fixes the site.
Compare representative Australian conditions and separate response, transfer and rendering work. Origin location and caching can matter, but neither guarantees every page and dynamic task is fast.
Next: Compare features, support and security responsibilitiesCompare features, support and security responsibilities
Compare features, support and security responsibilities
Compare application compatibility, supported runtime/database versions, HTTPS, staging, backups, reporting and required integrations against the real site. For WordPress, use the current official requirements alongside theme/plugin compatibility and support. Do not switch PHP/database versions or install a new control panel on production merely because a comparison chart lists a higher number.
Ask who maintains each layer and handles an incident, certificate renewal, restore, malware issue and application fault. Confirm backup coverage, frequency, retained history, protection from deletion, restoration access and an authorised restore check. The Australian website security guidance provides questions about hosting safeguards and responsibilities. A certificate, security badge or included backup does not prove the website cannot be compromised or fully restored.
Confirm staffed support hours/time zone, channels, priority/escalation, response versus restoration targets, exclusions and extra charges. Infrastructure uptime and support for a broken plugin may have different scopes. Compare current written terms and actual support evidence, including how to reach help when normal email fails. Do not infer immediate repair or universal application support from “24/7”.
Compare supported features, restore evidence, ownership and real support commitments. Requirements, a badge or a managed label do not establish complete security, recovery or instant repair.
Next: Plan a controlled change and protect other servicesPlan a controlled change and protect other services
Plan a controlled change and protect other services
If a change is justified, agree the precise work, current quotation/renewal terms, migration or setup charges, affected services, authority and acceptance. Keep ownership of business accounts and required documentation clear. Compare the whole scope rather than an introductory price alone; do not cancel the existing service before continuity and recovery have been settled.
Have the authorised website/hosting owners prepare and verify an appropriate staging or migration copy, including the required files, database, certificates, application configuration and sensitive-data handling. Keep a test copy from sending real customer mail, taking live payments or exposing private content. A staging site is not safe merely because its URL is obscure.
Coordinate any DNS change with the actual DNS owner, preserving unrelated website/email records and a practical recovery plan. A nameserver change can affect services beyond the website; a domain transfer is not a routine prerequisite for changing hosting. Record how new orders, messages or other writes during the transition will be handled. Reversing DNS alone may not reconcile changes made in two copies.
Approve the exact scope and protect sources, accounts, private staging data and dependent services. Retire the old arrangement only through an accepted transition, not a trial cancellation or blanket DNS replacement.
Next: Verify the agreed site tasks and capacity scopeVerify the agreed site tasks and capacity scope
Verify the agreed site tasks and capacity scope
Verify representative public pages and permitted account/application tasks under agreed conditions. Confirm HTTPS, key assets, expected content, required integrations and appropriate caching behaviour. For forms or commerce, use an authorised safe test process; do not submit real leads, customer data, payments or orders merely to check the page.
Review the specific resource/error evidence that prompted the work, compare relevant regional timings and confirm support/recovery responsibilities. If hosting or DNS changed, check the affected website and other agreed dependencies. Record what was actually tested, what remains untested and who owns any unresolved issue. A page loading once does not prove traffic-spike capacity or complete restoration.
Stop unrelated changes when the agreed scope is accepted. Keep necessary prior sources and recovery until the responsible owner authorises retirement, and schedule review around renewals or workload changes. This limited verification does not guarantee uptime, universal Australian speed, all-traffic resilience or a particular search ranking.
Verify the real tasks and original constraint, record regional/functional scope and gaps, and retain required recovery. One successful page request is not a load, uptime, security or full-migration guarantee.
Back to the symptom checkerGet help with a defined hosting or performance problem
Get help with a defined hosting or performance problem
Use the actual hosting provider and website owner to assess a limit, interruption, application fault or move. Privately provide the site/task, affected time and region, minimal relevant error/usage evidence and current plan scope. Do not send passwords, database exports, private visitor logs or full server configuration in a general enquiry.
Our web hosting service and website speed optimisation pages can start a scoped discussion. Agree authority, preservation, actual responsibilities, costs and verification before work. No generic feature list guarantees a site will never fail or that a hosting move will fix every slow task.
If an incident is suspected, preserve relevant evidence and follow the known response process. If the actual cause is application code, content or another service, keep that work separately owned rather than changing hosting repeatedly. A useful assessment should identify the next responsible action and its limits.
Use the right provider and website owner for the actual fault. Keep evidence minimal and scope the work; hosting, application performance and incident response may need different owners.
