How to Run a Free Website SEO Audit with Sonar

A website SEO audit should help you decide what to fix next. A long list of warnings is less useful when you cannot find the affected page, reproduce the problem or understand the consequence. Sonar gives website owners a way to inspect technical evidence from public pages and turn that evidence into a practical repair list.

This guide explains a repeatable audit workflow using Sonar’s free website audit workspace. It focuses on what the crawler can actually observe: returned HTML, response details, page relationships and selected content signals. It also explains the boundaries, because a technical score cannot tell you everything about search demand, website visitors or the quality of your business.

What a website SEO audit can tell you

A technical audit asks whether important pages are accessible, understandable and connected. It can flag a missing title, repeated descriptions, an unexpected canonical URL or a failed page request. These findings give you specific places to investigate.

A crawler can also compare the pages it has seen. For example, two articles may share a title because a template failed to substitute the article name. A useful landing page may appear in the sitemap while no sampled page links to it. Both are worth reviewing, but neither observation automatically proves that Google has excluded the page.

Keep three questions separate:

• Can a crawler fetch and interpret the page?
• Does the page satisfy a real visitor’s purpose?
• Does search-performance evidence show that the page is being discovered?

Sonar helps with the first question and parts of the second. Search Console and your own analytics provide additional evidence for the third.

Step 1: Choose a clear audit scope

Start with the public HTTPS address you want to examine. Choose a single-page audit when you have a specific problem, such as a newly published service page. Choose a site crawl when you want to compare multiple pages and their connections.

The available crawl options and shared service limits are shown in the workspace. A bounded crawl is a sample, especially on a large website. Do not describe a report containing a small set of pages as a complete examination of thousands of URLs.

Before starting, record your goal. Useful examples include checking a redesigned navigation menu, reviewing a new blog category or confirming that important product pages return successful responses. A defined goal makes the report easier to interpret and prevents a healthy score from distracting you from the actual problem.

Step 2: Let the crawl collect evidence

Enter the address and select Analyze website. The crawler reads the original HTML returned by the website, follows permitted links within its scope and respects applicable robots rules. It does not behave like a fully rendered browser executing every JavaScript component.

This distinction matters for modern websites. A navigation menu that appears only after client-side rendering may be visible to you while absent from the response that Sonar inspects. That is a reason to inspect rendering and link delivery, rather than immediately concluding that the website has no navigation.

Keep the workspace open while a client-driven crawl progresses. If you pause or leave, use the available resume controls instead of repeatedly starting the same audit. Repeated fresh scans create separate snapshots and make comparisons harder.

Step 3: Read page failures before cosmetic warnings

Begin with pages that could not be fetched successfully. A failed request can result from an unavailable page, a redirect problem, a crawler block, a timeout or a response outside the supported scope. The correct fix depends on the evidence.

Open the affected URL yourself and check its intended purpose. If the page was deliberately retired, decide whether a relevant replacement should receive a redirect or whether a genuine not-found response is appropriate. Do not redirect every missing page to the homepage simply to hide an error count.

Next, review important indexability and canonical signals. An intentional private page should not become public just to improve an audit score. Conversely, a public service page with an accidental noindex instruction deserves investigation before you spend time rewriting a short description.

Step 4: Improve titles and descriptions in context

A page title should communicate the page’s specific purpose. “Services” may be accurate but unhelpful when several different service pages use it. A title such as “Commercial Kitchen Maintenance in Lahore” provides clearer context if that is genuinely what the business offers.

Descriptions should help a prospective visitor decide whether to open the result. Write them for people rather than filling them with repeated keywords. Search engines may choose another snippet, so a description is an editorial signal rather than a guarantee about the final search result.

When Sonar identifies repeated titles or descriptions:

• Open each affected page and compare its real purpose.
• Check whether the repetition comes from a shared template.
• Keep related pages distinct when their services or audiences differ.
• Consider consolidation when two pages genuinely answer the same question.

Make the smallest justified change and preserve information that already helps visitors.

Step 5: Review internal links and orphan candidates

Internal links help people move between related pages and help crawlers discover those pages. A sitemap is useful, but it does not replace a sensible navigation and content structure.

Treat an orphan candidate as a question: where should a visitor encounter this page? A pricing explanation might belong near product information. A troubleshooting article might belong in a help category and in the feature guide that creates the need for it.

A sample-based report has limits. A linking page may be outside the sample, delivered through JavaScript or unavailable during the crawl. Confirm the finding before changing your site. Our guide to finding and fixing orphan pages provides a separate checklist and explains why the sitemap alone is not proof of useful internal linking.

Step 6: Interpret the technical score correctly

Sonar’s technical health score comes from its own weighted checks. It is not Google’s ranking score, a domain-authority metric or proof that a website is secure. The scoring methodology explains the calculation and the boundaries of the evidence.

A high score can coexist with weak content, limited search demand or poor conversion. A lower score may include intentional decisions that require context. For example, a useful page can contain a deliberate canonical relationship that should be understood before being changed.

Use the score to track comparable technical snapshots, then read the underlying findings. Comparing different page samples can change the average even if no individual page was edited. Record scope and date alongside the number so that your team does not mistake a sampling difference for a successful repair.

Step 7: Measure speed separately

Response time from a crawler is not the same as a Core Web Vital. It reflects a particular request, route and execution environment. A fast HTML response does not guarantee that a page renders quickly on a visitor’s phone.

Sonar keeps performance evidence separate from the technical checklist. Use the available official PageSpeed workflow or supported report import to examine actual Lighthouse results. Direct provider integrations depend on operator configuration, availability and quota; an unavailable provider result should remain unavailable rather than becoming an invented score.

When you investigate speed, look for the resource or layout behavior causing the problem. Compressing an already small logo is unlikely to solve a page dominated by a large video, delayed application code or an unstable banner.

Step 8: Turn findings into an accountable repair list

Choose a small group of changes with a clear owner and a way to verify completion. A useful task includes the affected URL, the observed issue, the intended behavior and the verification method.

For example, “Improve SEO” is difficult to complete. “Replace the repeated title on the commercial maintenance page, confirm the deployed HTML and recrawl that URL” is specific enough for a teammate to act on.

Prioritize work using:

• User impact: does the problem stop someone reaching important information?
• Search accessibility: does it prevent useful public content being discovered or interpreted?
• Confidence: can you reproduce the problem and explain its cause?
• Effort: can one shared template repair improve several affected pages?

Do not assume that every notice deserves equal attention.

Step 9: Recheck the published website

Editing a local file is not the same as fixing the public page. Confirm that the change was deployed, that caching is not serving the old response and that the affected URL still works on mobile.

Run a comparable follow-up audit. Review the affected check and page evidence rather than celebrating only the overall number. If a warning remains, compare the returned HTML with what you expected the deployment to serve.

Then monitor outcomes over time. Better navigation may help visitors immediately, while search discovery and ranking changes require separate observation. There is no guaranteed timetable connecting a technical edit to a particular Google position.

When Sonar is the right starting point

Sonar is useful when you need a focused, free technical review and want to understand the evidence behind a finding. It is not a substitute for a global backlink database, independent keyword-volume research or Google’s own indexing records.

If your next question involves competitor backlink profiles or broad search-market research, read Sonar vs Ahrefs vs Semrush. Different tools answer different questions, and choosing the right evidence is more useful than expecting one score to answer everything.

Start with one important page in Sonar, fix a problem you can explain and recheck the published result. That repeatable habit is a stronger foundation than collecting warnings without acting on them.