{"id":4635,"date":"2026-02-06T19:47:18","date_gmt":"2026-02-06T16:47:18","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/404-management-on-hosting-and-dns-301-redirects-soft-404s-and-real-fixes\/"},"modified":"2026-02-06T19:47:18","modified_gmt":"2026-02-06T16:47:18","slug":"404-management-on-hosting-and-dns-301-redirects-soft-404s-and-real-fixes","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/404-management-on-hosting-and-dns-301-redirects-soft-404s-and-real-fixes\/","title":{"rendered":"404 Management on Hosting and DNS: 301 Redirects, Soft 404s and Real Fixes"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>404 errors look harmless at first glance: a user hits an old URL, your server says \u201cNot Found\u201d, they go back to search results. But when you look at this from a hosting and DNS perspective, unmanaged 404s quietly waste crawl budget, confuse search engines, hide real bugs in your stack, and make migrations far riskier than they need to be. In many audits we run at dchost.com, a messy 404\/redirect situation is one of the first issues we spot in server logs, especially after domain changes, HTTPS migrations or large content refactors. The good news: with a bit of structure, you can turn 404 management into a predictable, almost boring part of your operations. In this article we will walk through how 404s actually happen on hosting and DNS, the difference between real and soft 404 errors, how to fix broken links with clean 301 redirects, and how to avoid the subtle pitfalls that keep returning in SEO reports.<\/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=\"#404_Soft_404_and_DNS_Errors_Whats_Really_Going_On\"><span class=\"toc_number toc_depth_1\">1<\/span> 404, Soft 404 and DNS Errors: What\u2019s Really Going On?<\/a><ul><li><a href=\"#HTTP_404_vs_DNS-Level_Errors\"><span class=\"toc_number toc_depth_2\">1.1<\/span> HTTP 404 vs DNS-Level Errors<\/a><\/li><li><a href=\"#What_Is_a_Soft_404\"><span class=\"toc_number toc_depth_2\">1.2<\/span> What Is a Soft 404?<\/a><\/li><li><a href=\"#Other_Relevant_Status_Codes_301_302_410_and_503\"><span class=\"toc_number toc_depth_2\">1.3<\/span> Other Relevant Status Codes: 301, 302, 410 and 503<\/a><\/li><\/ul><\/li><li><a href=\"#Common_Real-World_Causes_of_404s_on_Hosting_and_DNS\"><span class=\"toc_number toc_depth_1\">2<\/span> Common Real-World Causes of 404s on Hosting and DNS<\/a><ul><li><a href=\"#1_URL_Structure_Changes_and_Content_Refactors\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1. URL Structure Changes and Content Refactors<\/a><\/li><li><a href=\"#2_HTTP_to_HTTPS_and_www_non-www_Canonicals\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2. HTTP to HTTPS and www \/ non-www Canonicals<\/a><\/li><li><a href=\"#3_Domain_Subdomain_and_Brand_Changes\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 3. Domain, Subdomain and Brand Changes<\/a><\/li><li><a href=\"#4_DNS_Misconfigurations_and_Expired_Domains\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 4. DNS Misconfigurations and Expired Domains<\/a><\/li><li><a href=\"#5_Application-Level_Edge_Cases\"><span class=\"toc_number toc_depth_2\">2.5<\/span> 5. Application-Level Edge Cases<\/a><\/li><\/ul><\/li><li><a href=\"#Why_404_Management_Matters_for_SEO_UX_and_Infrastructure\"><span class=\"toc_number toc_depth_1\">3<\/span> Why 404 Management Matters for SEO, UX and Infrastructure<\/a><\/li><li><a href=\"#Finding_404_and_Soft_404_Problems_on_Your_Hosting\"><span class=\"toc_number toc_depth_1\">4<\/span> Finding 404 and Soft 404 Problems on Your Hosting<\/a><ul><li><a href=\"#1_Reading_Web_Server_Logs\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Reading Web Server Logs<\/a><\/li><li><a href=\"#2_Google_Search_Console_and_Analytics\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Google Search Console and Analytics<\/a><\/li><li><a href=\"#3_Crawlers_and_Automated_Checks\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Crawlers and Automated Checks<\/a><\/li><li><a href=\"#4_During_Migrations_and_Deployments\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. During Migrations and Deployments<\/a><\/li><\/ul><\/li><li><a href=\"#Fixing_Broken_Links_with_Smart_301_Redirects\"><span class=\"toc_number toc_depth_1\">5<\/span> Fixing Broken Links with Smart 301 Redirects<\/a><ul><li><a href=\"#When_to_Use_301_vs_410_vs_Leaving_a_404\"><span class=\"toc_number toc_depth_2\">5.1<\/span> When to Use 301 vs 410 vs Leaving a 404<\/a><\/li><li><a href=\"#Designing_a_Redirect_Strategy\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Designing a Redirect Strategy<\/a><\/li><li><a href=\"#Implementing_301s_on_Apache_htaccess\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Implementing 301s on Apache (.htaccess)<\/a><\/li><li><a href=\"#Implementing_301s_on_Nginx\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Implementing 301s on Nginx<\/a><\/li><li><a href=\"#Redirects_vs_DNS_What_Goes_Where\"><span class=\"toc_number toc_depth_2\">5.5<\/span> Redirects vs DNS: What Goes Where?<\/a><\/li><\/ul><\/li><li><a href=\"#Avoiding_Soft_404_Errors_on_Hosting_and_DNS\"><span class=\"toc_number toc_depth_1\">6<\/span> Avoiding Soft 404 Errors on Hosting and DNS<\/a><ul><li><a href=\"#1_Make_Sure_Error_Pages_Return_the_Correct_Status\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. Make Sure Error Pages Return the Correct Status<\/a><\/li><li><a href=\"#2_Dont_Turn_Every_Problem_into_a_200_OK\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Don\u2019t Turn Every Problem into a 200 OK<\/a><\/li><li><a href=\"#3_Handle_Maintenance_and_Outages_with_503_Not_404\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Handle Maintenance and Outages with 503, Not 404<\/a><\/li><li><a href=\"#4_Avoid_Long_Redirect_Chains_and_Loops\"><span class=\"toc_number toc_depth_2\">6.4<\/span> 4. Avoid Long Redirect Chains and Loops<\/a><\/li><\/ul><\/li><li><a href=\"#DNS_and_Multi-Domain_Strategy_for_Clean_404_Management\"><span class=\"toc_number toc_depth_1\">7<\/span> DNS and Multi-Domain Strategy for Clean 404 Management<\/a><ul><li><a href=\"#1_Parked_Domains_and_Canonical_Targets\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Parked Domains and Canonical Targets<\/a><\/li><li><a href=\"#2_Cleaning_Up_Old_Subdomains_and_Dangling_DNS\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Cleaning Up Old Subdomains and Dangling DNS<\/a><\/li><li><a href=\"#3_Sitemaps_robotstxt_and_404_Hygiene\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Sitemaps, robots.txt and 404 Hygiene<\/a><\/li><\/ul><\/li><li><a href=\"#What_We_Focus_on_at_dchostcom_and_How_You_Can_Adopt_the_Same_Habits\"><span class=\"toc_number toc_depth_1\">8<\/span> What We Focus on at dchost.com (and How You Can Adopt the Same Habits)<\/a><\/li><\/ul><\/div>\n<h2><span id=\"404_Soft_404_and_DNS_Errors_Whats_Really_Going_On\">404, Soft 404 and DNS Errors: What\u2019s Really Going On?<\/span><\/h2>\n<h3><span id=\"HTTP_404_vs_DNS-Level_Errors\">HTTP 404 vs DNS-Level Errors<\/span><\/h3>\n<p>First, a key distinction: a <strong>404 error is an HTTP status code<\/strong> returned by your web server (Apache, Nginx, LiteSpeed, etc.). It means: \u201cThe domain resolved correctly, a web server answered, but this specific path does not exist here.\u201d<\/p>\n<p>By contrast, <strong>DNS-level errors<\/strong> like <em>NXDOMAIN<\/em> happen before any HTTP conversation starts. When a user sees \u201cThis site can\u2019t be reached\u201d or <code>DNS_PROBE_FINISHED_NXDOMAIN<\/code>, the browser couldn\u2019t find a valid IP for the domain or subdomain. That\u2019s a DNS problem, not a 404. If you need a refresher on this layer, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-nedir-a-aaaa-cname-mx-txt-ve-srv-rehberi\/\">what DNS records are and how A, AAAA and CNAME work<\/a> is a good background read.<\/p>\n<h3><span id=\"What_Is_a_Soft_404\">What Is a Soft 404?<\/span><\/h3>\n<p>A <strong>soft 404<\/strong> is not an official HTTP status, but a term used by search engines (especially Google Search Console) for pages that:<\/p>\n<ul>\n<li>Return HTTP <strong>200 OK<\/strong> (or sometimes a redirect), <strong>but<\/strong><\/li>\n<li>Contain content that clearly says something like \u201cPage not found\u201d, \u201cThis product is unavailable\u201d, or otherwise has <strong>very little or no useful content<\/strong>.<\/li>\n<\/ul>\n<p>From a browser\u2019s point of view everything is fine: it got a 200 response. From a crawler\u2019s point of view, this is misleading. The page looks like an error page pretending to be normal content, so it\u2019s treated as a <strong>soft 404<\/strong>. These often appear when developers implement custom 404 pages but forget to set the proper status code, or when they remove many products\/posts and leave thin stub pages behind.<\/p>\n<h3><span id=\"Other_Relevant_Status_Codes_301_302_410_and_503\">Other Relevant Status Codes: 301, 302, 410 and 503<\/span><\/h3>\n<p>404 management is never just about 404. The broader picture includes:<\/p>\n<ul>\n<li><strong>301 Moved Permanently<\/strong>: permanent redirect; tells browsers and search engines that a URL has a new canonical home.<\/li>\n<li><strong>302 \/ 307 Temporary Redirect<\/strong>: short-term move; the old URL might be back later.<\/li>\n<li><strong>410 Gone<\/strong>: the resource is deliberately and permanently removed with no replacement.<\/li>\n<li><strong>503 Service Unavailable<\/strong> (with <code>Retry-After<\/code>): planned maintenance or temporary overload, not a 404.<\/li>\n<\/ul>\n<p>For a deeper dive into how these codes impact indexing and performance, you can check our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-durum-kodlari-seo-ve-hosting-icin-301-302-404-410-ve-5xx-rehberi\/\">what HTTP status codes mean for SEO and hosting<\/a>. In this article we\u2019ll focus on when and how to choose between 404, 301 and 410 in real infrastructure.<\/p>\n<h2><span id=\"Common_Real-World_Causes_of_404s_on_Hosting_and_DNS\">Common Real-World Causes of 404s on Hosting and DNS<\/span><\/h2>\n<h3><span id=\"1_URL_Structure_Changes_and_Content_Refactors\">1. URL Structure Changes and Content Refactors<\/span><\/h3>\n<p>One of the most common reasons we see for 404 growth is a big content restructure: changing a blog from <code>\/2024\/02\/post-name<\/code> to <code>\/blog\/post-name<\/code>, moving a store from <code>\/shop\/<\/code> to <code>\/store\/<\/code>, or renaming category slugs. From the CMS side it feels like \u201cjust updating permalinks\u201d. From the outside world, thousands of old links from Google, social media, newsletters and partner sites suddenly break unless you put <strong>301 redirects<\/strong> in place.<\/p>\n<p>This is exactly the scenario where pattern-based redirect rules shine. We covered this in depth, with concrete <code>.htaccess<\/code> and Nginx examples, in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/seo-kaybi-olmadan-url-yapisini-degistirmek-htaccess-ve-nginx-301-yonlendirme-rehberi\/\">changing URL structure safely with 301 redirects<\/a>. When you plan ahead, you can migrate entire sections without a spike in 404s or SEO loss.<\/p>\n<h3><span id=\"2_HTTP_to_HTTPS_and_www_non-www_Canonicals\">2. HTTP to HTTPS and www \/ non-www Canonicals<\/span><\/h3>\n<p>Another classic source of redirects and 404s is the move from <code>http:\/\/<\/code> to <code>https:\/\/<\/code>, or choosing a canonical hostname like <code>www.example.com<\/code> instead of <code>example.com<\/code>. If this is misconfigured, you can end up with loops (more on that later) or stray URLs that don\u2019t redirect to the secure canonical version at all.<\/p>\n<p>The correct approach is usually:<\/p>\n<ul>\n<li>Choose a single canonical hostname (<code>www<\/code> or bare domain).<\/li>\n<li>Serve HTTPS there as the primary version.<\/li>\n<li>Use 301 redirects from all other variants (http \u2192 https, non-www \u2192 www or vice versa).<\/li>\n<\/ul>\n<p>If you\u2019re planning a full HTTPS move, we strongly recommend following a structured process like in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpsye-gecis-rehberi-seo-kayipsiz-ssl-migrasyonu-hsts-ve-canonical-ayarlari\/\">HTTP to HTTPS migration guide with HSTS and canonical settings<\/a>. A clean HTTPS migration often reduces 404 chaos dramatically.<\/p>\n<h3><span id=\"3_Domain_Subdomain_and_Brand_Changes\">3. Domain, Subdomain and Brand Changes<\/span><\/h3>\n<p>When a brand changes its main domain, introduces language subdomains, or merges sites, it\u2019s easy to create thousands of broken links if the migration is handled only at DNS level (changing nameservers or A records) without planning HTTP redirects.<\/p>\n<p>Typical patterns include:<\/p>\n<ul>\n<li>Moving from <code>oldbrand.com<\/code> to <code>newbrand.com<\/code> without 301s.<\/li>\n<li>Turning <code>blog.example.com<\/code> into <code>example.com\/blog\/<\/code>.<\/li>\n<li>Retiring old country domains and consolidating into a single global site.<\/li>\n<\/ul>\n<p>DNS alone cannot send a browser to a new URL path; it only translates names to IPs. Without well-thought-out redirect rules on the web server, you will see a flood of 404s. If you\u2019re planning to consolidate multiple domains, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/birden-fazla-alan-adini-ayni-siteye-yonlendirmek-seo-301-canonical-ve-park-alan-adi-stratejileri\/\">pointing multiple domains to one website with 301 redirects and canonical settings<\/a> is an excellent reference.<\/p>\n<h3><span id=\"4_DNS_Misconfigurations_and_Expired_Domains\">4. DNS Misconfigurations and Expired Domains<\/span><\/h3>\n<p>Sometimes the problem isn\u2019t the web app at all; it\u2019s DNS. We frequently see:<\/p>\n<ul>\n<li>Domains pointing to the wrong server IP after a migration.<\/li>\n<li>Subdomains left with stale A\/AAAA records to servers that no longer host the site.<\/li>\n<li>CNAME chains pointing to decommissioned hosts.<\/li>\n<li>Domains that simply expired or were transferred without copying DNS records.<\/li>\n<\/ul>\n<p>In these cases, users often see browser-level errors (NXDOMAIN, timeouts) instead of a clean 404 page. From an operations point of view, those are worse, because you have no chance to present a helpful error page or redirect. That\u2019s why we emphasise DNS reviews in every migration and recommend using a checklist like in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/ajanslar-icin-yeni-musteri-hosting-ve-dns-altyapisi-kontrol-listesi\/\">hosting and DNS audit checklist for new clients<\/a>.<\/p>\n<h3><span id=\"5_Application-Level_Edge_Cases\">5. Application-Level Edge Cases<\/span><\/h3>\n<p>Finally, some 404s come from application logic:<\/p>\n<ul>\n<li>Dynamic routes that assume an ID or slug exists in the database.<\/li>\n<li>Filters and pagination that generate invalid URLs when parameters are missing.<\/li>\n<li>Search pages that show \u201cno results\u201d but still return HTTP 200 with almost no content, triggering soft 404s.<\/li>\n<\/ul>\n<p>These are best fixed jointly by developers and ops: the app should explicitly return 404 or 410 when something is truly missing, and your web server should provide a solid fallback 404 page for any paths the app doesn\u2019t recognise.<\/p>\n<h2><span id=\"Why_404_Management_Matters_for_SEO_UX_and_Infrastructure\">Why 404 Management Matters for SEO, UX and Infrastructure<\/span><\/h2>\n<p>Let\u2019s be clear: <strong>some 404s are normal<\/strong>. Users mistype URLs, old links from third-party sites linger forever, bots crawl random paths. That\u2019s fine. The problem is <strong>uncontrolled 404 growth<\/strong> and <strong>soft 404 patterns<\/strong> that signal deeper issues.<\/p>\n<ul>\n<li><strong>SEO impact:<\/strong> Search engines waste crawl budget on useless URLs, miss your important new pages, or drop them because signals are diluted between old and new URLs.<\/li>\n<li><strong>User experience:<\/strong> Broken links from your own menus, sitemaps or emails frustrate visitors and reduce conversions.<\/li>\n<li><strong>Monitoring noise:<\/strong> Real problems (like 500 errors) get buried under thousands of avoidable 404s in logs and dashboards.<\/li>\n<li><strong>Migration risk:<\/strong> Domain or URL changes become much riskier if you can\u2019t predict how 404s and 301s will behave.<\/li>\n<\/ul>\n<p>Our aim at dchost.com is not to chase zero 404s\u2014that\u2019s unrealistic\u2014but to build a <strong>clean, intentional 404\/301\/410 strategy<\/strong> so that every missing URL has a clear reason and behaviour.<\/p>\n<h2><span id=\"Finding_404_and_Soft_404_Problems_on_Your_Hosting\">Finding 404 and Soft 404 Problems on Your Hosting<\/span><\/h2>\n<h3><span id=\"1_Reading_Web_Server_Logs\">1. Reading Web Server Logs<\/span><\/h3>\n<p>On a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>, your most honest source of truth is the <strong>access log<\/strong>. For example, on Apache you might see:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">&quot;GET \/old-blog\/post-123 HTTP\/1.1&quot; 404 512 &quot;-&quot; &quot;Mozilla\/5.0 ...&quot;<\/code><\/pre>\n<p>The <code>404<\/code> in the status field is what you\u2019re hunting for. You can quickly count top 404 URLs with tools like <code>grep<\/code> and <code>awk<\/code>, or more advanced log analysis stacks. If you want a refresher on reading log formats and diagnosing HTTP errors, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-sunucu-loglarini-okumayi-ogrenin-apache-ve-nginx-ile-4xx-5xx-hatalarini-teshis-rehberi\/\">how to read web server logs to find 4xx\u20135xx errors<\/a>.<\/p>\n<h3><span id=\"2_Google_Search_Console_and_Analytics\">2. Google Search Console and Analytics<\/span><\/h3>\n<p>Google Search Console (GSC) is especially useful for <strong>soft 404s<\/strong>. In the Indexing reports, it explicitly lists URLs considered soft 404, based on both response codes and page content. If you see many URLs there, you likely have one of these issues:<\/p>\n<ul>\n<li>Error pages returning 200 instead of 404.<\/li>\n<li>Very thin category or product pages.<\/li>\n<li>Redirect chains ending on empty or irrelevant pages.<\/li>\n<\/ul>\n<p>Web analytics tools (GA4, Matomo, etc.) are also helpful: create a report filtered by <code>page title contains \"404\"<\/code> or by the 404 template URL. That shows which missing URLs actual users hit, not just bots.<\/p>\n<h3><span id=\"3_Crawlers_and_Automated_Checks\">3. Crawlers and Automated Checks<\/span><\/h3>\n<p>SEO crawlers (Screaming Frog, Sitebulb, etc.) simulate a search engine crawling your site and report 404s, redirect chains and soft 404-like patterns. These are great when you\u2019re planning a migration: crawl the old site, export all URLs, then ensure each one has a defined destination (301, 404, or 410) on the new infrastructure.<\/p>\n<h3><span id=\"4_During_Migrations_and_Deployments\">4. During Migrations and Deployments<\/span><\/h3>\n<p>We advise treating 404 behaviour as an explicit checklist item for any big change: new theme, URL refactor, domain change, or platform migration. A simple but effective approach:<\/p>\n<ol>\n<li>List key URLs (home, categories, best-sellers, top blog posts, landing pages).<\/li>\n<li>Test them before and after cutover, following all redirects until the final destination.<\/li>\n<li>Record the final status code (should be 200, 301 or 302; never 404 for key pages).<\/li>\n<li>Watch logs for spikes in 404 shortly after deployment.<\/li>\n<\/ol>\n<p>This is also where well-tuned DNS and TTL planning help; if you want to go deeper on that side, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">TTL strategies for zero-downtime migrations<\/a> is a good complement to this 404-focused view.<\/p>\n<h2><span id=\"Fixing_Broken_Links_with_Smart_301_Redirects\">Fixing Broken Links with Smart 301 Redirects<\/span><\/h2>\n<h3><span id=\"When_to_Use_301_vs_410_vs_Leaving_a_404\">When to Use 301 vs 410 vs Leaving a 404<\/span><\/h3>\n<p>Not every missing URL deserves a redirect. A simple rule of thumb:<\/p>\n<ul>\n<li><strong>Use 301<\/strong> when there is a <strong>clear, permanent replacement<\/strong> that satisfies the same intent (e.g. a product moved to a new slug, a blog post relocated under a different category).<\/li>\n<li><strong>Use 410<\/strong> when the content is deliberately removed and has no equivalent (e.g. a legal notice that no longer applies, a discontinued product line you don\u2019t want indexed anymore).<\/li>\n<li><strong>Leave 404<\/strong> when the URL was never real or is obviously garbage (bots probing random paths).<\/li>\n<\/ul>\n<p>Abusing 301s (\u201ceverything 301s to the homepage\u201d) is almost as bad as leaving everything broken. Search engines may treat such redirects as soft 404s if the target page is irrelevant.<\/p>\n<h3><span id=\"Designing_a_Redirect_Strategy\">Designing a Redirect Strategy<\/span><\/h3>\n<p>Before touching configuration files, map out your redirects:<\/p>\n<ol>\n<li><strong>One-to-one redirects:<\/strong> Specific high-value URLs (top blog posts, landing pages, campaign URLs) should have precise 301 rules to their new equivalents.<\/li>\n<li><strong>Pattern-based redirects:<\/strong> For large structural changes (e.g. <code>\/blog\/old-slug<\/code> \u2192 <code>\/blog\/new-slug<\/code> with predictable patterns).<\/li>\n<li><strong>Fallback behaviour:<\/strong> Define what to do when no redirect rule matches: usually a well-designed 404 page with helpful links.<\/li>\n<\/ol>\n<p>For big refactors, we often combine both: pattern rules handle 95% of URLs, and a small manual mapping file covers the highly linked or unusual ones.<\/p>\n<h3><span id=\"Implementing_301s_on_Apache_htaccess\">Implementing 301s on Apache (.htaccess)<\/span><\/h3>\n<p>On shared hosting or Apache-based VPS setups, <code>.htaccess<\/code> is a common place to configure redirects. A simple one-to-one rule:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Redirect 301 \/old-page\/ https:\/\/www.example.com\/new-page\/<\/code><\/pre>\n<p>Pattern-based with <code>mod_rewrite<\/code> might look like:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">RewriteEngine On\n# Move all posts from \/old-blog\/ to \/blog\/\nRewriteRule ^old-blog\/(.*)$ \/blog\/$1 [R=301,L]<\/code><\/pre>\n<p>Always test rules on a staging environment when possible, and make sure you don\u2019t accidentally create loops (e.g. rule A sending to URL B, while rule B sends back to URL A).<\/p>\n<h3><span id=\"Implementing_301s_on_Nginx\">Implementing 301s on Nginx<\/span><\/h3>\n<p>On Nginx, redirects are typically placed in the <code>server<\/code> block configuration. A basic example:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">server {\n    listen 80;\n    server_name old.example.com;\n    return 301 https:\/\/new.example.com$request_uri;\n}<\/code><\/pre>\n<p>And a path-only rewrite:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">location \/old-blog\/ {\n    return 301 \/blog\/$request_uri;\n}<\/code><\/pre>\n<p>Or, for a more flexible pattern:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">location ~ ^\/old-blog\/(.*)$ {\n    return 301 \/blog\/$1;\n}<\/code><\/pre>\n<p>After updating Nginx, always <code>nginx -t<\/code> to test the configuration before reloading.<\/p>\n<h3><span id=\"Redirects_vs_DNS_What_Goes_Where\">Redirects vs DNS: What Goes Where?<\/span><\/h3>\n<p>It\u2019s important not to mix roles:<\/p>\n<ul>\n<li><strong>DNS<\/strong> maps domains\/subdomains to IPs or other hostnames (via A\/AAAA\/CNAME). It cannot say \u201cthis URL moved to <code>\/new-page<\/code>\u201d.<\/li>\n<li><strong>HTTP redirects<\/strong> (301\/302) happen in the web server or application. They know about paths and can implement complex logic.<\/li>\n<\/ul>\n<p>If you want <code>oldbrand.com\/path<\/code> to redirect to <code>newbrand.com\/new-path<\/code>, DNS should point <code>oldbrand.com<\/code> to a web server that knows how to handle that redirect. Trying to \u201cdo redirects in DNS\u201d with CNAMEs usually leads to confusion, and in many cases isn\u2019t even allowed at the zone apex.<\/p>\n<h2><span id=\"Avoiding_Soft_404_Errors_on_Hosting_and_DNS\">Avoiding Soft 404 Errors on Hosting and DNS<\/span><\/h2>\n<h3><span id=\"1_Make_Sure_Error_Pages_Return_the_Correct_Status\">1. Make Sure Error Pages Return the Correct Status<\/span><\/h3>\n<p>The most common soft 404 pattern we see is a beautiful custom 404 page that still returns <strong>HTTP 200<\/strong>. From a design perspective it looks perfect; from SEO\u2019s perspective, it\u2019s a lie.<\/p>\n<p>On Apache, you typically set:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ErrorDocument 404 \/custom-404.html<\/code><\/pre>\n<p>Make sure your custom 404 file does <strong>not<\/strong> override the status. The web server should send 404, while the user sees your styled error page. On Nginx:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">error_page 404 \/custom-404.html;\nlocation = \/custom-404.html {\n    internal;\n}<\/code><\/pre>\n<p>In both cases, confirm with curl or your browser\u2019s developer tools that the final response code is 404, not 200.<\/p>\n<h3><span id=\"2_Dont_Turn_Every_Problem_into_a_200_OK\">2. Don\u2019t Turn Every Problem into a 200 OK<\/span><\/h3>\n<p>Some frameworks or themes try to be too \u201chelpful\u201d: if a product is missing, they show a generic \u201cproduct not found\u201d block on a normal template and still return 200. Or they display category pages with no products and almost no content. Google often flags these as soft 404s.<\/p>\n<p>Better patterns include:<\/p>\n<ul>\n<li>If the specific item truly does not exist anymore, return 404 or 410.<\/li>\n<li>If possible, suggest <strong>related items<\/strong> or <strong>closest alternative pages<\/strong> and use 301 to those, provided the intent is really similar.<\/li>\n<li>For empty categories, provide substantial, useful content explaining the situation and linking to relevant alternatives, or deindex them if they aren\u2019t meant to be landing pages.<\/li>\n<\/ul>\n<h3><span id=\"3_Handle_Maintenance_and_Outages_with_503_Not_404\">3. Handle Maintenance and Outages with 503, Not 404<\/span><\/h3>\n<p>During planned maintenance, some sites mistakenly serve 404 or 200 with a \u201cSite under maintenance\u201d message. Both are misleading for crawlers. The correct status is <strong>503 Service Unavailable<\/strong> with a <code>Retry-After<\/code> header, which clearly tells search engines: \u201cThis is temporary, come back later.\u201d<\/p>\n<p>We\u2019ve written a full guide on how to do this without hurting rankings or UX in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/bakim-modu-ve-planli-kesinti-yonetimi-seo-kaybi-yasamadan-maintenance-page-yayinlama-rehberi\/\">maintenance windows and downtime pages for SEO-safe outages<\/a>. Following that playbook helps you avoid sudden waves of soft 404 and indexing issues after maintenance.<\/p>\n<h3><span id=\"4_Avoid_Long_Redirect_Chains_and_Loops\">4. Avoid Long Redirect Chains and Loops<\/span><\/h3>\n<p>Soft 404s sometimes show up at the end of messy redirect chains. For example:<\/p>\n<ol>\n<li><code>\/old-product<\/code> \u2192 301 \u2192 <code>\/product<\/code><\/li>\n<li><code>\/product<\/code> \u2192 302 \u2192 <code>\/product?ref=abc<\/code><\/li>\n<li><code>\/product?ref=abc<\/code> \u2192 301 \u2192 <code>\/shop\/product<\/code><\/li>\n<\/ol>\n<p>Even if the final URL returns 200, crawlers may treat this as low-quality or ambiguous, especially if the target content is thin. Best practices:<\/p>\n<ul>\n<li>Ensure <strong>no more than one hop<\/strong> for the majority of redirects.<\/li>\n<li>Update older rules so they point directly to the current canonical URL.<\/li>\n<li>Periodically crawl your site to detect chains and loops and clean them up.<\/li>\n<\/ul>\n<h2><span id=\"DNS_and_Multi-Domain_Strategy_for_Clean_404_Management\">DNS and Multi-Domain Strategy for Clean 404 Management<\/span><\/h2>\n<h3><span id=\"1_Parked_Domains_and_Canonical_Targets\">1. Parked Domains and Canonical Targets<\/span><\/h3>\n<p>Many businesses own multiple domains: typos, legacy brand names, ccTLDs, and marketing domains. If these just show a blank parking page or redirect everything to the homepage, you\u2019re missing an opportunity to control UX and SEO.<\/p>\n<p>A better pattern is:<\/p>\n<ul>\n<li>Point all auxiliary domains via DNS to a small web server configuration.<\/li>\n<li>Implement <strong>301 redirects<\/strong> at HTTP level to the main canonical site (preserving paths where relevant).<\/li>\n<li>Use consistent canonical tags so search engines understand which domain is primary.<\/li>\n<\/ul>\n<p>We go deeper into these decisions\u2014including when to keep parked domains truly parked vs actively redirected\u2014in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/park-alan-adlari-nasil-yonetilir-parking-301-ve-canonical-icin-uygulanabilir-stratejiler\/\">how to manage parked domains without hurting SEO<\/a>.<\/p>\n<h3><span id=\"2_Cleaning_Up_Old_Subdomains_and_Dangling_DNS\">2. Cleaning Up Old Subdomains and Dangling DNS<\/span><\/h3>\n<p>Over the years, projects accumulate test subdomains, old microsites, staging environments and forgotten apps. From a DNS point of view, they may still exist and point to IPs that no longer serve valid content, resulting in strange 404s or worse, error pages from unrelated services.<\/p>\n<p>We recommend a periodic inventory:<\/p>\n<ul>\n<li>List all A, AAAA and CNAME records in your DNS zones.<\/li>\n<li>Check each subdomain in a browser and via curl.<\/li>\n<li>Either remove unused records or implement clean 301\/302 or proper 404\/410 responses on a controlled server.<\/li>\n<\/ul>\n<p>This is not only good hygiene for 404 management; it\u2019s also a security practice, reducing the chance of subdomain takeover on abandoned hostnames.<\/p>\n<h3><span id=\"3_Sitemaps_robotstxt_and_404_Hygiene\">3. Sitemaps, robots.txt and 404 Hygiene<\/span><\/h3>\n<p>Your <code>sitemap.xml<\/code> and <code>robots.txt<\/code> are effectively public declarations of what you consider to be \u201creal\u201d URLs on your site. If the sitemap still lists URLs that now return 404 or soft 404, crawlers will keep hitting them.<\/p>\n<p>After big migrations or cleanups, regenerate sitemaps to include only live, indexable URLs. Also ensure <code>robots.txt<\/code> does not accidentally block access to your 404 page or important redirect destinations. We cover these details more thoroughly in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/robots-txt-ve-sitemap-xml-dogru-kurulumu-adim-adim-seo-ve-hosting-rehberi\/\">setting up robots.txt and sitemap.xml correctly for SEO and hosting<\/a>.<\/p>\n<h2><span id=\"What_We_Focus_on_at_dchostcom_and_How_You_Can_Adopt_the_Same_Habits\">What We Focus on at dchost.com (and How You Can Adopt the Same Habits)<\/span><\/h2>\n<p>From our perspective as a hosting provider, 404 management sits at the intersection of <strong>DNS, web server configuration and application logic<\/strong>. When we help customers with migrations or troubleshoot ranking drops, our approach usually follows this order:<\/p>\n<ol>\n<li><strong>DNS sanity check:<\/strong> Confirm all relevant domains and subdomains point to the right IPs and that there are no obvious NXDOMAIN or misrouted traffic issues.<\/li>\n<li><strong>Log-based 404 review:<\/strong> Analyse access logs for frequent 404s, group by URL patterns, and identify whether they come from external links, internal links or bots.<\/li>\n<li><strong>Redirect mapping:<\/strong> For important or heavily linked URLs, define explicit 301s. For obviously junk URLs, keep a clean 404.<\/li>\n<li><strong>Status code correctness:<\/strong> Ensure custom error pages really return 404, maintenance pages return 503, and content moves use 301.<\/li>\n<li><strong>Soft 404 audit:<\/strong> Use GSC and crawlers to identify soft 404 patterns, then adjust templates, content and HTTP codes accordingly.<\/li>\n<\/ol>\n<p>You can adopt the same flow regardless of where you host, but if you\u2019re on our shared hosting, VPS, dedicated or colocation services, our team is used to working through these steps with real log data and your application stack. Clean 404 management is not about perfection; it\u2019s about removing surprises from your infrastructure.<\/p>\n<p>If you\u2019re planning a domain change, HTTPS migration or a large content refactor and want to avoid a mess of broken links and soft 404 warnings, it\u2019s worth treating 404 management as a first-class part of your project plan, not an afterthought. Map your URLs, design your redirects, fix your status codes, and let DNS, hosting and application work together. That way, search engines, users and your monitoring tools all see a consistent, predictable picture\u2014and you can ship changes with confidence.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>404 errors look harmless at first glance: a user hits an old URL, your server says \u201cNot Found\u201d, they go back to search results. But when you look at this from a hosting and DNS perspective, unmanaged 404s quietly waste crawl budget, confuse search engines, hide real bugs in your stack, and make migrations far [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4636,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4635","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\/4635","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=4635"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4635\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4636"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4635"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4635"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4635"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}