A 15-minute website health check you can run yourself

You do not need an agency to find the obvious problems on a site. In about 15 minutes, with free tools and no logins, you can check whether a page is slow, hard for search engines to read, awkward to use with a keyboard, or missing basic security headers.

This is a first-pass checklist for a site you own or have permission to test. It will not replace a full audit, a penetration test, or real-user performance data. It will give you a short, ranked list of fixes so you know where to start.

Use your homepage, plus one important inner page if you have time (pricing, a key article, or a signup page). Write down each issue as you go: what you saw, where, and whether it looks high-impact or just tidy-up work.

What you need

All of this is free:

• Chrome or another Chromium browser, with DevTools (right-click the page, then Inspect)
• PageSpeed Insights, if you would rather not run Lighthouse locally
• A terminal, for a few curl commands
• A notes file

Check only sites you own or have permission to test. The exposed-file checks below are ordinary GET requests, but they are still not something to run against other people's websites.

Minutes 0–3: speed

Open the page in a fresh Incognito/private window (extensions can skew results). Then either:

• In Chrome DevTools, open the Lighthouse tab, choose Mobile, and run an analysis, or
• Paste the URL into PageSpeed Insights

Lighthouse is a lab test on one device and network. PageSpeed Insights also shows field data from Chrome users when enough people have visited the page. Treat lab scores as a diagnosis, not a trophy. Google's Core Web Vitals thresholds, when field data is available, are:

• LCP (largest contentful paint): 2.5 seconds or less is "good"
• INP (interaction to next paint): 200 milliseconds or less is "good"
• CLS (cumulative layout shift): 0.1 or less is "good"

You do not need a 100. Look at the Opportunities and Diagnostics lists and write down the first concrete problems, for example:

• A hero image that is far larger than the screen, or served as an uncompressed PNG
• A script loaded up front that is not needed for the first paint (analytics, chat widgets, and tag managers are common)
• Fonts that block text from rendering
• Images or embeds without width and height, which often cause layout shift
• A slow server or redirect chain before the page even starts to load

If you have 30 extra seconds, reload the page with DevTools open, switch to the Network tab, and sort by size. The two or three heaviest files are usually the right place to start.

Minutes 3–6: SEO basics

View the page source, or run:

curl -sL "https://www.example.com/" | tr '\n' ' ' | grep -oE '<title[^>]*>[^<]*</title>|<meta[^>]+>|<link[^>]+rel="canonical"[^>]*>|<h1[^>]*>[^<]*</h1>'

Replace the URL with yours. Then confirm each of these:

1. One clear <title>. It should name the page, not just the brand. Browser-tab length is a hint; if the title is cut off, it is probably too long.
2. A meta description. Google may rewrite it, but an empty or duplicated description is still a missed chance to explain the page.
3. A single <h1> that matches what the page is actually about, with headings that follow in order (h2, then h3). Don't skip from h1 to h4 just for the font size.
4. A canonical URL (rel="canonical") that points at the preferred version of this page, including the host you actually want (www or not, https).
5. Open Graph tags for link previews: og:title, og:description, og:image, and og:url. Open the image URL on its own and check that it loads.
6. /robots.txt and /sitemap.xml. They should return HTTP 200, not 404 or a soft 200 error page.

curl -sI "https://www.example.com/robots.txt"
curl -sI "https://www.example.com/sitemap.xml"

In robots.txt, make sure you have not accidentally disallowed the whole site (Disallow: /) or blocked a section you meant to keep public. If the sitemap exists, open it and confirm it lists the canonical URLs of your important pages.

Click through the main navigation and footer. Note any obvious 404s or redirect chains (page A → B → C). You do not need a full crawler for this first pass.

Minutes 6–9: accessibility spot checks

Automated tools catch a lot, and they also miss a lot. Do both a tool pass and a short manual pass.

• Run the Accessibility category in Lighthouse, or install the free axe DevTools extension and scan the page.
• Unplug the mouse and Tab through the header, navigation, and any form. You should see a clear focus ring on each control, and you should be able to reach the main actions without getting stuck.
• Check images that carry meaning. Decorative images can have empty alt="". Informative images need alt text that still makes sense if the image is gone.
• Check form inputs: every field should have a visible label, not just a placeholder.
• Look at text on top of photos or colored blocks. If you have to squint, contrast is probably too low. A hero headline in light text on a bright image is a common failure.

Write down anything that would stop someone from reading, moving, or submitting the page. Those rank above purely cosmetic issues.

Minutes 9–12: security basics

These checks are about ordinary web hygiene, not a penetration test.

HTTPS and mixed content. The address bar should show HTTPS. In DevTools, open Network, reload, and look for any http:// requests for scripts, styles, or images on an https:// page. Mixed content gets blocked or flagged, and it undermines HTTPS.

Security headers. Request the response headers:

curl -sI "https://www.example.com/"

On some hosts the apex (example.com) and www return different headers, so check the host you actually serve. You are looking for something like:

A missing header is a finding, not a disaster. Add the straightforward ones first. Do not paste a strict Content-Security-Policy from a blog post onto a live site. A CSP has to match the scripts, styles, and embeds you actually use, or it will break the page. Draft it, test it with Content-Security-Policy-Report-Only, then enforce it.

If you ship a Next.js app, you can set the safer, low-risk headers in next.config.js (or next.config.ts) like this:

const securityHeaders = [
  {
    key: "Strict-Transport-Security",
    value: "max-age=63072000; includeSubDomains",
  },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  {
    key: "Referrer-Policy",
    value: "strict-origin-when-cross-origin",
  },
  {
    key: "Permissions-Policy",
    value: "camera=(), microphone=(), geolocation=()",
  },
];

module.exports = {
  async headers() {
    return [{ source: "/:path*", headers: securityHeaders }];
  },
};

Leave preload off the HSTS line until you understand the preload list requirements. Once a domain is preloaded, removing it is not instant.

On WordPress, Webflow, Shopify, or a static host, the same headers are usually set in the host's dashboard, a plugin, vercel.json, Netlify _headers, or a Cloudflare Transform Rule. The values above still apply; only the place you paste them changes.

Exposed files (sites you own only). These paths should not return a 200 with real contents:

curl -sI "https://www.example.com/.env"
curl -sI "https://www.example.com/.git/HEAD"
curl -sI "https://www.example.com/.git/config"

A 404, 403, or 301/302 to a generic page is what you want. A 200 that shows environment variables or git metadata is urgent: rotate any credentials that may have been in that file, then block the path.

Cookies. In DevTools, open Application → Cookies. Anything that is a session or authentication cookie should be Secure and HttpOnly, and should set an explicit SameSite value. Marketing cookies are a separate conversation; the failure to flag here is an auth cookie that JavaScript or a non-HTTPS request can read.

Minutes 12–15: rank the list and pick three

You now have a messy list. Score each item quickly:

• Impact: Does it affect load time, understandability, keyboard use, or a basic security control?
• Effort: Can you fix it in a few minutes (a title tag, an alt attribute, a header) or does it need a redesign?

Sort by impact, then by effort. Circle three fixes you can ship this week. A typical first set looks like: compress and resize the hero image, write a real title and meta description, and add HSTS plus X-Content-Type-Options. Leave the long tail for later.

If you want a copy-paste record, this template is enough:

Page:
Date:

Speed:
- [ ] Lighthouse / PageSpeed run (mobile)
- [ ] Heaviest files noted
- [ ] LCP / INP / CLS notes (field data if shown)

SEO:
- [ ] Title
- [ ] Meta description
- [ ] Single H1 and sensible heading order
- [ ] Canonical URL
- [ ] Open Graph tags and image
- [ ] robots.txt and sitemap.xml return 200
- [ ] Main nav/footer links checked

Accessibility:
- [ ] Automated scan (Lighthouse or axe)
- [ ] Keyboard / focus check
- [ ] Alt text on informative images
- [ ] Form labels
- [ ] Contrast on hero and buttons

Security:
- [ ] HTTPS, no mixed content
- [ ] Headers: HSTS, CSP, nosniff, frame control, Referrer-Policy, Permissions-Policy
- [ ] /.env and /.git not exposed
- [ ] Auth cookies: Secure, HttpOnly, SameSite

Top 3 fixes (impact × effort):
1.
2.
3.

What this check does not cover

It does not measure real-world rankings, conversions, or uptime. It does not test authentication, payments, APIs, or business logic. It does not mean the site is secure, accessible, or fast for every user. And a strong Lighthouse score is not a promise that Google will rank the page higher.

When you are done, fix the three items, then run the same 15 minutes again. The second pass is usually much shorter.

If you would rather have someone else run a structured check across a site (up to five pages) and send a ranked fix list, I offer that as a paid service. It covers speed, SEO, accessibility, and security basics, and I deliver a PDF and Markdown checklist within 48 hours of your intake answers. It is my own product, it costs $49, and it does not include making the changes or any guarantee of rankings: Website Health Check.