Web hosting: tutorials & guidesAll tutorials around web hosting with Plesk

Web hosting is rented storage space on a server that is already fully set up: web server, PHP, database and mail server are running, and everything is managed via the graphical interface of Plesk Obsidian. You do not need a command line for this - and that is exactly how web hosting differs from a VPS, where you build this layer yourself and maintain it permanently.

You should know two things before you get started. First, web hosting always goes together with a domain: the storage space alone cannot be reached under any name. The domain can be registered with us or connected from another provider. Second, backups are self-service - the Plesk Backup Manager creates them at the push of a button, but nobody does it for you. Make a backup before every major update and keep a copy outside the web hosting, for example locally on your computer.

The typical order for new web hosting: connect the domain, set up the certificate, install the application. After that, mail accounts, databases and cron jobs become relevant. That is exactly how the guides below are grouped - migration and buying advice sit alongside as separate blocks. If you do not have web hosting yet, it makes sense to read from the bottom up.

Setting up

The first steps after ordering - and the order here is not a matter of taste but a technical necessity. A Let's Encrypt certificate can only be issued once the domain already points to the web hosting: that is exactly what the certificate authority checks. And every installation created before the certificate ends up with the wrong addresses in its database.

Expect some waiting time with the first step. DNS changes do not take effect immediately, but only once the old answer has dropped out of the resolvers' caches - the record's TTL determines how long that takes. Lowering the TTL one or two days before the switch noticeably shortens this window. Background in DNS records explained.

Subdomains follow the same logic as the main domain: their own directory, their own DNS record, their own certificate. The main domain's certificate explicitly does not cover them - a point that is regularly overlooked and leads to security warnings in the browser.

Building the site

For the site itself, there are two routes, and both are included in every package at no extra cost: the website builder as a graphical construction kit or WordPress as a full content management system. The decision between them depends less on the range of functions - both can do more than most projects need - than on a simple question: who will look after this site in two years, and how often?

WordPress is software that runs on your web hosting and needs regular updates: core, theme and every plugin. If they are skipped for months, the site becomes a security risk. The builder does not have this problem, because no software is operated by you there - in return, you are tied to its range of functions and cannot add a plugin.

One point affects both: when publishing, the builder writes to the domain's document root and replaces whatever is there. On a domain that already runs a site, a backup therefore has to come first. You can still run both in parallel - just per domain or subdomain, not in the same directory.

Management

What is regularly needed in day-to-day operation. You create mail accounts and databases directly in Plesk; mail storage is counted separately from web storage, so large mailboxes do not come at the expense of your website. MariaDB is used as the database system, managed via phpMyAdmin - every CMS installation takes up exactly one database.

The PHP version can be switched per domain. That is practical if an older project and a current CMS sit on the same package. Before a version jump, however, make a backup: plugins that use a removed function will otherwise fail without warning. You set up cron jobs via the task scheduler; with WordPress, it is worth switching off the internal WP-Cron and running a real cron job instead - it then runs on schedule rather than only when visitors arrive.

There are two routes for direct access to the files: the file manager in Plesk for quick work in the browser and an FTP program for anything bigger. The connection is encrypted via FTPS. Additional accounts with their own home directory are the clean route if a service provider is to work on a single project only and must not see the package's other domains.

Optimizing & troubleshooting

Once the site is up, the work shifts: instead of setting up, it is about keeping it fast and finding the cause when something goes wrong. For speed, it pays to follow the order of impact - and that is clear. Images make up 60 to 80 percent of the transferred data on a typical site. Uploading them in the size in which they are actually displayed gains more than any other single measure.

With faults, a different rule applies: back up first, then search. A backup of the broken state sounds absurd, but it is the lifeline in case a repair attempt makes things worse. After that, the shortest route is the question of what was changed last - an update, a new plugin, a version change. That is where the cause lies in the vast majority of cases, and the debug log makes it visible.

The .htaccess file plays a role in both areas: it controls redirects and the browser cache, and at the same time it is the most common cause of a 500 Internal Server Error. A typo in it takes the site down immediately and completely - which is why a copy of the file belongs before every change.

Migration

Switching providers is uncritical as long as the order is right. The mistake that makes a migration expensive is always the same: switching the domain first and then copying the files. In between lies the time in which visitors land on an empty directory and mail goes nowhere.

The right order is: transfer the content, test the site via a preview address, and only then switch the DNS records. That way, the old site remains reachable until the switch. For the first step, Plesk includes a website import and an email import that take over files, databases and mailboxes from the previous provider.

Before ordering

Buying advice before you commit to a package. Storage requirements are almost always overestimated: a typical club or company site stays well below what even the smallest package offers. Only media libraries, shops with many product images and mailboxes that have not deleted anything for years get big. So check the number of databases and mail accounts rather than the pure gigabytes - it is the databases that run short first with several projects.

The second question is whether it should be web hosting at all. As soon as your own server services, a Docker stack or freely selectable software come into play, the range of functions of a shared environment ends - then the route leads to a VPS. And when comparing providers, it pays to look at the price after the first year: promotional prices for new customers say little about the running costs.

Frequently asked questions