I run this exact sequence whenever I inherit a client's codebase or get asked "why isn't this site ranking." It's not exhaustive, but it catches the issues that matter most, fast enough that you can do it before a client call.

Why speed first

Page speed is the fastest thing to check and usually the biggest lever, so I start there. Open Chrome DevTools, go to the Lighthouse tab, and run a mobile audit. You're looking at three numbers specifically:

• Largest Contentful Paint (LCP): should be under 2.5 seconds

• Cumulative Layout Shift (CLS): should be under 0.1

• Interaction to Next Paint (INP): should be under 200ms

If LCP is bad, nine times out of ten it's an unoptimized hero image or a render-blocking script loading before anything visible. Check the Network tab and sort by size. Anything over 500KB for an above-the-fold image is worth flagging immediately.

For a quicker terminal check without opening a browser, I'll run this to see raw response headers and time to first byte:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com

If TTFB alone is over 600ms, the problem is server-side or CDN-related, not frontend code, and that changes where you spend the rest of your audit time.

Check crawlability before anything else on-page

Before you touch titles and meta descriptions, confirm Google can actually see the pages. This is the step people skip and it's the one that quietly tanks a whole site.

Pull up /robots.txt and read it line by line. I've seen sites accidentally block /blog/ or entire subdirectories because a disallow rule was copied from staging and never removed. Then check /sitemap.xml exists and actually lists the pages you care about, not a stale version from a previous CMS migration.

In Google Search Console, check the Coverage report for anything marked "Excluded" that shouldn't be. If a service page is showing as "Crawled, currently not indexed," that's usually a thin content or duplicate content signal, not a crawling problem, and it needs a different fix.

This is also where I look at internal linking. Teams that run technical SEO services in the Philippines will usually check that core service pages are linked from multiple places across the site, not buried three clicks deep with no inbound links from anywhere else. If a page you want to rank only gets traffic from the nav bar, it's not getting enough link equity passed to it.

On-page basics, fast

For each key page, check:

• Title tag: unique, under 60 characters, primary keyword near the front

• Meta description: unique, compelling, not auto-generated boilerplate

• One H1 per page, and it should not just repeat the title tag word for word

• Image alt text: present and descriptive, not "image1.jpg" or empty

You can speed this up by viewing page source and searching for <title> and name="description" directly instead of clicking through every page manually. For a site with dozens of pages, I'll sometimes write a small script that pulls all title tags at once using a basic fetch loop, but for a 30 minute audit, spot-checking the top 5 to 10 pages by traffic is usually enough to spot a pattern.

Mobile behavior, not just mobile-friendly

Google's mobile-friendly test tool will tell you a page "passes," but that doesn't mean it's actually good on mobile. Open the site on an actual phone, or use Chrome DevTools device emulation, and check:

• Tap targets aren't overlapping or too small

• Text is readable without pinching to zoom

• Forms and buttons don't get cut off or covered by sticky headers

• Pop-ups or cookie banners don't cover the entire viewport on load

I've flagged sites that pass every automated mobile check but have a newsletter popup that covers 80% of the screen with no visible close button on smaller devices. Automated tools won't catch that. Your eyes will.

Quick technical sweep

Last five minutes, run through:

• SSL certificate valid and no mixed content warnings in the console

• No broken internal links (a tool like Screaming Frog's free tier covers up to 500 URLs)

• Check the browser console for JavaScript errors on page load

• Confirm canonical tags point to the right URL, especially on paginated or filtered pages

Broken links and console errors are easy to dismiss as minor, but they're often symptoms of something bigger, like a recent framework migration that didn't get fully tested before launch.

Putting it together

None of these checks require expensive tooling. Chrome DevTools, Search Console, and a free crawler tier will get you through all of it. What matters more than the tools is the order: speed and crawlability first, because they gate everything else, then on-page and mobile, then a final technical sweep.

If an audit like this turns up more issues than a quick fix can handle, that's usually the point where it makes sense to bring in a team that does full website redesign and revamp services rather than patching individual pages one at a time. A 30 minute audit is meant to tell you how big the problem is, not necessarily to fix it on the spot.

FAQ

How often should I audit a website? For an active business site, a quick audit like this once a month is reasonable. A deeper audit with a full crawl and backlink review makes more sense quarterly.

Do I need paid tools to do this properly? No. Chrome DevTools, Google Search Console, and the free tier of a crawler like Screaming Frog cover almost everything in this checklist.

What's the single most common issue you find? Unoptimized images causing slow LCP, followed closely by pages that are crawlable but not getting internal links from anywhere meaningful.

Can I automate this entire process? Parts of it, yes. Speed checks and broken link scans can run on a schedule. Mobile usability and content quality still need a human eye.

What if the site fails most of these checks? Don't try to fix everything at once. Fix crawlability first, then speed, then on-page details. Fixing on-page copy on a page Google can't crawl is wasted effort.