Webpage Audit Checklist for SEO, Content, Technical Quality & AI Search

Do not score a page before understanding its purpose

A good audit starts with the page's job. A tutorial, product page, local service page and login page should not be judged by the same content template. First identify the intended user, search intent and business goal; then evaluate whether the page performs that job well.

The first group checks are deliberately broader than a traditional SEO audit. They cover five universal areas: content and intent, on-page structure, technical SEO and performance, trust/UX, and AI-search visibility plus measurement. After those, the page shows how to add a site-specific quality profile rather than forcing every website into the same template.

Content quality and search intent

1. Clear page purpose: the visitor can understand what the page is for within the first screen.
2. Intent match: the content answers the problem implied by the target query rather than merely repeating keywords.
3. Direct opening: important questions are answered early before secondary background.
4. Original value: include first-hand experience, examples, calculations, screenshots, data, templates or observations when appropriate.
5. Complete coverage: answer the important subquestions without padding the article with unrelated sections.
6. Current facts: check dates, product names, interface steps, prices, laws, model names and other time-sensitive claims.
7. Evidence: support factual claims with primary or authoritative sources where verification matters.
8. Clear entities: use unambiguous product, company, feature and concept names instead of vague references.
9. Useful examples: show how the advice works in practice instead of relying only on definitions.
10. No fake freshness: update the modified date when the page has genuinely changed; do not change dates only to look recent.

On-page SEO and information architecture

11. Unique title: accurately describe the page and make the main topic clear.
12. Useful meta description: summarize the page for searchers without keyword stuffing.
13. One clear H1: align the visible headline with the page topic and search intent.
14. Logical H2/H3 structure: headings should help readers scan the answer in a meaningful order.
15. Descriptive internal links: connect the page to relevant tutorials, hubs and supporting pages using natural contextual anchors. Prefer links that genuinely help the reader continue the topic rather than adding links only for SEO.
16. Authoritative outbound sources: cite original documentation, standards or research when it adds trust or context.
17. Descriptive image alt text: describe informative images for accessibility; decorative images do not need keyword-heavy alt text.
18. Useful captions/media context: explain what screenshots, charts and videos demonstrate.
19. Breadcrumbs: help users and search engines understand where the page sits within the site structure.
20. Relevant structured data: use supported markup that matches visible content. Do not add schema simply because a type exists on Schema.org.

Technical SEO, indexing and performance

21. Correct HTTP status: real pages should normally return 200; redirects should be 3xx; missing pages should return 404/410.
22. Crawlable when needed: important pages should not be unintentionally blocked by robots.txt, CDN rules or authentication.
23. Indexable when intended: check robots meta tags and X-Robots-Tag headers for accidental noindex instructions.
24. Canonical is correct: important pages should point to the preferred URL, and duplicates should not send conflicting canonical signals.
25. Sitemap consistency: include canonical indexable URLs; remove redirects, broken URLs, duplicates and noindex pages.
26. Mobile usability: content, controls, tables and navigation should work on small screens without hiding essential information.
27. LCP: optimize the loading of the main visible content, especially large hero images, fonts and render-blocking resources.
28. INP: keep interactions responsive by reducing long JavaScript tasks and unnecessary main-thread work.
29. CLS: reserve space for images, ads and embedded media to avoid disruptive layout shifts.
30. Broken links and crawl traps: fix broken internal links and control unnecessary URL combinations, internal search or faceted-navigation patterns.

Trust, usability, accessibility and conversion

31. Simple navigation: users can reach the next logical page without hunting through the site.
32. Readable typography: use comfortable font sizes, spacing and contrast across desktop and mobile.
33. Intrusive elements controlled: pop-ups, sticky banners and ads should not obstruct the main content.
34. Author/publisher context: make it clear who created the content when that information helps users judge trust.
35. About/contact transparency: make business or publisher information easy to find when relevant.
36. Commercial disclosure: label sponsored, affiliate or paid relationships appropriately.
37. Higher standards for high-stakes topics: health, finance, legal and safety content should use strong sourcing, appropriate expertise and clear limitations.
38. CTA matches user intent: the next action should be relevant rather than interrupting the task.
39. Security and privacy: use HTTPS and handle personal data, forms, consent and tracking responsibly.
40. Local information is accurate when relevant: keep business name, contact details, service area, hours and Business Profile information consistent.

AI Overviews, AI Mode and modern search visibility

41. Eligible for normal Search: to be a supporting link in AI Overviews or AI Mode, the page must first be indexed and eligible to appear in Google Search with a snippet.
42. Important information is in text: do not hide the only explanation inside an image, animation or video.
43. Strong internal discovery: connect the page from relevant hub and supporting pages so its topical context is clear.
44. Useful media supports the text: original screenshots, diagrams and video can clarify concepts when they genuinely help users.
45. Structured data matches visible content: markup can help Google understand page information, but there is no special “AI Overview schema.”
46. No special AI file required for Google Search: Google says you do not need new machine-readable AI files or special AI markup to appear in its AI features.
47. Answer specific subquestions clearly: use concise definitions, comparison tables and step-by-step sections when those formats best help the reader.
48. Cite strong primary sources: make factual claims easy to verify, particularly for changing or high-stakes information.
49. Measure in Search Console and GA4: AI Overviews and AI Mode activity is currently included within Search Console's Web performance data rather than provided as a separate AI-search report.
50. Measure outcomes, not only clicks: monitor engagement, leads, sales, sign-ups or other meaningful actions after users arrive.

Add a website-specific quality profile

The universal checks can be used on almost any website. The next layer should reflect what the website actually publishes and how its users interact with it. A technical tutorial site, ecommerce store, local-service website and news publisher need different implementation checks.

Treat this second layer as a reusable site quality profile. Keep the universal audit stable, then change the site-specific checks to match the website's content model, templates, user journeys and recurring QA problems.

Plus2Net technical tutorial quality profile

The following checks come from practical modernization work across Plus2Net tutorial sections such as Python, PHP, JavaScript, HTML, SQL, ASP and Photoshop. They are intentionally more specific than the universal audit because a technical learning page can fail even when its basic SEO is correct.

51. Interactive accessibility: forms, buttons, menus and interactive demos should use meaningful labels, real interactive elements, keyboard access and usable focus behaviour. Controls should remain usable on mobile, forms should be responsive, and the page should not create unnecessary horizontal overflow.
52. Classify the page before auditing it: determine whether the URL is a substantive tutorial or reference page, hub/index page, demo or helper, exercise or quiz, redirect, shared include/template, tool, or downloadable resource. Apply the checks appropriate to that page type instead of forcing every URL to behave like a normal article.
53. Match QA claims to the testing actually performed: distinguish static checks such as source inspection, linting, metadata review, sitemap reconciliation and link validation from browser or runtime checks such as rendering, clicks, forms, JavaScript behaviour, video playback, database or session behaviour and network requests. Do not claim that runtime behaviour was tested unless it was actually exercised.
54. Check section-wide crawlability and orphan pages: audit the section as a connected internal-link graph, not only as individual pages. Important indexable pages should have a logical crawlable route from the section homepage or their primary hub. Identify orphan pages, missing hub-to-child links, accidental self-links and pages discoverable only through the XML sitemap.
55. Answer near the top: explain the concept, task or function early so the learner understands what the page will help them do before moving into deeper detail.
56. Logical learning sequence: where appropriate, organize the tutorial as definition or purpose → syntax → simple example → explanation → advanced examples or variations.
57. Table of contents for long pages: long tutorials should provide jump navigation near the top so users can move directly to the section they need.
58. Section anchors and long-page navigation: every TOC link should use a unique working ID, and very long pages should make returning to the top or moving between sections easy.
59. Breadcrumb follows the real learner path: place the breadcrumb at the actual top of the learner content and make it reflect the page's primary information hierarchy. Include the relevant pillar or sub-pillar when one genuinely exists. The current page should be the final plain-text item, not a clickable self-link.
60. Related topics and learning path: provide genuinely relevant parent, sibling, previous, next or practical follow-up tutorials so the learner is not left at a dead end. Use descriptive anchor text and avoid linking the current page to itself. A shared generic footer can support navigation, but it should not replace page-specific contextual links or useful Further Reading recommendations.
61. Pillar or hub relationship: important pages should belong to a clear primary subject hub or learning cluster. The hub should provide normal crawlable links to its intentional substantive child pages, while overlapping topics can receive contextual links from secondary hubs where useful. An XML sitemap should support discovery, not replace the site's learner-facing internal-link architecture.
62. Sitemap-assisted contextual internal linking: review the relevant section sitemap or site URL inventory, identify natural topic matches in the page text, and link the first useful occurrence of a matching term to the best supporting tutorial. The link may stay inside the same section or cross into another section when that helps learning. For example, a Python MySQL tutorial can link the first natural mention of SELECT or WHERE to the corresponding SQL tutorial. Avoid forcing links, repeating the same link on every occurrence, or linking terms that do not genuinely help the reader.
63. Preserve useful original material and functionality: modernization must not accidentally remove unique explanations, examples, source code, forms, controls, outputs, demos, helper or processor files, downloads, notebooks, sample data, screenshots, videos, diagrams or shared facilities that still provide learner value. Obsolete or unsafe material may be corrected, consolidated, clearly labelled as historical, or replaced with a better equivalent.
64. Remove only genuine duplication: two examples should not be merged merely because the code looks similar; preserve them when each demonstrates a different concept, option or result.
65. Token-level syntax coloring: learner-facing code should visually distinguish meaningful tokens such as keywords, strings, variables, comments and SQL clauses rather than applying one color to the whole block.
66. Code remains copyable: syntax highlighting and HTML escaping must not alter, hide or corrupt the code a learner copies.
67. Complete runnable example first: when useful, provide one complete working example before shorter fragments that demonstrate only a changed option or technique.
68. Progressive examples explain the change: when a later example modifies earlier code, clearly identify what changed and why instead of making the learner compare two large blocks manually.
69. Displayed PHP variables remain literal: when PHP code is embedded inside a host-page PHP string or echo, variables intended for learners such as $query, $row or $dbo must be escaped in the source so the rendered tutorial displays them literally rather than interpolating them.
70. Code syntax is validated: PHP, JavaScript, SQL, Python and other executable examples should be checked for syntax errors before publishing.
71. Modern safe coding practice: newer examples should prefer current safe techniques such as validation, escaping and prepared database statements. Older methods may remain when they have learning value, but their status should be clear.
72. Legacy technology is labelled: deprecated HTML, older ASP techniques, obsolete APIs or historical patterns should be identified as legacy so learners do not mistake them for current best practice.
73. Responsive images and screenshots: instructional images should scale correctly on mobile while retaining useful dimensions, alt text and context.
74. Responsive video embeds: YouTube and other embedded videos should use the approved responsive container and must not overflow the page on mobile.
75. Responsive code and tables: long SQL/PHP/JavaScript lines and wide data tables must not break the mobile layout; use safe horizontal scrolling where required.
76. Referenced media and files exist: check image paths, demo files, downloads, source files and other linked resources so the tutorial does not contain broken teaching material.
77. Infographics are added only when useful: add diagrams for processes, comparisons, architecture or workflows when they genuinely reduce cognitive load. Do not add graphics simply to satisfy an image quota.
78. Shared template and dependency integrity: use approved shared headers, footers, navigation, author blocks and layout components correctly. Check the impact of changing a shared include before editing it, and avoid duplicate viewport tags, duplicate author/footer/analytics output, conflicting Bootstrap or JavaScript versions, obsolete layout classes, malformed wrappers and unnecessary duplicate frontend libraries.
79. Rendered-page QA: inspect the actual browser output on desktop and mobile for overflow, broken navigation, duplicate IDs, malformed wrappers, leaked entities, accidental server-side interpolation, hidden content, unusable controls and header/footer problems. Source inspection and syntax checks are important, but they do not replace rendered browser testing.
80. Content consolidation and URL retirement: if an older page substantially overlaps a stronger page and no longer has enough unique value to justify remaining separate, review it for useful text, examples, media, traffic and backlinks before retiring it. Preserve any valuable material in the best matching retained page, update internal links that point to the old URL, use a relevant permanent 301 redirect, remove the retired URL from navigation and sitemaps, and monitor the migration in Search Console.
81. Section-wide candidate discovery: Before starting another modernization pass, scan the complete section for recurring editorial leakage, outdated patterns, structural inconsistencies and other quality signals. Use the results to build the page-review list; do not treat every text match as an automatic error.

Section-wide candidate scan before page editing

Before deciding which pages in a tutorial section need another modernization or quality pass, run a section-wide source scan first. The purpose is to identify candidate pages for manual review rather than opening and rewriting every page.

Useful section-wide scans can flag pages containing:

• editorial or modernization-process language visible to learners,
• phrases referring to an "original", "old", "retained", "modernized" or "previous" version where the history itself is not part of the lesson,
• generic transition text repeated across many tutorials,
• deprecated or legacy coding patterns presented without appropriate context,
• missing or inconsistent breadcrumbs, canonicals, headings or internal links,
• old template structures or incomplete modernization patterns,
• broken or outdated links to demos, downloads, images, notebooks or supporting files,
• learner-facing code blocks that need technical validation,
• pages that appear disconnected from the section homepage or their primary topic hub.

After the scan, de-duplicate repeated matches and classify the affected pages as high-confidence cleanup, manual review, or false positive / intentional usage. This produces a focused list of pages that genuinely need attention and avoids unnecessary rewriting of pages that are already good.

SEO advice I would remove from an older audit checklist

Turn the audit into an action plan

After reviewing the universal audit and any applicable website-specific profile, classify every finding by evidence and impact rather than fixing items in numerical order.

Use NotebookLM to review an audit from your own sources

This article originally used NotebookLM for this workflow. The product is now Gemini Notebook. It remains useful when you load audit notes, Search Console exports, technical reports and official reference documents into one notebook.

Use a prompt such as:

Using only the sources in this notebook, audit the target webpage.

Organize the findings into these sections:
1. Search intent and content quality
2. On-page SEO and internal linking
3. Indexing, canonical, robots and sitemap issues
4. Core Web Vitals / performance
5. Trust, accessibility and conversion
6. AI Overviews / AI Mode readiness based on Google's documented requirements
7. Website-specific quality profile, if one is supplied

For internal linking:
- use the supplied sitemap or URL inventory as the candidate destination set,
- identify natural topic matches in the page text,
- prefer the first useful occurrence of the matching term,
- allow relevant cross-section links when they help the reader,
- do not force repeated links to the same destination.

For each issue:
- quote or identify the evidence from the supplied sources,
- classify it as Critical, High, Medium or Low priority,
- explain the user or search impact,
- give a specific recommended fix.

Do not invent missing metrics or assume a problem exists when the sources do not prove it.
Finish with the top five actions in recommended implementation order.

This approach is useful because the model is asked to ground the audit in the material you supplied rather than creating a generic SEO checklist from memory.

A modern webpage audit is broader than keyword placement

The strongest pages combine useful and current content with clean indexing signals, thoughtful contextual internal links, good page experience, transparent sourcing and a clear next action for the user. A reusable site-specific quality profile then protects the details that generic SEO audits often miss, such as code accuracy, learning flow, responsive examples and template integrity on a technical tutorial site.