{"id":2824,"date":"2025-12-03T23:31:30","date_gmt":"2025-12-03T20:31:30","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/security-checklist-for-new-websites-20-hosting-settings-to-configure-on-day-one\/"},"modified":"2025-12-03T23:31:30","modified_gmt":"2025-12-03T20:31:30","slug":"security-checklist-for-new-websites-20-hosting-settings-to-configure-on-day-one","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/security-checklist-for-new-websites-20-hosting-settings-to-configure-on-day-one\/","title":{"rendered":"Security Checklist for New Websites: 20 Hosting Settings to Configure on Day One"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>You can launch a new website in a few clicks, but getting its <strong>security foundation<\/strong> right on day one takes a bit more discipline. Most compromises we see at dchost.com do not start with exotic zero\u2011days; they start with default passwords, missing HTTPS, open ports, outdated PHP, or an admin panel exposed to the entire internet. The good news: if you treat hosting security as a checklist and not an afterthought, you can remove a huge portion of your real\u2011world risk before your first visitor arrives.<\/p>\n<p>In this article we will walk through a <strong>20\u2011point security checklist for new websites<\/strong>, focused entirely on settings you can (and should) configure on your hosting platform from day one. Whether your site is on shared hosting, a managed <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, a <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocation with us, you can follow the same structure: lock down access, secure the network edge, harden the application environment, and make sure you can recover if something goes wrong.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#1_Identity_Accounts_and_Access_Dont_Start_with_a_Skeleton_Key\"><span class=\"toc_number toc_depth_1\">1<\/span> 1. Identity, Accounts and Access: Don\u2019t Start with a Skeleton Key<\/a><ul><li><a href=\"#1_Change_All_Default_Passwords_and_Enable_2FA\"><span class=\"toc_number toc_depth_2\">1.1<\/span> 1. Change All Default Passwords and Enable 2FA<\/a><\/li><li><a href=\"#2_Create_Separate_Accounts_and_Follow_Least_Privilege\"><span class=\"toc_number toc_depth_2\">1.2<\/span> 2. Create Separate Accounts and Follow Least Privilege<\/a><\/li><li><a href=\"#3_Harden_SSH_Access_For_VPS_Dedicated_and_Colocation\"><span class=\"toc_number toc_depth_2\">1.3<\/span> 3. Harden SSH Access (For VPS, Dedicated and Colocation)<\/a><\/li><li><a href=\"#4_Lock_Down_Your_Hosting_Control_Panel\"><span class=\"toc_number toc_depth_2\">1.4<\/span> 4. Lock Down Your Hosting Control Panel<\/a><\/li><li><a href=\"#5_Use_a_VPN_or_Bastion_for_Sensitive_Access\"><span class=\"toc_number toc_depth_2\">1.5<\/span> 5. Use a VPN or Bastion for Sensitive Access<\/a><\/li><\/ul><\/li><li><a href=\"#2_DNS_TLS_and_Network_Edge_Secure_the_Front_Door\"><span class=\"toc_number toc_depth_1\">2<\/span> 2. DNS, TLS and Network Edge: Secure the Front Door<\/a><ul><li><a href=\"#6_Configure_DNS_Correctly_and_Enable_DNSSEC\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 6. Configure DNS Correctly and Enable DNSSEC<\/a><\/li><li><a href=\"#7_Get_an_SSLTLS_Certificate_and_Enforce_HTTPS\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 7. Get an SSL\/TLS Certificate and Enforce HTTPS<\/a><\/li><li><a href=\"#8_Use_Modern_TLS_Protocols_and_Ciphers\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 8. Use Modern TLS Protocols and Ciphers<\/a><\/li><li><a href=\"#9_Set_Core_HTTP_Security_Headers\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 9. Set Core HTTP Security Headers<\/a><\/li><li><a href=\"#10_Configure_a_Web_Application_Firewall_WAF\"><span class=\"toc_number toc_depth_2\">2.5<\/span> 10. Configure a Web Application Firewall (WAF)<\/a><\/li><\/ul><\/li><li><a href=\"#3_Application_and_Server_Hardening_Make_Exploits_Work_Harder\"><span class=\"toc_number toc_depth_1\">3<\/span> 3. Application and Server Hardening: Make Exploits Work Harder<\/a><ul><li><a href=\"#11_Disable_Directory_Listing_and_Default_Files\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 11. Disable Directory Listing and Default Files<\/a><\/li><li><a href=\"#12_Set_Correct_File_and_Folder_Permissions\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 12. Set Correct File and Folder Permissions<\/a><\/li><li><a href=\"#13_Choose_a_Supported_PHP_Version_and_Disable_Dangerous_Functions\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 13. Choose a Supported PHP Version and Disable Dangerous Functions<\/a><\/li><li><a href=\"#14_Secure_Database_Access_and_Isolation\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 14. Secure Database Access and Isolation<\/a><\/li><li><a href=\"#15_Protect_Admin_and_Login_Endpoints\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 15. Protect Admin and Login Endpoints<\/a><\/li><\/ul><\/li><li><a href=\"#4_Email_Backups_and_Observability_Prepare_for_Failure_in_Advance\"><span class=\"toc_number toc_depth_1\">4<\/span> 4. Email, Backups and Observability: Prepare for Failure in Advance<\/a><ul><li><a href=\"#16_Set_SPF_DKIM_and_DMARC_for_Your_Domain\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 16. Set SPF, DKIM and DMARC for Your Domain<\/a><\/li><li><a href=\"#17_Configure_Automated_OffServer_Backups\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 17. Configure Automated, Off\u2011Server Backups<\/a><\/li><li><a href=\"#18_Separate_Staging_and_Production_Environments\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 18. Separate Staging and Production Environments<\/a><\/li><li><a href=\"#19_Set_Up_Monitoring_Alerts_and_Log_Retention\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 19. Set Up Monitoring, Alerts and Log Retention<\/a><\/li><li><a href=\"#20_Document_Your_Security_Baseline_and_Responsibilities\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 20. Document Your Security Baseline and Responsibilities<\/a><\/li><\/ul><\/li><li><a href=\"#5_Putting_It_All_Together_on_Day_One\"><span class=\"toc_number toc_depth_1\">5<\/span> 5. Putting It All Together on Day One<\/a><\/li><\/ul><\/div>\n<h2><span id=\"1_Identity_Accounts_and_Access_Dont_Start_with_a_Skeleton_Key\">1. Identity, Accounts and Access: Don\u2019t Start with a Skeleton Key<\/span><\/h2>\n<h3><span id=\"1_Change_All_Default_Passwords_and_Enable_2FA\">1. Change All Default Passwords and Enable 2FA<\/span><\/h3>\n<p>Your first job after provisioning hosting is to remove <strong>default credentials<\/strong>. That means:<\/p>\n<ul>\n<li>Hosting control panel login (cPanel, Plesk, DirectAdmin, custom panels)<\/li>\n<li>FTP\/SFTP accounts<\/li>\n<li>Database admin accounts (phpMyAdmin, adminer, etc.)<\/li>\n<li>Application admin logins (WordPress, PrestaShop, Laravel admin, etc.)<\/li>\n<\/ul>\n<p>Create <strong>unique, random passwords<\/strong> (use a password manager) and switch on <strong>two\u2011factor authentication (2FA)<\/strong> wherever the panel allows it. Many compromises happen because a reused password from another breach is tried against your newly created hosting account. 2FA breaks that chain immediately.<\/p>\n<h3><span id=\"2_Create_Separate_Accounts_and_Follow_Least_Privilege\">2. Create Separate Accounts and Follow Least Privilege<\/span><\/h3>\n<p>On day one it is tempting to do everything from one super\u2011privileged login. That is convenient but dangerous. Instead:<\/p>\n<ul>\n<li>Use one <strong>owner<\/strong> account with full rights, and separate <strong>developer<\/strong> or <strong>content editor<\/strong> accounts with limited permissions.<\/li>\n<li>If you are an agency, give each customer a separate hosting account rather than stacking many sites under one user.<\/li>\n<li>For FTP\/SFTP, avoid sharing the main account; create per\u2011user logins restricted to relevant directories.<\/li>\n<\/ul>\n<p>This \u201cleast privilege\u201d design ensures a stolen credential cannot automatically control everything.<\/p>\n<h3><span id=\"3_Harden_SSH_Access_For_VPS_Dedicated_and_Colocation\">3. Harden SSH Access (For VPS, Dedicated and Colocation)<\/span><\/h3>\n<p>If your website runs on a VPS, dedicated server or colocation machine, SSH is your lifeline \u2014 and a common attack target. Before you put the site into production:<\/p>\n<ul>\n<li><strong>Disable password logins<\/strong>; use SSH keys only.<\/li>\n<li>Change the <strong>SSH port<\/strong> from 22 to a non\u2011standard port (it does not replace security, but it cuts noise from bots).<\/li>\n<li>Disable root login via SSH and use a normal user with <code>sudo<\/code>.<\/li>\n<li>Consider using Fail2ban or the equivalent to ban IPs after repeated failures.<\/li>\n<\/ul>\n<p>We go much deeper on this topic in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-nasil-saglanir-kapiyi-acik-birakmadan-yasamanin-sirri\/\">the calm, no\u2011drama guide to securing a VPS server<\/a>, which you can reuse as a server\u2011side companion to this checklist.<\/p>\n<h3><span id=\"4_Lock_Down_Your_Hosting_Control_Panel\">4. Lock Down Your Hosting Control Panel<\/span><\/h3>\n<p>Control panels (cPanel, Plesk, DirectAdmin, custom dashboards) are powerful; if attackers reach them, they can change DNS, upload malware, or steal backups. On day one:<\/p>\n<ul>\n<li>Restrict panel access to <strong>HTTPS only<\/strong>.<\/li>\n<li>If your hosting includes IP allowlists, restrict administrative access to office\/VPN IP ranges.<\/li>\n<li>Ensure failed login attempts are <strong>rate\u2011limited<\/strong> or temporarily blocked.<\/li>\n<li>Disable or limit single\u2011click file managers or terminal features for non\u2011admin accounts.<\/li>\n<\/ul>\n<p>In cPanel environments, follow our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-guvenlik-sertlestirme-kontrol-listesi\/\">cPanel security hardening checklist<\/a> for additional, panel\u2011specific controls like brute\u2011force protection and malware scanning.<\/p>\n<h3><span id=\"5_Use_a_VPN_or_Bastion_for_Sensitive_Access\">5. Use a VPN or Bastion for Sensitive Access<\/span><\/h3>\n<p>For high\u2011value sites (e\u2011commerce, SaaS dashboards, internal tools) consider limiting SSH, database administration tools, and even panel access to a <strong>VPN<\/strong> or bastion host:<\/p>\n<ul>\n<li>Only the VPN subnet can reach SSH or database ports.<\/li>\n<li>Admin URLs (e.g., <code>\/wp-admin<\/code>) can optionally be restricted by IP.<\/li>\n<\/ul>\n<p>This adds one more layer between the public internet and your critical entry points without changing your application code.<\/p>\n<h2><span id=\"2_DNS_TLS_and_Network_Edge_Secure_the_Front_Door\">2. DNS, TLS and Network Edge: Secure the Front Door<\/span><\/h2>\n<h3><span id=\"6_Configure_DNS_Correctly_and_Enable_DNSSEC\">6. Configure DNS Correctly and Enable DNSSEC<\/span><\/h3>\n<p>Your DNS zone is as critical as your web server; if it is compromised, traffic can be silently redirected to malicious servers. When you first configure your domain:<\/p>\n<ul>\n<li>Ensure <strong>nameserver<\/strong> records (NS) correctly point to your intended DNS provider or to private nameservers you operate.<\/li>\n<li>Lock down access to the DNS management interface with strong passwords and 2FA.<\/li>\n<li>Enable <strong>DNSSEC<\/strong> (Domain Name System Security Extensions) to protect against DNS spoofing where supported by your registrar and DNS provider.<\/li>\n<\/ul>\n<p>If you want a deeper dive on why this matters, read our explainer on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-web-sitenizi-nasil-daha-guvenli-hale-getirir\/\">what DNSSEC is and how it makes your website more secure<\/a>.<\/p>\n<h3><span id=\"7_Get_an_SSLTLS_Certificate_and_Enforce_HTTPS\">7. Get an SSL\/TLS Certificate and Enforce HTTPS<\/span><\/h3>\n<p>Serving your website only over HTTP on launch day is no longer acceptable. You need an <strong>SSL\/TLS certificate<\/strong> from day one, even for simple brochure sites. On the hosting side, you should:<\/p>\n<ul>\n<li>Install a certificate (Let\u2019s Encrypt or commercial) on your main domain and all relevant subdomains.<\/li>\n<li>Configure <strong>automatic renewal<\/strong> to avoid expired cert outages.<\/li>\n<li>Set up 301 redirects from <code>http:\/\/<\/code> to <code>https:\/\/<\/code> for every hostname.<\/li>\n<\/ul>\n<p>If you are planning a full migration from HTTP, we recommend following our <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/\">step\u2011by\u2011step HTTPS migration guide with 301 redirects and HSTS<\/a> so you do not hurt your SEO while improving security.<\/p>\n<h3><span id=\"8_Use_Modern_TLS_Protocols_and_Ciphers\">8. Use Modern TLS Protocols and Ciphers<\/span><\/h3>\n<p>Once HTTPS is enabled, check the <strong>TLS configuration<\/strong> itself. On a VPS or dedicated server, that usually means editing your web server config (Nginx, Apache, LiteSpeed). In control panels, you often have presets such as \u201cmodern\u201d or \u201chigh security\u201d. Aim for:<\/p>\n<ul>\n<li>Enabling <strong>TLS 1.2 and 1.3<\/strong>; disabling TLS 1.0\/1.1 and all SSLv2\/3.<\/li>\n<li>Using strong cipher suites that support <strong>forward secrecy<\/strong>.<\/li>\n<li>Enabling <strong>OCSP stapling<\/strong> and proper certificate chains.<\/li>\n<\/ul>\n<p>We maintain a separate deep\u2011dive on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-tls-guvenlik-guncellemeleri-ne-zaman-nasil-ve-neyi-degistirmelisiniz\/\">which SSL\/TLS security updates you must keep up to date<\/a> if you want a configuration checklist for Nginx and Apache.<\/p>\n<h3><span id=\"9_Set_Core_HTTP_Security_Headers\">9. Set Core HTTP Security Headers<\/span><\/h3>\n<p>HTTP security headers are lightweight but powerful protections you can enable on day one. At a minimum, configure these headers at the web server or hosting panel level:<\/p>\n<ul>\n<li><strong>Strict-Transport-Security (HSTS)<\/strong> to force future HTTPS usage.<\/li>\n<li><strong>X-Frame-Options<\/strong> or <strong>Content-Security-Policy frame-ancestors<\/strong> to prevent clickjacking.<\/li>\n<li><strong>X-Content-Type-Options: nosniff<\/strong> to block MIME sniffing.<\/li>\n<li><strong>Referrer-Policy<\/strong> to limit referrer leakage.<\/li>\n<\/ul>\n<p>Later you can add stronger controls like CSP. For a practical walkthrough, see <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-ve-digerlerini-ne-zaman-nasil-uygulamalisin\/\">our friendly guide to HTTP security headers<\/a>, which includes real example configurations.<\/p>\n<h3><span id=\"10_Configure_a_Web_Application_Firewall_WAF\">10. Configure a Web Application Firewall (WAF)<\/span><\/h3>\n<p>A <strong>web application firewall<\/strong> inspects HTTP requests and blocks common attack patterns such as SQL injection, cross\u2011site scripting and malicious file uploads. On day one:<\/p>\n<ul>\n<li>Enable ModSecurity (or your panel\u2019s built\u2011in WAF) with a ruleset like OWASP CRS.<\/li>\n<li>Start in <strong>blocking mode<\/strong> for critical rules; tune if you see false positives.<\/li>\n<li>Log WAF events to a dedicated file for later analysis.<\/li>\n<\/ul>\n<p>Position your WAF as early as possible in the request path (ideally at the edge or front web server) so it can protect all your applications and subdomains behind the same shield.<\/p>\n<h2><span id=\"3_Application_and_Server_Hardening_Make_Exploits_Work_Harder\">3. Application and Server Hardening: Make Exploits Work Harder<\/span><\/h2>\n<h3><span id=\"11_Disable_Directory_Listing_and_Default_Files\">11. Disable Directory Listing and Default Files<\/span><\/h3>\n<p>On fresh hosting accounts, web roots often allow <strong>autoindex<\/strong> or \u201cdirectory listing\u201d, showing visitors the raw list of files if there is no index file. That leaks sensitive structure and encourages exploration. On day one:<\/p>\n<ul>\n<li>Disable directory listing in your web server or via <code>.htaccess<\/code> if using Apache.<\/li>\n<li>Remove or rename default files (e.g., <code>info.php<\/code>, sample scripts, \u201cIt works!\u201d pages).<\/li>\n<li>Ensure the document root contains only your application, not random tools or installers.<\/li>\n<\/ul>\n<h3><span id=\"12_Set_Correct_File_and_Folder_Permissions\">12. Set Correct File and Folder Permissions<\/span><\/h3>\n<p>Incorrect permissions are a classic reason malware can spread across sites on the same account. As you deploy your site:<\/p>\n<ul>\n<li>Use <strong>644<\/strong> for files and <strong>755<\/strong> for directories in most PHP setups.<\/li>\n<li>Ensure files are owned by the correct user (matching your PHP handler, e.g., PHP\u2011FPM pool user).<\/li>\n<li>Mark <strong>upload<\/strong> directories as <strong>non\u2011executable<\/strong> if you can, to prevent uploaded scripts from running.<\/li>\n<\/ul>\n<p>For CMS platforms like WordPress, combine correct permissions with application\u2011level hardening (disabling file editors, protecting <code>wp-config.php<\/code>, etc.). We cover this angle in depth in our WordPress hardening and security articles.<\/p>\n<h3><span id=\"13_Choose_a_Supported_PHP_Version_and_Disable_Dangerous_Functions\">13. Choose a Supported PHP Version and Disable Dangerous Functions<\/span><\/h3>\n<p>Your choice of <strong>PHP version<\/strong> and configuration can dramatically change your attack surface. On day one:<\/p>\n<ul>\n<li>Pick a <strong>currently supported PHP release<\/strong> (PHP 8.x at the time of writing).<\/li>\n<li>Make sure each website runs on its own PHP version\/pool where possible.<\/li>\n<li>Disable or restrict dangerous functions (e.g., <code>exec<\/code>, <code>shell_exec<\/code>) unless your application really needs them.<\/li>\n<li>Set sensible limits for <code>upload_max_filesize<\/code>, <code>post_max_size<\/code> and <code>max_execution_time<\/code> to reduce abuse.<\/li>\n<\/ul>\n<p>If you manage multiple sites per server, per\u2011site PHP configuration is critical, as we discussed in our piece on managing multiple PHP versions on common control panels.<\/p>\n<h3><span id=\"14_Secure_Database_Access_and_Isolation\">14. Secure Database Access and Isolation<\/span><\/h3>\n<p>Every new website with dynamic content relies on a database. To keep it safe from day one:<\/p>\n<ul>\n<li>Create a <strong>separate database user per site<\/strong> with only the privileges it needs (usually just on its own database).<\/li>\n<li>Avoid using the global <code>root<\/code> account in application configuration.<\/li>\n<li>Bind the database server to <strong>localhost<\/strong> unless you explicitly need remote access.<\/li>\n<li>If remote access is required, restrict by IP and enforce TLS where possible.<\/li>\n<\/ul>\n<p>This isolation prevents an exploited site from trivially reading or corrupting other applications\u2019 data.<\/p>\n<h3><span id=\"15_Protect_Admin_and_Login_Endpoints\">15. Protect Admin and Login Endpoints<\/span><\/h3>\n<p>Almost every automated attack we see targets <strong>login pages<\/strong> and admin URLs. On day one, configure:<\/p>\n<ul>\n<li><strong>Rate limiting<\/strong> for login paths (e.g., <code>\/wp-login.php<\/code>, <code>\/admin<\/code>, <code>\/user\/login<\/code>).<\/li>\n<li>Optional IP allowlists for sensitive admin panels when feasible.<\/li>\n<li>CAPTCHA or other abuse controls for forms that create accounts or send emails.<\/li>\n<li>Unique admin paths where your platform supports safe renaming (be careful: some plugins break with URL changes).<\/li>\n<\/ul>\n<p>Combine this with strong per\u2011user passwords and 2FA and you will stop the majority of brute\u2011force attempts before they become a resource problem.<\/p>\n<h2><span id=\"4_Email_Backups_and_Observability_Prepare_for_Failure_in_Advance\">4. Email, Backups and Observability: Prepare for Failure in Advance<\/span><\/h2>\n<h3><span id=\"16_Set_SPF_DKIM_and_DMARC_for_Your_Domain\">16. Set SPF, DKIM and DMARC for Your Domain<\/span><\/h3>\n<p>Email might seem separate from <a href=\"https:\/\/www.dchost.com\/web-hosting\">web hosting<\/a>, but attackers frequently abuse new domains to send phishing messages. Configuring <strong>SPF, DKIM and DMARC<\/strong> in DNS from day one helps protect your brand and inboxes:<\/p>\n<ul>\n<li>Publish an <strong>SPF<\/strong> TXT record listing legitimate mail servers.<\/li>\n<li>Enable <strong>DKIM<\/strong> signing in your email platform and add the public key records.<\/li>\n<li>Start with a <strong>DMARC<\/strong> policy in monitoring mode (<code>p=none<\/code>) with reporting addresses so you can see abuse attempts.<\/li>\n<\/ul>\n<p>Our separate guides on SPF, DKIM, DMARC and mail deliverability go into the specifics of syntax and troubleshooting if you need a deeper configuration runbook.<\/p>\n<h3><span id=\"17_Configure_Automated_OffServer_Backups\">17. Configure Automated, Off\u2011Server Backups<\/span><\/h3>\n<p>No security checklist is complete without backups. A compromise, misconfiguration or hardware failure is survivable if you can restore clean data quickly. On day one, configure:<\/p>\n<ul>\n<li>Automated daily backups of files and databases.<\/li>\n<li>Storage on a <strong>separate system<\/strong> (another server or object storage), not only on the same disk as your site.<\/li>\n<li>Retention policies (e.g., 7 daily, 4 weekly, 6 monthly backups).<\/li>\n<li>Periodic <strong>restore tests<\/strong> so you know backups are actually usable.<\/li>\n<\/ul>\n<p>We strongly recommend following the <strong>3\u20112\u20111 backup strategy<\/strong> from the start: at least three copies, on two different media, with one offsite. Our article on the <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">3\u20112\u20111 backup strategy and automating backups on cPanel, Plesk and VPS<\/a> shows exactly how to configure this.<\/p>\n<h3><span id=\"18_Separate_Staging_and_Production_Environments\">18. Separate Staging and Production Environments<\/span><\/h3>\n<p>It is risky to develop and test directly on your live site. On day one, plan for at least two environments:<\/p>\n<ul>\n<li><strong>Production<\/strong>: Your real users, with strict security and change control.<\/li>\n<li><strong>Staging<\/strong>: A copy of production for testing updates, plugin changes, and configuration tweaks.<\/li>\n<\/ul>\n<p>Host staging under a separate subdomain or even account, protect it with HTTP auth or IP restrictions, and avoid indexing by search engines. This isolation means a broken plugin or misconfigured WAF rule is discovered before it affects real customers.<\/p>\n<h3><span id=\"19_Set_Up_Monitoring_Alerts_and_Log_Retention\">19. Set Up Monitoring, Alerts and Log Retention<\/span><\/h3>\n<p>Security is not only about prevention; you also need <strong>visibility<\/strong>. As soon as your site goes live, configure:<\/p>\n<ul>\n<li><strong>Uptime monitoring<\/strong> to alert you if the site stops responding.<\/li>\n<li>Resource monitoring (CPU, RAM, disk, bandwidth) for servers and hosting plans.<\/li>\n<li>Centralized logging where feasible, with at least 7\u201330 days of logs.<\/li>\n<li>Alert thresholds for suspicious patterns (e.g., spikes in 4xx\/5xx errors, WAF blocks, or login failures).<\/li>\n<\/ul>\n<p>Even basic monitoring and log retention will help you detect attacks earlier and understand what happened if something does go wrong.<\/p>\n<h3><span id=\"20_Document_Your_Security_Baseline_and_Responsibilities\">20. Document Your Security Baseline and Responsibilities<\/span><\/h3>\n<p>Finally, good security on day one should be <strong>repeatable<\/strong>. Take an extra hour to document:<\/p>\n<ul>\n<li>Which settings you applied on the hosting panel and server.<\/li>\n<li>Where backups are stored and how to restore them.<\/li>\n<li>Which admin accounts exist and who owns them.<\/li>\n<li>Which third\u2011party services are allowed to access your hosting (CI\/CD, monitoring, email gateways, etc.).<\/li>\n<\/ul>\n<p>This baseline becomes your reference when you add new sites or onboarding new team members, and it makes annual security reviews much easier.<\/p>\n<h2><span id=\"5_Putting_It_All_Together_on_Day_One\">5. Putting It All Together on Day One<\/span><\/h2>\n<p>Security can feel overwhelming when you list everything that <em>could<\/em> go wrong, but a structured hosting checklist turns it into a straightforward setup process. If you walk through these 20 items on the day you launch a new website, you will have covered the biggest real\u2011world risks: exposed admin panels, weak authentication, missing HTTPS, unsafe defaults, unprotected databases, absent backups, and zero visibility.<\/p>\n<p>From the dchost.com side, we see a clear pattern: websites that start life with strong hosting\u2011level security settings and regular reviews remain far more resilient over the years, even as plugins, themes and business requirements evolve. As you grow, you can build on this foundation with more advanced techniques like CSP nonces, multi\u2011region redundancy, and dedicated WAF tuning, which we discuss across many of our security and infrastructure articles.<\/p>\n<p>If you are about to launch a new project, treat this checklist as part of your go\u2011live runbook alongside design, SEO and performance checks. Work through it once, keep a copy in your documentation, and revisit it whenever you spin up a new hosting plan, VPS, dedicated server or colocation setup. A calm, well\u2011configured day one dramatically reduces the chances of a panicked day thirty.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>You can launch a new website in a few clicks, but getting its security foundation right on day one takes a bit more discipline. Most compromises we see at dchost.com do not start with exotic zero\u2011days; they start with default passwords, missing HTTPS, open ports, outdated PHP, or an admin panel exposed to the entire [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2825,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2824","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2824","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2824"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2824\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2825"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2824"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2824"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2824"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}