How to Do a Simple SEO Audit with Free Tools (Step-by-Step Guide)
An SEO audit is a structured check of a website, done with a short list of questions and a few reliable tools. The point is to see how search engines can reach your pages, how those pages feel to a visitor, and whether the titles and descriptions make sense. You do not need a paid suite for a useful audit. Official free tools from Google are enough for most small Blogger sites.
This guide walks through a practical workflow: what to prepare, which tool to open at each step, what to write down, and what to fix first. It is not a ranking promise, and it is not a long list of every technical item you might ever change. For a companion list of technical checks, see the technical SEO checklist for beginners. Use that post when you already know the kind of issue you are hunting. Use this one when you want a repeatable audit from start to finish.
If you want a first pass on one page before you open Search Console, use the free SEO audit tool. Paste the live HTML to check the title, headings, meta tags, images, and links. It does not replace Search Console, and the score is not a ranking result.
What an SEO Audit Is, and What It Is Not
A simple audit is a review with a purpose. You pick the pages that matter, you run the same checks on them, and you leave with a short list of problems in a sensible order. It usually covers indexing, a few important URLs in detail, speed and basic page experience, titles and descriptions, the sitemap, structured data if you use it, and links on those key pages.
It is not a score you have to reach. PageSpeed Insights and Lighthouse both produce numbers, but those numbers are not official ranking targets, and a lab score of 100 does not mean the site is "done." An audit is also not a substitute for useful content. If a page does not help the searcher, a clean report will not save it.
It is not something you have to finish in one evening, and it is not a reason to change the theme, the titles, and the sitemap all at once. The useful habit is smaller: run the workflow, fix the highest-priority issues, retest, and come back after the next batch of posts or after a theme change.
What You Need Before You Start
Three things make the rest of the work much easier.
First, a verified property in Google Search Console. Without it, you can still run PageSpeed Insights, Lighthouse, and the Rich Results Test on public URLs, but you will be missing the field view of indexing, sitemaps, and (when enough traffic exists) Core Web Vitals. If the property is not set up yet, follow the guide to Google Search Console for beginners, then return to this workflow.
Second, a short list of important URLs. For a small blog, that is usually the homepage, the about page if you have one, and five to ten posts you actually care about: recent guides, pages that already get some search clicks, or pages you have just updated. You do not need to test every tag page and every archive. A focused list keeps the audit honest and short.
Third, a notes page. A simple document or a sheet with four columns is enough: the URL, the tool you used, what you found, and what you plan to do. The notes matter more than a screenshot collection. They stop you from "fixing" the same issue twice, and they help you retest the right thing later.
A Practical Audit Workflow
The order of the steps is deliberate. There is little value in compressing an image on a page that Google is not allowed to index, or rewriting a title on a URL that returns an error. Work from "can this page be found?" toward "is this page pleasant to use?" and then toward "is the snippet clear?" Extras such as structured data come after that.
In brief, the workflow looks like this:
- Prepare Search Console, your key URLs, and a notes page.
- Read the Pages and Sitemaps reports in Search Console.
- Inspect the important URLs one by one.
- Test those same URLs in PageSpeed Insights and in Lighthouse.
- Review titles, descriptions, sitemap listing, structured data, and links.
- Prioritize, fix one group of issues, retest, and wait for field data to catch up.
Each tool answers a different question. Keep that in mind when two reports appear to disagree. They often measure different things, at different times, on different kinds of data.
Step 1: See How Google Indexes the Site
Open Google Search Console and start with the site-level view. The Pages report (under indexing) is the place to see how many URLs Google has indexed, and how many it has excluded or marked with an issue. This is the closest official picture of how the site is being processed. A site: search in Google is only a rough glimpse and can miss URLs or show stale results. Do not treat it as the audit.
Write down the indexed count, then open the reasons on the excluded or error side. Some exclusions are expected. Tag pages, similar copies, or URLs you chose not to index can appear there without being an emergency. The findings that matter are pages you care about that are not indexed, pages with a clear error, or a sudden change you cannot explain.
Common reasons you may see include pages that were crawled but are not currently indexed, pages that were discovered but not crawled yet, and pages excluded by a noindex tag. Those labels describe a state, not a diagnosis on their own. For a page you want in Search, inspect the URL, and check whether the content is thin, whether it is blocked, or whether it needs more time and a real internal link.
While you are in Search Console, open the Sitemaps report as well. Confirm that your sitemap is submitted and that the report is not showing an error. You will look at the sitemap in more detail later. Also glance at the Core Web Vitals report if it has data. You only need to note whether mobile field data is already a problem on important URL groups. The deeper fixes belong in the Core Web Vitals guide.
If Search Console shows a manual action, stop and read that report before you spend time on titles or speed. A manual action is uncommon on a careful site, but it outranks the rest of this workflow until it is understood.
Step 2: Inspect a Few Important URLs
The Pages report tells you about groups of URLs. URL Inspection tells you about one address. For each URL on your short list, paste it into the inspection tool and read the result for the last time Google crawled that page.
Look for a few plain facts. Can Google request the URL? Is it on the index, or is there a reason it is not? Which sitemap, if any, listed it? When was it last crawled? If the page is not available, the tool will usually say so clearly, for example because of a 404, a redirect, or a noindex rule. Write the result next to the URL in your notes. Do not rely on memory.
URL Inspection can also run a live test. Use that after you have made a real change, or when you suspect the last crawl is out of date. The live test is a current fetch, not a promise that the index has already been updated. If the live test looks healthy and the last crawl does not, you may only need to wait, or, for a truly important URL, request indexing after the fix is live.
Requesting indexing is a limited action. It is meant for a small number of important URLs, not for every post on the site, and not as a way to "refresh" a page every morning. Use it after you have actually repaired something: a mistaken noindex, a restored URL, or a substantially updated guide. Then leave it. Repeating the request will not force a faster result.
Step 3: Check Speed and Page Experience on Key Pages
Once you know the important URLs can be reached, test how they load. Use PageSpeed Insights on the same short list, and start with the mobile view. Mobile-first indexing means the mobile experience is the one that matters most for Search, and a phone is usually the tighter test.
PageSpeed Insights shows two layers when it can: field data from real Chrome visits, and a lab audit underneath. If field data exists, read that first for Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. If it is missing, that is normal on a new or quiet URL. Use the lab section to find a specific cause, such as a large featured image, then confirm what you see on a real phone. A related walkthrough of the speed tools is in how to improve website speed with free tools. For thresholds and Blogger-specific fixes, use the Core Web Vitals guide rather than turning this audit into a second copy of that article.
Lighthouse is the lab test you can run in Chrome DevTools, on the page itself. Open the page, open DevTools, go to the Lighthouse panel, and run an analysis. The performance run is a lab test, and the SEO category checks basic issues such as a missing title, a blocked page, or a missing viewport. Lighthouse does not measure Interaction to Next Paint, because there is no real user tapping the page. It is also not a substitute for Search Console. Treat it as a way to catch problems while you edit.
Do not chase a perfect score. Note the issues that would actually help a reader on a phone: a huge image, a layout that jumps, a viewport problem, or a page that ignores a tap. For layout, tap targets, and theme settings, see how to make a website mobile-friendly. Write the findings down, then move on. Speed work comes after indexing issues in the priority list, not before.
Step 4: Review Titles and Descriptions
With the important URLs still in front of you, look at the title and the meta description of each one. In Blogger, the post title is usually the title element, and the Search Description field is the description you can control. That field has a 150-character limit in the Blogger editor, so keep the text inside it. Google may still rewrite a snippet in Search. A clear, unique description is still worth writing, because it is the text you offered, and it often appears when Google does not replace it.
Check three things. Is the title unique, or do several posts share almost the same wording? Does the title describe the page in ordinary language? Is the description a real summary, or a stuffed line that nobody would click? You can compare the live HTML in the page source, and you can search for the page to see how it currently appears. Search Console can also show titles and descriptions in some views, but a direct look at the post settings is the simplest check during an audit.
You do not need to rewrite every title in one sitting. Flag the ones that are duplicated, vague, or badly cut off, and come back to them after any indexing or error fixes. This audit is a pass over the pages you already chose to inspect, not a full meta-tag lesson.
Step 5: Confirm the Sitemap
A sitemap does not force indexing, but it helps Google discover the URLs you consider important. In Search Console, open the Sitemaps report and confirm that the sitemap you rely on is listed, was read recently, and is not reporting an error. On Blogger, a sitemap is usually available as a feed URL. If you are not sure which address is submitted, the report will show it.
Then do a simple cross-check. Pick two or three URLs from your important list and confirm they appear in the sitemap. If a key post is missing, that is a finding. If the sitemap lists URLs that no longer exist, that is also a finding. You do not need to rebuild the sitemap by hand during this audit. Note the problem, fix the cause (for example a URL that should not be public, or a post that was unpublished), and look at the report again later. A longer, dedicated walkthrough lives in the sitemap guide if you need it after the audit.
Step 6: Test Structured Data with the Rich Results Test
If your theme or a post includes structured data, such as Article markup, a breadcrumb, or FAQ markup, test a key URL in the Rich Results Test. This is Google's official tool for seeing which rich results a page can qualify for. You can paste a public URL or a code snippet. The default test uses a smartphone user agent, which matches how most people browse.
Read the result carefully. "Valid" means the markup the test supports was understood and did not fail. It does not mean a rich result will actually appear in Search. Google may not show an enhancement even when the test is clean. Errors should be fixed if you intended to use that type. Warnings are worth reading, but they are not always a reason to tear the theme apart during a first audit.
The Rich Results Test is not a general validator for every schema.org type. For markup that the test does not cover, Google points to the Schema Markup Validator at validator.schema.org. Older references to the Structured Data Testing Tool are out of date; that Google-specific tool was retired. If you do not use structured data at all, you can skip this step and note that fact. Adding markup is not a required part of a basic audit.
Step 7: Check Links on Important Pages
Finally, look at the links on the pages you already have open. Click the internal links in the post and in the main menu. If a link goes to a 404 page, a redirect loop, or a blogspot address you meant to update to your custom domain, write it down. Internal broken links are the first ones to fix, because they affect both readers and the way people move around your own site.
Search Console can also surface URLs that were not found, in the Pages report or in related indexing details. That is useful for catching a deleted post that still has incoming links. You do not need a paid crawler for a small blog. A careful pass over the homepage, the menu, and the key posts will catch most of the damage. External links that have gone stale can be updated when you notice them, but they are usually a lower priority than a broken link inside your own navigation.
When you fix a link, re-open the page and click it again. Do not assume the editor saved what you expected, especially if you edited HTML by hand.
How to Prioritize What You Found
An audit that produces twenty notes is only useful if you know which notes to act on first. Use a simple order, and resist the urge to start with the most visible cosmetic change.
- Pages you care about that are blocked, excluded, or not indexed. A mistaken noindex tag, a blocked resource, or a key post that never made it into the index belongs here.
- Clear errors on those same URLs, such as a 404, a bad redirect, or a page that cannot be fetched.
- Speed and layout problems on the important pages, especially on mobile. Large images, layout shifts, and heavy widgets sit in this group.
- Weak or duplicated titles and descriptions on those pages.
- Sitemap errors, structured data issues, and leftover broken links that did not already appear above.
Fix one group, then retest with the same tool that found the problem. If URL Inspection showed a noindex, inspect the URL again after you remove it. If PageSpeed Insights pointed to a huge featured image, run the URL again after you compress it. Do not judge the Search Console field reports on the same afternoon. Those reports are built from real visits over a recent window, and they take time to move.
This is also why the technical checklist post is a companion rather than a second copy of this audit. Once you have found, for example, a robots rule or a mixed-content warning, that checklist is a better place to think through the fix. The audit's job is to notice the issue and put it in the right place on the list.
After the Audit
A finished audit is a short list, not a redesigned site. Publish the fixes you have actually tested. Then give Search Console time. Request indexing only for a truly important URL you have changed. Check the Pages report and the URL Inspection result on a later day, not every hour.
It is reasonable to run this workflow after a theme change, after a batch of new posts, or when something looks wrong in Search Console. A small blog does not need a daily audit. A lighter look at the Pages report, plus a full run of this workflow a few times a year, is enough for many sites. If you change the theme or add a new gadget, run the key-URL steps again.
Keep the notes. The next audit is faster when you can see what you already fixed, and what you decided to leave alone.
Notes for Blogger Users
Most audit fixes on Blogger happen in two places: the theme, and the HTML or settings of a post. Indexing problems sometimes come from a gadget or a theme setting rather than from the post itself. Speed problems often come from a large featured image or from extra widgets. Title and description problems are usually in the post editor. When you edit theme HTML, save a copy first.
Blogger already provides a sitemap and a default robots.txt in typical setups. Do not replace those with a downloaded file from an unrelated platform. If you are unsure, look at what Search Console already has, and at the live /robots.txt on your domain, before you add new rules.
If you still have old blogspot links in menus or in older posts, note them during the link pass and switch them to your www.freeseolab.com URLs. That is a common leftover on a custom domain, and it is an easy win once you are already clicking through the important pages.
Simple SEO Audit Checklist
- Confirm Search Console is verified, and write down five to ten important URLs.
- Read the Pages and Sitemaps reports, and note why any key URL is excluded or in error.
- Run URL Inspection on those URLs. Use a live test after you make a real change.
- Test the same URLs in PageSpeed Insights, mobile first, and in Lighthouse.
- Review titles and descriptions, and flag any that are duplicated, vague, or badly cut off.
- Confirm that important URLs are in the sitemap and that the sitemap report has no error.
- If you use structured data, test a key page in the Rich Results Test. A valid result does not guarantee a rich result in Search.
- Check links on the homepage, the menu, and the key posts. Fix internal broken links first.
- Prioritize: indexing and errors first, then speed on those pages, then snippets and extras.
- Retest in the same tool, then wait for Search Console field data to catch up.
You can also start a key URL in the free SEO audit tool, then continue this checklist in Search Console and PageSpeed Insights.
Frequently Asked Questions
Do I need a paid SEO tool to audit a small blog?
No. Search Console, PageSpeed Insights, Lighthouse, and the Rich Results Test cover the checks in this workflow. A paid crawler can help on a very large site, but it is not a requirement for a typical Blogger blog.
How often should I run an audit?
There is no official schedule. Run this workflow after a theme change, after a batch of new or updated posts, or when Search Console shows a new problem. A quick look at the Pages report can happen more often. A full pass a few times a year is enough for many small sites.
Why do PageSpeed Insights and Search Console disagree?
They are not always measuring the same thing. PageSpeed Insights shows a lab test every time, and field data only when enough recent visits exist for that URL or origin. Search Console's Core Web Vitals and indexing reports are field-based and update over a recent window. A difference is expected. For indexing questions, trust Search Console. For a specific speed cause, use the lab test and a real phone.
Should I request indexing for every post after the audit?
No. Request indexing only for a small number of important URLs, and only after a real fix or a substantial update. It is a limited tool, not a publish button, and repeating it will not force Google to recrawl the whole site.
Is the Mobile-Friendly Test still the right tool?
No. Google discontinued the standalone Mobile-Friendly Test. For this audit, use a real phone, the mobile view in PageSpeed Insights, and the Lighthouse checks that cover viewport and similar basics. The mobile-friendly guide on this site covers the layout work in more detail.
Does a valid Rich Results Test mean I will get rich results?
No. The test tells you whether supported structured data on the page is valid enough to qualify. It does not promise that a rich result will appear. Google may still show a normal result.
What if Search Console has no field data yet?
That is common on a new property or a quiet page. You can still inspect URLs, run lab tests, click through links, and review titles. Use those checks until enough real visits exist for the field reports to appear. Do not keep republishing a post in the hope of forcing a number.
Should I fix every item Lighthouse flags?
No. Use Lighthouse to find problems, then decide whether a change helps a real visitor or unblocks a page. Some suggestions have little effect on a small Blogger site, and some are not practical because you do not control the hosting. Start with the issues that affect your important pages, and leave the rest in the notes.
Final Thoughts
A simple SEO audit is a habit, not a performance. You prepare a short list of URLs, you ask the same questions in the same order, and you leave with a priority list instead of a pile of screenshots. Search Console tells you how Google is treating the site. URL Inspection zooms in on one address. PageSpeed Insights and Lighthouse show how a page loads. The Rich Results Test checks structured data if you use it. Your own click-through of key pages catches broken links that a report can miss.
Fix the things that stop a page being found before you polish the things that make it faster or clearer. Retest in the same tool, then wait. The official free tools are enough for this work. The audit helps you notice problems early; it does not promise a higher ranking on its own.