Skip to content
Published
Updated

How to analyse a website

To analyse your website, check whether people can find its important pages, understand what you offer and complete an enquiry or purchase. Work through search visibility, speed, usability and the contact or booking process, then make a short list of problems to fix.

For automated technical checks on a public page, use the free URL Analyzer. The steps below add manual checks and help you decide which findings need attention.

You can do a useful first review yourself. Choose a few important pages, work through the checks below, and keep a short record of what you find. If you already know something is broken, start there.

Website analysis dashboard with technical SEO and performance signals

Choose the pages and tasks to check

Write down what a visitor needs to accomplish: understand a service, find a price, send an enquiry or complete a booking. This gives you something specific to test.

For a small business website, begin with the homepage, an important service or product page, and the contact or booking process. Include a page that receives search traffic if you have that information. On a larger website, sample each different page layout and any pages where visitors have reported problems.

Checking one web page tells you about that page. It does not establish that the whole website works. A shared menu fault may affect every page, while a broken booking calendar may affect only one important task. When you find a problem, check where else it occurs.

For each finding, save the URL, device and browser, what you tried, and what happened. A screenshot or the exact error message is more useful than a note saying “the form is broken”.

1. Search visibility: can the right people find the page?

Start with an important page that you want people to find through search. In Google Search Console, use URL Inspection to check its indexing status. Then look at the queries bringing impressions and clicks to that page. Do they relate to what the page actually offers?

Read the page with those visitors in mind. Does its title describe the subject accurately? Does the opening answer their question? Can they find the details they need to make a decision?

If a page is missing from search, investigate the reason before changing its copy. Google’s SEO starter guide explains the basics of discovery and indexing. The URL Analyzer can help you inspect technical signals on a public page, but it cannot confirm that Google has indexed it.

For problems across multiple pages, the technical SEO guides explain what to investigate next, including internal links, access restrictions and duplicate URLs. Keep deliberate exclusions, such as private account pages, separate from pages that should appear in search.

2. Performance: can visitors read and act without waiting?

Open the chosen pages on a phone and use them. Watch when the main content appears, whether text or buttons move while loading, and whether the menu and form respond when you touch them. Try a mobile connection as well as your usual Wi-Fi.

Run a page through PageSpeed Insights to investigate what you noticed. It combines a controlled lab test with real-user field data when enough is available. The lab test helps identify possible causes; field data describes previous visits. They can disagree because they measure different conditions.

  • Content appears late: look for large images, slow server responses or scripts delaying the page.
  • The layout jumps: watch for images, banners or embedded content arriving without space reserved for them.
  • A control reacts slowly: test the actual interaction. A page may look finished while its booking calendar or menu is still unresponsive.

These are starting points for investigation, not diagnoses. Repeat a test before drawing conclusions from one unusually slow result. Save the original result and use comparable conditions after making a change. Google’s PageSpeed Insights documentation explains the difference between lab and field data.

3. Usability: can people understand and use the page?

Read a service or product page as someone who knows nothing about the business. Can you tell what is offered, who it is for, what it costs or how to get a price, and what to do next? Missing information can make a technically sound page difficult to use.

Ask someone unfamiliar with the website to find a particular service or answer. Watch where they hesitate before giving directions. A menu label that makes sense inside the business may mean very little to a customer.

Accessibility belongs in this review too. Try these basic checks:

  • Use the keyboard to move through links, menus and forms. You should be able to see which control is selected and operate it without a mouse.
  • Zoom in and check whether text remains readable and important controls stay available.
  • On a phone, check for overlapping text, awkward sideways scrolling and buttons that are difficult to tap.
  • Check that form fields have clear labels and that errors explain what needs correcting. Colour alone should not carry the message.

WAVE can help flag issues such as missing labels and low text contrast. Automated checks and this short review cannot establish full accessibility. The W3C’s Easy Checks give practical instructions for a first review, with links to deeper evaluation.

4. User journeys: does the enquiry or sale actually complete?

Follow the whole route a customer would take. Start on a service or product page, find the next step, fill in the details and check the result. Test on mobile as well as desktop.

For an enquiry form, confirm all of the following:

  • You can find the form from the relevant page, and it asks for information you can reasonably provide.
  • An incomplete or invalid submission explains the problem and keeps the details you already entered.
  • A successful submission gives a clear confirmation and explains what happens next.
  • The enquiry reaches the intended inbox or customer system, with the details intact and a usable reply address.

A success message proves only what the interface displayed. Check that the business actually received the enquiry. If it did not, note the test time and ask the developer to trace the submission through the application and email service.

For a booking or checkout, include availability, total price, payment and confirmation. Use the provider’s test mode where possible, or arrange a controlled test with whoever handles orders so it does not create an unexpected charge or reservation.

Decide what to fix first

For each finding, ask who it affects, what it prevents and how certain you are about the cause. Then consider the effort and risk of the change.

I would put a confirmed problem that stops an enquiry, payment or essential interaction near the top of the list. A fault in a shared navigation or form component also deserves attention because one repair may help many pages. A lower score or an isolated warning needs a clearer explanation of its effect before it becomes a priority.

Keep suspected causes separate from confirmed facts. “The image is large” is an observation. “The main content stays blank while this image loads” is a specific problem you can investigate and retest.

Example: analysing this guide

In October 2026 I ran this review on webstudiet.com and started with this page. Over the previous six months, Search Console showed it with 20,000 of the website’s 23,095 impressions in Google, and one click. The review produced three findings:

  1. The page appeared in search but was not chosen. With almost no clicks, the title and description are the usual suspects. The average position, about 51, pointed somewhere else: very few searchers ever get that far down the results, so a better snippet would not have changed much. The website’s largest queries were broad searches such as “website analysis” and “analyze website”, and most people searching like that want a tool that checks their website, not a guide. The real question was which page should answer which search. I gave the URL Analyzer a title aimed at people looking for a tool and retitled this guide around how to do the analysis. Whether that works will only show in Search Console over the following months.
  2. The analyzer’s own advice was wrong in places. The CSP finding below came with a vague suggestion, so I went through every fix text the tool gives. One check failed pages without a robots meta tag and recommended adding index, follow. Google’s documentation says that indexing the page and following its links is the default, so the tag is not needed. I fixed the check rather than the pages. A finding from a tool is a claim to verify, even when I built the tool.
  3. A security header scored lower than it needed to. Mozilla’s HTTP Observatory gave the website a B+ because its Content Security Policy allowed inline scripts. On a WordPress website where plugins add their own inline scripts, removing that permission can turn into a long project, and I would often leave it. Here, only two small scripts from the build and one script that Cloudflare injects stood in the way, so the change was worth making. The grade went to A+.

I prioritised them in that order because search visibility concerns the page’s whole purpose, the wrong check could mislead anyone using the tool, and the security header was a smaller risk with a clear fix. A different website may need a different order.

Leave yourself a short, usable action list

Each task should record the affected page or component, the evidence, the proposed action, who will handle it and how you will check the result. For example:

Mobile menu: fails to open on the homepage, service page and contact page in the tested mobile browser. Screenshot and browser details attached. Developer to investigate the shared menu. After the fix, repeat those checks and confirm the links can also be reached and used with the keyboard.

You can usually correct unclear wording, missing information and ordinary content links yourself if you manage the content. Problems involving code, server settings, payments or message delivery may need a developer. Your test notes give them a useful starting point.

After a fix, repeat the original task and check the surrounding steps still work. Keep the same small selection of pages for future checks, especially after changes to navigation, templates, forms or booking integrations. Use the optimization guides when you need more detail on a particular improvement.

The analysis is useful when it leaves you able to say what needs attention, why it matters and how you will know it is fixed.

More articles