The short answer: Getting found on Google and getting cited by ChatGPT, Gemini or Perplexity mostly depend on the same fundamentals: every page has its own title and description, search engines can find every page, your content is in the page's HTML rather than loaded later by JavaScript, and your business details are stated clearly and consistently. When we audited our own website in October 2026, we found nine problems, and none of them were visible in a browser.
Like most small businesses, we built our website, launched it, and moved on to client work. In October 2026 we finally gave stratigconsulting.in the same technical audit we'd give anyone else's site. We expected a short list. Instead we found that Google had been shown the same title for every single page on our website, including all seven of our articles.
This article walks through what we found, what each problem meant, and how we fixed it. At the end there's a checklist you can run on your own site in about 30 minutes, most of it without a developer.
What is GEO, and is it different from SEO?
GEO (generative engine optimisation) means making your website easy for AI tools like ChatGPT, Google's AI Overviews, Gemini and Perplexity to read, understand and cite when they answer someone's question.
It sounds like a new discipline. In practice, it is mostly SEO done properly. Google's own guidance, last updated in December 2025, says there are no additional requirements or special optimisations needed to appear in AI Overviews or AI Mode: a page needs to be indexed and eligible to show a snippet in normal Google Search.
The one real difference is technical. Google renders JavaScript before reading a page. Many AI crawlers do not. A study of Vercel's network published in December 2024 found that none of the major AI crawlers it tested, including those from OpenAI, Anthropic and Perplexity, executed JavaScript. If your content only appears after JavaScript runs, those tools may see an empty page.
Our first guess was wrong
Our site is built with Next.js, a modern JavaScript framework. So our first suspicion was the classic one: maybe our article text only appeared after JavaScript loaded, making it invisible to AI crawlers.
We tested it in 30 seconds, and you can do the same on your own site:
- Open any important page, such as a service page or blog article.
- Right-click and choose View Page Source (on a Mac,
Option + Cmd + Uin Chrome). - Press
Ctrl + Fand search for a full sentence from the middle of the page.
If the sentence is there, crawlers can read it. Ours was. Our articles were fine on that front. The real problems were elsewhere, and far less obvious.
What we actually found
| Problem | What it meant | Fix |
|---|---|---|
| Every page had the same title and description | Google saw 13 pages all called "IT Consulting & Digital Growth in Pune" | A unique title and description per page and per article |
| Our articles weren't in the sitemap | Search engines had to stumble on them through links | A sitemap built automatically from our article list |
No canonical tags; mixed www and non-www | Google had to guess which version of each page was the real one | One canonical URL per page, always on www |
| Business details pointed at the wrong domain | Our structured data named a .com address we don't use | One correct, sitewide business profile |
| No article author or dates in structured data | No signal of who wrote what, or when | Article markup with a named author and publish date |
| Pages faded in from invisible | Each page started blank until JavaScript loaded | First load now shows content immediately |
| Fake URLs returned "200 OK" | Google could index endless "Post not found" pages | Real 404 responses for pages that don't exist |
| Uncompressed article images | Full-resolution photos slowed every article down | Resized, compressed images; lazy loading on the blog list |
| Our build ignored code errors | Bugs could reach the live site silently | Error checks switched back on |
Here's what the most important ones mean in plain language.
1. Every page had the same title
The page title is the blue headline Google shows in search results, and it's one of the strongest signals of what a page is about. Ours was identical everywhere: our homepage title, repeated on the services page, the about page and every article.
The cause was technical: the way our pages were built didn't allow each one to set its own title, so they all inherited the homepage's. It's a very common problem on sites built with modern JavaScript frameworks, and it's invisible unless you look at the page source or search Google for your own site.
Check yours: search Google for site:yourdomain.com. If many results share the same headline, you have this problem.
2. Our articles weren't in the sitemap
A sitemap is a file that lists every page you want search engines to know about. Ours listed six pages and none of our seven articles. It also told Google that every page had changed "today", every time the site was rebuilt, which teaches search engines to ignore the date entirely.
Our sitemap is now generated from the same list that powers the blog, so a new article appears in it the moment it's published, with its real publish date.
3. Our business details were inconsistent
Structured data is a block of code, invisible to visitors, that tells search engines and AI tools facts about you: your business name, location, contact details, who wrote an article and when. AI tools lean on it to work out who you are and whether to trust you.
Ours had one block, on the homepage only, and it pointed to the wrong domain and the wrong LinkedIn page. We replaced it with a single sitewide profile and added article markup naming our founder as the author of each post, with publish dates.
Google is explicit that structured data should match what's visible on the page. So we also added a visible author byline to every article, rather than only declaring it in code.
4. Every page started invisible
Our site used a fade-in animation between pages. That animation also ran on the first page load, so each page began fully transparent and only appeared once JavaScript had loaded. On a slow mobile connection, visitors stared at a blank screen, and Google's page-speed measurements counted that delay against us.
We kept the animation for moving between pages, and removed it from the first load.
Should you let AI crawlers read your site?
Your robots.txt file tells crawlers what they may and may not read. Most small business sites allow everything by default, which already includes AI crawlers. You don't need to add anything to be visible.
What's worth knowing is that the big AI companies use separate crawlers for separate jobs. OpenAI, for example, uses OAI-SearchBot to show websites in ChatGPT's search results, and GPTBot to collect training data for its models. OpenAI's documentation says sites that block OAI-SearchBot won't appear in ChatGPT search answers. You can allow one and block the other.
We chose to allow both. For a consultancy, being cited when someone asks an AI tool about automation or app development costs in India is worth more than keeping our articles out of training data. Your answer may differ. A publisher whose content is the product might reasonably block training crawlers. Either way, it should be a deliberate decision, not a default nobody looked at.
One common misconception: Google-Extended, Google's AI-related robots setting, does not control whether you appear in Google Search or AI Overviews. Those are governed by Googlebot. Blocking Googlebot to stay out of AI Overviews would remove you from Google Search entirely.
What we deliberately didn't do
- No special "AI markup". Google says none is needed for AI Overviews. We used standard schema.org markup that has existed for years.
- No keyword stuffing or AI-written filler pages. They don't help, and they dilute the pages that do.
- No backdated content. Article dates in our structured data are the dates they actually went live. An AI tool that sees a date it can't trust has less reason to trust the rest of the page.
A 30-minute checklist for your own website
You can do most of this without touching code. Anything that fails is a specific, fixable item to hand to your developer.
- The view-source test. Search the page source for a sentence from the page. Missing means AI crawlers probably can't read it.
- The title test. Search
site:yourdomain.comon Google. Every result should have its own, specific headline. - The sitemap test. Open
yourdomain.com/sitemap.xml. Every service page and article should be listed. - The fake-page test. Visit
yourdomain.com/this-does-not-exist. You should see a "not found" page, and your developer can confirm it returns a 404 status. - The robots test. Open
yourdomain.com/robots.txt. Make sure it isn't blocking anything you want found, and that its AI crawler settings are a decision you've actually made. - Register with Google Search Console and Bing Webmaster Tools. Both are free. Submit your sitemap to both. Without them, you can't see how search engines view your site.
- Claim your Google Business Profile. For local searches like "IT consultant in Pune", this often matters more than anything on your website. Keep your name, phone number and city identical everywhere they appear.
- Put a real name on your articles. A named author with relevant experience is a stronger trust signal than "Admin" or "Team".
- Answer first, then explain. AI tools tend to quote passages that answer a question directly. Start each article, and each major section, with a clear one or two sentence answer, then add detail, figures and examples.
The pattern behind all nine of our problems was the same: the website looked perfect to a human visitor. Search engines and AI tools don't look at your website the way your customers do. You have to check what they actually receive.
What we're measuring next
We made these changes in October 2026 and set up Google Analytics, Google Search Console and Microsoft Clarity at the same time, so we can measure the effect properly rather than guess.
We'll publish the results, including what improved, what didn't, and how often AI tools send visitors our way, in a follow-up article once we have enough data to say something meaningful.
If you'd like us to run this same audit on your website, book a free strategy call below. We'll tell you what we find, whether or not you hire us to fix it.