| After buying hosting, complete twelve tasks in your first week: point DNS, issue SSL, force HTTPS, create email accounts, add SPF and DKIM records, confirm backups, set PHP version, enable caching, harden logins, set up monitoring, verify Search Console, and record your recovery details. |
A new hosting account arrives with almost everything switched off. The server works, but the settings that keep a site secure, delivered and recoverable are yours to configure. Skip them and nothing breaks immediately, which is exactly why they get skipped. The consequences arrive months later as spam foldered email, a failed restore, or a login page being brute forced by a botnet.
This checklist puts the twelve tasks in dependency order, so each step works when you reach it. It assumes a cPanel account on shared hosting. If you have not chosen a plan yet, start with how to choose a hosting plan without overpaying instead, then come back here.
Days one and two: get the domain resolving securely
1. Point your DNS and lower the TTL first
Update the nameservers at your registrar to the ones in your hosting welcome email, or create A records pointing to the account IP address. Before you make the change, lower the TTL on the existing records to 300 seconds. Propagation then completes in minutes rather than the full 24 to 48 hours people expect, because resolvers stop holding the old answer. Raise the TTL back to 3600 or higher once the site is stable.
2. Issue SSL and confirm it covers every hostname
Most cPanel hosts issue certificates automatically through AutoSSL, using Let’s Encrypt or a comparable authority. Check that the certificate covers both the bare domain and the www version, and any subdomain you use such as blog or shop. Certificates from Let’s Encrypt last 90 days and renew automatically, so a renewal failure is silent until the browser warning appears. Our guide to why every website needs SSL explains what the certificate does and does not protect.
3. Force HTTPS and pick one canonical hostname
An issued certificate does not redirect anything by itself. Add rules that send HTTP to HTTPS and choose either www or non-www as the single canonical version. Serving both creates duplicate URLs for every page on the site, which splits signals in search and confuses analytics. Set it once, in .htaccess or the panel, and never revisit it.
| RewriteEngine On RewriteCond %{HTTPS} off [OR] RewriteCond %{HTTP_HOST} ^www\. [NC] RewriteRule ^(.*)$ https://example.com/$1 [R=301,L] |
Days two and three: make email work and stay out of spam
4. Create real mailboxes, not just forwarders
Create the addresses the business will actually use, then set quotas so one mailbox cannot fill the account. A professional email address on your own domain also signals legitimacy to customers in a way a free mailbox does not, which matters more in B2B enquiries than most owners expect.
5. Add SPF, DKIM and DMARC records
These three DNS records decide whether your mail reaches the inbox. SPF lists the servers allowed to send for your domain. DKIM signs each message cryptographically. DMARC tells receiving servers what to do when a message fails the first two. Major mailbox providers now expect authentication on bulk senders, and unauthenticated mail is routinely rejected outright rather than foldered. Combine them with the sending reputation factors in our guide to IP reputation and email deliverability.
Start DMARC at p=none while you read the reports, then move to quarantine and finally reject once legitimate senders all pass.
6. Send a test message to an external provider
Send from your new mailbox to a Gmail or Outlook address, then open the message headers and confirm that SPF, DKIM and DMARC all report a pass. Testing internally proves nothing, because messages inside the same server never leave it. This one test catches most misconfigured records before customers ever see them.
Days three and four: performance and stack settings
7. Set the correct PHP version
New accounts often default to an older PHP branch for compatibility. Each supported branch receives active support for roughly two years and security fixes for a third year, after which it stops receiving patches entirely. Select a currently supported version in the panel, then load the site and check the error log before you assume it worked.
8. Enable caching and compression
Switch on the server cache your host provides, then add expiry headers for static assets and enable Brotli or gzip compression. Compression alone typically reduces HTML, CSS and JavaScript transfer by a large margin, which improves both load time and your monthly bandwidth usage. If pages still feel slow afterwards, work through the reasons a website is slow rather than adding more plugins.
9. Confirm the backup actually restores
Automated backups are standard, and untested backups are worthless. Find out the retention window, the frequency and whether the databases are included. Then restore one file to prove the process works while nothing is on fire. Our post on why backup is necessary covers the failure patterns, but the short version is simple: keep one copy off the server, under your own control.
Days five to seven: lock it down and instrument it
10. Harden logins and remove default accounts
Delete any default admin username, enforce long unique passwords, and enable two factor authentication on the hosting panel and the site dashboard. Restrict access to administrative paths by IP where the team allows it. Credential attacks are automated and constant, so they find a new site within days of it appearing in certificate transparency logs. The rest of the pattern is covered in common website security mistakes.
11. Set up uptime and expiry monitoring
Add external uptime monitoring that checks the site every few minutes from outside your own network. Set calendar reminders for domain expiry and certificate expiry, since an expired domain takes the site down more completely than any server fault. Then learn to read the numbers properly with how to check hosting uptime, because a 99.9 percent guarantee still allows roughly 43 minutes of downtime a month.
12. Verify Search Console and submit the sitemap
Verify the property in Google Search Console and Bing Webmaster Tools, submit the XML sitemap, and confirm that robots.txt is not blocking anything you want indexed. Do this in week one even if the site is not finished, because the coverage history you build now is what tells you whether a later problem is new or long standing.
The checklist as a table
| # | Task | Where it is done | Cost of skipping it |
| 1 | Point DNS, lower TTL first | Registrar and DNS zone | Long propagation and downtime during the switch |
| 2 | Issue SSL for all hostnames | cPanel SSL or AutoSSL | Browser security warnings |
| 3 | Force HTTPS, pick one hostname | .htaccess or panel | Duplicate URLs and split signals |
| 4 | Create mailboxes with quotas | Email Accounts | One inbox fills the whole account |
| 5 | Add SPF, DKIM, DMARC | DNS zone editor | Mail lands in spam or is rejected |
| 6 | Test to an external inbox | Any external mailbox | Broken records stay invisible |
| 7 | Set supported PHP version | MultiPHP or Select PHP | Unpatched runtime, plugin failures |
| 8 | Enable caching and compression | Panel and .htaccess | Slower pages, higher transfer |
| 9 | Verify a backup restores | Backup or JetBackup | Discovering the gap during an outage |
| 10 | Harden logins, enable 2FA | Panel and site admin | Credential stuffing succeeds |
| 11 | Monitor uptime and expiry dates | External monitor, calendar | Silent outages, expired domain |
| 12 | Verify Search Console, submit sitemap | Search Console | No visibility data when problems start |
Print it, work through it once, and the account is in a state you can hand to anyone. If you are still comparing providers rather than configuring one, our hosting plans and professional email plans set out what is included before you commit.
Frequently asked questions
Point your domain at the hosting account, but lower the DNS TTL to 300 seconds beforehand so the change propagates in minutes. Once the domain resolves, issue the SSL certificate and force HTTPS. Every later step depends on the domain resolving correctly first.
It depends on the TTL set before the change, not on the change itself. With a TTL of 300 seconds most resolvers update within minutes. With the common default of 86400 seconds, some resolvers keep serving the old record for up to 24 hours.
Yes. Major mailbox providers check authentication on inbound mail, and unauthenticated messages are commonly rejected or filtered. Small senders are affected as much as bulk senders, because the checks apply to the domain rather than to the volume.
Most hosts run automated backups as a courtesy rather than a guarantee, with a limited retention window and size ceilings. Read the backup policy, test a restore while nothing is broken, and keep one independent copy off the server.
Roughly 43 minutes of downtime per month, or about 8 hours 45 minutes per year. Guarantees also usually exclude scheduled maintenance and require you to claim credit yourself, so measure uptime independently rather than relying on the provider status page.
