1–2: Confirm website requirements and CMS support
Selecting a hosting provider starts with documenting the website’s jobs. Publishing content, serving downloads, customer login, orders and custom applications create different requirements. Record simultaneous operations, database needs, media volume and external services alongside traffic assumptions. Make unknowns visible rather than quietly treating them as small.
The second check is support for your actual CMS installation. A WordPress label or one-click installer is insufficient evidence. Compare WordPress’s current official requirements with your themes and plugins. Record ownership of installation, updates, troubleshooting and backups as separate tasks. Ask which of those the purchased service includes.
Shared hosting can be a candidate for some small websites, but it is not an automatic starting point for every new business. A specialised runtime, critical operation or intensive background work can require another model. Start with the current workload and choose responsibilities your team has the capacity to manage.
1. Requirement record
Website type, critical journeys, traffic assumptions, file/database volume and external connections. List unresolved questions separately.
2. CMS support
Runtime, database and extension requirements. Identify maintenance work that a one-click installation does not cover.
3–4: Read resource boundaries and the upgrade path
Your CMS content and integration structure determines the capacity trial. Ask about CPU, memory, storage, file counts and concurrent-work limits. Do not ignore storage and transfer at the beginning. Images, backups and logs can consume resources even on a small site. An unlimited label needs its underlying usage rules.
Distinguish bandwidth from a monthly transfer allowance. MDN describes bandwidth as a connection’s capacity over time, usually expressed in bits per second. A monthly GB allowance is a different boundary. Get the provider’s terminology, measurement period and consequences of exceeding a limit in writing.
The fourth check concerns growth: how are resources added, does an upgrade require interruption or migration, and how does the cost change? Staying with one provider does not automatically avoid moving the website. Define an upgrade trigger and rollback conditions before increased traffic creates an urgent decision.
| Check | Information required | Trial |
|---|---|---|
| 3. Resource limits | CPU, memory, storage and transfer rules | Observe realistic content and simultaneous operations. |
| 4. Upgrade path | Method, cost and possible interruption | Plan required steps and responsibility. |
FROM READING TO A NEXT STEP
Apply the hosting checks to your real website
Share the application stack and critical workflows. We can define the evidence and trial needed before purchase.
5: Assess availability alongside the incident process
A technical website review helps establish whether existing errors can be addressed through a hosting change. Ask which component an uptime percentage measures, from where and over which period. Understand exclusions such as planned maintenance or external dependencies. Service credit cannot replace a continuity plan for your business.
Can you inspect the provider’s status page, incident history and maintenance notices? A site may respond while its form or payment-return workflow is broken. Assign monitoring for the important business journeys. Identify who notices an interruption, contacts support and communicates with users. Those responsibilities need to remain clear outside ordinary office hours too.
Check HTTPS coverage and certificate renewal. Protecting transport does not resolve application vulnerabilities or unauthorised account access on its own. Request a responsibility map for server updates, application maintenance and account management. Evaluate a usable incident process rather than a general security slogan.
6–7: Trial management tools and runtime support
For custom content infrastructure or a ready-made CMS, identify management tools with the technical team. Validate DNS control, file/database transfer, SFTP or deployment access, logs and staging needs. Every package does not have to offer every tool; the tools your workflow requires must be available and usable.
Do not treat .htaccess access as a universal hosting feature. It belongs to Apache configuration, with usage conditions described in the official Apache guide. Ask how redirects and access rules are implemented on a different stack. A file-manager button alone does not prove that the necessary permissions are available.
The seventh check runs the application’s actual version and dependencies. Modern ASP.NET Core can also run on Linux, while older Windows-dependent components need separate assessment. Evaluate runtime support before an operating-system label. Confirm critical login, forms and background tasks in the trial before treating technical compatibility as complete.

8: Validate backup creation and restoration separately
As with migration preparation, record files, databases and email separately in the backup scope. Specify frequency, retention, storage location and access conditions. The amount of data loss the business can accept and the target for restoring service are different questions. The chosen process needs to address both.
A backup appearing in the dashboard does not prove you can restore it in the required way. For example, cPanel’s Backup Wizard documentation explains that automatic full-backup restoration requires provider/WHM involvement. That condition is not universal across hosting products. Verify the actual method and any cost for your package.
Try a sample restore in an isolated test environment. Check content, user access, forms and data consistency, then record the outcome and responsible person. Do not combine successful backup creation and the return of a working service into one completion mark. The trial should expose any missing access or support dependency.
9–10: Close commercial terms and support boundaries
Finish the provider comparison using total cost over the same period. Record signup, renewal, currency, taxes, extra resources, backups, migration and email where applicable. Read trial/refund periods, cancellation methods and excluded items. A fixed percentage is not a universal rule for an acceptable price increase.
Ask about support channels, hours, initial response and intervention scope. A site being unreachable, a broken plugin and an order notification failing can involve different responsibilities. Name the provider’s and developer’s role for each. Investigate the support process through sales explanations, documentation or a demonstration rather than inventing an incident.
Mark the ten checks as passed, awaiting evidence or unsuitable. Assess unresolved mandatory conditions explicitly when making the purchase decision. By the time a provider is chosen, prepare organisational account access, renewal tracking, a support owner and an exit plan. This makes the purchase an operating arrangement the business can sustain.
9. Commercial conditions
Initial term, renewal, extras, trial and refund. Record the usage and period for which the quoted price applies.
10. Support scope
Channel, operating hours, response and intervention boundaries. Name the person who owns and follows a critical problem.
BEFORE YOU DECIDE
Frequently asked questions
Should every new site start with shared hosting?
No. It can be a candidate, but application requirements, usage and operating responsibility determine fit. A specialised runtime or intensive processing may require a different service model.
Is one-click WordPress installation enough?
It simplifies setup but does not automatically cover theme/plugin compatibility, updates, backups or troubleshooting. Verify current requirements and maintenance ownership separately.
Are bandwidth and monthly traffic the same?
Technical bandwidth describes capacity over time, while monthly transfer describes usage volume. Package text may use the terms differently. Ask about units, measurement period, allowance and consequences of exceeding it.
Does every host need .htaccess?
No. It is an Apache configuration method. Validate how your chosen stack manages redirects and access rules, rather than reducing the requirement to one filename.
Does having a backup mean recovery is ready?
No. Scope, retention, access and restoration need separate checks. Restore a sample in isolation and confirm that critical journeys work before treating recovery readiness as verified.
Will a trial or refund cover every charge?
It depends on the provider’s terms. Domain, setup or third-party services may be excluded. Read the duration, cancellation process and data-retrieval conditions before purchase.
LET’S DEFINE THE SCOPE
Apply the hosting checks to your real website
Share the application stack and critical workflows. We can define the evidence and trial needed before purchase.
Discuss your website