What sets our shared CLOUD hosting apart:

No renewal price hikes | No upselling | No hidden fees | No overloaded servers | No shared databases | Fixed monthly pricing, even for Cloud Hosting | Expert support | Free 30 day trial | Free website migration

100% WordPress-Compatible Web Hosting Servers

WordPress Hosting Solutions

Economy	Regular	Deluxe	Ultimate
Perfect for customers who only want a simple personal website or a blog.	A good choice for any online store or a fairly complex website.	A reasonably priced shared web hosting package, good for resource-heavy personal websites.	The right solution for high-profile websites with lots of visitors.
Unlimited storage	Unlimited storage	Unlimited storage	Unlimited storage
Unlimited bandwidth	Unlimited bandwidth	Unlimited bandwidth	Unlimited bandwidth
1 website hosted	5 websites hosted	Unlimited websites hosted	Unlimited websites hosted
24/7/365 support	24/7/365 support	24/7/365 support	24/7/365 support
30 Days Money Back Guarantee	30 Days Money Back Guarantee	30 Days Money Back Guarantee	30 Days Money Back Guarantee
30-Day Free Trial	30-Day Free Trial	30-Day Free Trial	30-Day Free Trial
$4.95 / month	$8.75 / month	$17.50 / month	$25.00 / month
Compare All Hosting Plans	Compare All Hosting Plans	Compare All Hosting Plans	Compare All Hosting Plans
Create Account	Create Account	Create Account	Create Account

Questions about WordPress.org Web Hosting? See our FAQ.

A narrative guide to WordPress.org Web Hosting.

There is a funny thing about building a website.

People spend hours choosing a name. They look at themes, colors, fonts, photographs, menus, logos, buttons, and page layouts. They worry about what the homepage should say and whether the contact form looks trustworthy.

And then, somewhere in the middle of all that activity, there is a question that often gets treated as an afterthought:

Where is the website actually going to live?

That question is easy to overlook because hosting is mostly invisible. Visitors do not see the server. They do not know what operating system is running behind the scenes. They are not thinking about PHP versions, databases, storage systems, CPU limits, or how many simultaneous processes the account can handle.

They simply click a link.

The page opens.

Or it does not.

A site can feel quick and effortless because the underlying environment is doing its job quietly. It can also feel frustratingly slow for reasons that have nothing to do with the design the visitor is looking at.

That is why choosing a place for a WordPress.org website to live deserves more thought than simply searching for the cheapest plan with the largest number beside the word “storage.”

The Beginning

Imagine a man named Daniel.

He has finally decided to build the website he has been talking about for several years.

It will begin modestly. There will be a homepage, an About page, a few articles, a contact page, and perhaps a services section. He expects only a small number of visitors during the first few months.

So Daniel does what almost everyone does.

He searches.

There are hosting companies everywhere. Some promise simplicity. Others talk about speed. Some advertise huge amounts of storage. Others concentrate on security, automatic updates, or specialized platforms.

Then he notices the prices.

One company is considerably cheaper than the others.

Daniel almost clicks the order button.

But then he stops.

He realizes that he is not really buying a pile of storage or a monthly allowance of bandwidth. He is renting a place for software to operate.

That changes the question.

Instead of asking, “Which host is cheapest?” he starts asking, “What kind of environment will keep my website healthy?”

That second question is where a more sensible hosting decision begins.

Back to main menu

What WordPress.org Actually Means

There is often confusion around the words WordPress.org and WordPress.com.

They are related, but they are not the same thing.

WordPress.org is the home of the open-source WordPress software. You can obtain the software and install it on a hosting account of your choice. You therefore have much more direct control over the server environment, themes, plugins, files, database, and overall configuration of the website.

WordPress.com is a hosted service that runs WordPress for you as part of its own platform.

That distinction matters when discussing hosting.

When someone says they need hosting for a WordPress.org website, they are normally talking about finding a server where they can install and operate the WordPress software themselves, rather than simply creating a site inside a hosted service.

That freedom is one of the great strengths of the open-source model.

It also creates a responsibility that is easy to forget.

You get more control, but the environment you choose now matters more.

WordPress.org itself explains that WordPress needs a web server and that hosting providers can offer either general-purpose hosting or environments specifically designed around WordPress. It also maintains a page of recommended hosts, while pointing users toward the technical requirements that a suitable environment should meet.

So the hosting company becomes more than a company that provides disk space.

It becomes part of the environment in which your website exists.

Back to main menu

Why the Hosting Environment Matters

Suppose Daniel installs WordPress on two different servers.

The files are identical.

The theme is identical.

The plugins are identical.

The website content is identical.

Yet the two websites can behave differently.

One might open pages comfortably even when several visitors arrive together. The other could struggle when the database is busy or when a plugin starts using more resources.

One provider might make it easy to restore a backup. Another might technically have backups but make restoration difficult or slow.

One may offer a modern PHP environment and regularly maintained server software. Another may keep old components available for compatibility with legacy applications.

None of this is visible in the homepage design.

But it can become very visible to the person managing the site.

This is why a hosting plan should be judged as an operating environment, not simply as a collection of marketing numbers.

Storage matters, but storage is only one piece.

Bandwidth matters, but bandwidth is only one piece.

CPU resources matter. Memory matters. Database performance matters. PHP execution matters. File handling matters. Network quality matters. Security matters. Backup procedures matter.

And when something breaks, support matters enormously.

A cheap plan can look expensive very quickly when the website owner loses an afternoon trying to discover why a perfectly ordinary plugin stopped working.

Back to main menu

The Quiet Machine Behind the Screen

Most people never think about the physical or virtual machine that serves their website.

That is understandable.

When you type a web address into a browser, you expect something almost magical to happen. A request travels across the internet, reaches the appropriate server, WordPress does its work, the database supplies information, PHP processes the application logic, and the finished response is sent back to your browser.

All of that happens in a surprisingly short time.

What appears to be a simple webpage can therefore involve several systems working together.

The web server accepts the request.

PHP executes the application.

The database retrieves information.

The filesystem supplies images, scripts, stylesheets, and other files.

Security systems inspect traffic.

And sometimes caching systems help reduce how much work has to be repeated.

When everything is configured sensibly, the visitor sees none of this.

That is the goal.

The machinery disappears and the website remains.

Back to main menu

What WordPress Needs Today

This is one area where old hosting information can become misleading.

You will still find pages on the internet telling people that WordPress only needs very old versions of PHP and MySQL. Those statements may describe what the software can still run on, but they are not the modern baseline that WordPress.org recommends.

WordPress.org currently recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS. Apache or Nginx is recommended as the most robust and feature-rich web-server environment, although the requirements page notes that other servers supporting PHP and MySQL can also run WordPress.

That is a useful distinction.

There is a difference between “the software can still run” and “this is the environment recommended for a modern website.”

The WordPress Hosting Team also notes that PHP 8.4 and later are recommended for production environments, while PHP 8.3 has moved into security-only support. Its compatibility information shows that current WordPress releases continue to support modern PHP versions while the older minimum remains substantially lower than the versions recommended for new installations.

For a new website, that leads to a simple lesson.

Do not choose a host merely because it can somehow run WordPress.

Choose an environment that makes sense for a current WordPress installation.

Back to main menu

The Shared Hosting Question

Now Daniel discovers shared hosting.

The concept is simple.

Instead of paying for an entire server, many customers share the underlying infrastructure. This allows hosting companies to spread the cost across a large number of websites.

For a modest website, that can be entirely sensible.

There is nothing inherently wrong with shared hosting.

The important question is how the particular provider manages it.

Imagine an apartment building.

You have your own apartment, but you do not own the building. You share some of its infrastructure with everyone else.

If the building is well managed, there is no reason that arrangement cannot work beautifully.

But if too many people are squeezed into too little space, or if one tenant uses an extraordinary amount of a shared resource, everyone can notice the consequences.

Hosting works in a similar way.

The phrase “shared hosting” tells you something about the architecture, but not enough about the quality of the environment.

A carefully managed shared platform can be a very good home for a small WordPress site. A badly managed one can become frustrating even when the website itself is perfectly ordinary.

That is why resource limits deserve attention.

How much memory is available?

How much CPU time can the account use?

How many PHP processes can run at once?

Are there limits on database operations?

What happens when those limits are reached?

Those questions are usually more revealing than the amount of advertised disk space.

Back to main menu

The Database Nobody Sees

Visit a WordPress website and you see words, pictures, menus, buttons, and pages.

Behind that visible layer sits something much less glamorous.

The database.

It quietly stores a huge amount of the information that makes the website what it is.

Posts. Pages. Settings. Users. Comments where they are enabled. Plugin data. Theme settings. Categories. Tags. Custom fields. Relationships between pieces of information.

When you change the title of a page, you are not necessarily editing a giant piece of HTML sitting somewhere waiting to be delivered. WordPress often works dynamically, assembling the response from information stored in the database and files on the server.

That is why database performance can affect the experience even when the website does not appear technically complicated.

A site with thousands of posts, complicated plugin queries, large amounts of user information, or an especially busy administration area can create a very different workload from a small brochure-style website.

WordPress.org's installation documentation makes the basic point clearly: WordPress requires a MySQL or MariaDB database to store information.

The database therefore deserves to be treated as part of the website itself.

When you think about backups, performance, migration, and security, you are not really protecting “the files” alone.

You are protecting the relationship between the files and the information inside the database.

Back to main menu

Why PHP Matters

Daniel once assumed that PHP was something only developers needed to worry about.

Then a plugin stopped working.

The support message asked which PHP version he was using.

Suddenly, PHP did not seem so abstract.

WordPress is built around PHP, which means PHP is fundamental to the way the application operates on the server. The WordPress documentation describes PHP as the scripting language that drives the software and explains that the host needs to provide a supported version.

A modern hosting environment should therefore make it straightforward to run a current PHP version rather than forcing the site owner to remain on an outdated version indefinitely.

There is also a practical reason to pay attention to PHP beyond compatibility.

Newer releases can bring improvements in performance, security, and language capabilities. But websites are rarely made only from WordPress core. They are assembled from themes, plugins, custom code, and sometimes older components that may not all move forward at exactly the same speed.

That is why the ability to select and change PHP versions can be useful during maintenance.

A good host gives the website owner room to move forward.

Back to main menu

HTTPS Is No Longer an Extra

There was a time when people thought of HTTPS as something primarily associated with online banking or shopping carts.

That way of thinking has aged badly.

Today, HTTPS is part of the normal foundation of a modern website.

WordPress.org currently lists HTTPS as required for every installation and describes it as the mechanism that encrypts the site's connection.

For a visitor, HTTPS is represented by something very small in the browser interface.

For the website owner, it is more significant.

It affects how the site's connection is protected, how browsers treat the site, how forms are handled, and how modern services interact with the website.

Most reputable hosts now make SSL certificates easy to obtain and use, but “easy” should not be confused with “unimportant.”

A responsible hosting decision should include HTTPS from the beginning rather than treating it as a feature to add later.

Back to main menu

When Somebody Says “Fast Hosting”

Fast.

It is one of the favorite words in hosting advertisements.

Unfortunately, it is also one of the vaguest.

What exactly does fast mean?

A fast processor?

Fast storage?

Low network latency?

A well-configured web server?

Plenty of PHP workers?

An effective caching layer?

A quick database?

Optimized images?

All of the above?

The honest answer is that website speed is usually the result of many things working together.

A powerful server cannot compensate for a plugin that performs expensive database operations on every page load.

A beautiful modern theme cannot overcome enormous uncompressed images.

An excellent caching system cannot fix a badly configured server that repeatedly runs out of memory.

And even a well-optimized website can struggle if the underlying hosting account has severe resource restrictions.

This is why “fast hosting” should be treated as a starting point for investigation rather than a conclusion.

What matters is whether the environment can deliver the website's actual workload consistently.

Back to main menu

Images, Files, and the Weight of a Website

There was a time when a website could consist of a few lightweight images and some text.

Those days are mostly gone.

Modern sites can contain hero photographs, galleries, banners, videos, downloadable files, product images, PDF documents, screenshots, icons, fonts, and other media.

One large photograph is not necessarily a problem.

One hundred poorly optimized photographs can become one.

That is why storage and bandwidth should be considered together with the way media is prepared.

Imagine a restaurant website with photographs uploaded directly from a modern smartphone. The original image might be far larger than necessary for the space in which it will appear.

The site owner may think, “The host gives me plenty of storage, so there is no problem.”

But the visitor is not concerned with storage.

The visitor is waiting for the browser to receive the file.

So the best result often comes from two decisions working together: a hosting environment capable of delivering media efficiently and a website that does not send unnecessarily heavy files to the visitor.

Good infrastructure helps.

Good housekeeping helps too.

Back to main menu

Plugins Change the Story

One of the most attractive things about WordPress is also one of the reasons hosting discussions become complicated.

Plugins can change what the website does.

Suddenly the simple blog becomes a membership system.

Then it becomes a store.

Then somebody adds a backup tool, a security plugin, a visual editor, an SEO system, an image optimizer, analytics, a form builder, a booking system, and a handful of other extensions.

Each one may be useful.

Together they create an application environment that is much more demanding than the original installation.

That does not mean plugins are bad.

It means the website's workload is shaped partly by the decisions made after WordPress was installed.

A lightweight informational site with a small number of carefully chosen plugins may have modest requirements.

A highly customized site with many extensions, large databases, scheduled tasks, external connections, and complex functionality may require considerably more resources.

That is why two WordPress sites on the same server can behave very differently.

The WordPress core is only part of the story.

The rest is what you build around it.

Back to main menu

The Theme Is Only Part of It

The theme is usually the first thing people notice.

It controls much of the visual presentation, so it is natural to think of the theme as the personality of the site.

But the theme is not the whole website.

It is more like the building's interior design.

The server is the building itself.

The database is the storage room full of records that keep everything organized.

The plugins are the machinery and specialist equipment added for particular jobs.

The WordPress software is the system coordinating all of it.

That analogy explains why changing a theme can alter the site's performance even though the hosting account remains exactly the same.

One theme may load a relatively small amount of code. Another may introduce sliders, animations, additional scripts, dynamic layout features, and other resources.

Again, there is no universal rule that one approach is always best.

The practical lesson is simply to remember that a hosting environment cannot be judged independently from what will actually run inside it.

Back to main menu

What Happens When More People Arrive?

For months, Daniel's website receives a comfortable number of visitors.

Then something happens.

An article is mentioned by a large website.

Traffic rises.

His hosting plan does not change.

The server does not suddenly become physically different.

But the workload changes dramatically.

More people mean more requests.

More requests can mean more PHP execution, more database activity, more file delivery, and more concurrent processes.

This is where the difference between a website that merely “works” and a website that has enough capacity begins to reveal itself.

A small site can appear perfectly healthy on a modest plan because it rarely asks very much from the server.

Give the same site a sudden surge of visitors, and previously invisible limitations can become obvious.

This is why it is useful to think about capacity rather than only normal-day performance.

You do not need to buy the largest server available just because there is a possibility that your website might become popular.

But you also do not want a hosting environment so restrictive that a successful article becomes the event that brings the whole site to its knees.

Growth is supposed to be good news.

Your hosting should be able to handle at least some of it.

Back to main menu

Security Begins Before the First Visitor

Security is sometimes treated as a plugin that gets installed after the website has been built.

It is better understood as part of the environment from the beginning.

The server needs to be maintained.

PHP needs to be kept on a supported version.

Access needs to be protected.

HTTPS needs to be configured properly.

Accounts need sensible passwords and permissions.

WordPress itself, along with themes and plugins, needs responsible maintenance.

There is no single button marked “secure website.”

A hosting provider can provide a safer foundation, but it cannot take over every responsibility associated with the software installed by the customer.

That distinction matters.

A host manages the server environment it controls. The website owner still has to make sensible decisions about WordPress, plugins, themes, accounts, custom code, and administrative access.

WordPress.org's current requirements page also recommends an account setup in which PHP applications run using the account's own username rather than the server's default shared username, as an additional security consideration for hosting environments.

Security is therefore not one feature.

It is a chain.

Good hosting is one of the links.

Back to main menu

The Day Something Goes Wrong

There is an old rule in computing:

A backup is not important until the moment you desperately need one.

Daniel learns this the hard way.

One afternoon, he is making changes to the site. A plugin is behaving strangely. He tries something that seems harmless.

Then something goes wrong.

The website is not behaving as it did ten minutes earlier.

He is suddenly very interested in the word “restore.”

This is where the quality of a backup strategy becomes real.

A backup should not simply exist somewhere in an account. It should be usable.

The site files matter.

The database matters.

Uploads matter.

Configuration matters.

Customized files matter.

And the website owner should have some understanding of what can actually be restored and how long restoration takes.

A provider may advertise daily backups, but the sensible question is what happens when you need yesterday's version back.

Can you restore the entire account?

Can you restore the database?

Can individual files be recovered?

How long are backups retained?

Are backups stored separately from the live website?

There is no benefit in discovering the answers after disaster strikes.

Back to main menu

Updates and the Passing of Time

A website is not a photograph.

It changes.

WordPress changes.

Plugins change.

Themes change.

PHP changes.

Browsers change.

Security expectations change.

Even the hardware and software underneath the hosting account changes.

This is normal.

The problem begins when a website stands still while everything around it moves forward.

Old versions can become harder to support. New software may stop working with legacy components. Security updates eventually become unavailable for some products. A host may retire an older platform and require customers to move to a newer one.

That is why it is useful to think of hosting as a relationship rather than a purchase.

You are not merely buying a month of server time.

You are choosing the environment in which your website will need to evolve.

A provider that makes modernization difficult can become a burden over the years.

A provider that makes sensible upgrades straightforward can make website ownership considerably easier.

Back to main menu

When Support Becomes Important

Daniel once believed that good hosting meant never needing customer support.

Then he discovered what hosting support is really for.

Sometimes you do not need someone to fix your website.

You need someone to tell you what the server is doing.

Is the account hitting a memory limit?

Is the PHP version configured correctly?

Is the database server responding normally?

Has an account-level restriction been triggered?

Is there a problem with the server's configuration?

Or is the problem entirely inside WordPress?

Those questions can be surprisingly difficult for a non-technical website owner to answer alone.

Good support does not mean the hosting company should rewrite every plugin that has a bug.

It means the provider should be able to explain the environment it is responsible for and help identify where a problem appears to be coming from.

The distinction is important.

Sometimes the host is at fault.

Sometimes WordPress is at fault.

Sometimes a plugin is at fault.

Sometimes the administrator changed something five minutes earlier and forgot about it.

A good support team helps narrow the possibilities.

That can be worth far more than a tiny difference in the monthly price.

Back to main menu

Managed or More Hands-On?

At some point Daniel notices that hosting can be divided into another question.

How much responsibility does he actually want?

A more managed service can take care of more of the underlying environment, depending on the provider and the exact service being offered.

A more hands-on VPS arrangement may give him greater control over the server, but that control brings responsibility with it.

The word “managed” is therefore worth examining carefully.

Different companies use it differently.

One provider may include operating-system updates, monitoring, backups, and assistance with configuration. Another may call a service managed while leaving significant administration to the customer.

On an unmanaged environment, the administrator may need to understand server configuration, security updates, firewalls, monitoring, software installation, and troubleshooting at a considerably deeper level.

That can be a wonderful arrangement for someone who enjoys server administration.

It can be an exhausting arrangement for someone who simply wants to publish articles and run a business.

Neither approach is automatically superior.

The right question is:

Who is going to take responsibility when the server needs attention?

Back to main menu

Moving to Another Host

There is another part of hosting that people rarely consider when buying their first plan.

Leaving.

A website may stay with the same provider for years. Or it may not.

Perhaps the site becomes too large for the current environment.

Perhaps support deteriorates.

Perhaps the provider changes its platform.

Perhaps the price rises substantially.

Perhaps the website simply needs something the current host does not offer.

Whatever the reason, migration becomes part of the story.

Moving a WordPress website is not simply a matter of copying a folder.

The database must move.

Uploaded files must move.

Configuration needs to be correct.

Domains and DNS may need to be changed.

SSL must work on the new server.

PHP and database versions need to be compatible with the site.

Permissions need to be sensible.

Plugins and themes need to behave properly in the new environment.

And the website should be tested before the old hosting account is finally abandoned.

That is why portability matters.

One of the great strengths of self-hosted WordPress is that the site is not permanently locked to a particular hosting company. The freedom to move is valuable.

A good host should not make you afraid to leave.

Back to main menu

When a Small Site Gets Serious

Daniel's original plan was simple.

Ten pages.

A few articles.

Not many visitors.

Then the website began to grow.

The articles started attracting search traffic.

People shared them.

The contact form began generating genuine business.

More content followed.

More images were uploaded.

A few new plugins were added.

The database became larger.

The administration area became busier.

One day, Daniel notices that his hosting account has become the least interesting part of the website.

And that is a good thing.

The website has matured.

The hosting environment may eventually need to mature with it.

That could mean moving from a basic shared account to a stronger shared environment, a managed WordPress platform, a VPS, or dedicated infrastructure. The correct answer depends on the site's actual workload rather than the prestige of the hosting label.

A large server does not automatically make a small website better.

A small server does not automatically make a large website bad.

What matters is whether the environment provides enough resources, reliability, compatibility, security, and flexibility for the job.

Back to main menu

Common Hosting Mistakes

Some hosting mistakes appear again and again because they are easy to make.

The first is choosing by storage alone.

A huge storage allowance sounds impressive, but a website can have hundreds of gigabytes available and still suffer from insufficient processing resources.

The second is assuming that any account advertising PHP and MySQL is automatically a good modern WordPress environment.

WordPress.org now recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS. Older environments may still run WordPress, but that is not the same thing as being the recommended baseline for a new site.

The third mistake is ignoring resource limits.

Two providers can sell apparently similar hosting packages while placing very different restrictions on CPU, memory, processes, databases, or other resources.

The fourth is treating backups as somebody else's problem.

A hosting company's backup system can be useful, but the website owner should understand what is covered and how restoration works.

The fifth is installing plugins without considering the combined workload.

One extension may be harmless. Fifteen extensions doing heavy background processing are another matter.

The sixth is ignoring images.

Large files can make a site heavier than necessary, regardless of the quality of the server.

The seventh is waiting until the website is already overloaded before considering what happens next.

Planning an upgrade when everything is calm is considerably more comfortable than trying to migrate a struggling website in a panic.

And perhaps the most common mistake of all is assuming that hosting is something you buy once and forget forever.

Websites do not work that way anymore.

Back to main menu

How to Compare Hosting Properly

Imagine that Daniel has narrowed his choices to three companies.

The first is the cheapest.

The second has the largest storage allowance.

The third is slightly more expensive but clearly explains what is included.

Which one should he choose?

The answer cannot be found in the headline price.

He should begin with compatibility.

Does the provider support the modern PHP version recommended by WordPress.org?

Is the database environment current?

Is HTTPS properly supported?

What server software is used?

Can the account handle the expected workload?

What resource limits apply?

How are backups handled?

How are restores performed?

Can the site be upgraded without a painful migration?

How easy is it to change PHP versions?

What does customer support actually help with?

And perhaps most importantly:

What happens when the website becomes more successful than expected?

That final question is often forgotten.

A hosting company should not merely be evaluated by how well it handles your website on its quietest day.

It should also be evaluated by how well it can accompany the website as it grows.

WordPress.org itself recommends checking the host's technical compatibility before installation, rather than treating compatibility as an afterthought.

Back to main menu

A Sensible Setup

So what does a sensible environment look like?

There is no single specification that every WordPress website needs.

A personal blog and a busy online store are not the same thing.

A local business website and a large membership platform are not the same thing.

A website with ten pages and a website with ten thousand published entries should not necessarily live on identical infrastructure.

But there are some fundamentals.

Start with a current, supported PHP environment.

Use a current supported database platform.

Use HTTPS.

Make sure the web server is properly configured.

Know the hosting account's resource limits.

Have a realistic backup and restoration strategy.

Keep WordPress, themes, and plugins maintained.

Make sure images and other media are reasonably optimized.

Choose a service that can be upgraded as the website grows.

And know who you will contact when something unexpected happens.

WordPress.org's current recommendations provide a sensible technical starting point, while the actual hosting choice should be shaped by the site's workload and the amount of control and assistance the site owner wants.

That is a much better starting point than simply asking which plan has the biggest number.

Back to main menu

The Long-Term View

Five years pass.

Daniel looks back at the website he originally built and almost does not recognize it.

The homepage has changed.

The design has changed.

The amount of content has changed.

The number of visitors has changed.

The database has become much larger.

Several plugins have been replaced.

Others have disappeared entirely.

The PHP version has moved forward.

The hosting environment has changed too.

And Daniel has discovered something important.

None of these changes means that the original hosting decision was necessarily wrong.

The website simply grew.

That is what websites are supposed to do.

A website that begins on a modest hosting package does not have to remain there forever. A small site should not be forced into expensive infrastructure from day one merely because someone might someday need it.

But the reverse is also true.

A successful site should not remain trapped on inadequate infrastructure simply because the original plan was cheap.

The sensible approach is to start appropriately and grow deliberately.

Back to main menu

The Ending Is Really a Beginning

Back in the beginning, Daniel thought he was choosing a hosting plan.

He was actually choosing an environment.

That small difference in wording turned out to matter.

The website he built depends on a server that can execute the software, a database that can store its information, storage that can hold its files, a network that can deliver them, security measures that help protect the environment, and a backup system that can help bring the site back when something goes wrong.

None of that appears in the website's navigation menu.

None of it is visible in the hero image.

Yet it is all part of the experience.

When a visitor clicks a page and it opens smoothly, the visitor does not praise the database.

When a contact form works, the visitor does not think about PHP.

When an article loads correctly after a server update, nobody sends a thank-you note to the backup system.

That is how infrastructure is supposed to work.

It stays in the background.

It does its job.

And the website gets to be the website.

That is perhaps the most useful way to think about hosting for a WordPress.org site.

You are not simply buying somewhere to place files.

You are choosing the environment in which your website will live, change, grow, and occasionally misbehave.

The best choice is therefore not necessarily the cheapest package. Nor is it necessarily the most expensive server available.

It is the environment that fits the website you have, gives it enough room to breathe, meets the current technical expectations of WordPress, and offers a sensible path forward when the site becomes larger, busier, or more demanding.

And that is the part that is easy to miss when comparing hosting companies.

The real product is not the storage number.

It is everything that happens between the moment a visitor clicks the link and the moment the page appears on the screen.

Back to main menu

Practical Takeaway

Choosing a home for a WordPress.org website does not need to become a technical nightmare.

Start with the fundamentals. WordPress.org currently recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS. Apache or Nginx is recommended, while WordPress can also operate on other suitable PHP and MySQL-compatible server environments.

Then look beyond the basic compatibility checklist.

Consider the resources available to the account. Understand the database environment. Check what backups actually include. Find out how restoration works. Look at how easy it is to change PHP versions. Ask what happens when traffic increases. Find out what support covers. And think about whether the service gives the website somewhere sensible to go when it grows.

Most importantly, do not confuse a technically compatible host with a good host for your particular website.

A hosting plan can meet the minimum requirements and still be a poor fit because of severe resource limits, weak support, awkward administration, inadequate backup procedures, or a lack of room for future growth.

On the other hand, a modest plan from a well-managed provider can be an excellent home for a small site.

The goal is not to buy the biggest server.

The goal is to give your website the kind of home where it can quietly do its job.

Because when everything is working properly, hosting is almost invisible.

And perhaps that is the best compliment a hosting environment can receive.

Back to main menu

FAQ

This FAQ is about using the self-hosted WordPress software: you have a domain, a hosting account, and a WordPress installation running on the server. It explains what each part does, what you really need, what can go wrong, and the little things that become important once you have been running a site for a while.

FAQ menu

• 1. Getting your head around the setup
• 2. The server WordPress runs on
• 3. Installing it and getting online
• 4. Themes, plugins, and customization
• 5. PHP, databases, and the less visible stuff
• 6. Making the site fast
• 7. Security and backups
• 8. Domains, DNS, HTTPS, and email
• 9. Updates, maintenance, and fixing things
• 10. Moving the site and dealing with growth

1. Getting your head around the setup

1. So what does WordPress.org give me?

The simplest way to think about it is this: you get the WordPress software, but not the computer it runs on. You download or install the software on a server, connect your domain to that server, and then manage the site from there. That separation is actually a very good thing because you are free to choose the company providing the server and can move the site later if you decide you no longer like the service.

2. Why do people call it “self-hosted”?

It sounds as though you have to own a server, but you don't. “Self-hosted” mainly means that you are responsible for the WordPress installation while a hosting company supplies the server. You are renting the space and computing resources rather than handing the whole website over to one closed platform.

3. Is WordPress.org the same as WordPress.com?

No, and getting this straight at the beginning saves a lot of confusion later. WordPress.org is the home of the open-source software, while WordPress.com is a hosted service that offers WordPress websites as a product. They are closely related, but the rules, pricing, available features, and amount of control can be quite different.

4. Why would I choose the self-hosted route?

Usually because you want freedom. You can choose your own provider, install the plugins and themes you need, access your files and database, make deeper changes, and move the whole site somewhere else when necessary. That freedom is particularly valuable once a site becomes important to you and you don't want somebody else's platform deciding what you can and cannot do.

5. What's the catch?

The trade-off is that you have more things to look after. Nobody is going to magically know that a plugin has been abandoned, that your PHP version needs attention, or that your backup failed last Tuesday unless you or your provider are watching those things. It is not difficult, but it is a little more hands-on.

6. Do I have to be a programmer?

No. Most people who run ordinary sites spend very little time writing code. You can create pages, publish articles, upload pictures, install plugins, and change your design from the dashboard. Technical knowledge becomes useful when you start customizing the installation or have to diagnose a problem, but there is no programming exam you need to pass before you can publish your first page.

7. Is it overkill for a small site?

Not at all. A small company site or personal project can run on a modest account without using anything complicated. In fact, a small site is a nice place to learn because you can experiment without having a huge operation depending on every little change you make.

8. Can it be used for something much bigger?

Yes. The same software can sit behind a very small brochure site or a much more demanding operation. What changes as a site grows is usually the hosting environment, the amount of server power it needs, the way caching is handled, and the care taken with backups and maintenance.

9. Who owns my website?

Your hosting account doesn't turn your site into the property of the hosting company. You normally control the WordPress installation, its content, and the domain, subject of course to the terms of the services and licenses you use. This is one of the reasons I always tell people to keep access to their own domain registrar and important accounts.

10. Can I leave my provider later?

Yes. That is one of the first things I like about this setup. You can take your files and database to another server and point the domain there. A move can be simple or complicated depending on the site, but you are not permanently married to the first host you choose.

11. Is there any reason not to move?

Only practical ones. Moving a mature site takes time, and a complicated installation may have special server settings, email arrangements, scheduled jobs, or integrations that need to be recreated. A good provider is worth keeping when it is doing the job well, so I would not move simply for the sake of moving.

Back to FAQ menu

2. The server WordPress runs on

12. What is the server actually doing?

It stores the site's files, runs the WordPress code, talks to the database, and sends the finished result back to the visitor's browser. When somebody opens a page, the server may have to do quite a bit of work before anything appears on the screen. You don't usually see that work, which is why it is easy to forget that there is a real machine underneath the dashboard.

13. What does WordPress need from the server?

At the basic level, it needs a supported version of PHP, a compatible database such as MySQL or MariaDB, and a web server configured to serve the site properly. It also needs enough memory, processing power, storage, and network capacity for what you are asking it to do. The exact requirements become more demanding when you add things such as a store, membership system, or large amounts of traffic.

14. Why do people keep talking about PHP versions?

Because PHP is the language running much of the software on the server. WordPress, your theme, and your plugins all depend on it. An old PHP version can eventually become a security and compatibility problem, while a new one may expose old code that was never written to work with it.

15. Should I simply choose the newest PHP version available?

I wouldn't do that blindly. Newer supported releases are attractive for good reasons, but the site has to be compatible with them. On an established installation, I prefer to check the important plugins and theme first, make a backup, and then change the PHP version rather than flipping the switch and hoping for the best.

16. How much storage does a WordPress site really need?

Usually much less than the large numbers in a hosting advertisement make you think. The software itself isn't enormous. Images, videos, backups, old copies, plugin data, and downloadable files are what tend to eat the space over time. A site with lots of photographs can therefore use more storage than a much more sophisticated site that mostly contains text.

17. What is RAM used for?

RAM gives PHP and other server processes room to work. A simple site can get by with relatively little, while a busy site or one using demanding plugins may need considerably more. When memory becomes scarce, things can get unpleasant: pages may slow down, processes can fail, and you may start seeing errors that weren't there before.

18. What does CPU usage tell me?

It gives you an idea of how much processing work the site is asking the server to do. A request isn't necessarily “one unit” of work; a single page can trigger PHP, several database queries, plugin functions, scheduled tasks, and other operations. On shared hosting, unusually high CPU use can also mean that the account is getting close to the provider's resource limits.

19. What's an inode limit?

It is basically a limit on the number of files and directories in your account. People often watch their disk space and never think about file count. That can be a mistake because some caches, backup systems, and plugins create huge numbers of little files without using a particularly large amount of storage.

20. Does it matter whether the server uses Apache or Nginx?

It can matter to the person running the server, but it is not something a beginner needs to lose sleep over. Both can run WordPress very well. The more important question is whether the provider has configured its environment properly and whether the service gives the site the resources it needs.

21. Why does everyone talk about “server resources”?

Because the server has finite resources, even when a plan sounds unlimited. CPU time, memory, disk I/O, database connections, and other limits still exist somewhere. When a site starts pushing against those limits, you may notice slow responses, failed jobs, or warning messages in the hosting control panel.

22. Does unlimited storage mean I can store anything I like?

No. “Unlimited” almost always comes with a fair-use policy or other restrictions. A normal website with sensible files may never notice those limits, but using a web account as a giant file-storage service is a different matter. Read the terms rather than assuming that unlimited means literally unlimited in every circumstance.

23. Does the physical location of the server matter?

Yes, but it isn't the only thing that matters. If most of your visitors are in one part of the world, having the server reasonably close can help with network distance. A badly configured server can still be slow when it is next door, though, while a well-optimized site can perform surprisingly well from farther away.

Back to FAQ menu

3. Installing it and getting online

24. What's the easiest way to install WordPress?

For most beginners, the easiest route is the installer supplied by the hosting company. You select the domain, provide the administrator details, and let the system create the files and database. There is nothing wrong with a manual installation, but there is little benefit in making the first setup harder than it needs to be.

25. What does a manual installation involve?

You upload the WordPress files, create a database and database user, give WordPress the connection details, and then complete the installation through your browser. Once you understand what each step is doing, it makes sense rather than feeling mysterious. The first time is the awkward one.

26. Where do the WordPress files live?

They sit in a directory on the server, usually the directory that the domain is configured to serve as its public web root. A hosting account can have several domains, subdomains, or test installations, so the folder structure can become more complicated than it looks at first glance.

27. What's the database connection information?

WordPress needs the database name, database username, password, and server address so it can store and retrieve information. Those details are normally kept in wp-config.php. When a site suddenly says it cannot connect to the database, those settings are one of the first things worth checking.

28. What's wp-config.php?

It is one of the key configuration files in the installation. Besides the database settings, it can contain security keys and various optional settings that control how WordPress behaves. Most of the time you can leave it alone, which is exactly what I recommend if you don't have a reason to change it.

29. Can I install it in a subdirectory?

Yes. You might deliberately want a site to live in something like example.com/blog rather than directly at example.com. Whether that is a good idea depends on the structure of the project, and moving an existing installation between a directory and the root later needs to be handled carefully because URLs and configuration are involved.

30. What if I want a second site?

You have several options. You can install another independent WordPress site on the same hosting account, use a subdomain, use another domain, or choose WordPress Multisite when a network structure genuinely makes sense. Separate installations are often easier to manage when the sites have little to do with one another.

31. Can I build the site before pointing the domain at it?

Often you can, using a temporary address or a staging environment supplied by the provider. That can be handy because you can get the installation ready before changing public DNS. Just remember that temporary addresses can introduce complications with URLs, so I prefer using the actual domain or a proper staging setup when the provider supports it.

32. What is a hosting control panel?

It is the provider's management area for your account. Depending on the company, it may let you create databases, manage files, choose PHP versions, set up email accounts, inspect resource usage, create backups, and do other server-related jobs without using a command line.

33. Do I need FTP?

You can run a site without ever touching an FTP program, but having secure file access is extremely useful. When the dashboard stops working because of a bad plugin or theme, direct access to the files can be the quickest way back in. I prefer SFTP when it is available.

34. What is SFTP?

It is a secure method for transferring files between your computer and the server. It is particularly useful for moving an installation, replacing files, taking a close look at the directory structure, or recovering from a problem that prevents you from using the dashboard normally.

35. Is SSH necessary?

Not at all. SSH is mainly useful when you are comfortable working with commands or need advanced access. It becomes especially handy for things such as WP-CLI, log inspection, bulk file operations, and more complicated maintenance, but a normal site can run perfectly well without it.

Back to FAQ menu

4. Themes, plugins, and customization

36. What is the theme responsible for?

The theme controls the presentation of the site and provides templates for displaying your content. That includes things like page layouts, headers, footers, archives, typography, navigation, and other visual details. Some themes also pack in lots of extra functionality, which is convenient until you decide to change the theme and discover that half the site depended on it.

37. And what exactly is a plugin?

A plugin adds functionality to WordPress. It can create a store, a form, a search tool, custom fields, an SEO system, a backup system, a security layer, or something much smaller. I tend to think of plugins as little software applications living inside the site, because that is essentially what they are.

38. How many plugins is too many?

There isn't a magic number. Ten well-written plugins can be perfectly fine, while one badly behaved plugin can make a site miserable. I pay much more attention to what the plugins are doing than to the number shown on the Plugins screen.

39. Why can a plugin slow the site down?

It depends on what the plugin does and when it does it. Some run code on every page request, some make lots of database queries, some contact outside services, and some create background tasks. A plugin that looks tiny from the dashboard can still be doing quite a lot of work behind the scenes.

40. Can plugins interfere with one another?

Yes. Two plugins may change the same part of WordPress in different ways, load competing versions of a library, or expect different behavior from the same theme or server environment. Sometimes the conflict is obvious; other times you get something strange like one button no longer working and have no idea why.

41. Is it safe to download a plugin from a random website?

I wouldn't. Plugins have enormous access to a site, so installing unknown software is not a harmless experiment. Stick to reputable sources and be especially suspicious of “free premium plugins” that have been modified or stripped of licensing restrictions. A bargain plugin can turn into a very expensive security problem.

42. What does “nulled plugin” mean?

It usually means a paid plugin has been modified so it can be used without the normal license. Besides the obvious legal and support issues, you have no reliable way of knowing what else has been changed. Some of the worst website compromises I've seen discussed in the WordPress world have involved exactly this kind of software.

43. What's a child theme?

It is a way of making theme customizations without directly changing the parent theme. Your custom files and changes live separately, so an update to the parent theme is less likely to wipe them out. You don't need a child theme for every little visual adjustment, but it is extremely useful when you need deeper changes.

44. Why shouldn't I edit the parent theme directly?

Because the next theme update may replace the file you changed. That can leave you wondering where your carefully written code went. There are safer ways to customize a site, depending on the job, including a child theme or a small custom plugin.

45. Should functionality belong in the theme?

I prefer essential functionality to stay independent of the design where practical. A theme is something you may eventually replace, while things such as custom content types, important redirects, or site-specific functionality often need to survive a redesign. Keeping those two jobs separate can save a lot of trouble later.

46. Can I disable a plugin without deleting it?

Yes. Deactivating it stops its normal WordPress functions while leaving its files on the server. That is useful when you are troubleshooting because you can turn something off temporarily and see whether the problem disappears before deciding whether to remove it permanently.

47. Should unused plugins be deleted?

Usually, yes. Leaving a plugin deactivated for years serves little purpose unless you genuinely need it as part of a particular setup. Removing software you no longer use reduces clutter and avoids having forgotten, outdated code sitting on the server.

48. What about unused themes?

I normally keep the active theme and one sensible default WordPress theme available as a fallback, then remove the rest unless there is a reason to keep them. A spare default theme can be surprisingly helpful when diagnosing a theme problem.

49. Why do people say not to install a plugin for everything?

Because each plugin adds another piece of software that needs to cooperate with everything else. Sometimes a small piece of custom code is cleaner than installing a large plugin just to solve one tiny problem. The goal isn't to have the fewest plugins possible; it is to have a site where every installed component has a good reason for being there.

50. Can I customize WordPress without knowing PHP?

For many things, yes. Modern themes and plugins can take you a long way without code, and simple CSS or HTML changes are often enough for small adjustments. PHP becomes useful when you want to change how the software behaves rather than simply how it looks.

Back to FAQ menu

5. PHP, databases, and the less visible stuff

51. Why would WordPress suddenly complain about memory?

Usually because the PHP process has reached its allowed memory limit while trying to do some job. A complicated plugin, a large import, a heavy page, or a badly behaved piece of code can use more memory than the current limit permits. Increasing the limit can help, but first I want to know why the site is using so much.

52. What is the PHP memory limit?

It is the amount of memory PHP is allowed to use for a request. Think of it as a ceiling rather than a tank that is permanently filled. Raise it too little and some tasks fail; raise it excessively and you can simply allow a bad process to consume more server resources than it should.

53. What's max execution time?

It is the maximum time PHP is allowed to spend on certain operations before the server stops the process. Most pages finish well within that period, but large imports, backups, image processing, and some updates can take longer. That is when the setting becomes noticeable.

54. What is upload_max_filesize?

It limits the size of certain files PHP will accept during an upload. If the media library or an installer tells you a file is too large even though your hosting account has plenty of storage left, this setting may be the culprit.

55. Why can the hosting company change PHP settings for me?

Many shared and managed accounts expose selected PHP settings through the control panel. It gives you a little flexibility without giving you control over the entire server. Which settings you can change varies from one provider to another.

56. What happens if the database goes down?

The site can no longer retrieve the information it needs, so the public pages and dashboard may stop working properly. You can see messages about establishing a database connection or similar errors. The database server itself might be down, or there could be a configuration, credentials, connection-limit, or server resource problem.

57. Why is the database so important?

Because a huge amount of the site's information lives there. Your pages and posts are not simply sitting in folders as individual documents. WordPress retrieves much of the content and configuration from the database, which is why a proper backup needs to include it.

58. Can the database become bloated?

It can. Revisions, temporary data, plugin information, logs, abandoned tables, and other material can accumulate over the years. That does not mean you should aggressively “clean” everything you can find. Database cleanup can be useful, but deleting something you don't understand is a good way to create a problem rather than solve one.

59. What is object caching?

It keeps frequently requested pieces of data available in a fast cache so WordPress doesn't have to retrieve or rebuild the same information repeatedly. On the right kind of site, that can reduce database work and improve responsiveness.

60. What is Redis?

Redis is one of the technologies that can provide persistent object caching. It stores data in memory so it can be retrieved very quickly. Not every site needs it, but it can be useful on busy or database-heavy installations.

61. What is WP-Cron?

It is WordPress's way of handling scheduled tasks. Publishing scheduled posts, checking updates, and running certain plugin tasks can all depend on it. The slightly odd part is that the default mechanism is triggered by site activity rather than functioning exactly like a traditional server cron job.

62. Why are scheduled posts sometimes late?

On a quiet site, there may not be a request at exactly the moment WordPress expects one, so the scheduled task can run later. That is one reason larger or more time-sensitive sites sometimes use a real server cron job instead.

63. What's .htaccess?

On Apache servers, .htaccess can contain instructions that affect how requests are handled. WordPress commonly uses it for rewrite rules, which help make clean URLs work. It is a small file with a lot of power, so I would back it up before changing it.

64. Why do file permissions matter?

They determine who can read, write, or execute files on the server. WordPress needs enough access to do its job, but giving everything the broadest possible permissions is not a sensible shortcut. Correct permissions help balance functionality and security.

65. What is WP-CLI?

WP-CLI lets you manage WordPress from a command line instead of the dashboard. It can be incredibly useful for experienced users because you can perform repetitive or large-scale tasks quickly. For beginners, I would treat it as a useful tool to learn gradually rather than copying commands from the internet without understanding what they will change.

Back to FAQ menu

6. Making the site fast

66. Why is my site slow when the server seems powerful enough?

Because server power isn't the whole story. Large images, inefficient plugins, too much JavaScript, database queries, external services, poor caching, and slow code can all hold a site back. I've seen modest sites become much faster simply by removing unnecessary work rather than buying a bigger server.

67. What does page caching actually do?

Without caching, WordPress may rebuild a page every time somebody requests it. A page cache can keep a ready-made version and serve that instead. For pages that don't change constantly, that can save the server a lot of work and make the site feel dramatically quicker.

68. Why shouldn't I just install every performance plugin I find?

Because performance plugins can interfere with one another just like any other software. One may cache a page, another may alter scripts, and a third may try to do its own version of both. I would rather have one well-understood performance setup than several plugins fighting over the same job.

69. What is browser caching?

It allows a visitor's browser to keep copies of things such as images, CSS, and JavaScript for a while. When the visitor comes back, the browser may not need to download everything again. That is particularly helpful for repeat visits.

70. What does a CDN add?

A CDN can serve cached copies of suitable files from locations distributed around the world. So instead of every visitor pulling every image or stylesheet directly from your main server, some of those files can come from a location closer to them.

71. Does every site need a CDN?

No. A small site with visitors concentrated near the server may get little benefit from one. A site with an international audience or a lot of static content has a stronger case. I would add a CDN because the site needs it, not because somebody told me every serious site must have one.

72. Why did changing the cache make my new design disappear?

Because you may still be looking at an older cached copy of the page or its supporting files. Caches can exist in several places, including the server, a CDN, and the browser. After a major change, you sometimes need to clear more than one layer before everybody sees the new version.

73. Are images really such a big deal?

Yes, especially photographs. A modern phone can produce a huge image that looks beautiful but is far larger than the web page needs. Resize images sensibly, compress them, and don't upload a five-megapixel original when a fraction of that size will look identical on the page.

74. What's lazy loading?

It means certain images or other resources are loaded when they are needed rather than all at once. If a page contains many pictures far below the fold, there is little reason to make the browser download all of them before the visitor can read the top of the page.

75. Can a faster hosting plan fix everything?

No. More resources can certainly help when the site is genuinely short of them, but extra CPU does not magically repair bloated images, inefficient code, or a badly configured cache. I like to identify the bottleneck first and spend money on that problem rather than simply buying a larger package.

76. Should I trust a single speed score?

No. Speed-testing tools are useful, but different tools measure different things and results can vary depending on the test location and conditions. I look at the actual page, the server behavior, and the detailed findings rather than treating one number as the health score of the entire site.

77. Why can the dashboard be slow when the public pages are fine?

The dashboard does different work. Plugins can perform database-heavy tasks there, scheduled jobs may run in the background, and some admin screens make external requests or load large amounts of information. A fast public site and a slow dashboard can therefore exist at the same time.

Back to FAQ menu

7. Security and backups

78. Doesn't the hosting company take care of security?

It takes care of some of it, not all of it. The provider can protect the server and infrastructure, but it can't decide which plugin you install or whether your administrator password is “password123.” There is a boundary between server security and website security, and you need to know where that boundary sits.

79. What's the most sensible first security step?

Protect the administrator accounts properly. Use strong unique passwords, enable two-factor authentication where practical, and don't give everyone administrator access just because it is convenient. A surprising number of security problems begin with an account that should have been better protected.

80. Do I need two-factor authentication?

For administrator accounts, I think it is one of the easiest security improvements you can make. Even if somebody manages to obtain the password, there is another barrier in the way. The slight inconvenience when logging in is a pretty good trade for that extra protection.

81. What is a security plugin actually doing?

Depending on the plugin, it may inspect login attempts, block suspicious requests, scan files, add firewall rules, enforce security settings, or help with monitoring. Different products do different things, so I wouldn't judge them by the word “security” on the plugin page alone.

82. Should I install several security plugins for extra protection?

Usually no. Security software often overlaps, and more does not automatically mean safer. I would rather use one sensible security setup and understand what it is doing than run several systems that all inspect the same traffic and occasionally get in each other's way.

83. What makes backups different from security?

A backup doesn't stop an attack, but it can save you after one. It also protects you from your own mistakes, failed updates, accidental deletion, and other disasters that have nothing to do with hackers. I consider backups the safety net underneath everything else.

84. What should a complete backup contain?

You normally need both the site's files and the database. Saving only the files is not enough because much of the site's content and configuration lives in the database. Depending on the setup, you may also need copies of other important configuration or service information to recreate everything cleanly.

85. Should the backup stay on the same server?

I would not rely on that as the only copy. If the server or account has a serious problem, you don't want the original site and every backup to disappear together. Keeping at least one independent copy somewhere else gives you much more useful protection.

86. How often should backups run?

It depends on how often the site changes and how much work you can afford to lose. A mostly static site may be perfectly comfortable with less frequent backups, while an active store or busy publication may need several restore points each day. The sensible question is not “What is the standard?” but “How much recent work can I afford to lose?”

87. Is one backup enough?

I wouldn't trust a single copy. You want some history because problems are not always discovered immediately. If the site was compromised three days ago and your only backup was made yesterday, restoring it may simply put the compromised state back online.

88. Why should I test the backup?

Because seeing a file named backup.zip does not prove that the site can actually be restored from it. Files can be incomplete, databases can be missing, credentials can be wrong, or the backup process can fail without anybody noticing. A test restore is the closest thing you have to proof.

89. What happens if I accidentally delete something important?

This is where a good backup system earns its keep. Depending on the system, you may be able to restore a particular file, a plugin, the database, or the whole site. The better the backup history, the more precisely you can recover without throwing away newer work.

90. What if the site is hacked?

Don't assume that changing the homepage back is enough. You need to work out how the attacker got in, remove the unwanted code, change affected credentials, update vulnerable software, and make sure you are not restoring the same problem from an old backup. For a serious compromise, getting professional help can be a very sensible decision.

Back to FAQ menu

8. Domains, DNS, HTTPS, and email

91. Does my domain have to be registered with the hosting company?

No. The domain registrar and the company hosting the website can be two completely different businesses. Some people prefer keeping them together because it is simpler, while others deliberately separate them so that the domain remains independent of the hosting account.

92. Why do I need DNS?

DNS is what tells the internet where your domain's services are located. Your website, email, verification services, and other systems can all use DNS records for different purposes. Once you understand that DNS is basically the directory that points things in the right direction, a lot of hosting terminology becomes easier.

93. What's an A record?

An A record normally points a hostname to an IPv4 address. In a straightforward website setup, it is one of the records telling the browser which server should receive the request for the domain.

94. What's a CNAME?

A CNAME creates an alias from one hostname to another hostname. It is commonly used for subdomains and for services that provide a hostname rather than a fixed IP address. Which record you need depends on the service you are connecting.

95. Why doesn't a DNS change happen instantly?

Because DNS information is cached. Different networks and DNS resolvers may continue using the previous information until their cached copy expires. That is why a freshly changed domain can appear to work from one connection while still showing the old site somewhere else.

96. Is DNS propagation a problem with the hosting company?

Not necessarily. People often blame the new server because they can see different results from different places, but that is often simply DNS caching doing its job. Of course, a DNS record can also be configured incorrectly, so you still need to check the actual records rather than blaming propagation for everything.

97. Why should the site use HTTPS?

HTTPS encrypts the connection between the visitor and the site and is now the normal way websites are expected to operate. It also avoids the browser warnings that can appear when a site relies on insecure connections. For an ordinary public site, I see little reason to leave HTTPS turned off.

98. Do I need to buy an SSL certificate?

Often you don't. Many providers offer free certificates through services such as Let's Encrypt. Paying for a certificate is not automatically buying better security; what matters is how it is issued, installed, maintained, and renewed.

99. What happens if the certificate expires?

The browser can warn visitors that the connection is not secure, and access may become difficult or blocked. Many certificates renew automatically, but automatic renewal can fail because of DNS problems, configuration changes, or other issues. It is worth knowing who is responsible for the renewal process on your account.

100. Can the website and email use different companies?

Absolutely. Your web server can be in one place and your email somewhere else. DNS tells mail servers where to deliver messages, so changing your email service does not require moving the website.

101. Why did my email stop working when I changed the website DNS?

Most likely because more than one DNS record was involved and something important was removed or replaced. The website can keep working perfectly while email fails because mail uses its own records. This is one of the reasons I never copy a new DNS zone wholesale without first checking what services are already using the domain.

102. Should DNS stay with my hosting company?

That's a preference rather than a rule. Keeping it there can make the setup straightforward. Using a separate DNS provider can give you more control and means the DNS service isn't tied to a particular hosting account. Either approach is perfectly workable when it is properly configured.

Back to FAQ menu

9. Updates, maintenance, and fixing things

103. Who updates WordPress?

That depends on the service you bought. With ordinary self-managed hosting, you are generally responsible for the software running inside your account. A managed service may take care of some or much of this for you, but you should never assume that “managed” means every possible update is being handled.

104. Should I update everything immediately?

Security fixes deserve prompt attention, but larger updates deserve a little thought. On an important site, I like to have a current backup and check compatibility before installing major changes. There is nothing brave about updating a production site five minutes before an important deadline.

105. Why did an update break my site?

Usually because one piece of software stopped agreeing with another. The new plugin may conflict with the theme, the new WordPress version may expose old code, or the server's PHP version may have changed. The update itself isn't necessarily defective; it may simply have revealed an incompatibility that was already waiting underneath.

106. What if a plugin update causes a fatal error?

Don't panic. If you can identify the plugin that was updated immediately before the crash, disabling it can often bring the site back. Depending on your setup, that can be done from the dashboard, through the hosting file manager, or using SFTP if the dashboard is unavailable.

107. Can I disable a plugin when I can't log in?

Yes. One common method is to rename its directory so WordPress no longer recognizes it as an active plugin. That sounds crude, but it can be an extremely useful emergency trick when a plugin has taken the dashboard down with it.

108. What's a critical error?

It normally means some PHP code failed badly enough that WordPress could not complete the request. The message itself doesn't necessarily tell you the real cause. The useful information is often in the associated error details or logs, where you can see which file or function failed.

109. What are PHP error logs?

They record problems generated by PHP. When a site suddenly starts misbehaving, an error log can turn “something is broken” into “this plugin called this function and failed here.” That makes troubleshooting much less like guesswork.

110. Should debugging be turned on permanently?

Not usually on a live public site. Debugging can reveal useful details, but showing those details to visitors can expose technical information that should remain private. It is a tool for finding problems, not something I would leave displaying errors publicly for months.

111. Why can the site break after changing PHP?

Because PHP is the environment in which the plugins, theme, and WordPress code run. Old code can rely on behavior that has changed or disappeared in a newer PHP release. A backup and a test environment make this sort of change much less stressful.

112. What should I do before changing PHP?

Make a fresh backup, check the important plugins and theme, and use a staging copy when the site matters enough to justify one. Then change PHP and test the site rather than assuming everything is fine because the homepage still loads.

113. Why should I keep a staging site?

Because it gives you somewhere to make mistakes safely. You can test a new plugin, update a theme, change PHP, adjust code, or try a caching setting without immediately putting the experiment in front of your visitors. Once you've broken a live site at an inconvenient time, staging suddenly seems like a very cheap luxury.

114. Why can a site become slower after years of use?

Sites accumulate baggage. The database gets larger, the media library grows, plugins leave data behind, caches become more complicated, traffic increases, and the site's original design decisions may no longer make sense. Nothing has to be catastrophically wrong for an old installation to benefit from a little housekeeping.

115. What should I check during a routine maintenance session?

I would look at updates, backups, site availability, important forms, storage and resource usage, the HTTPS certificate, and anything that matters specifically to the site. You don't need to turn maintenance into a weekly engineering project. A short, regular check is usually more useful than a massive cleanup every two years.

Back to FAQ menu

10. Moving the site and dealing with growth

116. How do I move a WordPress site to another host?

At the most basic level, you move the files and database, recreate the necessary settings on the new server, test the installation, and then point the domain to the new location. Migration plugins can automate much of that work, but complicated sites sometimes benefit from a more controlled manual migration.

117. Is migrating a site difficult?

A simple site is often surprisingly easy to move. The complications tend to appear with large databases, unusual server configurations, ecommerce sites, external integrations, custom cron jobs, separate email systems, or a site that has been heavily customized over the years. The software isn't necessarily the difficult part; the history of the individual site is.

118. Should I leave the old hosting account running during the move?

Yes. I would keep it until the new installation has been thoroughly tested. Check the front end, dashboard, forms, media, downloads, scheduled tasks, and anything else important to the site. Cancelling the old account too early turns a small migration problem into a much bigger one.

119. Will visitors notice when the site moves?

Ideally, no. If the new server is prepared first and DNS is changed carefully, the site can move with little visible interruption. There can be a period when some people still reach the old server because of DNS caching, so it is wise to keep both environments ready during the transition.

120. What does a staging copy have to do with migration?

Quite a lot, actually. A staging copy gives you a safe place to test the new environment before the move becomes public. You can check PHP, plugins, themes, URLs, database connections, and other details before visitors are sent there.

121. When have I outgrown shared hosting?

Look at what the site is telling you. Repeated CPU or memory warnings, persistent slowness under normal traffic, database bottlenecks, or a genuine need for more control are good reasons to consider an upgrade. “I have a bigger website now” is less useful than actual evidence from the server.

122. Does that mean I should move straight to a VPS?

No. A VPS is more powerful and flexible, but it can also require more technical involvement. If the site is working comfortably on a good shared service, moving to a VPS may simply give you another set of things to administer without improving the visitor's experience very much.

123. What is managed hosting really buying me?

Mostly convenience and someone else's expertise. Depending on the provider, managed service can include things like updates, backups, caching, security measures, monitoring, and technical support. The important thing is to look at the actual list of services rather than assuming every company uses “managed” to mean the same thing.

124. Can an ordinary setup handle an online store?

A small WooCommerce store can often start on shared hosting, provided the package is sensible and the server is well configured. Stores are more demanding than simple informational sites because carts, checkouts, customer accounts, orders, payment systems, and database activity create work that a plain brochure site doesn't have.

125. When does a CDN become more useful as the site grows?

Usually when the audience becomes more geographically spread out or the amount of static content grows. A CDN can also help take some pressure off the origin server. It is not a replacement for good hosting, though; it mainly changes where certain resources are delivered from.

126. Should I use WordPress Multisite?

Only when you actually want a network of related sites managed from one installation. Multisite is useful in the right situation, but it also changes how plugins, themes, users, and databases work. For two unrelated websites, separate installations are often simpler.

127. What is the biggest mistake beginners make with hosting?

They often buy far more than they need while paying too little attention to what is actually included. Then, when something goes wrong, they discover that backups are limited, support is poor, or a supposedly unlimited package has important restrictions. A sensible package from a provider you can actually work with is worth more than an impressive specification sheet.

128. What's the mistake experienced users see over and over?

Adding complexity without a reason. A person installs five optimization plugins, three security plugins, several overlapping backup tools, a collection of abandoned themes, and a dozen plugins they used once and forgot about. After a while nobody knows which part is doing what. A simpler site is not automatically a better site, but a site you understand is usually much easier to keep healthy.

129. What would you set up first on a brand-new installation?

I would get the domain and DNS under control, make sure HTTPS works, confirm the PHP version is sensible, set up reliable backups, protect the administrator accounts, and then build the site. Design comes after those basics for me. A beautiful site that can't be restored after a bad update isn't much of a victory.

130. What is the one piece of advice you would give a beginner?

Learn what each part of your setup is actually responsible for. Know which company controls the domain, where the website lives, where the email is handled, where the backups are stored, which PHP version is running, and how to get into the files if the dashboard stops working. Once you understand those few things, the whole subject becomes much less intimidating, and when something does go wrong, you have a reasonable idea where to start looking.

Back to FAQ menu