The Basics of Shared Hosting Configurations
SEO guide explaining the basics of shared hosting configurations. Learn the best practices, setups, and automation tricks.
What shared hosting actually gives you
Shared hosting places many customer accounts on one physical or virtual server. Each account gets its own home directory, databases, email boxes and a slice of the server’s CPU, memory and disk input/output. The hosting company manages the operating system, the web server software, security patches and hardware. You manage everything inside your account.
That division of responsibility is the most important thing to understand before you start configuring. You usually cannot install system packages, change kernel settings or edit the main web server configuration. You can, however, change a surprising amount: the PHP version, PHP limits, URL rewriting, redirects, caching headers, scheduled tasks, DNS records (if the host also serves your DNS), mailboxes and SSL certificates.
Inspect Any Domain and Web Hosting Instantly
Inspect the infrastructure of any domain or website in seconds using TLDix WHOIS Domain, Hosting Lookup and Domain Oracle (AI).
Most shared hosts expose these controls through a panel such as cPanel, Plesk, DirectAdmin or a custom dashboard. The names differ, but the underlying settings are the same, and this guide focuses on those settings rather than on any single panel.
The core components of a shared hosting account
Before changing anything, take an inventory of what your account contains. A typical plan includes the following building blocks:
- Document root. The folder your primary domain serves files from, often
public_htmlorhttpdocs. Addon domains and subdomains get their own folders. - Web server. Usually Apache, LiteSpeed or Nginx in front of Apache. Apache and LiteSpeed read
.htaccessfiles; pure Nginx setups do not. - PHP handler. The runtime that executes PHP code, typically PHP-FPM or LiteSpeed’s LSAPI, with several versions selectable per account or per folder.
- Databases. MySQL or MariaDB, managed through phpMyAdmin or a database wizard.
- Email. Mailboxes, forwarders, autoresponders and spam filtering on the same server.
- DNS. A zone editor if your domain uses the host’s name servers.
- SSL. Often a free automated certificate, with an option to upload a commercial one.
- Cron and file manager. Scheduled tasks and browser-based file access, plus SFTP or FTP credentials.
If you are still choosing a provider, our guide on choosing the best web hosting explains which of these features matter for different kinds of sites.
Understanding resource limits
Marketing pages emphasise disk space and “unmetered” bandwidth, but the limits that actually slow or suspend shared accounts are usually less visible. Many hosts use account isolation technologies (CloudLinux LVE is a common example) that cap what each account can consume. Look for these values in your panel or ask support:
| Limit | What it controls | Symptom when you hit it |
|---|---|---|
| CPU | Share of processor time for your account | Slow pages under load, throttling |
| Physical memory | RAM available to your processes | 500 errors, PHP processes killed |
| Entry processes | Concurrent connections to dynamic scripts | 508 “Resource Limit Reached” errors |
| Number of processes | Total processes, including cron and SSH | Failed cron jobs, timeouts |
| I/O and IOPS | Disk read and write throughput | Slow backups and database queries |
| Inodes | Total number of files and folders | Uploads or emails fail despite free space |
Exact numbers vary widely between providers and plans, so compare them directly rather than relying on plan names. A site with heavy caching and few plugins can run comfortably on modest limits, while an unoptimised store may hit entry process caps with relatively little traffic.
How to stay within limits
- Enable page caching so most visits are served without running PHP.
- Delete old backups, cache folders and unused installations that eat inodes.
- Move heavy scheduled work to quiet hours.
- Block abusive bots and aggressive crawlers that inflate process counts.
Configuring PHP correctly
PHP settings are the configuration area you will touch most often. Start with the version: run a currently supported PHP release that your application officially supports. Old versions stop receiving security fixes, and newer ones are generally faster. Change versions on a staging copy first if you can, because older plugins or themes may break.
Depending on the host, PHP limits are set through a “PHP options” screen, a .user.ini file in your document root, or php_value lines in .htaccess (on Apache with mod_php or compatible handlers). A typical .user.ini looks like this:
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
display_errors = Off
log_errors = On
Keep display_errors off on live sites, since error messages can reveal file paths and other details. Log errors instead and review the log after updates. Do not set limits higher than your plan’s memory allowance; the panel value will not override the account cap.
Using .htaccess for redirects and security
On Apache and LiteSpeed servers, .htaccess files let you change behaviour per folder without touching the main server configuration. The most common uses are forcing HTTPS, choosing between www and non-www, and protecting sensitive files.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
<Files "wp-config.php">
Require all denied
</Files>
Options -Indexes
This example redirects all HTTP traffic to HTTPS with a permanent redirect, blocks direct access to a configuration file and disables directory listings. Some hosts behind a proxy need a different HTTPS condition, such as checking the X-Forwarded-Proto header, so test after every change. A single typo in .htaccess can return a 500 error for the entire site, so keep a copy of the working version before editing.
Caching and compression headers
You can also set browser caching and compression through .htaccess using mod_expires and mod_deflate, if the host enables them. Many caching plugins write these rules automatically. Check with your host before adding duplicate rules, as LiteSpeed servers often have their own cache module.
Domains, DNS and email setup
Connecting a domain to shared hosting means either pointing the domain’s name servers to the host or keeping DNS elsewhere and creating A (and possibly AAAA) records that point to the server’s IP address. Pointing name servers is simpler; keeping external DNS gives you more control and makes it easier to move hosts later. Our guide to DNS records basics covers the record types involved.
Email on shared hosting needs a little extra care, because deliverability depends on DNS:
- MX records must point to the server that receives your mail.
- SPF (a TXT record) lists which servers may send mail for your domain.
- DKIM signs outgoing messages; most panels can generate the key and record.
- DMARC tells receivers what to do with mail that fails SPF and DKIM checks.
If you use an external email provider instead, make sure the hosting server is not still configured to accept mail locally for your domain, or messages sent from your website may never leave the server.
SSL, cron jobs and backups
Most shared hosts now issue free domain-validated certificates automatically, often through Let’s Encrypt or a similar certificate authority. Confirm that every hostname you use, including www and any subdomains, is covered and that automatic renewal succeeds. Renewal can fail silently if DNS points elsewhere or if a redirect blocks the validation path.
Cron jobs run scripts on a schedule. Many content management systems rely on them for scheduled posts, emails and cleanup. Instead of letting visitors trigger these tasks, set a real cron job in the panel:
*/15 * * * * /usr/local/bin/php /home/username/public_html/cron.php >/dev/null 2>&1
The PHP binary path differs between hosts, so check your panel’s documentation. Avoid running heavy jobs every minute, which can push you into process limits.
For backups, do not rely only on the host’s copies. Host backups are a useful safety net, but retention periods and restore options vary, and they are typically stored with the same provider. Download periodic full backups or send them to separate storage, and test a restore at least occasionally.
A practical configuration checklist
Use this checklist when setting up a new account or reviewing an existing one:
- Select a supported PHP version and set sensible memory and upload limits.
- Force HTTPS and choose one canonical hostname with a 301 redirect.
- Disable directory listings and protect configuration files.
- Remove unused applications, themes, plugins and old staging copies.
- Enable caching and confirm you stay within CPU and entry process limits.
- Configure MX, SPF, DKIM and DMARC records for your domain.
- Replace visitor-triggered cron with a real scheduled task.
- Set up off-site backups and test a restore.
- Record domain, SSL and hosting renewal dates in one place.
That last step is easy to forget. A perfectly tuned account still goes offline if the hosting plan or the domain expires. You can check which provider hosts a site with the TLDix hosting lookup, and keep domains and hosting plans in your TLDix hosting panel to get reminders before renewal dates arrive.
When to move beyond shared hosting
Shared hosting is a good fit for brochure sites, blogs, small stores and many small business applications. It stops being a good fit when you repeatedly hit resource limits after optimising, when you need software the host will not install, or when you need guaranteed isolation for compliance reasons. At that point a VPS, managed cloud hosting or a platform-specific managed service may be worth the higher cost and responsibility. Moving is much easier if you already keep clean backups, use external DNS or documented records, and know exactly which settings you changed along the way.