THE SMALL-BUSINESS WEBSITE DESK
A practical website health checklist
Use a browser, a few representative pages, and a written record to separate a visible problem from a guess. These checks help you describe work clearly; they cannot certify accessibility, security, legal compliance, or future search performance.
1. Read the HTML title and description
Open each page and check its browser-tab title. Then use View Page Source and search for <title> and name="description". For JavaScript sites, compare the browser’s Elements panel, because the rendered page may differ from its initial HTML.
Write a specific, readable title that identifies the page’s service or subject. The description should accurately summarize that page, without repeated keywords. Flag identical titles across unrelated pages. Google may generate different title links and snippets, so these fields do not guarantee the wording shown in search. See the Google Search Central SEO Starter Guide.
2. Check canonical URLs and indexing instructions
Search the page head for rel="canonical". If present, open its destination and confirm that it represents the intended version, not a staging address or unrelated page. A canonical is a preference signal; Google can choose another URL. Compare it with links and sitemap entries. See Google’s canonical guidance.
Look for a robots meta tag and inspect response headers for X-Robots-Tag. Investigate unexpected noindex on public pages. Open your site’s /robots.txt and note rules that block important paths. Do not remove rules blindly: some exclusions are intentional. Crawling restrictions and indexing instructions are different; blocked crawling may prevent a crawler from seeing noindex. Google’s robots.txt documentation explains why robots.txt is not a privacy control.
3. Try the mobile layout and zoom
Check for width=device-width, initial-scale=1 in the viewport meta tag. Then use a real phone and a narrow desktop browser window. Read the main text, open navigation, and follow the primary action. Look for horizontal scrolling, clipped content, overlapping controls, and links that are difficult to tap.
Zoom the page and navigate with Tab; focus should remain visible and controls reachable. A viewport tag alone does not establish usability or accessibility. Avoid disabling user zoom. MDN’s viewport reference explains the setting.
4. Review image meaning and download size
Inspect important images for useful alt text describing their purpose in context. Decorative images generally need empty alt text; a linked image needs an accessible name that conveys the link’s purpose. Do not turn descriptions into keyword lists.
In the browser Network panel, reload and sort image requests by size. Investigate unusually large downloads for small displayed pictures. Ask whether a smaller or responsive version would preserve clarity. Explicit width and height help reserve space before loading. Compare the result visually after changes; a smaller file is not useful if text becomes unreadable. Consult MDN’s image element reference.
5. Follow links and inspect redirects
Click navigation, service links, phone and email links, policy links, and the main action. Check both the destination address and the content: a successful response can still show the wrong page. Record broken destinations and unexpected detours.
Use the Network panel with Preserve log enabled to inspect redirects. A redirect to a replacement page can be intentional; repeated hops or a loop need investigation. Update internal links to the intended final destination where practical. Test old bookmarked URLs after changing a page address.
6. Confirm what happens after a form
With the owner’s permission, send an obviously labeled test inquiry using an address you control. Check required-field errors, keyboard operation, the success message, and whether the message reaches the expected inbox or system. A success banner alone does not prove delivery.
Confirm that the page explains the next step without promising an unsupported response time. Test an invalid entry to see whether correction is clear and existing input survives. Use a sandbox for payment journeys; do not create real charges merely to check a button.
7. Verify contact and policy information
Find the business name, working contact route, service scope, and relevant terms, privacy, and refund information. Check that prices and limitations agree across pages. Remove expired offers and unsupported claims. Make sure contact links work on mobile.
These details help visitors understand who they are dealing with. Their presence does not establish legal compliance, validate a business, or prove that a service produces results. Policy wording needs review against actual business practices.
8. Review cache and security headers
In Network, select the main document and a static asset, then inspect response headers. Ask the developer whether Cache-Control fits each response: versioned assets and private customer pages have different needs. no-cache permits storage but requires validation before reuse; it is not the same as no-store. See MDN’s caching guide.
Confirm HTTPS loads without browser warnings. Record security headers for review, including Content-Security-Policy. A header’s presence alone proves little about protection, and copying an arbitrary policy can break legitimate resources. Ask for a tested configuration suited to the site; MDN’s CSP reference describes its behavior.
9. Separate search evidence from performance measurement
For a property you control, use Search Console URL Inspection to compare indexed information with a live test. Check crawl details and Google’s selected canonical. A live test is not a promise of indexing, and older indexed data may lag recent edits.
Core Web Vitals concern loading, interaction responsiveness, and visual stability. They require actual browser measurement. Compare repeatable browser tests with available real-user field data; device, network, and user behavior affect results. Sparse traffic may mean no field report. A laboratory score is not a measured business outcome. This site’s automated tool does not run browser performance tests or measure Core Web Vitals.