Sam Na writes practical guides on AI-assisted productivity, digital workflows, and systems that help people create more reliable digital work. His RoutineOS articles focus on turning AI-generated results into useful processes that people can understand, check, and improve.
An AI-generated website can look finished while its contact form goes nowhere, its mobile navigation hides important pages, or its main button leads to an unfinished screen. A useful pre-publish review checks what visitors can actually read, understand, and do. The goal is to catch those problems while you can still correct them without confusing real visitors.
A practical AI website review combines automated checks with human testing. AI can identify suspicious content, inconsistent page structures, and possible usability problems, but it cannot prove that a form submits correctly, that a visitor understands the offer, or that a page works on every device unless those behaviors have actually been tested.
You have asked an AI tool to build a website, refined the layout, replaced the temporary copy, and reached a preview that looks ready to share.
Now imagine opening that site as a visitor who has never seen your project. You tap the menu on your phone, read a service description, press the main button, and complete the contact form. The page displays a cheerful success message, but the business never receives the inquiry.
The design looked complete. The visitor's task was not.
That is the reason to review an AI-generated website before publishing it. A visual preview tells you how the site appears under certain conditions. It does not automatically establish whether the site's content is accurate, whether interactions lead to real outcomes, or whether the same experience remains usable on other screens.
AI-generated websites deserve the same practical testing as websites assembled manually. The difference is that conversational generation can produce a large amount of interface and code before anyone has inspected the individual decisions behind it.
A button may be connected to a placeholder action. A form may only imitate submission. A generated testimonial may sound authentic without referring to a real customer. A responsive layout may work at one width and break a few pixels below it.
Rather than asking AI to make the entire site better, review the website in separate passes. Each pass should have a clear question and a result you can verify.
A website is ready for visitors when its important promises, paths, and interactions have been checked against reality—not merely when the AI preview looks polished.
Set up a review version and prioritize real risks
Before testing the site, make sure you know which version you are reviewing.
AI builders make changes quickly. That convenience can become a problem if the homepage changes while you are testing its links, or if another prompt replaces a form you have already approved.
A stable review version gives every test a reliable starting point. It also makes failures easier to reproduce because you can identify what the site looked like when the problem occurred.
Keep the review environment separate from public traffic
Where possible, use a private preview, staging URL, unpublished version, or temporary deployment that is separate from the public site.
The exact option depends on the platform. Some AI website builders provide preview links and publishing controls. A code-based project may use a staging environment or a separate deployment.
The important requirement is that reviewers can inspect the website without exposing unfinished pages to ordinary visitors.
A staging environment should resemble the eventual public environment closely enough for meaningful testing. If the production version uses a different domain, form service, payment configuration, or content database, record those differences because they can affect how the site behaves after publication.
Do not use real customer records or sensitive credentials simply to make a preview feel realistic. Create test data and use sandbox services when the feature supports them.
Give each page a practical acceptance test
A vague review question such as “Does this page look good?” is difficult to answer consistently.
A better question describes something observable. For example, a service page should explain the service, show the important conditions, and lead visitors to the correct inquiry route. A resource page should make the information readable and help visitors move to the next relevant resource.
Consider a fictional bicycle-repair business that has generated a five-page website with AI. The homepage introduces the service, another page explains repair categories, an FAQ handles common questions, and a contact page accepts quote requests.
The launch review should test those responsibilities rather than judge every page by the same generic design standard.
Check whether a new visitor can identify the service, relevant location or service area, and primary next action without reading the entire site.
Confirm that the descriptions, limits, inclusions, and next steps match what the business can actually provide.
Test the form, input validation, confirmation state, notification delivery, and the route by which the business receives the request.
Look for accurate, useful answers rather than generic text or claims that the business never confirmed.
Rank issues by consequence, not appearance
You are likely to find more issues than you can fix at once. Some will prevent visitors from using the website, while others will involve visual preferences that have little effect on the experience.
Put those findings into different priority levels.
A broken contact form on a lead-generation website may be a launch blocker. A primary navigation item that cannot be reached by keyboard may also prevent people from using the site. A slightly uneven decorative margin is unlikely to deserve the same urgency.
These categories are a practical review method rather than a formal industry grading standard. The right priority depends on the purpose of the site and the people who use it.
Review a stable version of the website, define what each important page must accomplish, and prioritize problems by their effect on real visitors. A reliable launch review begins with clear pass conditions, not a collection of visual opinions.
Test mobile layout, navigation, and links
Mobile testing should begin with the actual visitor experience rather than a screenshot of a narrow desktop browser window.
Responsive design can look correct in a generated preview while behaving differently when someone scrolls, opens a menu, fills out a field, or taps a small target on a phone.
A desktop browser's device simulator is useful for finding layout issues. Testing on physical devices adds another perspective because touch behavior, mobile keyboards, browser controls, and available screen space can change how the interface works.
Test the layout at more than one screen width
Open the homepage and the most important interior pages at several widths. Include a narrow phone, a larger phone, a tablet-sized view, and desktop.
Do not assume that a layout is safe simply because it looks good at the specific width used by the AI preview.
Resize the viewport slowly and watch the points where content changes position. Cards may stop wrapping before a breakpoint activates. A long navigation label may push another item off the screen. A pricing or feature block may require horizontal scrolling because it has a fixed width.
Check the full page rather than just the hero. Generated layouts sometimes handle the first section well while leaving a footer, form, accordion, or nested component difficult to use on smaller screens.
Follow the navigation as a visitor would
A navigation menu can contain every planned page and still be difficult to use.
Open it on a phone. Select a section, return to the previous page, reopen the menu, and try another route. If the menu is collapsible, confirm that it closes when expected and does not trap content behind an overlay.
Look at how the current page is represented. Visitors should be able to understand where they are and return to a useful starting point without guessing.
On desktop, try the same journey without using the mouse. You will perform a more thorough keyboard accessibility review later, but this first pass may already expose a menu that works only when someone hovers over it.
It is also worth asking someone who has not worked on the project to find a particular page. Give them a task such as locating repair prices or finding out whether the business serves their neighborhood. Watch where they click before explaining the navigation.
Open every important link instead of trusting its label
AI-generated interfaces often contain realistic-looking buttons and links. Their labels can be correct even when their destinations are missing, temporary, or unrelated to the surrounding content.
Create a simple link inventory for the main navigation, homepage CTAs, footer, contact details, and important cross-page links.
Open each destination. Confirm that it loads the intended content and that the visitor can continue the task after arriving.
Pay special attention to links that are easy to overlook during visual review: email addresses, phone numbers, downloadable files, in-page anchors, external resources, social profiles, and links hidden inside cards.
A button labeled “Request a Quote” has a hover effect and changes color when tapped, but the action may lead to an empty route or an unfinished form.
The button opens the correct quote request page, the page loads successfully, and the visitor can complete the action it promises.
For larger sites, a link checker or crawler can help identify broken URLs. Manual testing remains useful because a link can return a successful response while displaying the wrong page or an irrelevant destination.
Do not mark a navigation or link check as passed because the element can be clicked. Confirm where it goes, what appears after the click, and whether the destination supports the visitor's original task.
Inspect the full site at multiple viewport widths, use the mobile menu on an actual device when possible, and follow real visitor paths. Test link destinations as working journeys rather than treating clickable styling as proof of functionality.
Prove that CTAs and forms actually work
The main call to action is one of the most consequential parts of a website because it connects the visitor's interest to an actual outcome.
If your site is intended to generate inquiries, a broken form can make the entire project ineffective even when every other page looks attractive.
If the website collects signups, reservations, orders, or applications, the standard should be equally practical: a visitor must be able to complete the action and receive an appropriate result.
Trace each CTA to its real outcome
Start with the primary CTA on the homepage. Follow it all the way through the intended journey.
For example, a button labeled “Request a Repair Quote” should lead to a place where a visitor can provide the information needed for an estimate. A button labeled “View Services” should open the relevant service information rather than a generic homepage section that does not answer the question.
When the visitor finishes the action, the interface should tell them what happened and what to expect next.
Do not stop testing at the first click. The destination, required input, completion step, and confirmation all belong to the same task.
Test form success, failure, and recovery
Forms deserve separate attention because an AI can generate their appearance without connecting them to the service that processes submissions.
A working form requires more than fields and a Submit button.
Enter valid test data and submit it. Then confirm that the intended recipient or system actually receives the information. A success message alone is not sufficient evidence of delivery.
Next, try submitting an empty required field, an incorrectly formatted email address, and a longer message. The form should explain the problem clearly and allow the visitor to correct it without unnecessarily losing previously entered information.
Where applicable, test what happens when the network connection fails or the receiving service is temporarily unavailable. The website should not display a false success state when the submission was unsuccessful.
Review what happens to submitted information
Once a website accepts information from visitors, the review must include what the site collects, where it sends that information, and who can access it.
Check whether the form requests information that is genuinely needed. Confirm that submitted records are delivered only to authorized recipients and that any connected services have been configured for the intended environment.
If the site needs a privacy notice, consent mechanism, retention policy, or another disclosure, determine those requirements from the actual service, audience, and applicable rules rather than accepting generic legal text generated by AI.
Do not enter real payment information, passwords, sensitive personal records, or production credentials into an unverified prototype to see whether it works. Use supported test modes and appropriately restricted test accounts.
A form that says “Message sent successfully” without sending the message is a functional failure. A form that exposes submitted information to unauthorized people is a more serious problem. Both require correction before visitors are invited to use the feature.
Test the complete conversion path, not just its appearance. Every important CTA should lead to the promised destination, and every form should be tested for valid submissions, errors, confirmation, delivery, and appropriate handling of visitor information.
Review content accuracy and usability
A generated website may use confident, polished language that makes unverified information feel authoritative.
This is especially risky when AI fills missing details with plausible business claims. An invented service guarantee or fictional customer quote can appear perfectly natural inside a finished layout.
The content review should compare the website with actual source material and test whether the wording communicates clearly to a new visitor.
Build an inventory of claims that need evidence
Read the website page by page and highlight statements that a visitor might reasonably rely on.
Look for prices, service areas, opening hours, business addresses, staff qualifications, performance claims, product capabilities, refund conditions, turnaround times, guarantees, and customer testimonials.
Compare each consequential statement with the source of truth: the business's approved information, product documentation, service agreement, official policy, or another authoritative record.
Do not use another AI model's confidence as evidence that a claim is correct. The second model may repeat a plausible assumption without knowing that the information was invented during the first generation.
Review the website copy against the approved source material I provide. Do not infer missing facts. Extract claims about prices, services, locations, qualifications, guarantees, product behavior, testimonials, availability, and other details visitors may rely on. For each claim, identify its page or section and classify it as SUPPORTED, NEEDS CLARIFICATION, CONTRADICTED, or NOT VERIFIED. Do not rewrite the claims until I have reviewed the findings. Website content: [PASTE CONTENT]. Approved sources: [PASTE SOURCES].
Read the copy as someone who has never seen the project
Accuracy is necessary, but a factually correct page can still be difficult to understand.
Read the homepage without referring to your original brief. Can you tell what the site offers, who it serves, and what action someone should take? Do the service descriptions distinguish the options, or do they rely on general language such as “innovative solutions” and “exceptional experiences”?
AI-generated copy often sounds complete because it uses fluent sentences and familiar marketing patterns. Those patterns may hide a lack of detail.
Replace vague claims with specific information the organization can substantiate. Explain what is included, how the process works, who should use the service, and any conditions that affect the visitor's decision.
Do not make every paragraph longer. Sometimes clearer copy is shorter because it removes filler and places the useful information closer to the beginning.
“We deliver innovative, customer-focused solutions designed to exceed expectations.” The statement does not identify what the business provides or what the visitor should expect.
“Request a repair estimate by describing the bicycle problem and choosing your preferred contact method.” This explains a real action without inventing a service promise.
Check consistency across the entire site
AI may generate pages in separate sessions or revise one section without updating related content elsewhere.
As a result, the homepage might describe three service categories while the navigation displays four. A contact page might mention a response time that does not appear in the approved business information. Different pages may use different names for the same feature.
Compare key details across the homepage, service pages, contact page, FAQs, and footer. Identify the official wording for product names, services, locations, contact details, and primary CTAs.
For larger sites, AI can help extract these details and highlight inconsistencies. You still need to decide which version is correct based on the original source.
Review AI-generated website copy against approved facts, then read it as a new visitor. Remove unsupported claims, replace vague marketing language with useful information, and make sure important details remain consistent across pages.
Check accessibility beyond automated scores
Accessibility belongs in the pre-publish review because a website can appear easy to use while excluding visitors who navigate differently.
Someone may use a keyboard rather than a mouse. Another person may enlarge text, use a screen reader, or rely on captions and clear form labels.
Automated testing tools can identify certain accessibility problems, but they cannot determine whether every interaction makes sense or whether the entire experience works for people with different needs.
The W3C Web Accessibility Initiative provides practical starting checks for page titles, headings, text alternatives, contrast, zoom, keyboard access, and forms. Its guidance also emphasizes that passing quick checks does not establish complete accessibility. See W3C's official Easy Checks resource.
Navigate the website without a mouse
Open the site in a browser and move through its interactive elements with the keyboard.
Use Tab to move forward through links and controls, and Shift+Tab to move backward. Try Enter or Space to activate the controls that should respond to those keys.
Watch the visible focus indicator. You should be able to tell which link, button, or form field is currently selected.
Open and close menus, follow links, use accordions, and move through forms. If the site contains a modal or another overlay, check whether focus behaves logically and whether you can leave the component without becoming trapped.
Pay attention to custom AI-generated widgets. A clickable visual element is not necessarily a semantic button, and a menu that reacts to mouse hover may not respond to keyboard input.
Review headings, form labels, images, and contrast
A visually attractive hierarchy is not automatically a meaningful document hierarchy.
Check that major sections and subsections use headings according to their relationships. A large decorative line of text should not replace the page's actual heading structure.
Form controls need understandable labels that are programmatically connected to the relevant fields. Placeholder text alone may disappear as someone types and should not be treated as a substitute for a proper label.
Images also need attention. Informative images should have text alternatives that communicate their useful meaning. Decorative images generally need an empty text alternative so they do not add unnecessary announcements for screen reader users.
Finally, examine text contrast. Light gray text on a white card may look sophisticated in a generated design but become difficult to read. Use a contrast checker rather than relying on appearance alone.
Enlarge the page and inspect the reading order
Use browser zoom and text enlargement to see whether the layout continues to work when content occupies more space.
Watch for navigation items that disappear, buttons that overlap, text that is clipped, and dialogs that become impossible to close.
Next, consider the order in which the content would be read without its visual styling. A design may place a card beside a paragraph for visual balance, but the underlying reading sequence still needs to make sense.
If possible, test the primary page journey with a screen reader and with someone who is unfamiliar with the site. These checks can reveal problems that a visual scan or automated report does not explain.
Use accessibility tools as evidence, not certification
An accessibility checker can identify issues such as missing labels, insufficient contrast in detected elements, or certain semantic markup problems.
It cannot guarantee that every sentence is clear, every custom interaction is usable, or every accessibility requirement has been satisfied.
Run automated checks to find potential problems. Then manually review the important interactions and apply the accessibility requirements relevant to the website.
For projects with legal, contractual, institutional, or other formal accessibility obligations, a qualified accessibility review may be needed beyond this initial checklist.
A perfect automated accessibility score is not proof that a website is fully accessible. Treat the tool as one reviewer, then test how real people can navigate, understand, and complete important tasks.
Combine automated accessibility checks with keyboard navigation, meaningful heading and label review, contrast testing, zoom, and reading-order inspection. Real usability requires more evidence than a single score.
Check performance and technical SEO
Once the website's core interactions are working, inspect whether the pages load reasonably well and whether search engines can discover the content you intend to publish.
These are different questions.
A fast page may still have incorrect indexing settings. A page with correct SEO metadata may feel slow because its main image is unnecessarily large or its scripts delay interaction.
Review the visible loading experience and the technical settings separately so that one successful check does not hide another problem.
Use PageSpeed Insights to investigate performance
Google PageSpeed Insights reports on mobile and desktop performance and provides diagnostic suggestions.
Where sufficient data exists, it can show field data from real Chrome users. It also uses Lighthouse to perform laboratory testing under simulated conditions.
Those two types of information serve different purposes.
Field data describes real-world experiences over a collection period, while lab testing helps identify specific problems in a controlled environment. A newly published website may not yet have enough real-user information for page-level field data.
Open Google PageSpeed Insights, enter the URL of an accessible test page, and inspect the mobile and desktop results. Private previews may not be reachable by the service, so use an appropriate accessible environment without exposing sensitive staging content.
Understand the Core Web Vitals before chasing scores
Core Web Vitals focus on three measurable aspects of the user experience: loading, responsiveness, and visual stability.
Google's recommended good thresholds are shown below. They are measured using the 75th percentile of page experiences, separately for mobile and desktop.
These are Google's published Core Web Vitals targets, not guarantees of search rankings or proof that every visitor will have a good experience. See Google's Web Vitals documentation.
If a report identifies a problem, connect the metric to something observable.
A poor loading result may involve an oversized hero image or render-blocking resources. Slow interaction may involve heavy JavaScript or expensive work on the main thread. Unexpected layout movement may occur when images, advertisements, banners, or dynamic components appear without reserved space.
Do not change several unrelated parts of the website simply to improve an aggregate score. Identify the likely source, make a focused correction, and measure again.
Check whether large images, unnecessary scripts, font loading, or rendering dependencies delay the content visitors expect to see first.
Open menus, change filters, type into fields, and activate controls while watching for delays that make the interface feel unresponsive.
Look for text, images, buttons, or other elements shifting after they appear, especially when late-loading content enters the page.
Record the tested page and environment, change one likely cause, and compare results rather than judging a single run in isolation.
Check titles, descriptions, canonical URLs, and indexing settings
Technical SEO review should begin with the information search engines and visitors need to identify the page.
Each important page should have a descriptive title that matches its actual content. The meta description should accurately summarize the page rather than repeat generic sales language.
Google may generate search result snippets from page content or use the meta description when appropriate, so a written description is not a guarantee of the exact text that will appear in search results.
Check that the page's preferred URL is clear and that canonical settings, when used, point to the intended version. Confirm that the public page is not accidentally marked with a noindex directive or blocked in a way that prevents the intended search-engine access.
A preview or staging site may intentionally restrict indexing. Those protections should be reviewed separately from the final public configuration.
Google's SEO Starter Guide explains the role of descriptive titles, useful content, links, and page descriptions. Its noindex documentation explains how indexing directives operate and why blocking a page in robots.txt does not reliably substitute for noindex.
Review structured data without promising search features
AI can generate structured data quickly, but that does not mean the resulting markup accurately describes the website.
If the site uses Article, Product, Organization, LocalBusiness, FAQ, or another schema type, check whether the selected type is appropriate and whether the included fields match visible, verifiable information.
Do not add ratings, prices, author details, business locations, or other structured claims that cannot be supported by the actual page and source records.
Use Google's Rich Results Test for supported rich-result types and another schema validation method when needed. Passing syntax checks does not guarantee that Google will display a rich result, and some valid schema types are not eligible for a special Google Search appearance.
Google explains these boundaries in its structured data guidelines.
Do not treat a high performance score, valid structured data, or completed metadata as proof that the website will rank well. Those checks identify technical conditions. Search visibility also depends on whether the content is useful, accessible, and relevant to actual searches.
Measure page performance with the appropriate distinction between lab and field data, then investigate observable loading and interaction problems. Review public URLs, metadata, indexing directives, and structured data separately so technical settings do not undermine an otherwise usable website.
Run the final AI-assisted launch review
After the individual checks, you need one final process that turns scattered findings into a publication decision.
This is where AI can help organize the review, compare results across pages, and identify unresolved inconsistencies.
Its role should be narrow.
AI can review the information you give it, but it should not claim to have clicked a button, submitted a form, inspected a private page, or measured a website unless the connected environment actually allowed that test to run.
Give AI evidence rather than a vague request to improve everything
Provide the current page copy, screenshots where useful, page URLs that the tool can actually access, an inventory of links, relevant test results, and the list of problems you have already found.
Ask AI to identify additional review candidates without making changes immediately.
Keep content review separate from implementation review. A model can judge the clarity of a headline from the text you supply. It cannot prove that a form delivers notifications from a screenshot of that form.
Act as a pre-publish website reviewer. Review only the evidence I provide or pages you can genuinely access. Do not claim to have tested interactions, forms, accessibility, performance, or indexing if you have not performed those checks. Identify potential problems in mobile layout, navigation, link destinations, CTA clarity, factual accuracy, content consistency, form behavior, accessibility, performance, and search visibility. For each finding, provide the affected page or component, the evidence, why it matters, a suggested severity, and the exact manual test needed to confirm it. Separate VERIFIED ISSUES, SUSPECTED ISSUES, and NOT TESTED. Do not redesign or rewrite the website automatically.
Keep a short issue log that anyone can understand
A useful issue report should make a failure easy to reproduce.
Instead of writing “mobile layout broken,” record the page, browser, approximate viewport, component, and visible behavior. Explain what should have happened and what actually happened.
For example: “On the contact page at a narrow mobile width, the Submit button extends beyond the right edge of the screen. Expected: the button remains fully visible and usable without horizontal scrolling.”
That description is specific enough for a person or coding agent to act on. It also provides a clear condition for deciding whether the fix worked.
Use a launch gate instead of waiting for perfection
A website is unlikely to be completely free of minor imperfections.
The more useful question is whether any unresolved problem would prevent visitors from using the site safely and as intended.
Before publication, confirm that major visitor journeys work, consequential facts are correct, essential content is accessible, and the technical environment is configured for the intended audience.
If an issue remains, decide whether it blocks launch, needs a documented workaround, or can reasonably be handled after publication.
Perform a short smoke test after publication
The final pre-publish review cannot establish that every production setting will behave exactly like the preview.
Once the site is live, open the public URL directly and repeat the most important tests. Check navigation, the primary CTA, contact routes, and any feature that depends on the live domain or production configuration.
Confirm that the intended pages are publicly accessible and that private staging pages or temporary testing routes have not accidentally been exposed.
For forms or other connected services, use an appropriate safe test to confirm the live integration. If the site handles actual transactions, use the service's supported testing or verification procedure rather than creating unintended real charges.
Record anything that differs from the reviewed version and assign it an owner. The publication itself is another environment change, so it deserves a quick verification pass.
A launch-ready website is not one with no remaining design preferences to debate. It is one where the critical paths have passed meaningful tests, important claims are supported, and unresolved risks are understood rather than hidden by the finished appearance.
Use AI to organize evidence and identify issues for confirmation, not to manufacture a passing result. Keep reproducible findings, correct launch blockers, apply a clear release decision, and verify the critical public experience immediately after publishing.
Frequently Asked Questions
Publish a website that works, not just one that looks finished
AI has made it possible to produce convincing websites before every detail has been properly examined.
That is a useful capability during creation, but it changes the responsibility of the final review. A polished interface can no longer be treated as evidence that the website behind it is ready for visitors.
The review should begin with the site's real purpose. Identify the actions visitors need to complete, test those paths, and correct anything that prevents the intended outcome.
Then inspect the experience across devices. Follow navigation links, read the copy without relying on project knowledge, submit forms, and confirm that important information reaches the correct destination.
Check the content against authoritative sources and remove unsupported claims. Test keyboard navigation, form labels, headings, contrast, and the page's behavior when content is enlarged.
Use performance tools to investigate slow or unstable experiences. Review titles, public URLs, indexing settings, and structured data so that the technical configuration matches the website you intend to publish.
AI can help with much of this work, particularly when reviewing content, comparing screenshots, analyzing code, organizing issues, or suggesting focused corrections. Its findings become useful when they point to something a reviewer can confirm.
The goal of a website launch checklist is not to create endless opportunities for another round of editing.
It is to establish that the important parts of the website are accurate, usable, and working as intended.
Once the critical problems have been resolved, the remaining improvements can be managed through an ordinary maintenance process rather than allowing the website to remain permanently unfinished.
Open your AI-generated website as a first-time visitor on a phone. Find the main offer, follow its primary CTA, and complete the action all the way to a verified outcome. Record anything that fails or feels confusing. Fix the highest-impact problem first, then repeat the test before moving to accessibility, performance, and search settings. Build confidence from results you can actually verify.
Sam Na writes about practical AI workflows, digital productivity, and systems for making technology useful in everyday work. His RoutineOS guides focus on planning, building, testing, and improving AI-assisted projects through clear processes that help people understand what has been generated, identify what still needs attention, and make responsible decisions about the final result.
This guide provides general information about reviewing and improving AI-generated websites. The checks your site needs will depend on its purpose, audience, platform, hosting environment, features, and the information or transactions it handles. Automated tools and AI reviewers can miss important problems, and a basic checklist does not establish full accessibility, security, privacy, or legal compliance. Before publishing a consequential service or collecting sensitive information, review the latest official requirements and consider an appropriate technical, accessibility, security, or legal specialist where your project calls for one. Use the tests in this guide as a practical starting point and expand them according to the risks of your own website.
Official introductory guidance covering page titles, image alternatives, headings, contrast, keyboard access, form labels, and other accessibility checks, including the limits of preliminary evaluation.
Read the official W3C accessibility guidanceOfficial documentation explaining mobile and desktop performance testing, laboratory diagnostics, real-user field data, and how PageSpeed Insights reports performance results.
Read the official PageSpeed Insights documentationOfficial technical guidance describing Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and their recommended good-experience thresholds.
Read the official Web Vitals guidanceOfficial guidance on making website content understandable and discoverable, including descriptive page titles, search snippets, useful content, and crawlable links.
Read the official Google SEO Starter GuideOfficial documentation covering indexing directives, implementation methods, and the interaction between noindex and crawler access.
Read the official Google indexing documentationOfficial technical and content guidelines explaining how structured data should represent visible page information and why valid markup does not guarantee a rich result.
Read the official structured data guidelines