--- title: "DIY website audit: useful checks and when to get help" description: "Carry out a focused DIY website audit of content and important journeys, record useful evidence, and recognise where specialist investigation is needed." url: https://fkweb.dev/en/insights/diy-website-audit/ lang: en-GB alternates: en: https://fkweb.dev/en/insights/diy-website-audit/ fr: https://fkweb.dev/fr/articles/auditer-site-soi-meme/ nl: https://fkweb.dev/nl/inzichten/zelf-website-auditen/ de: https://fkweb.dev/de/wissen/website-selbst-pruefen/ x-default: https://fkweb.dev/en/insights/diy-website-audit/ --- 1. [Home](https://fkweb.dev/en/) 2. [Insights](https://fkweb.dev/en/insights/) 3. Can you audit your website yourself? # Can you audit your website yourself? Carry out a focused DIY website audit of content and important journeys, record useful evidence, and recognise where specialist investigation is needed. By [Fernando Kylas](https://fkweb.dev/en/about/)23 July 20258 min read You can audit parts of your website yourself, especially the accuracy of its information and the behaviour of important customer journeys. A focused DIY website audit can reveal problems worth addressing and give a specialist a better starting point. It does not have to become an attempt to certify every technical aspect of the site. I would begin with a small set of realistic tasks and a simple evidence record. Note the page, what you tried, what happened, and why it matters. This makes the exercise useful even if you cannot yet explain the cause. A reproducible observation is stronger than an alarming score without context. Treat the review as investigation rather than an immediate repair session. A tool’s suggestion can raise a useful question without providing enough information for a live configuration change. The aim is to understand where the website fails its task, what is already working, and which uncertainty deserves further attention. ## Define a manageable review around the business Choose a meaningful boundary. You might review how a potential customer finds a service and makes an enquiry, or how someone checks event information. Avoid trying to inspect every page and every setting in one sitting. A focused route can produce a clearer decision than an unfinished catalogue of unrelated issues. Write down who the visitor is and what they need to accomplish. Use a plausible starting point rather than assuming everyone begins at the homepage. A person arriving on an article needs a route towards relevant services; an existing customer looking for instructions may have a different task. Include the business outcome without inventing a performance target. A successful enquiry journey should deliver the intended information to the responsible person. Whether it attracts enough suitable prospects is a wider question. Keeping those levels separate prevents a functional check from becoming an unsupported claim about conversion. My guide to what a website audit should include explains how scope influences the usefulness of findings. For an initial review, state what you examined and what remains outside it. That boundary helps a later specialist understand what your observations can establish. ## Check the offer and factual information Read important pages as someone unfamiliar with the business. Can you understand the service, who it suits, what is included, and what happens next? Check contact details, relevant locations, conditions, and any displayed prices. Compare the text with the current offer, not with your memory of what was approved at launch. You are well placed to recognise factual errors that a public tool cannot know. A technically sound page might describe an activity the business stopped offering. A profile might name an old contact person. Record the correction needed and who has authority to confirm it before changing uncertain details. Inspect the support for important claims. A statement about results should have evidence appropriate to that result. A project example should describe real work accurately. If you cannot verify a published assertion, mark it for investigation rather than assuming publication proves it was checked. Consider missing conditions as well as wrong statements. For an illustrative training provider, a course page might explain its subject clearly but omit dates or the method of checking availability. The page can be attractive and accurate yet still leave a prospective participant unable to make the next decision. ## Follow one journey through to its real outcome Begin at the chosen entry point and follow the intended route. Note what information you need at each stage and whether it is available. Repeat on a phone where practical. This is a review of the connected experience, not just a check that each page opens separately. Coordinate any test submission with whoever receives it and label it clearly. Avoid creating real purchases or bookings merely to see what happens. Where a complete transaction needs testing, arrange an appropriate method with the responsible team. The test itself should not create uncertainty for customers or staff. For a permitted enquiry test, check the result inside the business as well as the success message. Did the intended recipient receive it, with the relevant information? Does the visitor understand the next step? A reassuring screen does not establish that the operational part of the journey completed. Separate observed failure from an assumed cause. If a message did not arrive, record that outcome and the conditions before blaming the form, email service, or hosting. A useful report describes the symptom precisely enough for someone to investigate the connected systems without starting from a guess. ## Examine navigation and ordinary interaction Review the main menu, important links, buttons, and form instructions along the route. Do labels explain the destination or action? Does a link lead to the expected page? An action can function technically while its wording leaves the visitor uncertain about commitment or what will happen next. Use realistic content and inspect expected error feedback where practical. An empty required field should not leave the person without a useful next step. Observe whether instructions remain understandable when the layout changes. Record the actual interaction instead of judging the control only from its normal appearance. Try moving through the route with a keyboard and enlarging text. These observations may expose barriers, but your own successful attempt does not establish that the site is accessible to everyone. Your knowledge of the page can also make an unclear interaction easier for you than for a new visitor. W3C’s [initial accessibility checks](https://www.w3.org/WAI/test-evaluate/preliminary/) are explicitly a first review, not a comprehensive assessment. My article on accessibility scope and testing develops that boundary. Report what you found without claiming a level of assurance that the method cannot support. ## Use available account evidence carefully If you have authorised Search Console access, review information relevant to the pages and question under examination. Google’s [introductory guidance](https://developers.google.com/search/docs/monitor-debug/search-console-start) describes its indexing and search-performance information. That account evidence can complement what you observe on the public website. Ask whether a report concerns a page that should fulfil a particular search role. Do not assume every excluded URL should be indexed or every short-term change indicates a persistent fault. A finding becomes more useful when linked to the intended page purpose and a suitable comparison period. Record the date range and filters behind any observation. Comparing a complete month with a partial month can create a misleading impression. A change in one page’s activity also needs context before it is described as a whole-site problem. Preserve enough detail for the comparison to be checked later. Where access or measurement is missing, record the gap. A public search or a colleague’s recollection cannot substitute for unavailable account data. You can still identify a question for investigation without supplying guessed figures or suggesting that the absence of evidence proves either success or failure. ## Treat tools as aids rather than repair instructions A public checker can reveal page characteristics, broken destinations, or potential technical concerns. Its results depend on access and test conditions. Read the explanation behind a warning and identify the affected task before deciding what work it warrants. Not every flagged item has equal consequence for your website. Save the tested URL, date, relevant settings, and useful result. If you repeat a check, note material differences in conditions. Otherwise, a changed score might reflect the test rather than a website change. A comparison should answer a question, not become an endless search for a perfect number. Avoid installing a collection of tools simply to make the review feel complete. Start with the information available and use additional methods where they resolve a specific uncertainty. A tool that produces more findings does not necessarily make the diagnosis clearer or help identify the right priority. My article on [using ChatGPT for a website audit](https://fkweb.dev/en/insights/chatgpt-seo-audit/) explains another version of this distinction. An automated explanation can suggest a useful hypothesis while missing important context. Verify the finding against the actual page and system before treating the proposed cause or remedy as established. ## Recognise when specialist investigation adds value Get appropriate help when the issue involves unfamiliar server settings, complex integrations, suspected compromise, or a failure with significant consequences. A public review may not provide the access or expertise needed. Describe the evidence and urgency rather than attempting an improvised repair beyond what you understand. Recurring symptoms also deserve a deeper diagnosis. If the same problem returns after repeated fixes, another scan may reproduce the warning without explaining the cause. A specialist should connect observations, examine relevant systems, and explain what evidence supports the proposed response. The value lies in the investigation, not simply the report’s length. Do not use destructive changes to content, redirects, plugins, or accounts as casual experiments. A live change needs an understood purpose, an appropriate recovery arrangement, and checks of its consequences. A diagnostic warning alone does not establish that the suggested intervention is safe or suitable for this implementation. Professional involvement can remain focused. You may need interpretation of one important finding rather than a complete redesign or a large audit programme. Ask what question the work will resolve and what information is needed. A proportionate engagement should build on useful observations you already gathered. ## Turn observations into a decision someone can act on Group findings by affected task. For each important item, include the page, action, observed result, practical consequence, and any uncertainty about cause. Keep screenshots or records that clarify the issue. Avoid surrounding a reproducible problem with unrelated warnings that make the brief harder to understand. Distinguish prompt attention from further investigation and optional improvement. A confirmed failure in a main enquiry route deserves a different response from a minor presentation preference. Do not assign urgency solely from a tool’s colour or label. Explain the consequence and identify who can assess or correct it. After a correction, repeat the relevant task and record the result. My article on [what happens after a website audit](https://fkweb.dev/en/insights/after-website-audit/) explains why recommendations need follow-through. Closing a finding should mean the relevant behaviour was checked, not merely that someone reported making a change. A useful DIY website audit ends with clearer evidence and a manageable next decision. You do not need to explain every technical cause yourself. Knowing what you observed, what matters to the business, and where your review stops can be enough to make the next professional conversation more precise and worthwhile. ## Related services - [UX audit](https://fkweb.dev/en/services/ux-audit/) - [SEO and AI search](https://fkweb.dev/en/services/seo/) [All insights](https://fkweb.dev/en/insights/) Next step ## Have a project in mind? Let us talk it through. Tell me what exists today and what needs to change. I reply within 2 business days, in English or French. [Start a project](https://fkweb.dev/en/contact/)Or email me directly [thatsme@fernandokylas.com](mailto:thatsme@fernandokylas.com)