How to analyse your website

A website analysis checks four areas: search visibility, performance, usability and the user journeys that lead to enquiries or sales. The goal is to find the most important problems and decide what to fix first.

Want a quick technical first pass? Run an important page through the URL Analyzer, then use this guide to investigate the results and decide what matters.

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.

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: three findings on a service website

Imagine a review produces these findings. This is an illustrative example, not a report from a client project:

1. The mobile menu will not open. You reproduce it on several pages in the same browser. Visitors using that setup cannot reach the service and contact links through the menu. Investigate the shared menu first, then test it across the affected pages and with keyboard input.
2. The main service image appears slowly. Repeated tests show a large download delaying it. Once navigation works, resize and compress the image appropriately, then compare loading and visual quality under the same conditions.
3. A report flags a missing image description. Check the image’s purpose before editing it. An informative image needs a useful text alternative; a purely decorative image may correctly have an empty alt attribute. Resolve the warning based on the actual use.

The order comes from the effect on visitors and the evidence you have. 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.