25-Point Website Audit for AI Search Visibility

When checking AI search exposure, many managers check robots.txt or JSON-LD first. While these two items are important, allowing robot access or applying structured data alone does not mean the website is utilized as a source for answers or brand information.

For search engines and AI systems to understand a site, they must be able to read together which company operates it, what questions each page answers, what the main URL is, whether the author and modification date can be verified, what evidence was used, and how related documents are connected.

GEO is an operational method that checks and reinforces this technical structure and content/trust information in accordance with the context of the questions. The basic concepts and differences from SEO can be found in the ‘What is GEO?’ guide; this article focuses on the diagnostic items for the website itself.

The purpose of diagnosis is not to pass all 25 items or to achieve a visually appealing score. The key is to identify issues that block crawling on official pages connected to important questions, problems that make understanding the topic difficult, and issues with insufficient trust evidence, and to determine the order of corrections.

robots.txt guides the crawler access scope and checks actual server access and the status of public URLs. Collection accessibility, page subject, operating entity, content basis, and relationships between documents must be consistent together.

Check access blocking issues before content quality. There is a difference between a page existing and being indexable, and there is also a difference between what is displayed on a browser screen and what is output in the initial HTML. Metadata and JSON-LD must also be examined not only for their existence but also for whether they match the actual content.

Public results can be categorized into ‘Immediate Improvement,’ ‘Priority Reinforcement,’ and ‘Normal or Observation.’ Items that directly affect access and indexing, such as robots blocking or noindex on public pages, are considered for immediate improvement, while items with weak explanations and basis are reinforced starting with important pages.

Look at business-critical pages first, rather than diagnostic scores. After making corrections, we re-examine the server response, initial HTML, metadata, and JSON-LD for the same URL, and note that actual indexing and reflection in search results may take time. We do not conclude that a single discovered item is the sole cause of non-exposure.

The following table summarizes the 25 available diagnostic items from the perspectives of collection, understanding, and trust. Normal signals are not a guarantee of passing but represent the currently verifiable status, while problematic signals are observations requiring further verification.

Check the Collection, Indexing, and Server Groups before evaluating the content. Since actual requests may be blocked even if the configuration file appears normal, inspect the file content, response headers, and server behavior separately.

Check: User-agent: * rules, misconfigurations of Disallow, sitemap declarations, major crawler rules, and domains/paths. robots.txt guides the scope of crawler access, and you must check actual server access and the status of public URLs together. Issue Signal: Public pages or rendering assets are blocked, or sitemaps from other domains are declared. Improvement Direction: Allow only necessary public paths and clean up unnecessary rules. Verification Method: Check the robots.txt source text and the actual request results of the target URL together.

Checks: Server firewalls, CDN/WAF, country-specific blocking, repetitive request restrictions, CAPTCHA, 403·429 responses, and User-Agent policies. Why it is important: Even if robots.txt is set to Allow, if the security layer rejects the request, the content cannot be retrieved. Issue Signal: Opens in a standard browser, but specific requests are blocked or it switches to a login or challenge screen. Improvement Direction: Establish reasonable access policies for crawlers and public pages that are verifiable through official documentation while maintaining security. Verification Method: Compare the server logs with the status and response body of the same URL.

Checking: Examine meta robots, X-Robots-Tag, page-specific noindex, staging settings, and canonical conflicts. Why it is important: Unlike robots.txt, which handles crawl traffic, noindex is a means of instructing exclusion from search indexing. Signs of a problem: noindex remains in the public page HTML or response headers. Direction for improvement: Verify the publication intent and modify the meta and header settings together. Verification Method: Directly read the initial HTML head and HTTP response headers and compare the results by environment.

Checks: Includes public URLs, 200 responses, valid XML, canonical URLs, lastmod, and checks for duplicates and the exclusion of 404, redirect, and noindex URLs. Why it matters: The sitemap conveys information on the URLs to discover and changes, and checks the actual response, canonical, and indexability status together. Warning signs: Mixed private, duplicate, or other-hosted URLs, or repeated lastmods unrelated to actual modifications. Direction for improvement: Maintain only public, canonical URLs. Verification method: Compares the XML parsing results with the actual page state.

Checks: HTTPS certificate, 200 status, 301·302 chain, www·non-www, trailing slash, HTTP→HTTPS, redirect loop, and soft 404. Why it is important: Multiple URL variations and long navigation paths can make representative document resolution and reliable access difficult. Warning signs: The same page opens on multiple hosts or navigates repeatedly to the final URL. Improvement direction: Use a single representative host and short, persistent redirects. Verification method: Log the status and Location headers from the initial request to the final 200.

The Rendering, Accessibility, and Technology group verifies that the result seen in the browser matches the document at the time of collection. This requires examining the source, the rendered DOM, and the mobile screen separately.

Checking: The H1 and core body in the page source, content before JavaScript execution, infinite scrolling, load after click, API errors, and hydration errors. Why it is important: Content visible on the screen may not be present in the initial HTML, and the document may become empty upon execution failure. Signs of a problem: Only the shell is output, and the critical answer appears after the client request. Direction for improvement: Provide core explanations via server-rendered or static HTML. Verification method: Compare the source HTML with the DOM after rendering.

Checking: View initial server response, load failures, timeouts, excessive images, layout shifts, hydration errors, and mobile network status. Why it matters: It is more important that the core content is reliably delivered with every request than to check specific speed scores. Signs of problems: Intermittent 5xx, blank screens, recurring long waits, or large element shifts. Direction for improvement: Start by reducing server errors and core asset bottlenecks. Verification method: Repeatedly check status codes and content delivery status under various conditions.

Checking: Viewport settings, horizontal overflow, tables and code blocks, CTAs, font size, mobile menus, and image cropping. Why it matters: If content is cropped on mobile, it can become difficult for both users and crawling systems to identify document relationships. Issue Signal: The entire page shifts horizontally, or buttons and table columns become fixed outside the screen. Improvement Direction: Tables should provide their own horizontal scrolling and limit the body width. Verification Method: Check actual operations and horizontal overflow at key breakpoints starting from 320px.

Checks: HTML lang, body language, multilingual page, and if hreflang exists, examine the target URL and language code. Why it matters: The document language is the primary clue for reading tools and search systems to interpret page context. Issue Signal: Different language codes are assigned to Korean body text, or language-specific pages incorrectly share the same canonical. Improvement Direction: Unify language information to align with actual content and URL policies. Verification Method: Compare the lang, hreflang, and canonical of the final HTML together.

Checking: See if image alts are meaningful, if alts for decorative images are empty, and if filenames, captions, logo descriptions, and text are placed only on the image. Why it matters: Alts replace the meaning conveyed by the image and are not a keyword repetition box. Signs of a problem: The same phrase appears on every image, or there are only long screenshots without body text. Direction for improvement: Briefly explain the purpose of the image and provide key information in HTML text as well. Verification method: Check if the context can be understood without viewing the image.

Metadata and headings explain the page's main topic. We do not simply count the existence of each element, but check if they point to the same question and URL.

Checking: Unique title per page, brand name, core topic, and duplicate titles and templates. Why it is important: The title is meta-information that briefly identifies the document's main topic. Warning signs: Multiple pages use the same title, such as 'Homepage' or 'Post,' or the brand name appears twice. Direction for improvement: Naturally distinguish the page's core question from the brand. Verification method: Check the HTML title and the site-wide duplicate list.

Checking: Page content summary, brand/service, duplicate/empty values, exaggerated phrases, and body text consistency. Impressions, quotes, and recommendations are recorded by question, platform, and time, and measured repeatedly using the same criteria. Problem Signal: All pages use the same ad copy or promise services that are not present in the actual body text. Improvement Direction: Specifically summarize the questions and scopes that the pages answer. Verification Method: Compare the final meta values ​​with the body text on the first page.

Checks: Look for self-referencing canonicals, different URLs/domains, http/https, www, and inconsistencies between parameters and sitemaps. Why it is important: A canonical is a signal indicating the preferred representative URL among duplicate candidates. Problem Signal: Detail posts point to a list or another post as a canonical, while internal links use yet another URL. Improvement Direction: Unify canonicals, sitemaps, OGs, and internal links to align with the actual canonical policy. Verification Method: Compare the final HTML links with all URL signals. Impressions, quotes, and recommendations are recorded by the question, platform, and time, and are measured repeatedly using the same criteria.

Checks: og:title, og:description, og:url, og:type, og:image, og:site_name, absolute path, and image response. Why it matters: Open Graph is meta-information that primarily helps with shared previews and document identification. Problem signals: Remaining page titles/URLs or images are 404. Improvement directions: Use absolute URLs and representative images that match the current page. Impressions, quotes, and recommendations are recorded by question, platform, and time, and measured repeatedly using the same criteria.

Checks: Clear H1, page subject, title and semantic match, hidden/plural H1, and titles within images. Why it matters: H1 is the main heading that the user sees on the screen. Problem signs: H1 is missing or visually hidden, and card titles are repeated haphazardly as H1. Direction for improvement: Place a screen title that explains the core question. Verification method: Check the number and content of H1 visible in the rendered DOM.

What to check: Look for the order of H1→H2→H3, design misuse, question-based subheadings, table of contents links, and empty headings. Why it matters: Headings explain the information relationships and sub-questions within the long body text. Problem signs: Headings are skipped for font size or contentless headings are repeated. Direction for improvement: Place topics and detailed criteria at the same level below the main question. Verification method: Check if the document flow is established even when reading only the headings.

The Content-Document Relationship group looks at question resolution and connections between pages rather than character count. Quick answers, sufficient evidence, and internal links must support the same user intent.

What to check: Look for the core answer in the introduction, question repetition, definitions, comparisons, and conditions, and alignment between the summary box and the conclusion. Why it matters: A quick conclusion is a structure that answers the user's core question first, rather than just a single short sentence. Problem signs: Background explanations and advertisements are long, and the answer appears only at the end. Direction for Improvement: Present the conclusion, conditions, and limitations first, and explain the rationale afterwards. Verification Method: Check if the answer and scope of the text can be understood by reading only the first page.

Checks: Match between title and body, core and sub-questions, specific explanations, examples, conditions, limitations, and promotional sentences. Why It Is Important: Even if the word count is long, if the question is not resolved, the understanding of the topic and user value are weak. Problem Signals: Most content consists of repeating keywords or promoting services different from the title. Direction for Improvement: Add conditions and rationale necessary for the user to make a judgment. Verification Method: Match the list of questions expected from the title with the actual answer paragraph. **Direction for Improvement:**

Checking: Compare tables, step lists, checklists, on-screen FAQs, interpretations at the bottom of tables, and consistency between mobile tables and FAQ pages. Why it matters: Structural elements must clearly indicate the comparison, order, and relationships of information. Warning signs: Tables are added for keyword repetition, or on-screen answers differ from schema answers. Direction for improvement: Use only the structure necessary for the actual body and append interpretation sentences. Verification method: Check for consistency between mobile operations and on-screen JSON-LD questions and answers.

Checking: Look for core and hub pages, orphan pages, meaningful anchors, broken links, draft and hidden links, and contextual relationships. Why it matters: Internal links explain the thematic relationships and representative content between pages. Problem Signals: Repeats only ‘Read More’ or links to private or irrelevant pages. Improvement Direction: Specify the reader's next purpose in the anchor. Verification Method: Check link responses and visibility status, and review the page relationship diagram.

Trust, operating entities, and structured data groups check if the facts verifiable on the screen match the machine-readable descriptions. Do not create non-existent individual authors or external channels.

What to check: Check author, publisher, datePublished, dateModified, consistency between screen and JSON-LD, and author introduction. Why it is important: You must be able to verify who was responsible for writing or modifying it and when to determine the context of the information. Problem Signal: Using arbitrary expert names or updating only the date to the latest without actual modifications. Improvement Direction: If no actual individual is present, display a verifiable organization as the author/publisher. Verification Method: Compare the screen date with the Article JSON-LD value.

Checks: Company introduction, official company name, Korean/English brand, representative/contact information, URL, service scope, footer, and external notations. Why it is important: If the operating entity information varies from page to page, the connection between the brand and official documentation may be weakened. Problem Signal: Multiple company names are mixed on the same site, or inquiry information differs. Improvement Direction: Establish an authentic notation such as "SUMMITFEED" for the first mention and "SUMMITFEED" for subsequent mentions. Verification Method: Compare About · Footer · Home · external official channels.

Checking: Look for duplicate outputs in Organization's name, alternateName, url, logo, @id, and sameAs, and WebSite's publisher and inLanguage. Why it is important: Global entities complement the relationship between the site operator and the website. Warning signs: Company information not on the screen, unverified sameAs, outdated logos, or a mix of multiple @ids. Direction of improvement: Use only values ​​found on the actual screen and official URL. Verification method: Collect page-by-page JSON-LDs to check for Organization and WebSite duplication and connections.

Check: Look for headline, author, publisher, date, mainEntityOfPage, image, Breadcrumb, FAQ matches, duplicate schemas, and page types. Why it matters: Structured data helps machines understand document and site hierarchy, but it must not differ from the screen. Warning signs: Add FAQs that are not on the screen or display AboutPage as Article. Directions for improvement: Link the minimum accurate type that fits the page type. Verification method: Compare parsing and verification tools with the screen content.

Check: Look for official documentation, personal experience/original data, source URLs, long direct citations, copies of the same manuscript, duplicates across multiple domains, canonicals, demo/actual data, and ad notices. Why it matters: E-E-A-T is not a single schema, but a state where experience, expertise, external verifiability, and transparency are connected across the entire site. Problem Signal: Claims are made without attribution, or the same content is duplicated across multiple domains without distinguishing between authentic and non-authentic versions. Improvement Direction: Specify official 1 source materials and authentic URLs. Verification Method: Check the evidence for each claim and the representative signals for duplicate URLs.

llms.txt, RSS or feeds, IndexNow, web app manifests, and separate AI data feeds are auxiliary elements that can be used optionally after verifying operational purposes and official support scope. Impressions, citations, and recommendations record the question, platform, and time, and are measured repeatedly using the same criteria.

If the site is not a PWA, there is no need to force the creation of a manifest, and llms.txt is not described as a mandatory priority element. If necessary features are not available, prioritize reinforcing the consistency of access, representative URL, content, and operator among the core 25 items.

Generally, you can review them in the following order: access and indexing blocking, representative URLs and redirects, HTML body and rendering, title, canonical, and H1, Organization and Article structured data, body answering core questions, author, source, and company information, internal links, duplicate content, and mobile, performance, and auxiliary elements. However, the order may vary depending on business-critical pages and the actual scope of the outage.

Website diagnostic results make it easier to determine actual work priorities when viewed alongside target questions, brand mentions by platform, source citations, and competitor analysis tables.

You can determine which items to improve first—such as crawl blocking, metadata, JSON-LD, content, and internal links—based on the current state of your website.

1. It is assumed that citations are granted simply by setting robots.txt to Allow. Since robots handles access scope, you must re-verify the actual server response, indexability, content, and trust information.

2. noindex and robots.txt are considered the same setting. Since robots handles crawling and noindex handles exclusion from indexing, you must check the file, HTML, and response headers separately.

3. If it appears on the screen, it is assumed to be present in the initial HTML as well. You must compare the page source with the post-rendered DOM to verify when the core answer is displayed.

4. Use the same title and description on all pages. You must create unique meta-information based on the questions and body content for each page.

5. Link the canonical to a different page or an incorrect host. You must check if the sitemap, Open Graph, and internal links point to the same main URL.

6. Insert information into the JSON-LD that is not on the screen. Structured data is not a hidden promotional space, so you should only explain the actual displayed company, document, and FAQ information.

7. The FAQ on the screen and the answers on the FAQPage are different. You must ensure that questions and answers are generated from the same data and that there are no duplicate schemas.

8. Only long articles are published without the author or revision date. The actual author/publisher and the change history must be matched between the screen and the Article data.

9. The same manuscript is copied verbatim to external channels. You must define the official URL and the role of each channel, and review the canonical and content differences of duplicate documents.

10. Articles are isolated without internal links. You must verify that contextually appropriate links are connected in related hubs and representative articles.

11. To increase the score, items with the least impact are modified first. You must first address access blocking and critical gaps in important conversion pages.

12. Describes optional elements like llms.txt as if they were mandatory. You must verify the official support scope and operational purpose, and distinguish them from core technology, content, and trust items.