In a recent interview with David Iwanow, Google's John Mueller was asked whether AEO and GEO are dead. His answer, as reported by Search Engine Journal, is a good filter for founders deciding where to spend their time:

"I think you'll see that a lot of the AI systems, they build on SEO. So from that point of view, I think it's going to continue to be relevant. I think especially technical SEO is going to remain very relevant."

He also said that AI systems crawl a bit differently, because some crawl for training and some for fresh content, and called that "another flavor of technical SEO."

Google's own guide to AI features in Search says the same thing in documentation form. There are no extra requirements to appear in AI Overviews or AI Mode. A page has to be indexed and eligible to show in Search with a snippet.

So what does "technical SEO for AI search" actually mean for a small team? Here is the checklist I use.

Why the tricks expire

Mueller didn't call every listicle spam. He described a familiar pattern: a tactic works, everyone copies it, many people do it badly, and then the systems catch up.

"So if you go all out and say, my whole strategy is listicles, then at some point that's going to switch off and you're left with nothing really."

And on what to do instead:

"Building up a serious, stable foundation for a website, I think that's the most critical part."

A simple test before you spend a week on the latest AI trick: if this tactic stopped working next quarter, would your site still be better for having done it?

1. Crawlability: can the bots reach the page?

• Important pages should be reachable through normal links, not only through search boxes, scripts or forms.
• Read your robots.txt line by line. Every block on a crawler should be a choice you made, not something copied from a forum.
• Check your CDN or firewall too. Google's guide lists allowing crawling "by any CDN or hosting infrastructure" as an SEO basic, because a bot rule can block what robots.txt allows.

2. Indexability: is it actually in the index?

A crawled page is not always an indexed page. Look for:

• Stray noindex tags, often left over from a staging site
• Canonical tags pointing at the wrong URL
• Duplicate versions of a page (http and https, with and without a trailing slash)
• Redirect chains

Search Console's URL Inspection tool shows what Google saw. Use it on your five most important pages.

3. Rendering: is the content in the HTML?

If your main copy only appears after heavy JavaScript runs, some crawlers may not see it the way a browser does. Google's guide lists "making sure that important content is available in textual form" among its basics. A quick test:

curl -s https://yourdomain.com/ | grep -i "your main headline"

If your headline or product description is missing from the raw HTML, that is worth fixing before any AEO work.

4. Structure and internal links

• Use clear headings that say what each section is about.
• Link related pages to each other with plain anchor text.
• Keep important pages a few clicks from the home page.
• Find orphan pages (no internal links pointing in). People and crawlers both miss them.

5. Structured data that matches the page

Titles, meta descriptions and structured data like Organization or Product markup give systems clean signals. Google says no special schema is needed for AI features, and that your structured data should match the visible text on the page. Broken or mismatched markup is a common gap when you compare your page with the one ranking above you.

6. Backlinks are still part of the foundation

Technical SEO makes your pages readable. Links help show whether they are worth reading. If AI systems build on SEO, the authority signals that help you rank are part of what they build on.

Mueller also warned small businesses to question what their SEO vendors are doing, since shortcuts like keyword stuffing worked "for a bit" and then stopped. Practical link work for a small team:

• Know which sites link to you and which pages they point at.
• Spot spammy links early.
• Look at the links behind competitors who outrank you, and find the relevant ones you could earn.
• Watch for lost links to key pages. They can explain a drop that looks like a mystery.

Where AEO and GEO fit

AEO and GEO are useful names for a real goal: being named when someone asks an AI a buying question. Mueller's comments suggest the route there runs through the same foundation. A sensible order:

1. Fix what stops pages being crawled, indexed or read.
2. Clean up and strengthen your links.
3. Write clear pages that answer the questions buyers actually ask.
4. Measure whether rankings and AI mentions move over time.

Most AEO advice lives in steps three and four. Many sites quietly fall short on one and two.

Measure over time, not once

A single audit tells you where you stand on one day. It doesn't tell you whether your fixes helped. Technical issues also come back after a redesign or a new plugin, and AI answers vary from one run to the next.

I work at Serpair, and this is the problem we built it for. It keeps the history of your site audits, Google rankings and AI mentions, so you can see which changes moved things and which did nothing. If you want to see where your foundation stands today, run the free SEO and AI visibility check on your domain. No sign-up needed.

Which of these six do you find most often broken on early-stage sites?

They read a thread about AI Overviews. In one week they rewrite the home page headline, add an FAQ section, change the pricing page title, publish two blog posts and fix a redirect. A month later, search traffic is up a bit. Or down a bit. Gemini mentions them once, then doesn't.

Then someone asks the obvious question: which of those changes worked? Nobody knows. So the next round of changes is a guess too.

As developers, we would never ship code this way. We have version control, tests and a way to compare before and after. SEO and AI visibility deserve the same habits. You don't need new tools for most of it. You need a changelog, a fixed set of queries and a little patience.

1. Keep a changelog for your site, not just your code

Git already tells you what changed in the code. It doesn't tell you why, or what you expected to happen in search. So keep a separate, boring file next to your repo. Mine looks like this:

## 2026-11-03
- URL: /pricing
- Change: title "Pricing" -> "Acme pricing: plans for small teams, free trial"
- Why: pricing queries show us on page 2 with a vague title
- Watch: "acme pricing", "acme cost", "acme free trial"
- Review on: 2026-12-01
- Result: (fill in later: kept, reverted, inconclusive)

The important fields are "Watch" and "Review on". Writing down what you expect to move, before you ship, stops you from finding a story in the numbers afterwards. The "Result" line is the one most people skip, and it is the one that makes the file useful six months later.

Include changes you didn't plan, too. A CMS migration, a new cookie banner, a CDN setting, a theme update. Those are often the real cause when a chart suddenly drops.

2. Freeze a set of queries, like test fixtures

You can't tell if something improved if you measure different things each time. So pick a fixed list of queries and keep it stable, the same way you keep test fixtures stable.

For most early products, 15 to 30 queries is plenty. Split them into a few groups:

• Brand: your product name, and your name plus "pricing" or "reviews".
• Category: what a buyer types when they don't know you yet, like "uptime monitoring for small sites".
• Problem: the pain in plain words, like "how do I know when my site goes down".
• Comparison: "acme vs [the usual alternative]" and "[alternative] alternatives".

Write the AI version of each one as a full question, the way people actually ask Gemini or read an AI Overview. "What's a good uptime monitor for a small SaaS?" is a different test from the keyword "uptime monitor".

Store the list in a file in your repo. If you add a query later, note the date, so you don't compare a new query against history it never had.

3. Take a baseline before you change anything

This is the step everyone skips because it feels slow. Without it, the changelog is just a diary.

Before your next batch of changes, record:

1. Search Console numbers for each query and each page you plan to touch. Clicks, impressions and average position over the last 28 days. Export the CSV and commit it, or save it with a date in the file name.
2. What Google shows for each query in a logged out browser. Does an AI Overview appear? Which sites does it link to? Where do you rank in the normal results?
3. What Gemini says when you ask the question version. Are you mentioned? Is a link to your site shown? Which competitors are named?

A tiny script makes this less painful. Even a CSV you fill in by hand works:

date,query,surface,shown,position_or_mention,cited_url,competitors_named
2026-11-01,uptime monitoring for small sites,google_organic,yes,14,/features,"PingCo,StatusPal"
2026-11-01,uptime monitoring for small sites,ai_overview,no,,,
2026-11-01,what's a good uptime monitor for a small saas,gemini,no,,,"PingCo,UptimeHQ"

Note the competitors column. It matters more than it looks, and I'll come back to it.

4. AI answers are flaky tests. Treat them that way

If you ask Gemini the same question twice, you may get two different answers. AI Overviews also don't show for every query, and they can come and go for the same query. If you check once and see yourself mentioned, that isn't a result. It's one sample.

We already know how to deal with flaky tests. Run them more than once and look at the rate, not a single pass or fail.

• Ask each AI question a few times per check, and record how many times you were mentioned.
• Check on a schedule, for example every week, instead of whenever you feel curious.
• Look at the trend over several weeks. "Mentioned in 1 of 3 runs in October, 2 of 3 in November" is a signal you can work with. "Mentioned yesterday" is not.

Also keep the conditions the same each time. Same browser setup, logged out, same location if you can. Personalized results will make your history noisy.

5. Change one thing per page, then wait

If you change the title, the intro and the internal links on a page all at once, you'll never know which one helped. One meaningful change per page per review window is a good rule. You can still change many pages at once, as long as each page has one change you can point to.

Then wait longer than feels comfortable. Google's own SEO Starter Guide says that some changes might take effect in a few hours and others could take several months, and that in general you likely want to wait a few weeks to assess whether your work had an effect. It also says not every change will make a noticeable difference. That is why the "Review on" date in the changelog is usually three or four weeks out, not three days.

6. Use competitors and untouched pages as your control group

Here is why the competitors column matters. Search results move for reasons that have nothing to do with you. Google updates, seasonal demand, a competitor's launch, a news story in your category.

If your rankings for a query went up after your change, check what happened to the competitors on the same query. If everyone moved up together, your change may not be the reason. If you moved and they didn't, that is much stronger evidence.

The same goes for your own pages. Keep a few pages you deliberately don't touch during a review window. If the changed pages improve and the untouched ones stay flat, you have something close to a control group. It isn't a lab experiment, but it is far better than a guess.

7. Close the loop every month

Once a month, open the changelog and fill in every "Result" line that is due. Be honest. Most entries will say "inconclusive", and that's fine. The ones that say "kept" become your playbook. The ones that say "reverted" save you from repeating them.

After a few months, you'll have something most early-stage teams don't: a record of what works for your site, in your category, against your competitors. That is worth more than any generic checklist, including the ones I've written.

Where a tool fits

Everything above works with a text file, a CSV and Search Console. I'd start that way, so you understand what you are measuring.

Disclosure: I work at Serpair. It is a growth-journey tracker, which means it keeps the history for you: your Google rankings, mentions in AI answers and what your competitors are doing, all over time, so you can line changes up against results and see which ones worked. If you want a starting baseline before your next batch of changes, there is a free SEO and GEO check that runs on your public domain, and a free trial if you want to keep tracking after that.

Either way, write down your next change before you ship it. I'd like to hear which entry in your changelog surprised you most.

There's a lot of noise about this PHP vulnerability. So here are the 5 steps, each one backed by what an official advisory or vendor actually says.

1. Find every PHP site you own

The source: CISA notes that "PHP is often a component of other software" (CISA). The PHP project says "all PHP installations serving web requests" are at risk (php.net).

What it means: your main site isn't the whole list. Count the blog, landing pages, old microsites, staging, and anything that ships PHP inside it. NCSC-NL keeps a list of third-party products that bundle PHP (NCSC-NL on GitHub). PHP also sits under WordPress, Drupal, Joomla and Magento.

2. Check the PHP version

The source: Qualys warns that the version php -v shows on the command line "may belong to a different installation from the one serving web requests" (Qualys).

What it means: check the version your website actually runs. Your hosting dashboard usually shows it. In WordPress, go to Tools > Site Health > Info > Server. Some servers send an X-Powered-By header, but many hide it, and a missing header proves nothing either way.

3. Update, or get your host to confirm in writing

The source: Cloudflare says administrators "need to update the PHP software running their applications" (Cloudflare).

What it means: move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. There is no official PHP2Shell release below 8.2; patch via a vendor backport or upgrade. A backported package may keep an older version number, so check your vendor's advisory rather than the number alone. PHP 8.1 reached end of life on 31 Dec 2025, and CISA says those who can't update, or still run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated". PHP 8.2 security support ends on 31 Dec 2026, so aim for 8.3 or newer when you upgrade.

4. Keep a firewall on while you patch

The source: Cloudflare says its PHP2Shell protections are "deployed automatically on all plans with WAF deployed, including Free users", and still tells customers to patch. The PHP project says its temporary mitigations reduce some attack paths but "do not make an installation safe" (php.net).

What it means: a firewall buys you time. It doesn't replace the update.

5. Watch for signs of trouble

The source: Amazon said "PHP2Shell is now being broadly exploited in the wild", and says to start investigations from 17 Oct, not from the disclosure date (AWS Security Blog). For balance, CISA's alert on 21 Oct said it had not observed exploitation at the time of publication. The AWS statement is the more recent picture.

What it means: turn on Google Search Console, check its Security issues report, and rotate passwords and API keys if anything looks off. Wiz showed the flaws can leak "passwords, tokens, and API keys" from server memory (Wiz).

Why this is also an SEO problem

Does your SEO tool check your PHP version? Search Console only tells you after you're hacked. Its Security issues report shows findings once Google determines a site "was hacked, or that it exhibits behavior that could potentially harm a visitor or their computer" (Search Console Help). The same help page names "an older, insecure version of Drupal, Joomla! or WordPress" as a way attackers get in.

A hacked site can get a "This site may be hacked" label, drop out of results and out of AI Overviews. Google says a supporting link in AI Overviews "must be indexed and eligible to be shown in Google Search with a snippet" (Google Search Central). After cleanup, "A review can take from a few days to a few weeks to complete".

A quick first look

I work at Serpair. Our free check checks whether your site advertises a PHP/CMS version affected by PHP2Shell and known CVEs. It's passive: it reads the publicly advertised version and sends no attack traffic. One possible result is "version hidden / not exposed", and hidden doesn't mean patched, so confirm with your host. A passive check isn't a full security audit. Enter your site and work email for a partial report by email, then register on Serpair for the full report. Free, no credit card required.

All sources and the check are in the founder checklist for PHP2Shell.

Which of the 5 steps took you longest? Did your host patch before you asked, or did you have to chase them?

A quick note on names. Below, the Cloud terms means the Google Cloud Terms of Service, the Workspace terms means the Google Workspace Service Specific Terms, the AUP is Google's Acceptable Use Policy, and the agent guidelines are the Google Cloud Agentic AI Responsible Use Guidelines.

Clause 1: AI agents are now named in the restrictions

The clause. Section 3.3 of the Cloud terms says the customer will not "access or use the Services or any AI Agent ... in violation of the AUP".

What it means for a solo dev. Anything your agent does on Google's services is judged against the same rules as anything you do by hand.

The fix: list your agents. You can't hold agents to a rule you don't know they're under. Write down every agent with a token for your Google accounts: coding agents with Gmail or Drive scopes, automation flows with an AI step, browser agents, AI inbox apps. Then check the OAuth grants against that list. On a personal account that's Google Account > Security > third-party connections. On Workspace it's Admin console > Security > Access and data control > API controls. Revoke anything you can't name.

Clause 2: you cover Google if your agent breaks the rules

The clause. Section 13.2 of the Cloud terms has the customer indemnify Google for "Customer's or an End User's use of the Services or AI Agents in breach of the AUP or Section 3.3 (Restrictions)".

What it means for a solo dev. If your agent's behaviour gets Google pulled into a third-party claim, the cost can land on you.

The fix: read-only access. The cheapest way to shrink that exposure is to shrink what agents can do. Agents that summarize, search or triage only need read-only Gmail and Drive scopes. Keep send, delete and share scopes for the one flow that has a human approval step in front of it.

Clause 3: you're solely responsible, including for omissions

The clause. Section 13.3 of the Workspace terms says "Customer is solely responsible for: (i) any Agentic AI Action", and an Agentic AI Action includes "omissions or failures to execute such tasks". Section 13.3(b) adds "Customer is solely responsible for any liability arising from disabling or bypassing any of these safeguards", meaning the human confirmation safeguards.

What it means for a solo dev. The agent sending the wrong thing is yours, the agent not sending the right thing is yours, and switching off confirmations makes it yours twice over.

The fix: a human approves sends. If a tool offers a confirmation step before it sends, posts, pays or deletes, keep it on. In your own agents, route outbound actions through a draft or queue that a person approves. Drafts are cheap. Unsent mistakes are free.

Clause 4: suspension can be immediate

The clause. Section 4.2 of the Cloud terms says Google "may immediately Suspend" if "Customer is in breach of Section 3.3 (Restrictions)". AUP violations under section 4.1 get a notice and 24 hours to fix, but a 3.3 breach doesn't have to wait.

What it means for a solo dev. One bad agent run can take an account offline the same day, and for most of us that account is our domain email.

The fix: a separate account. Give agents their own properly licensed account or service account, so a suspension doesn't take your main inbox with it. Keep agents off the founder's admin account. Don't use the extra account to share files around Workspace limits, and don't use agents to multiply accounts: "Creating or managing numerous accounts to evade detection" is on the agent guidelines prohibited list.

Clause 5: the bill is yours too

The clause. The agent guidelines say "you remain liable for any charges accrued by your agents".

What it means for a solo dev. A retry loop that runs all weekend is a billing problem you own, not a bug you can dispute.

The fix: a spending cap. Set budgets and billing alerts on every project an agent can touch, and put hard limits on API usage where the provider supports them. Rate-limit outbound email and posting in code, not in the prompt.

What ties the five together

Read in order, the clauses move from agents being covered by the rules to you paying for what they do. The fixes follow the same path: know what's running, limit what it can touch, put a person in front of anything outbound, contain the damage, and cap the cost. Google also "strongly recommends implementing human oversight and explicit approval mechanisms" in the agent guidelines, so fixes 2 and 3 line up with what Google itself asks for.

Not legal advice.

Originally published on Serpair: Google's new AI agent terms, explained.

How are you using AI in your business right now? Did Google notify you too? Have you changed anything since, and what guardrails do you have in place?

The first few users are usually people who already know you. Friends, family, an old coworker, someone from a group chat. They sign up because you asked, and that matters. It's how most of us get the first round of real feedback.

Then it goes quiet. And the easy conclusion is that the product isn't good enough.

Sometimes that's true. But there's a duller explanation worth ruling out first: the people who don't know you have no way to come across you. Your friends found you through you. A stranger finds you through a search box, or more and more often, by asking an AI assistant a question and reading whatever it says back.

I think of those assistants as the next best friend after the real ones. Your friends can only tell people they know. An assistant answers whoever asks, including people you'll never meet. But it can only mention you if it has something to go on.

Here's the check I'd run before rewriting the product. It's all free and takes an evening.

1. Search your own name in a private window. Type your exact product name into Google while logged out. Do you come up first? Or does a different product, a GitHub repo or a common word win? If people can't find you when they already know the name, nothing else on this list matters much yet.

2. Ask the question your customer would ask. Not "what is [my product]". The problem itself, in the words a customer would use. Ask it in ChatGPT, Perplexity and Gemini, and look at which tools get named and which pages get cited. Run it more than once, because the answers change between runs. You're looking for a pattern, not a verdict.

3. Read your about page like a stranger. Can someone tell in one sentence what you do, who it's for and who's behind it? Google's own guidance on helpful content points to background about the site and its About page as signals of trust. An assistant trying to describe you needs the same basic facts.

4. Count the mentions you didn't write. Your site says what you claim. Other places show whether anyone noticed. Directory listings, a README, a comparison post, a useful answer in a community thread. If the only page that mentions you is your own, that's a gap you can start closing this week.

5. Make sure your docs or FAQ answer real questions. Go back to step 2. For every question where you didn't show up, is there a page on your site that answers it plainly near the top, in text rather than an image? If not, write that page. It helps the human reader first, and anything that reads your site second.

None of this replaces a product people want. But if the check turns up gaps, fix those before you decide the idea is dead. A quiet signup graph can mean nobody wants it, or it can mean nobody outside your circle has been told.

So before you rewrite anything, give it one evening. Be the stranger, run the five checks, and write down what you find. The list of gaps is often shorter than the list of features you were about to build.

Then keep writing it down. Run the same checks every few weeks and note what you changed in between: a new headline, a new page, a different pitch. Six months from now you won't remember which change brought the first strangers, or when a competitor started showing up ahead of you. Without a record, every pivot is a guess.

That record is what we're building Serpair for. It keeps the history of your growth in one place: your Google rankings, whether AI assistants mention you, and what your competitors are doing, tracked over time. So when you try a new angle, a new piece of content or a change in positioning, you can look back and see what worked and what didn't. You can still do all of this by hand with a spreadsheet; Serpair just keeps it for you.

If you want a starting point, run a free SEO and AI visibility check on your site. It's a snapshot of where you stand today, the first entry in that log.

I'm Reza from the Serpair team. Everything below is free to do.

Start with the questions, not the code

Before changing anything, open a text file and write down five questions a stranger might ask when they have the problem your project solves. Write them the way a person talks, not the way your landing page talks.

For a made-up uptime monitor called ExampleMon, the list might look like this:

1. what is examplemon
2. cheap uptime monitoring for a side project
3. how do I get alerted when my site goes down
4. examplemon vs a self-hosted status page
5. is examplemon free

Notice the spread: your name, the problem without your name, a comparison, and price. Every item below exists to give Google and AI assistants a clear, crawlable answer to one of these.

If friends tested your project, use them here. Ask them how they'd describe it to someone else. Their wording is usually closer to a real query than yours.

The checklist

Check: Your name returns you, and only you

Question 1 is the one you can win first, and it's easy to lose without noticing.

• Search your exact project name in a logged-out browser. If a different product, a GitHub fork or a dictionary word wins, you have a naming problem to work around.
• Make the page title on your home page carry the name and a plain description together, for example ExampleMon: uptime alerts for small sites.
• Once your site is verified in Google Search Console, open the Performance report and filter queries containing your name. That tells you whether people search for you and whether you show up when they do.
• Ask ChatGPT, Perplexity and Gemini "what is [your name]". If they confuse you with something else, the rest of this list is how you correct it.

Check: An about page that says who, what and why

New projects often skip this page because it feels vain. It isn't. Google's guidance on helpful content lists "background about the author or the site" and links to "a site's About page" among the things that make content trustworthy (Google Search Central). An assistant that's asked about you needs the same facts.

Keep it boring and specific:

• What the project does, in one sentence a stranger understands.
• Who it's for and who it isn't for.
• Who builds it, with a real name and a link to a profile you actually use.
• What state it's in, such as beta or open source.

Use the same one-sentence description here, in your README, and on every listing. Consistency is what lets a crawler connect the pieces.

Check: Schema that matches the visible page

Structured data helps search engines understand what a page is about. For a web app, SoftwareApplication is the obvious type:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "ExampleMon",
  "applicationCategory": "DeveloperApplication",
  "operatingSystem": "Web",
  "description": "Uptime alerts for small sites.",
  "url": "https://examplemon.example",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

Two cautions. First, Google's software app rich result also needs either aggregateRating or review. A brand-new project probably has neither, so you may not get the rich result at all. Don't invent ratings to qualify. The markup still describes the app accurately, and that's worth having.

Second, schema isn't a back door into AI answers. Google says there's "no special schema.org structured data" needed for its AI features and that structured data should match the visible text (Google Search Central). Whatever is in the JSON should also be readable on the page.

Check: llms.txt, if you describe it honestly

llms.txt is a proposal by Jeremy Howard, first published in September 2024 at llmstxt.org. It's a Markdown file, usually at /llms.txt, with your project's name, a short summary and links to clean Markdown versions of your key pages. The idea is to give an agent that's already reading your site a tidy map instead of a pile of HTML.

What it is not: a ranking signal or a way to get discovered. Google's AI features guide says you don't need to create "new machine readable files, AI text files, or markup" to appear in AI Overviews or AI Mode. In 2025 Google's John Mueller wrote that no AI system was using it at the time.

Where it does make sense is documentation. If your project has docs that coding agents might read, a small file is cheap to add:

# ExampleMon

> Uptime alerts for small sites. Free tier, email and webhook alerts.

## Docs

- [Quick start](https://examplemon.example/docs/quickstart.md): add your first check
- [Webhooks](https://examplemon.example/docs/webhooks.md): payload format and retries

Add it as a convenience for agents, not as a traffic plan.

Check: Mentions you didn't write yourself

Your own pages tell search engines and assistants what you claim. Other sites tell them whether anyone noticed.

Honest ways to earn that as a developer:

• A clear GitHub README with the same one-line description and a link to your site.
• Listings on directories and launch sites relevant to your category, using identical wording.
• Technical write-ups on platforms like Hashnode about a real problem you solved while building it.
• Useful answers in communities where your users already ask questions, with a mention only when it genuinely helps.

Skip the shortcuts. Don't write your own Wikipedia article: its conflict of interest guideline discourages editing about your own company, and a new project rarely meets the notability bar anyway.

Check: Docs and FAQ pages that answer the real questions

Go back to your five questions. Each one that doesn't name you needs a page that answers it.

• Question 3 deserves a short guide: how to get alerted when your site goes down, with your tool as one option among the steps.
• Question 4 deserves an honest comparison page that says when the other option is the better choice.
• Question 5 deserves a pricing page in plain text, not just inside an image or a pricing widget.

Answer the question in the first couple of sentences, then go into detail, in HTML text rather than images.

FAQ sections are still worth writing for people and for assistants. Just don't add FAQPage markup expecting the old expandable results in Google. Since August 2023, Google has shown FAQ rich results only for "well-known, authoritative government and health websites" (Google Search Central Blog).

Run it again in a month

Treat the five questions like a regression suite. Every few weeks, search each one on Google and ask each one in a couple of AI assistants. Note whether you appear and what's said about you. AI answers vary from run to run, so look for a trend over several checks rather than reading too much into one result.

If you'd rather not keep that log by hand, Serpair tracks your Google rankings and whether AI assistants mention you, and its free plan comes with 50 credits.

Your friends tested the product. This checklist is how strangers get to find it.

Here's a checklist I use, in the order I'd check things.

1. Check robots.txt for accidental blocks

Open https://yoursite.com/robots.txt and read it line by line. Look for broad Disallow: / rules left over from staging.

Several AI companies publish their crawler user agents, such as GPTBot, OAI-SearchBot, PerplexityBot and Google-Extended. Decide on purpose which ones you allow. Check each vendor's docs, because names and behaviour change.

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

Sitemap: https://yoursite.com/sitemap.xml

Also check your CDN or firewall. Bot protection sometimes blocks crawlers even when robots.txt allows them.

2. Make sure the HTML has real content

Many crawlers don't run JavaScript the way a browser does. If your page is an empty shell until React loads, some of them see almost nothing.

A quick test:

curl -s https://yoursite.com/pricing | grep -i "your main heading"

If the text isn't in the raw response, consider server-side rendering or static generation for key pages. Frameworks like Next.js, Nuxt, Astro and SvelteKit make this straightforward.

3. Use clean, semantic structure

Crawlers and AI tools pull text by structure. Help them:

• One <h1> per page that says what the page is about.
• <h2> headings phrased like the questions users ask.
• A short, direct answer right under each heading.
• Real <table>, <ul> and <ol> elements instead of styled divs.
• Descriptive link text instead of "click here".

4. Add structured data that matches the page

JSON-LD gives machines explicit facts. Keep it honest and in line with the visible content.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "YourApp",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "url": "https://yoursite.com",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}
</script>

Useful types for product sites include Organization, SoftwareApplication, Article and FAQPage. Validate them with Google's Rich Results Test or the Schema.org validator.

5. Consider llms.txt, with realistic expectations

llms.txt is a proposed Markdown file at your site root. It lists your most important pages with short descriptions, for AI tools to read.

# YourApp

> YourApp helps small teams monitor scheduled jobs.

## Docs
- [Quick start](https://yoursite.com/docs/start): Install and first alert in five minutes.
- [Pricing](https://yoursite.com/pricing): Plans and limits.

It's cheap to add and easy to maintain. But it's a proposal, not a standard, and support across AI providers is unclear. Don't treat it as a replacement for the steps above.

6. Keep sitemaps and canonicals tidy

• Submit an up-to-date sitemap.xml in Google Search Console and Bing Webmaster Tools.
• Set canonical tags so duplicate URLs point to one version.
• Return proper 404s and 301s instead of soft errors.

Bing's index matters too, since some AI assistants have drawn on Bing results.

7. Verify, then repeat

After changes, check server logs for crawler user agents hitting your key pages. Then test a few real user questions in AI assistants and note whether your pages appear.

Summary

Content earns citations, but technical access decides whether you're even in the running. Fix crawl access, rendering, structure and structured data first. Then add extras like llms.txt.

I work on Serpair, which tracks Google rankings and AI citations together. The checklist above is free to apply on any site, with or without a tool.