Back to Site Mapped

Practical guide

A website health checklist for small teams

A website can look fine in your own browser while a customer meets a broken link, an expired certificate, or a page that search engines cannot index. This checklist starts with the failures that interrupt a visit and ends with improvements you can plan for later.

1. Check the address a customer actually uses

Open your public homepage in a private browser window. Try the address with and without www, and check that both reach one intended HTTPS address. A redirect is normal; a loop, a certificate warning, or a final error page is not. Repeat the check on a key service, booking, or contact page. Record the final URL and HTTP status so you can tell a temporary failure from a persistent one.

A single successful load is only a snapshot. Monitoring at regular intervals can catch an outage between your own visits, but it cannot prove the site was available every second or from every location.

2. Check what search crawlers are told

Visit /robots.txt and /sitemap.xml on your domain. The robots file should not accidentally disallow the public pages you want discovered. The sitemap should list current, public URLs on the hostname visitors reach. On an important page, inspect the canonical URL and any noindex instruction. A canonical pointing every page to the homepage can make distinct pages harder to understand; an unintended noindex can remove a page from search.

A sitemap is a discovery hint, not a promise of indexing. Keep login screens and private dashboards out of it. If a page has moved, update internal links and let the old URL redirect to the new one.

3. Walk the paths visitors use

Follow the navigation from the homepage to your main offer, pricing, and contact information. Broken internal links and missing images or stylesheets can block a customer even when the homepage itself returns 200. Each public page should have a specific title, a useful description, and a clear main heading. Duplicate titles often mean two pages are competing to describe different things in the same words.

Check those paths after a redesign, domain change, or content migration. A short manual visit is still useful because a simple crawler reads returned HTML and may miss interactions rendered only in the browser.

4. Fix interruptions before polish

  1. Restore pages that fail to load, HTTPS errors, and broken paths used to contact or pay you.
  2. Fix unintended noindex, blocked public pages, and wrong canonical URLs.
  3. Repair broken links and resources, then improve missing or duplicate page metadata.
  4. Review security headers and slower responses with your developer or hosting provider.

After each fix, revisit the affected URL. A scanner finding is a lead to investigate, not proof of a business impact. Keep a short record of what changed and what the page returned afterward.

What Site Mapped checks, and what it does not

Site Mapped checks HTTP availability, redirects, HTTPS and certificate signals, robots and sitemap presence, links and resources visible in returned HTML, page titles, descriptions, headings, canonical URLs, indexing instructions, and selected response headers. The number of pages and resources checked depends on the plan. Read more about SiteMappedBot and its bounded crawling.

These checks do not render JavaScript, run Lighthouse or Core Web Vitals, audit accessibility, certify security, or guarantee search rankings. Use a browser and specialist tools for those questions. If you want routine checks and a place to track findings, start with a free Site Mapped account.