{"id":3896,"date":"2026-01-01T16:03:41","date_gmt":"2026-01-01T13:03:41","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/hosting-and-dns-audit-checklist-for-agencies-when-onboarding-new-clients\/"},"modified":"2026-01-01T16:03:41","modified_gmt":"2026-01-01T13:03:41","slug":"hosting-and-dns-audit-checklist-for-agencies-when-onboarding-new-clients","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/hosting-and-dns-audit-checklist-for-agencies-when-onboarding-new-clients\/","title":{"rendered":"Hosting and DNS Audit Checklist for Agencies When Onboarding New Clients"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When an agency takes over a website, the riskiest part is rarely the design or content. It is the messy combination of domains, DNS, email routing and half-documented hosting that has grown over years. If you do not standardise how you audit these pieces on day one, you inherit every hidden problem: broken email, slow sites, mixed SSL, orphaned subdomains and surprise downtime during the first change you make. In this guide, we share a practical hosting and DNS audit checklist we use at dchost.com when onboarding new clients and agency partners. You can adapt it to your own process, tick through it on every project and massively reduce surprises later. We will walk through ownership, access, DNS records, email, hosting environment, performance, security, backups and documentation, with concrete questions to ask and items to verify.<\/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=\"#Why_Agencies_Need_a_Hosting_and_DNS_Audit_on_Day_One\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Agencies Need a Hosting and DNS Audit on Day One<\/a><\/li><li><a href=\"#Step_1_Map_Ownership_Providers_and_Access\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1 \u2013 Map Ownership, Providers and Access<\/a><ul><li><a href=\"#11_Identify_Who_Owns_What\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1.1 Identify Who Owns What<\/a><\/li><li><a href=\"#12_Collect_Logins_and_Stabilise_Access\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 1.2 Collect Logins and Stabilise Access<\/a><\/li><\/ul><\/li><li><a href=\"#Step_2_Full_DNS_Health_Check\"><span class=\"toc_number toc_depth_1\">3<\/span> Step 2 \u2013 Full DNS Health Check<\/a><ul><li><a href=\"#21_Confirm_Nameservers_and_DNS_Hosting\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 2.1 Confirm Nameservers and DNS Hosting<\/a><\/li><li><a href=\"#22_Inventory_All_DNS_Records\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2.2 Inventory All DNS Records<\/a><\/li><li><a href=\"#23_Check_TTLs_and_Plan_Change_Windows\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 2.3 Check TTLs and Plan Change Windows<\/a><\/li><li><a href=\"#24_DNS_Security_DNSSEC_Dangling_Records_and_Subdomain_Takeover\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 2.4 DNS Security: DNSSEC, Dangling Records and Subdomain Takeover<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Email_and_Deliverability_Audit\"><span class=\"toc_number toc_depth_1\">4<\/span> Step 3 \u2013 Email and Deliverability Audit<\/a><ul><li><a href=\"#31_MX_Setup_and_Redundancy\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 3.1 MX Setup and Redundancy<\/a><\/li><li><a href=\"#32_SPF_DKIM_DMARC_and_Reverse_DNS\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 3.2 SPF, DKIM, DMARC and Reverse DNS<\/a><\/li><\/ul><\/li><li><a href=\"#Step_4_Hosting_Environment_and_Server_Configuration\"><span class=\"toc_number toc_depth_1\">5<\/span> Step 4 \u2013 Hosting Environment and Server Configuration<\/a><ul><li><a href=\"#41_Identify_the_Hosting_Type_and_Capacity\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 4.1 Identify the Hosting Type and Capacity<\/a><\/li><li><a href=\"#42_Platform_Versions_PHP_Database_OS\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 4.2 Platform Versions: PHP, Database, OS<\/a><\/li><li><a href=\"#43_SSLTLS_Redirects_and_Canonical_URLs\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 4.3 SSL\/TLS, Redirects and Canonical URLs<\/a><\/li><\/ul><\/li><li><a href=\"#Step_5_Performance_Caching_and_CDN\"><span class=\"toc_number toc_depth_1\">6<\/span> Step 5 \u2013 Performance, Caching and CDN<\/a><ul><li><a href=\"#51_Baseline_Performance_from_the_Server_Side\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 5.1 Baseline Performance from the Server Side<\/a><\/li><li><a href=\"#52_Caching_Layers_Application_Server_and_CDN\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 5.2 Caching Layers: Application, Server and CDN<\/a><\/li><li><a href=\"#53_CDN_WAF_and_Edge_Configuration\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 5.3 CDN, WAF and Edge Configuration<\/a><\/li><\/ul><\/li><li><a href=\"#Step_6_Security_Backups_and_Disaster_Recovery\"><span class=\"toc_number toc_depth_1\">7<\/span> Step 6 \u2013 Security, Backups and Disaster Recovery<\/a><ul><li><a href=\"#61_HostingSide_Security_Basics\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 6.1 Hosting\u2011Side Security Basics<\/a><\/li><li><a href=\"#62_Backup_Coverage_and_Recovery_Testing\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 6.2 Backup Coverage and Recovery Testing<\/a><\/li><li><a href=\"#63_Simple_Disaster_Recovery_Plan\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 6.3 Simple Disaster Recovery Plan<\/a><\/li><\/ul><\/li><li><a href=\"#Step_7_Documentation_Standards_and_GoLive_Checklist_for_Agencies\"><span class=\"toc_number toc_depth_1\">8<\/span> Step 7 \u2013 Documentation, Standards and Go\u2011Live Checklist for Agencies<\/a><ul><li><a href=\"#71_Create_a_Living_Hosting_and_DNS_Sheet\"><span class=\"toc_number toc_depth_2\">8.1<\/span> 7.1 Create a Living Hosting and DNS Sheet<\/a><\/li><li><a href=\"#72_Standard_Agency_Rules_for_New_Clients\"><span class=\"toc_number toc_depth_2\">8.2<\/span> 7.2 Standard Agency Rules for New Clients<\/a><\/li><li><a href=\"#73_Plan_Future_Improvements_After_the_Audit\"><span class=\"toc_number toc_depth_2\">8.3<\/span> 7.3 Plan Future Improvements After the Audit<\/a><\/li><\/ul><\/li><li><a href=\"#Turning_Your_Checklist_into_a_Repeatable_Onboarding_Process_with_dchostcom\"><span class=\"toc_number toc_depth_1\">9<\/span> Turning Your Checklist into a Repeatable Onboarding Process with dchost.com<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Agencies_Need_a_Hosting_and_DNS_Audit_on_Day_One\">Why Agencies Need a Hosting and DNS Audit on Day One<\/span><\/h2>\n<p>Many agencies jump straight into redesigning the website or connecting analytics, only to discover later that:<\/p>\n<ul>\n<li>The domain is owned by a former freelancer, not the client.<\/li>\n<li>DNS is split across several providers and nobody is sure which one is authoritative.<\/li>\n<li>Email routing depends on a fragile MX setup and outdated SPF records.<\/li>\n<li>The site is running on an overloaded shared hosting plan with no usable backups.<\/li>\n<\/ul>\n<p>An early, structured audit solves these problems before they bite you. It allows you to:<\/p>\n<ul>\n<li>Clarify who owns what and who can approve critical changes.<\/li>\n<li>Map domain, DNS, hosting and email so your team is not guessing.<\/li>\n<li>Spot quick wins: SSL fixes, HTTP to HTTPS redirects, simple performance gains.<\/li>\n<li>Plan safe migrations, redesigns and campaign launches on top of a stable foundation.<\/li>\n<\/ul>\n<p>Use the checklist below as a repeatable onboarding template. For deeper background on how these building blocks work together, you can also read our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-hosting-nedir-domain-dns-sunucu-ve-ssl-nasil-birlikte-calisir\/\">what is web hosting and how domain, DNS, server and SSL work together<\/a>.<\/p>\n<h2><span id=\"Step_1_Map_Ownership_Providers_and_Access\">Step 1 \u2013 Map Ownership, Providers and Access<\/span><\/h2>\n<h3><span id=\"11_Identify_Who_Owns_What\">1.1 Identify Who Owns What<\/span><\/h3>\n<p>Before touching any setting, draw a simple map of ownership. For each item below, write down both the legal owner and the current administrator.<\/p>\n<ul>\n<li>Primary domain(s) and key subdomains<\/li>\n<li>Domain registrar account<\/li>\n<li>DNS provider \/ nameserver host<\/li>\n<li>Web hosting account (shared, reseller, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, dedicated, or colocation)<\/li>\n<li>Email service (self-hosted, hosting-based or third-party service)<\/li>\n<li>CDN \/ WAF \/ reverse proxy in front of the site, if any<\/li>\n<\/ul>\n<p>Questions to ask the client:<\/p>\n<ul>\n<li>Which email address receives registrar renewal emails and invoices?<\/li>\n<li>Has any previous agency or freelancer registered domains in their own name?<\/li>\n<li>Is there any shadow DNS (old nameservers still used by subdomains)?<\/li>\n<\/ul>\n<p>If you discover domains are not owned by the client, make it a priority to transfer them to an account controlled by the client (with your agency as a technical contact). Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-transferi-nasil-yapilir-epp-kodu-transfer-kilidi-ve-kesintisiz-gecise-sakin-bir-rehber\/\">how to transfer a domain without downtime<\/a> explains the safest process.<\/p>\n<h3><span id=\"12_Collect_Logins_and_Stabilise_Access\">1.2 Collect Logins and Stabilise Access<\/span><\/h3>\n<p>Once owners are clear, collect credentials in a secure way (password manager, secrets vault, not email threads). You typically need:<\/p>\n<ul>\n<li>Registrar login<\/li>\n<li>DNS provider panel login<\/li>\n<li>Hosting control panel (cPanel, Plesk, DirectAdmin or custom panel)<\/li>\n<li>Server SSH or RDP access for VPS \/ dedicated \/ colocation<\/li>\n<li>Admin access for email service, CDN \/ WAF, analytics and tag managers<\/li>\n<\/ul>\n<p>Security steps to include in your checklist:<\/p>\n<ul>\n<li>&#x2610; Enable 2FA on registrar, DNS and hosting accounts.<\/li>\n<li>&#x2610; Change passwords previously shared with old agencies or freelancers.<\/li>\n<li>&#x2610; Create separate logins for your agency instead of reusing the client\u2019s personal login.<\/li>\n<\/ul>\n<p>For agencies managing many clients, structured access is crucial. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ajanslar-icin-dns-ve-alan-adi-erisimi-yonetimi\/\">DNS and domain access management for agencies<\/a> shares practical patterns that scale.<\/p>\n<h2><span id=\"Step_2_Full_DNS_Health_Check\">Step 2 \u2013 Full DNS Health Check<\/span><\/h2>\n<h3><span id=\"21_Confirm_Nameservers_and_DNS_Hosting\">2.1 Confirm Nameservers and DNS Hosting<\/span><\/h3>\n<p>Your first DNS task is to confirm which nameservers are actually authoritative for the domain. Check at the registrar:<\/p>\n<ul>\n<li>List the current nameservers (e.g. ns1.example-isp.com, ns2.example-isp.com).<\/li>\n<li>Verify that DNS changes you see in the panel match what public DNS resolvers return.<\/li>\n<li>Note any legacy nameservers still referenced by subdomains or glue records.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Authoritative nameservers identified and documented.<\/li>\n<li>&#x2610; Registrar\u2019s nameserver settings match the intended DNS provider.<\/li>\n<li>&#x2610; No unexpected third-party nameservers (e.g. left from an old provider).<\/li>\n<\/ul>\n<p>If the client uses custom nameservers branded on their own domain (ns1.client.com, ns2.client.com), verify glue records and IPs. For a step\u2011by\u2011step approach, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ozel-ad-sunucusu-ve-glue-record-nasil-kurulur-kendi-dnsine-adim-adim-yolculuk\/\">private nameservers and glue records<\/a>.<\/p>\n<h3><span id=\"22_Inventory_All_DNS_Records\">2.2 Inventory All DNS Records<\/span><\/h3>\n<p>Next, take a snapshot of all DNS records. Export them from the DNS panel or manually copy them into your documentation. Pay special attention to:<\/p>\n<ul>\n<li><strong>A \/ AAAA<\/strong> \u2013 IPv4 and IPv6 for root domain (example.com), www and key subdomains.<\/li>\n<li><strong>CNAME<\/strong> \u2013 Aliases for app.example.com, cdn.example.com, tracking and third-party tools.<\/li>\n<li><strong>MX<\/strong> \u2013 Email routing and any backup MX servers.<\/li>\n<li><strong>TXT<\/strong> \u2013 SPF, DKIM, DMARC, verification records (Google, Meta, Microsoft, etc.).<\/li>\n<li><strong>SRV<\/strong> \u2013 VOIP, chat, Office\/Teams and other services.<\/li>\n<li><strong>CAA<\/strong> \u2013 Which certificate authorities are allowed to issue SSL for the domain.<\/li>\n<\/ul>\n<p>Questions to ask while reviewing:<\/p>\n<ul>\n<li>Do A and AAAA records point to the actual current hosting server or to an obsolete IP?<\/li>\n<li>Are there multiple A records with different IPs (intentional load balancing or a misconfiguration)?<\/li>\n<li>Is www an A record or a CNAME to the root, and is it consistent with your redirect strategy?<\/li>\n<li>Do MX records match the client\u2019s real email platform?<\/li>\n<li>Are there leftover TXT or CNAME records from old tools that can be removed?<\/li>\n<\/ul>\n<p>For a friendly deep dive into each record type (including common mistakes), you can refer to our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">DNS records explained like a friend: A, AAAA, CNAME, MX, TXT, SRV, CAA and the gotchas<\/a>.<\/p>\n<h3><span id=\"23_Check_TTLs_and_Plan_Change_Windows\">2.3 Check TTLs and Plan Change Windows<\/span><\/h3>\n<p>Time To Live (TTL) controls how long resolvers cache DNS answers. For new clients, you often find:<\/p>\n<ul>\n<li>Very high TTLs (e.g. 24 hours) that slow down propagation during migrations.<\/li>\n<li>Very low TTLs (e.g. 60 seconds) that increase DNS query load and can hide caching issues.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Note current TTLs for A\/AAAA, CNAME, MX and NS records.<\/li>\n<li>&#x2610; For upcoming migrations, plan to lower TTLs 24\u201348 hours before the cut\u2011over.<\/li>\n<li>&#x2610; After stabilisation, raise TTLs again to reasonable defaults (e.g. 1\u20134 hours for critical records).<\/li>\n<\/ul>\n<p>We share practical TTL patterns and migration timing in our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">the TTL playbook for zero\u2011downtime migrations<\/a>. It fits perfectly as a follow\u2011up to this audit.<\/p>\n<h3><span id=\"24_DNS_Security_DNSSEC_Dangling_Records_and_Subdomain_Takeover\">2.4 DNS Security: DNSSEC, Dangling Records and Subdomain Takeover<\/span><\/h3>\n<p>As part of your audit, capture the DNS security posture:<\/p>\n<ul>\n<li><strong>DNSSEC<\/strong> \u2013 Is DNSSEC enabled at the registrar and correctly configured on the DNS provider?<\/li>\n<li><strong>Dangling DNS<\/strong> \u2013 Any CNAMEs pointing to decommissioned services that could be hijacked?<\/li>\n<li><strong>Wildcard records<\/strong> \u2013 Are there broad wildcard A\/CNAME records that expose test subdomains?<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Confirm whether DNSSEC is enabled and not in a broken state (mismatched DS records).<\/li>\n<li>&#x2610; Identify DNS records pointing to services the client no longer uses.<\/li>\n<li>&#x2610; Remove or correct dangling records to reduce subdomain takeover risk.<\/li>\n<\/ul>\n<p>For clients with higher security requirements, consider planning DNSSEC activation after any immediate migration work is done. Our piece <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-ne-ise-yarar-alan-adiniz-ve-hostinginiz-icin-adim-adim-dnssec-kurulum-rehberi\/\">what is DNSSEC and when should you enable it<\/a> walks through a practical rollout process.<\/p>\n<h2><span id=\"Step_3_Email_and_Deliverability_Audit\">Step 3 \u2013 Email and Deliverability Audit<\/span><\/h2>\n<h3><span id=\"31_MX_Setup_and_Redundancy\">3.1 MX Setup and Redundancy<\/span><\/h3>\n<p>Email is where DNS mistakes hurt the most. Start by documenting:<\/p>\n<ul>\n<li>Current MX records, priorities and target hosts.<\/li>\n<li>Whether there is a backup MX server and if it is still maintained.<\/li>\n<li>Any split delivery or forwarding rules between services.<\/li>\n<\/ul>\n<p>Questions to clarify with the client:<\/p>\n<ul>\n<li>Which inboxes are business\u2011critical (billing, support, sales, HR)?<\/li>\n<li>Have they had recurring issues with emails going to spam or bouncing?<\/li>\n<li>Are there legacy mailboxes still receiving important mail (e.g. info@ used on old invoices)?<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; MX records accurately represent the real, in\u2011use email platform.<\/li>\n<li>&#x2610; No obsolete MX records pointing to decommissioned servers.<\/li>\n<li>&#x2610; If redundancy is needed, backup MX servers are documented and tested.<\/li>\n<\/ul>\n<h3><span id=\"32_SPF_DKIM_DMARC_and_Reverse_DNS\">3.2 SPF, DKIM, DMARC and Reverse DNS<\/span><\/h3>\n<p>Modern deliverability depends heavily on DNS\u2011side authentication:<\/p>\n<ul>\n<li><strong>SPF<\/strong> \u2013 TXT record listing IPs and services allowed to send mail for the domain.<\/li>\n<li><strong>DKIM<\/strong> \u2013 Public keys in DNS that match private keys used by mail servers to sign messages.<\/li>\n<li><strong>DMARC<\/strong> \u2013 Policy (none\/quarantine\/reject) and reporting addresses for handling failed SPF\/DKIM.<\/li>\n<li><strong>rDNS \/ PTR<\/strong> \u2013 Reverse DNS mapping sending IPs back to a valid hostname.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; SPF record exists, uses a sane policy (e.g. <code>~all<\/code> or <code>-all<\/code>) and includes all legitimate senders.<\/li>\n<li>&#x2610; No duplicate or conflicting SPF TXT records.<\/li>\n<li>&#x2610; DKIM is active for main sending systems (transactional email, newsletter, ticketing, etc.).<\/li>\n<li>&#x2610; DMARC record exists with appropriate policy level for the client\u2019s risk tolerance.<\/li>\n<li>&#x2610; For self\u2011hosted mail on VPS\/dedicated, PTR records are set correctly for outbound IPs.<\/li>\n<\/ul>\n<p>Improving email authentication is often a quick win early in an engagement. If you want a deeper playbook, see our detailed explanation of <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">how to improve email deliverability with SPF, DKIM, DMARC and rDNS<\/a>.<\/p>\n<h2><span id=\"Step_4_Hosting_Environment_and_Server_Configuration\">Step 4 \u2013 Hosting Environment and Server Configuration<\/span><\/h2>\n<h3><span id=\"41_Identify_the_Hosting_Type_and_Capacity\">4.1 Identify the Hosting Type and Capacity<\/span><\/h3>\n<p>Understanding the current hosting environment is essential before planning any redesign or marketing campaigns. For each site or application, capture:<\/p>\n<ul>\n<li>Hosting type: shared hosting, reseller hosting, VPS, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocation.<\/li>\n<li>Control panel: cPanel, Plesk, DirectAdmin, custom panel or none (pure SSH).<\/li>\n<li>Resource limits: vCPU, RAM, storage, inode limits, bandwidth quotas.<\/li>\n<li>Current average and peak usage (CPU, RAM, disk IO, bandwidth, database load).<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Hosting type and plan documented for each domain or project.<\/li>\n<li>&#x2610; Server location (country\/region) noted for performance and data\u2011protection reasons.<\/li>\n<li>&#x2610; Any upcoming campaigns or traffic spikes considered in capacity planning.<\/li>\n<\/ul>\n<p>If you manage many client sites, consider standardising on an agency\u2011friendly stack like reseller hosting or an agency VPS cluster. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ajanslar-icin-reseller-hosting-mi-vps-mi-olceklenebilir-barindirma-stratejisi\/\">reseller hosting vs VPS for agencies<\/a> discusses realistic architectures; at dchost.com we provide both options, plus dedicated servers and colocation for larger setups.<\/p>\n<h3><span id=\"42_Platform_Versions_PHP_Database_OS\">4.2 Platform Versions: PHP, Database, OS<\/span><\/h3>\n<p>Outdated software is a security risk and a barrier to performance tuning. For each hosting environment, note:<\/p>\n<ul>\n<li>PHP version(s) in use per site.<\/li>\n<li>Web server: Apache, Nginx, LiteSpeed and their version.<\/li>\n<li>Database engine and version: MySQL, MariaDB, PostgreSQL.<\/li>\n<li>Operating system: e.g. AlmaLinux, Debian, Ubuntu, plus major version.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; PHP version still supported and compatible with site CMS\/framework.<\/li>\n<li>&#x2610; Database version supported and receiving security updates.<\/li>\n<li>&#x2610; OS still within vendor support window.<\/li>\n<\/ul>\n<p>Document any blockers (custom code requiring older PHP, legacy extensions) and plan upgrades as a separate mini\u2011project. Our library includes in\u2011depth pieces like choosing <a href=\"https:\/\/www.dchost.com\/blog\/en\/ubuntu-mu-debian-mi-almalinux-mu-vps-uzerinde-web-hosting-icin-dogru-secim\/\">the right Linux distro for VPS web hosting<\/a> and tuning <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-opcache-ayarlari-wordpress-laravel-ve-woocommerce-icin-en-iyi-konfigurasyon-rehberi\/\">PHP OPcache settings for WordPress and Laravel<\/a> once the basics are clean.<\/p>\n<h3><span id=\"43_SSLTLS_Redirects_and_Canonical_URLs\">4.3 SSL\/TLS, Redirects and Canonical URLs<\/span><\/h3>\n<p>Misconfigured SSL and redirects are common on inherited projects. For each domain:<\/p>\n<ul>\n<li>Check if a valid SSL\/TLS certificate is installed (not expired, correct hostname, full chain).<\/li>\n<li>Test HTTP \u2192 HTTPS redirects for both root and www\/non\u2011www.<\/li>\n<li>Check that canonical host (with or without www) is consistent across redirects, sitemap and SEO settings.<\/li>\n<li>Verify HSTS configuration (if used) and ensure it is not misapplied to temporary domains.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; A valid <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a> covers all active hostnames.<\/li>\n<li>&#x2610; HTTP requests redirect to HTTPS exactly once (no redirect chains or loops).<\/li>\n<li>&#x2610; A single canonical hostname is enforced for SEO consistency.<\/li>\n<\/ul>\n<p>If you discover browser warnings or mixed\u2011content issues, prioritise fixing SSL early. Our posts on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sertifika-hatalari-rehberi-mixed-content-not-secure-ve-tarayici-uyarilarini-hosting-tarafinda-cozmek\/\">common SSL certificate errors<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/\">full HTTP to HTTPS migration with 301 redirects and HSTS<\/a> can guide your remediation plan.<\/p>\n<h2><span id=\"Step_5_Performance_Caching_and_CDN\">Step 5 \u2013 Performance, Caching and CDN<\/span><\/h2>\n<h3><span id=\"51_Baseline_Performance_from_the_Server_Side\">5.1 Baseline Performance from the Server Side<\/span><\/h3>\n<p>Before changing code or design, capture how the current hosting responds:<\/p>\n<ul>\n<li>Measure TTFB (Time To First Byte) from multiple regions.<\/li>\n<li>Check CPU, RAM and disk IO usage during peak traffic times.<\/li>\n<li>Review web server and PHP error logs for slow queries, timeouts or 500 errors.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Identify whether slowness is due to hosting limits, database issues or application code.<\/li>\n<li>&#x2610; For WordPress \/ PHP sites, note if object cache (Redis\/Memcached) is enabled.<\/li>\n<li>&#x2610; Confirm if HTTP\/2 or HTTP\/3 (QUIC) is enabled on the server and CDN.<\/li>\n<\/ul>\n<p>Your audit does not need to fix everything immediately, but documenting baseline performance informs your future hosting choices, such as moving heavy stores to a VPS or dedicated server at dchost.com when needed.<\/p>\n<h3><span id=\"52_Caching_Layers_Application_Server_and_CDN\">5.2 Caching Layers: Application, Server and CDN<\/span><\/h3>\n<p>Inherited projects often have overlapping or conflicting cache layers. Identify:<\/p>\n<ul>\n<li>Application\u2011level caching (WordPress plugins, Laravel caching, Magento FPC).<\/li>\n<li>Server\u2011side caching (OPcache, PHP\u2011FPM settings, Nginx micro\u2011caching, Varnish).<\/li>\n<li>CDN caching rules (HTML caching, static assets, API paths excluded).<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Confirm which layer is responsible for HTML caching (server vs CDN vs plugin).<\/li>\n<li>&#x2610; Ensure admin areas, carts and checkouts bypass full\u2011page caches.<\/li>\n<li>&#x2610; Verify Cache\u2011Control headers, ETags and <code>stale-while-revalidate<\/code> policies are not contradictory.<\/li>\n<\/ul>\n<p>During onboarding, your goal is to understand the existing stack and spot critical misconfigurations (e.g. pages that should not be cached). Later, when you stabilise the site, you can apply more advanced tuning such as <a href=\"https:\/\/www.dchost.com\/blog\/en\/core-web-vitalsi-hosting-tarafinda-iyilestirmek\/\">server\u2011side Core Web Vitals improvements<\/a> or specialised <a href=\"https:\/\/www.dchost.com\/blog\/en\/tarayici-ve-cdn-onbellekleme-neden-bu-kadar-kritik\/\">HTTP cache\u2011control and CDN rules<\/a>.<\/p>\n<h3><span id=\"53_CDN_WAF_and_Edge_Configuration\">5.3 CDN, WAF and Edge Configuration<\/span><\/h3>\n<p>If the client already uses a CDN or WAF in front of the site, document:<\/p>\n<ul>\n<li>Which domains and subdomains are on the CDN.<\/li>\n<li>Whether the CDN is in full proxy mode (orange cloud style) or DNS\u2011only.<\/li>\n<li>Any custom page rules, caching rules or WAF rules that could affect new features.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Origin IPs noted for each CDN\u2011protected hostname.<\/li>\n<li>&#x2610; WAF level, rate\u2011limiting and bot protection settings documented.<\/li>\n<li>&#x2610; Any important firewall or WAF exceptions recorded to avoid breaking existing integrations.<\/li>\n<\/ul>\n<h2><span id=\"Step_6_Security_Backups_and_Disaster_Recovery\">Step 6 \u2013 Security, Backups and Disaster Recovery<\/span><\/h2>\n<h3><span id=\"61_HostingSide_Security_Basics\">6.1 Hosting\u2011Side Security Basics<\/span><\/h3>\n<p>As an agency, you might not own the infrastructure, but you are responsible for not leaving obvious doors open. During your audit, check:<\/p>\n<ul>\n<li>Is SSH access enabled with password login, or key\u2011based only?<\/li>\n<li>Is root login allowed directly on VPS\/dedicated servers?<\/li>\n<li>Is a firewall (ufw, firewalld, iptables\/nftables) configured?<\/li>\n<li>Are control panel logins protected with 2FA?<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; At minimum, disable direct root SSH login and enforce strong credentials.<\/li>\n<li>&#x2610; Ensure critical ports are restricted to necessary IPs where possible.<\/li>\n<li>&#x2610; For shared\/reseller hosting, confirm file permissions are sane (no world\u2011writable 777 folders).<\/li>\n<\/ul>\n<p>For clients hosted on VPS or dedicated servers with dchost.com, we can help you apply a hardened baseline similar to what we describe in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-pratik-olceklenebilir-ve-dogrulanabilir-yaklasimlar\/\">VPS security hardening guides<\/a>.<\/p>\n<h3><span id=\"62_Backup_Coverage_and_Recovery_Testing\">6.2 Backup Coverage and Recovery Testing<\/span><\/h3>\n<p>Backups are only useful if you know where they are, how often they run and how to restore them. Document for each project:<\/p>\n<ul>\n<li>What backup system is used: hosting panel backups, custom scripts, external object storage, etc.<\/li>\n<li>Backup frequency: daily, hourly, weekly.<\/li>\n<li>Retention: how many days\/weeks\/months kept.<\/li>\n<li>What is actually backed up: files, databases, email, DNS configs.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Confirm at least one off\u2011site backup exists (not only on the same server).<\/li>\n<li>&#x2610; Perform at least one test restore (to staging) to verify backups are actually usable.<\/li>\n<li>&#x2610; Document who is responsible for monitoring backup jobs (client, agency, hosting provider).<\/li>\n<\/ul>\n<p>At dchost.com, we strongly recommend a 3\u20112\u20111 approach: multiple copies, on different media and at least one off\u2011site. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">the 3\u20112\u20111 backup strategy and automation on cPanel\/Plesk\/VPS<\/a> can help you standardise this across clients.<\/p>\n<h3><span id=\"63_Simple_Disaster_Recovery_Plan\">6.3 Simple Disaster Recovery Plan<\/span><\/h3>\n<p>Even a one\u2011page DR outline is better than nothing. As part of your audit, sketch:<\/p>\n<ul>\n<li>Recovery objectives: acceptable downtime (RTO) and data loss window (RPO).<\/li>\n<li>Where you would restore if the current server is lost (another dchost.com VPS, different region, etc.).<\/li>\n<li>Critical dependencies: database servers, object storage, external APIs.<\/li>\n<\/ul>\n<p>Checklist:<\/p>\n<ul>\n<li>&#x2610; Agree a simple RTO\/RPO expectation with the client.<\/li>\n<li>&#x2610; Note which backups would be used and where they are stored.<\/li>\n<li>&#x2610; Keep DR notes in the same shared documentation as your audit.<\/li>\n<\/ul>\n<h2><span id=\"Step_7_Documentation_Standards_and_GoLive_Checklist_for_Agencies\">Step 7 \u2013 Documentation, Standards and Go\u2011Live Checklist for Agencies<\/span><\/h2>\n<h3><span id=\"71_Create_a_Living_Hosting_and_DNS_Sheet\">7.1 Create a Living Hosting and DNS Sheet<\/span><\/h3>\n<p>All your audit work is wasted if it lives only in your head. Standardise a template (spreadsheet, ticket system, or internal wiki) with sections like:<\/p>\n<ul>\n<li>Domain and registrar details (ownership, renewal dates, contacts).<\/li>\n<li>DNS provider, nameservers, exported record set with timestamp.<\/li>\n<li>Hosting details: type, plan, resources, location, control panel.<\/li>\n<li>Email topology: MX, SPF\/DKIM\/DMARC, key mailboxes.<\/li>\n<li>SSL\/TLS and redirect map (HTTP \u2192 HTTPS, www vs non\u2011www).<\/li>\n<li>Backups and DR notes.<\/li>\n<\/ul>\n<p>This becomes your single source of truth. Every time you change something (e.g. move hosting to a new dchost.com VPS), update the sheet and attach any migration notes.<\/p>\n<h3><span id=\"72_Standard_Agency_Rules_for_New_Clients\">7.2 Standard Agency Rules for New Clients<\/span><\/h3>\n<p>Use the audit findings to define your minimum standards for onboarding:<\/p>\n<ul>\n<li>All domains moved under client\u2011controlled registrar accounts, not personal accounts.<\/li>\n<li>2FA enabled on registrar, DNS and primary hosting accounts.<\/li>\n<li>DNS cleaned of dangling records and documented.<\/li>\n<li>SPF\/DKIM\/DMARC configured for the primary sending domain.<\/li>\n<li>HTTPS enforced, with a valid certificate and clean redirect logic.<\/li>\n<li>At least daily backups with one off\u2011site copy.<\/li>\n<\/ul>\n<p>These rules help you say \u201cno\u201d when a client asks for risky shortcuts. Over time, you will have a stable, predictable environment for all your projects.<\/p>\n<h3><span id=\"73_Plan_Future_Improvements_After_the_Audit\">7.3 Plan Future Improvements After the Audit<\/span><\/h3>\n<p>The audit itself should not block urgent projects, but it should generate a backlog of improvements, such as:<\/p>\n<ul>\n<li>Migrating from fragile shared hosting to a right\u2011sized VPS or dedicated server.<\/li>\n<li>Consolidating multiple small hosting accounts into an agency\u2011managed stack.<\/li>\n<li>Implementing staging environments for complex sites.<\/li>\n<li>Upgrading outdated PHP\/DB versions in a controlled manner.<\/li>\n<\/ul>\n<p>Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ajanslar-ve-freelancerlar-icin-hosting-mimarisi-20-wordpress-sitesini-tek-altyapida-guvenle-yonetmek\/\">hosting architecture for agencies managing 20+ WordPress sites<\/a> shows how to turn those individual checklists into a coherent, scalable platform.<\/p>\n<h2><span id=\"Turning_Your_Checklist_into_a_Repeatable_Onboarding_Process_with_dchostcom\">Turning Your Checklist into a Repeatable Onboarding Process with dchost.com<\/span><\/h2>\n<p>Once you have run this hosting and DNS audit for a few clients, patterns emerge. You see the same weak points: domains split across old registrars, DNS panels nobody remembers, shared hosting with no backups, email authentication missing, or SSL cobbled together from multiple providers. The goal is not to make every client\u2019s infrastructure identical, but to bring each one up to a stable, well\u2011documented baseline where your team can move quickly without fear of \u201cbreaking the internet\u201d.<\/p>\n<p>At dchost.com, we work with many agencies that have formalised this exact process. They use a simple audit to decide when to leave existing hosting in place, when to move to an agency reseller plan, and when a dedicated VPS or physical server (or even colocation) makes more sense for performance or compliance reasons. Because we also provide domains and DNS hosting, you can gradually centralise key pieces under one roof while still keeping clear lines of ownership for your clients.<\/p>\n<p>If you want help adapting this checklist to your agency\u2019s workflow or planning a safe migration path from a messy legacy stack, our team is happy to share real\u2011world examples from projects we host. Start with one new client: run through the audit, document everything, and then refine the template. Within a few months, onboarding a new website will feel routine instead of risky\u2014and you will spend your time on strategy, design and growth, not on emergency DNS detective work.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When an agency takes over a website, the riskiest part is rarely the design or content. It is the messy combination of domains, DNS, email routing and half-documented hosting that has grown over years. If you do not standardise how you audit these pieces on day one, you inherit every hidden problem: broken email, slow [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3897,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3896","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\/3896","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=3896"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3896\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3897"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3896"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3896"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3896"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}