When your browser hits a 404, it means the server is responding fine \u2014 it just can’t find what you asked for at that URL. The server is alive. The specific page or file is not. That distinction matters when you’re trying to figure out what to fix.<\/p>\n
HTTP 404 (Not Found) means the server received your request and understood it, but couldn’t find the resource at the address you gave it. This is different from a 503 (server offline or overloaded) or a connection timeout (server completely unreachable). If you’re seeing 404, the site itself is functioning \u2014 the problem is with the specific URL.<\/p>\n
From a visitor’s perspective: a “Page Not Found” message and a dead end. From a site owner’s perspective: a broken request that’s worth investigating, because it’s either a typo, a deleted page, a moved page without a redirect, or a misconfigured server.<\/p>\n
A URL was mistyped or the link is outdated.<\/strong> The most frequent cause. Someone followed a link from three years ago, or typed the address slightly wrong. Nothing is broken on your server \u2014 the requested path just doesn’t exist. These show up in your access logs as 404s, but they’re often not yours to fix unless the stale link is one you control.<\/p>\n A page was deleted without a redirect.<\/strong> You removed a blog post, retired a product page, or cleaned up old content \u2014 without telling inbound links where to go. Every bookmark, search result, and external link pointing to that URL now hits a 404. If the page had traffic or links from other sites, that’s both a user experience problem and an SEO issue.<\/p>\n A page was moved to a new URL without a redirect.<\/strong> You restructured your site, changed a slug, or moved content into a different category \u2014 and the old URL no longer exists. Anything already indexed by search engines or bookmarked by visitors now returns 404 until you add redirects.<\/p>\n A broken or missing .htaccess file (WordPress).<\/strong> On WordPress, the .htaccess file in your public_html directory is what translates readable URLs like WordPress permalinks not flushed.<\/strong> After a migration, plugin install, or certain server changes, WordPress can lose its URL rewriting rules. The fix is usually trivial and takes 10 seconds.<\/p>\n A file uploaded to the wrong path.<\/strong> For non-WordPress sites, or for specific file references like images, PDFs, or downloads \u2014 the file either doesn’t exist at the path being requested, or the path in your code doesn’t match where the file actually lives on the server.<\/p>\n Check the URL for typos, especially near the end. Try navigating from the site’s homepage instead of using the direct URL. If it’s a page you expect to exist on an active site, the site owner probably moved it without setting up a redirect \u2014 try searching the site directly. If you need to reach the owner, most sites have a contact page accessible from the homepage.<\/p>\n Step 1: Figure out whether the page should exist.<\/strong> Before fixing anything, determine whether the URL was ever valid. Pull up Google Search Console and check the Pages or Coverage report \u2014 GSC lists every URL it has tried to crawl that returned 404. Compare that list against anything you’ve deleted, moved, or renamed recently.<\/p>\n Step 2: On WordPress, flush your permalinks first.<\/strong> Go to Settings > Permalinks in your WordPress admin and click Save Changes without changing anything. This regenerates the .htaccess rewrite rules and resolves most WordPress 404s that appear after a migration or plugin change. If that doesn’t work, check whether your .htaccess file exists in public_html and contains the standard WordPress rewrite block:<\/p>\n If the file is missing or that block isn’t there, you can recreate it via cPanel’s File Manager. Access .htaccess from public_html (you may need to enable “Show Hidden Files” in the File Manager settings).<\/p>\n Step 3: If content was deleted or moved, add a 301 redirect.<\/strong> A 301 redirect tells browsers and search engines that the content now lives somewhere else, permanently. For WordPress, the Redirection plugin handles this without touching .htaccess directly. For Apache-based hosting without WordPress, add a redirect rule to .htaccess:<\/p>\n Use the closest equivalent page as the destination, not just the homepage. If a blog post on Topic A was deleted, redirect to a related article \u2014 not to your homepage.<\/p>\n Step 4: Check GSC for the bigger picture.<\/strong> If you’ve had a site migration, restructure, or permalink change, do a full audit rather than fixing 404s one by one. In GSC, filter the Pages report for “Not found (404)” and export the list. Any URL with historical impressions or inbound links from other sites is worth a redirect. The rest can be left alone.<\/p>\n Not every 404 is a problem. Pages that never existed, or pages with no traffic and no inbound links, can return 404 indefinitely without affecting your site’s ranking. Google doesn’t penalise 404s \u2014 it simply stops trying to index those URLs.<\/p>\n What matters: if a URL has links pointing to it from other sites, or if it appeared in search results with real traffic, a 404 means that value is sitting idle. A 301 redirect captures it and passes it to a relevant page that still exists. For a recently migrated site especially, auditing your 404s in the first few weeks after launch is worth doing \u2014 stale links accumulate fast during a migration and can quietly drain traffic from pages that used to rank.<\/p>\n A 404 error means the server responded but couldn’t find the page. On WordPress, start with Settings > Permalinks > Save Changes \u2014 this resolves most post-migration and post-plugin 404s in seconds. If the page was deleted or moved intentionally, add a 301 redirect pointing the old URL to the closest equivalent page still on your site. For anything more systematic, Google Search Console’s 404 report shows you exactly which URLs are returning errors and whether any of them had meaningful traffic.<\/p>\n Since this article is on a hosting provider’s blog: 404 errors after a migration are often a server-configuration issue rather than a code problem. Missing .htaccess rules, permalink structures that don’t survive the move, or caching layers still serving old URL paths are the usual culprits. We see these regularly on sites migrated to CanSpace, and they’re typically resolved in one support ticket.<\/p>\n If you’re troubleshooting a post-migration 404 issue on a CanSpace account, our support team<\/a> can check your .htaccess, flush permalink rules, and pull pages from nightly backup if needed. Our hosting plans<\/a> include nightly backups and full support for this kind of issue. If you’re still on a US-based host and considering a move, the migration process itself is covered in detail on our why-Canadian hosting explainer<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" When your browser hits a 404, it means the server is responding fine \u2014 it just can’t find what you asked for at that URL. The server is alive. The specific page or file is not. That distinction matters when you’re trying to figure out what to fix. What a 404 status code actually tells […]<\/p>\n","protected":false},"author":1,"featured_media":5669,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"client_name":"","client_title":"","client_company_name":"","client_url":"","client_quote":"","footnotes":""},"categories":[137],"tags":[],"class_list":["post-5259","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-website-development"],"acf":[],"yoast_head":"\n\/blog\/my-post\/<\/code> into the actual file path the server needs. If this file is missing, corrupted, or has invalid rules, you’ll get 404s on posts and pages even though the content exists in the database.<\/p>\nHow to fix it if you’re a visitor<\/h2>\n
How to fix it if you own the site<\/h2>\n
# BEGIN WordPress\n<IfModule mod_rewrite.c>\nRewriteEngine On\nRewriteBase \/\nRewriteRule ^index\\.php$ - [L]\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteRule . \/index.php [L]\n<\/IfModule>\n# END WordPress<\/code><\/pre>\nRedirect 301 \/old-page-path\/ https:\/\/yourdomain.com\/new-page\/<\/code><\/pre>\nWhen 404s matter for SEO \u2014 and when they don’t<\/h2>\n
The short version<\/h2>\n
\n