Yusuf Aziz Articles & Research Notebook

How Do You Measure a Website in 2026? A Plain Guide to SEO, GEO and Overall Quality

Yusuf Aziz · · writing: Grok Assistant (AI) · source audit: Reaper

Calling a website "good" is no longer enough. People find information in two ways. One is the search engine. The other is AI assistants such as ChatGPT, Gemini and Perplexity. Both read your site. But each looks at different things.

This article explains how to measure a website from three angles: classic SEO, GEO (visibility in AI assistants) and overall quality. For each criterion we ask two questions: Why does it matter? How do you check it?

First, the concepts: SEO and GEO

SEO is about being findable in search results. GEO (Generative Engine Optimization), on the other hand, is about an assistant citing your site as a source when it answers a question.

The two are not rivals. Many assistants also crawl the web, rely on indexes and read pages. Google says there is no separate "trick" for AI features and that the fundamentals of SEO apply here too (Google Search Central: AI features). In other words, a solid foundation serves both sides.

1. Bot access: Can they read you?

Why it matters: If a bot cannot get into your page, it will neither index it nor cite it. Some sites block assistant bots without realizing it. Sometimes because of a firewall, sometimes because of an old line in robots.txt.

How to check:

  • Open yoursite.com/robots.txt. Read which bots are allowed (Google: Introduction to robots.txt).
  • Assistant companies publish the names of their bots. There is the OpenAI bot documentation for OpenAI's bots, the Perplexity bot documentation for Perplexity, and the Google crawler list for Google's crawlers (including Google-Extended).
  • An important distinction: some bots come for model training, others to answer a user's question in real time. You can block one and leave the other open. Make that decision knowingly.
  • If you use a CDN or a firewall, check its bot-blocking settings too. Even if robots.txt allows access, the firewall can shut the door.

2. Indexing and IndexNow

Why it matters: A page is not found the moment it is published. The search engine has to discover it. If updates are noticed late, outdated information keeps circulating.

How to check:

  • Look at the indexing reports in Google Search Console and Bing Webmaster Tools. Statuses such as "Discovered – currently not indexed" give you clues.
  • Check that your sitemap (sitemap.xml) is up to date.
  • IndexNow is an open protocol that lets you notify participating search engines when a page is added or changed. Check whether your site has a key file and whether changes are being submitted. Note: not every search engine uses IndexNow. Check support on the protocol's own page.

3. llms.txt: A roadmap for assistants

Why it matters: Web pages are made for people. Between menus, ads and scripts, the core information can get lost. llms.txt is a short Markdown file that sits at the site root or under a subpath. It guides assistants by saying "the important information is here".

An honest note: llms.txt is not an official standard; it is a proposal. Its own page describes it that way (llmstxt.org). The same page says thousands of sites publish the file and that some tools check it. But which assistant uses it, and to what extent, is not clearly documented for every company. So treat llms.txt as "a harmless extra that may be useful", not as a magic key.

How to check:

  • Does the yoursite.com/llms.txt address open?
  • Does it contain an H1 heading (the only thing the format requires), a short summary and links to important pages? The format rules are on llmstxt.org.
  • Do the links work? Does the information match what is currently on the site?

4. Structured data (schema)

Why it matters: Structured data tells machines explicitly what a page is about. "This is an organization", "this is an article", "this person is the author" and so on. Search engines use it for rich results. For assistants, too, it can reduce the risk of misreading the page.

How to check:

  • The types you use should exist in the schema.org vocabulary.
  • Test the page with the Google Rich Results Test and the Schema Markup Validator.
  • The most common problem is not an error but a contradiction. If the structured data gives one address and the page shows another, the machine cannot tell which one to believe. Compare details such as phone number, address, opening hours and prices across pages.

5. The source layer: What are your claims based on?

Why it matters: When answering, assistants may favor sources that look trustworthy. Google, too, emphasizes content that is "helpful, reliable and written for people" (Google: Creating helpful content). An unsourced figure or claim weakens the trust of both the reader and the machine.

How to check:

  • Is there a link to a primary source next to every important number or claim on the page? (Not a news story, but the original report, institution or law.)
  • Are the author and the date of the last update visible?
  • Is the same information written differently on different pages?

6. How do you measure visibility in assistants?

Why it matters: The outcome of GEO is your name and your link appearing in the assistant's answer. You need to see this by testing, not by guessing.

How to check:

  • Write down 10-20 real questions your customers would ask.
  • Ask these questions in ChatGPT, Gemini and Perplexity. Note whether your site is cited as a source in the answer.
  • Answers can vary by person, location and time. So a one-off test is not a definitive result. Repeat the same questions at regular intervals and look at the trend.
  • Track visits from assistant bots in your server logs, and traffic coming from these sources in your analytics.

7. Speed: Core Web Vitals

Why it matters: A slow site wears out both readers and bots. Google defines user experience through three core metrics: LCP (loading of the main content), INP (response to a click) and CLS (layout shift). The recommended thresholds are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS (web.dev: Web Vitals).

How to check:

  • Measure both mobile and desktop with PageSpeed Insights.
  • "Field data" (real users) and "lab data" (a single test) are different. Give priority to field data when you decide.
  • Look at the server's initial response time, page size and heavy template parts repeated on every page.

8. Accessibility

Why it matters: An accessible site is for everyone: a visually impaired reader, an old phone, a weak connection. A well-marked-up page is also one that machines read more easily.

How to check:

  • The international reference is the W3C WCAG 2.2 guidelines.
  • Do images have meaningful alternative text?
  • Is the heading order correct (H1, H2, H3)?
  • Is there enough contrast between text and background?
  • Can the site be navigated with a keyboard alone?
  • Automated tools (e.g. Lighthouse) are a good start, but they don't catch every problem. Test by hand as well.

9. Basic tags

Why it matters: The page title and description are the first things a person sees in a search result. If they are missing or identical on every page, the pages cannot be told apart.

How to check:

  • Does every page have its own unique <title> and meta description?
  • Does the canonical tag point to the correct address?
  • Are the Open Graph tags for sharing filled in?

10. KVKK and limits on health content

Why it matters: Being visible requires following the rules. In Türkiye, the processing of personal data falls under KVKK, the Personal Data Protection Law (Personal Data Protection Authority). In sensitive fields such as health, there are additional sector-specific rules for promotion and advertising. Content that breaks the rules is a risk, even if it ranks well.

How to check:

  • Is there a privacy notice and cookie information, and are they easy to find?
  • What data do your forms collect, and why? Are they asking for more than necessary?
  • Does your health content promise guaranteed results, make before-and-after claims or offer unsourced treatment promises?
  • Does the site open over HTTPS, and are security headers defined?
  • Consult a legal adviser about the current rules in your sector. This article is not legal advice.

A short checklist

  1. Are robots.txt and your firewall open to the bots you want?
  2. Are your pages indexed, and are changes being submitted?
  3. Do you have an llms.txt, and is it up to date? (A proposal, not a standard.)
  4. Is your structured data valid, and does it contradict the page?
  5. Do your claims have primary sources?
  6. Are you asking assistants real questions and keeping regular records?
  7. Are you within the Core Web Vitals thresholds?
  8. Can everyone use the site?
  9. Are titles and descriptions unique on every page?
  10. Are KVKK and sector rules being met?

What is behind this article?

We didn't just write these criteria down; we also built them into a tool. We made a site analysis engine we call Atlas Analiz, along with its mobile app.

What did we do? The engine reads many pages of a site together. It looks at 10 SEO and 8 GEO criteria: bot access, llms.txt, structured data, consistency across pages, sources, speed, KVKK and health-promotion limits. For each page it asks a question from the reader's point of view and writes a one-line verdict. It gives recommendations in three parts: what we saw, why it matters, what to do. The result is a short, 8-line summary. (The criterion and line counts come from our own engine.)

How did we do it? On a shared work board, together with several AI agents. Planning, code, interface language and auditing were assigned to separate agents; the work moved forward on the board, with records. This article, too, went through Reaper's source audit before publication.

Where is the evidence? A summary of the method and the criteria is on the atlasmaster.app evidence page.

The Atlas Analiz app is coming soon.