Most digital presence audits are sold as a service and delivered as a 40-page PDF. You can get the useful part yourself, this afternoon, with free tools and half an hour. What follows is the exact order we use on a first look at a client site, what each tool actually tells you, and what "good" looks like, so you can judge the output instead of staring at it.
Set a timer. Have your domain and your Google Search Console access ready.
The exact run order (and why the order matters)
Run the checks in dependency order, not in importance order. Start with what is visible to anyone from outside (speed, certificate, headers), move to what only you can see (Search Console), and finish with the structural checks that take longest (the crawl). If you run out of time, you have already caught the problems affecting every single visitor.
The full run:
- ▸Minutes 0 to 6: PageSpeed Insights on your homepage and one money page.
- ▸Minutes 6 to 12: Search Console indexing and search performance.
- ▸Minutes 12 to 16: Rich Results Test and the Schema.org validator.
- ▸Minutes 16 to 22: SSL Labs and a security header scan.
- ▸Minutes 22 to 26: mobile render, done honestly.
- ▸Minutes 26 to 30: broken links, redirects and crawl sanity.
Write every finding into one list as you go. Do not fix anything yet. Fixing mid-audit is how 30 minutes becomes a lost afternoon.
Minutes 0 to 6: PageSpeed Insights
Open pagespeed.web.dev, test your homepage and your highest-value page, and read the field data first. The top section is real Chrome user data over a trailing period. The lab score below it is a simulated run on a throttled device. Business decisions come from the field data. The lab score is a debugging aid, nothing more.
What good looks like, using Google's published Core Web Vitals thresholds at the 75th percentile:
- ▸Largest Contentful Paint at or under 2.5 seconds. Above 4 seconds this is a revenue problem, not a technical one.
- ▸Interaction to Next Paint at or under 200 milliseconds. INP replaced First Input Delay and it is the metric most plugin-heavy sites fail.
- ▸Cumulative Layout Shift at or under 0.1. Usually caused by images without dimensions, injected banners, and late-loading fonts.
If the field data section says there is not enough data, your traffic is below the reporting threshold and you must rely on lab numbers plus judgement. Always check mobile before desktop, because mobile is where the failures live. When the numbers are bad, the fix is rarely another plugin, it is a budget you enforce, which is the argument in Performance Budgets: Treat Speed as a Requirement, Not a Wish.
Minutes 6 to 12: Search Console coverage
Open the Pages report in Google Search Console and compare indexed pages against what you believe you published. This is the only tool in this list that shows what Google actually did with your site rather than what a simulator predicts. If your important pages are not indexed, nothing else in this audit matters yet.
Read it in this order:
- ▸Indexed count versus expectation. A shop with 400 products and 60 indexed pages has a structural problem, not a content problem.
- ▸The reasons under "not indexed". "Crawled, currently not indexed" usually signals thin or duplicated content. "Discovered, currently not indexed" often signals slow responses or crawl budget. "Excluded by noindex tag" is frequently a staging setting nobody removed at launch. "Alternate page with proper canonical tag" is often perfectly fine.
- ▸Sitemaps. Confirm yours is submitted, recently read, and free of errors.
- ▸Performance report, last three months, Pages tab. Sort by impressions. Pages with many impressions and a weak click-through rate have a title and description problem you can fix in minutes.
Then run URL Inspection on one important page and use the live test. Look at the rendered HTML and the screenshot. That single view answers most "why is this page invisible" questions.
Minutes 12 to 16: Rich Results Test and structured data
Paste your key URLs into Google's Rich Results Test, then into the Schema.org validator. The first tells you which rich result types Google recognises on that page. The second tells you whether your markup is valid at all, including types Google does not use. Run both, because they answer different questions.
Good looks like this:
- ▸Organization markup on every page, with a consistent name, url, logo and sameAs profiles.
- ▸A page-type entity on templates that deserve one: Article on posts, Product on products, Service on service pages, FAQPage only where the questions are visibly on the page.
- ▸Zero errors, and warnings you understand. Warnings are usually optional fields. Errors mean the block is being ignored entirely.
- ▸No markup describing content a user cannot see. That is a policy violation and it can cost you eligibility.
If the test returns nothing at all, your structured data is either missing or injected client-side where the parser never reaches it. That is the same failure mode that keeps you out of AI answers, covered in Your Website in the AI Era: What Changes When Machines Read It First.
Minutes 16 to 22: TLS certificate and security headers
Run your domain through the free SSL Labs server test, then through a security header scanner. Together they take six minutes and expose the two most common trust failures on small business sites: a certificate that is misconfigured or about to expire, and a complete absence of response headers.
For the certificate test, good looks like:
- ▸Grade A or A+, a complete certificate chain, and no weak protocol support. TLS 1.2 and 1.3 only.
- ▸A certificate valid for both the apex domain and www, matching every hostname you actually serve.
- ▸Renewal automated. If a human has to remember it, it will expire on a Saturday.
For headers, expect Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options set to nosniff, Referrer-Policy, and frame protection. Most sites score badly on the first run, and most of the fix is a few lines of server or CDN configuration. While you are here, confirm your DNS is locked down, because a certificate is only as trustworthy as the registrar account behind it, as explained in Hardening DNS: From Registrar Locks to Encrypted Resolvers. If you operate in the EU, these same controls become evidence you will be asked for, per The 2026 SME Cybersecurity Checklist for GDPR, NIS2 and DORA.
Minutes 22 to 26: the mobile render check
Google retired its standalone mobile-friendly test, so do this in Chrome DevTools plus Search Console's live URL inspection. Verify current tool availability before you rely on any single one. What you are testing is not "does it look responsive", it is "can a person finish the task on a mid-range phone on a bad connection".
The four-minute version:
- ▸Open DevTools, switch to device mode, and pick a mid-tier phone profile rather than the newest flagship.
- ▸Throttle the network to a slow 4G profile. Most audits pass only because they were run on office fibre.
- ▸Check tap-target spacing, that body text is readable without zoom, and that nothing overflows horizontally.
- ▸Attempt the primary conversion action: submit the form, add to cart, start the booking. Time it.
- ▸In Search Console URL Inspection, view the rendered screenshot Google captured. If it differs from what you see, you have a rendering or resource-blocking problem.
Minutes 26 to 30: broken links and crawl sanity
Run a free crawler across the site and sort the results by status code. The free tier of a desktop crawler such as Screaming Frog typically covers a few hundred URLs, which is enough for most business sites. Check the current limit before you plan around it.
Sort and scan for these, in order:
- ▸404s that are linked internally. Self-inflicted, always worth fixing, usually five minutes each.
- ▸Redirect chains. One hop is fine. Three hops wastes crawl budget and page speed.
- ▸Mixed content. Any http asset loaded on an https page.
- ▸Duplicate or missing titles and meta descriptions. The fastest ranking win on most sites.
- ▸Missing H1s, orphan pages, and pages nothing internally links to.
- ▸robots.txt and sitemap.xml, fetched by hand. Confirm robots.txt is not blocking something important and that the sitemap contains only canonical, indexable URLs.
If your site is large enough that a free crawler cannot finish it, that is itself a finding, and the architecture questions in How to Scale a Web App From 100 to 100,000 Users start to apply.
Turning 30 minutes of findings into a one-week fix list
Sort every finding into three buckets: broken, leaking, and slow. Fix broken first, because it costs you visitors today. Then fix leaking, the things quietly losing trust or ranking. Then fix slow, which is real engineering and deserves a plan rather than another plugin.
A realistic first week after this audit:
- ▸Day 1: certificate and header configuration, internally linked 404s, and any noindex tag left over from staging.
- ▸Day 2: titles and meta descriptions on the high-impression, low-click pages you found in Search Console.
- ▸Day 3: structured data on the main templates, then re-validate everything you touched.
- ▸Days 4 and 5: the single largest performance offender, usually images, fonts, or a third-party script nobody remembers adding.
Then re-run the same six checks in 30 days and compare. An audit you repeat is a monitoring system. An audit you run once is a document.
How TuniCyberLabs helps
We run this audit properly, with a full crawl, log analysis and a prioritised fix plan, and then we do the engineering: performance work, structured data, header and TLS configuration, and rebuilds when the platform itself is the bottleneck. That is the day job of our web and security engineering services.
Run the 30 minutes yourself first, then send us the list you could not fix, talk to an engineer.