Check if your pages are reachable

SiteCurl sends a request to every page in your scan and records the HTTP status code that comes back. A 200 means the page loaded. A 301 or 302 means the page redirected. A 404 means the page was not found. A 500 means the server hit an error.

For each page, SiteCurl reports the exact status code, the URL that was requested, and what the status means in plain terms. Pages returning errors are flagged as critical. Redirects are flagged as warnings because they add load time and may signal outdated URLs.

The check runs on every page in your scan, not just the home page. This catches pages that broke during a deploy, content pages that were deleted without a redirect, and staging URLs that leaked into production.

HTTP status codes are how your server tells browsers and search engines what happened when they asked for a page. The visitor never sees the code directly, but they see the result: a working page, a redirect to somewhere else, or an error screen.

The most common problem is a 404. It means the page does not exist. This happens when someone deletes a page, changes a URL slug, or makes a typo in a link. The visitor sees an error page. If your site does not have a custom 404 page, they see a generic server message that offers no way forward.

Server errors (500, 502, 503) are worse. They mean something broke on the backend: a crashed process, a database timeout, a bad deploy. These errors can affect one page or all pages depending on the cause. They tend to come and go, which makes them hard to catch without regular scanning.

Redirects (301, 302) are not errors, but too many of them signal outdated link structures. Each redirect adds a network round trip. If a visitor clicks a link that redirects twice before reaching the final page, they wait for three separate server responses. Search engine crawlers also follow redirects, spending their crawl budget on hops instead of real content.

A page that returns an error does not exist for your visitors. They cannot read it, buy from it, or share it. If a search engine crawler gets a 404, it removes that page from the index. If it gets a 500, it may reduce how often it crawls your entire site.

Error pages also break the experience for visitors who arrive from bookmarks, search results, or links on other sites. They expected content and got nothing. Most leave and do not come back.

For agencies managing client sites, a page returning a 500 error is an urgent call from the client. A monthly scan catches these before the client does. For e-commerce sites, a product page returning a 404 is a lost sale for every visitor who clicks that link.

E-commerce sites with rotating product catalogs are hit hardest. Seasonal products get removed, but links to them persist in category pages, email campaigns, and search results. Each dead link is a visitor who wanted to buy something and could not.

Content sites and blogs accumulate 404s over time as posts are edited, merged, or deleted. The longer the site has been running, the more dead URLs pile up. A site with five years of blog posts may have dozens of broken internal links.

SaaS marketing sites face 500 errors during deploys. A bad release can take down the pricing page or signup flow without anyone noticing until traffic drops. Regular scans act as an early warning system.

Step 1: Fix server errors first. Pages returning 500, 502, or 503 are the most urgent. Check your server logs for the error message. Common causes are crashed application processes, database connection failures, and syntax errors in recently deployed code.

Step 2: Add redirects for deleted pages. If a page was removed but still has inbound links, set up a 301 redirect to the closest relevant page. This preserves any search value the old URL had and sends visitors somewhere useful.

Step 3: Update internal links. For pages that moved to a new URL, update every internal link that points to the old address. Search your CMS or codebase for the old URL slug to find all references.

Step 4: Check your CMS and hosting settings. In WordPress, check the permalink settings and .htaccess file. In Shopify, check the URL redirects section under Settings. For static sites, check your server config or hosting dashboard for redirect rules.

Step 5: Set up a custom 404 page. When a page does not exist, give visitors a helpful 404 page with a search bar or links to your main sections. A good 404 page keeps visitors on your site instead of sending them away.

Mistake 1. Ignoring redirect chains. A page that redirects to another redirect wastes time for visitors and crawlers. Go straight to the final URL. Update the original link to point there directly.

Mistake 2. Using 302 redirects for permanent moves. A 302 tells search engines the move is temporary, so they keep the old URL indexed. Use 301 for permanent moves so search engines update their records.

Mistake 3. Not checking after a deploy. Many 500 errors appear only after a code change goes live. Run a scan after every major deploy to catch server errors before visitors do.

Mistake 4. Deleting pages without a plan. Before removing any page, check if other pages link to it and if it has search traffic. Set up a redirect first, then delete.

After making fixes, run another SiteCurl scan on the same pages. Every page should return a 200 status code. If a page still shows an error, check the server logs for that specific URL. You can also test individual pages with curl -sI https://yoursite.com/page and look at the HTTP status line at the top.

For redirects, verify the redirect chain is no more than two hops. Test with curl -sIL https://yoursite.com/old-page to follow all redirects and see each step in the chain.

Page reachability is the most basic check. If a page returns an error, nothing else matters: visitors cannot see it, search engines drop it, and every link pointing to it is wasted. Fix server errors and broken URLs first, then move on to other checks.