Help people find and understand your business.
122 of the 877 open businesses in the Squamish town read I published this year have no real website at all, and another 160 have at least one broken customer path on the site they do have (byImprint town read, 14 August 2026). A site that search and AI tools cannot find, read or trust is invisible before any ranking question comes up. This guide covers what actually needs to be true first: a working page, one document every fetcher can read, and a route a person and a crawler can both follow, then how to check what happened instead of assuming it.
Give each page a useful job.
A service page should explain the offer and the next step. A case should show actual work and its limits. A guide should help someone make a decision or complete a task. Link them to each other when the next page genuinely helps, not because a link is good for search.
On byImprint's site, the guide index groups practical questions while the service pages explain how to work together. That gives a reader a route from a problem to relevant help without a separate page for every wording of the same search.
122 of the 877 open businesses in my August town read had no real website, only a directory listing or a social profile standing in for one, and 160 had a broken step on the site they did have (byImprint town read, 14 August 2026). Before anything about AI or ranking, check that a working page exists for the question a customer, or a crawler, would actually ask.
Serve one document to every fetcher, not different ones.
In September 2026 I changed how this site answers requests, so that a human browser, Googlebot and an AI crawler such as OAI-SearchBot all receive the same HTML document for a given page, rather than a version built for one that is thin or awkward for the others. I did this because a page that renders correctly for a person but returns something incomplete to a crawler is effectively invisible to search and AI tools, whatever its actual content says.
I have not measured a ranking or traffic result from this change yet; it is too soon and the site is small. What I can state plainly is what changed and why: one document, one URL, the same content, no separate rendering path that a crawler sees differently from a visitor.
Make the sitemap something a fetcher can actually use.
I also checked that this site's sitemap is itself indexable and not blocked by the same rules that govern the pages it lists, following Google's own sitemap documentation. A sitemap a crawler cannot fetch is not a sitemap, whatever it claims to contain, and a blocked sitemap is a surprisingly common way for an otherwise reasonable site to stay invisible to a crawler without anyone noticing.
If you run a site on a platform that generates a sitemap automatically, do not assume it is correct. Fetch the sitemap URL yourself, the way a crawler would, and confirm it returns your real pages with a normal response, not a login wall, a redirect loop, or an error page dressed up as content. Check it again after any redesign or platform change, since a migration is exactly when a sitemap quietly breaks.
Check the rest of the site the way a crawler would, not the way a visitor does. A visitor sees the rendered page in a browser, with scripts run and styling applied; a crawler often sees something earlier in that process, and the two do not always match. Fetch a page's raw response separately from viewing it in a browser, and check that the text a customer would need, the offer, the price, the service area, is present in that response rather than only appearing after a script runs.
Check your robots rules the same way: read the actual file at the well-known robots path, not a summary of it from your website builder's settings panel. A rule that blocks an entire section by accident is easy to write and easy to miss, because the site still looks completely normal to a human visiting it.
Date and mark up what changes over time.
Reports and guides on this site now carry dated Article structured data, so a page that answers a question with a number, like this one, states plainly when that number was current and when the page was last checked. Google's own documentation on Article markup and on generative AI search both point to dated, well-structured content as easier for their systems to use correctly, though neither promises inclusion or ranking from using it.
If your site publishes anything time-sensitive, a price, a stock count, a seasonal offer, put a visible date on it and keep that date honest. An AI system summarising your page has no way to know a number is six months stale unless the page itself says so.
Keep one entity, not several.
I also aligned this site's name, description and details across Google, LinkedIn and X this September, so the same business reads the same way in each place. This is not a ranking trick; it is closer to bookkeeping. A search or AI system trying to work out whether the byImprint on the website is the same byImprint on the Business Profile has an easier job when the basic facts agree everywhere.
Check your own listings the plain way: read your website, your Google Business Profile and whichever social profiles you actually use, side by side, and fix any name, address or description that has drifted apart from the others over time.
Check eligibility before promising visibility.
Google's guidance says its AI search features use the foundations of Search. A page needs to be indexed, eligible for a snippet, and included under the relevant Search Console setting. Meeting those requirements does not guarantee it will be shown in any given feature.
Use Search Console to inspect the actual page and diagnose a block or an unexpected chosen canonical. A successful page fetch, or a submitted sitemap, is not proof of indexing on its own.
None of the changes described above guarantee a result. Google's own documentation is explicit that meeting the technical requirements does not guarantee a page will be shown. I am stating what I changed on this site and why, not claiming a ranking outcome from it.
Make important links ordinary links.
Google's link guidance recommends crawlable links with meaningful link text. Important pages should be reachable from another page, with a destination a reader can understand before clicking it.
Check the route yourself: Home to Guides to the relevant guide, then to its service or enquiry page. A technically listed URL with no useful route through the site is a weaker customer experience, and usually a weaker crawl path too.
Keep crawler controls distinct.
OpenAI documents separate controls for OAI-SearchBot, which supports search, and GPTBot, which concerns model training. Check the current documentation and your own crawler settings, rather than treating every AI bot as the same choice with the same trade-off; a business that wants to be found in an AI answer but not used to train a model needs to read the distinction, not guess at it.
Google says llms.txt and special AI text files are not required for its Search visibility. Such files can serve other integrations, but maintaining one does not establish rankings or inclusion in an AI answer on its own, and a poorly maintained one that drifts out of sync with the real site can do more harm than having none.
The same discipline applies to structured data, including the Article markup this site now carries: it describes the page it sits on, and if a template applies the same markup to every page without checking the actual content, the description can quietly stop matching what a visitor sees, a stale date, a wrong author, a price that changed on the page but not in the markup beside it.
Treat structured data as part of the content, reviewed on the same schedule as the page itself, not as a one-time technical task finished at launch and never revisited again.
Read one real indexing result, not a promise.
The clearest indexing result I have is from a Whistler dog walking business, Doggy Tales, published with the owner's permission. Several of its service pages were not indexed in June 2026. Chad, the owner, made the site and profile changes himself in June and took the Search Console indexing step on 8 July.
By the Day 90 check, every page that had been unindexed at Day 30 was indexed, 32 of 35 sitemap pages in total, verified 3 September 2026 against Search Console data through 1 September. That case does not prove a booking, revenue or ranking outcome; none of those were measured, and the full case notes that limit plainly.
What it shows is narrower and more useful here: an indexing problem, correctly diagnosed and fixed, resolved within the window Search Console itself reports. The same case also recorded the Business Profile appearing in six of eight sampled Whistler local-pack searches by the Day 90 check, against none of eight in June, a profile result rather than a website-indexing one, sampled once, from Whistler, on a desktop. See the full case for the sampling method and everything it does not claim.
Measure observations at the right level.
Track useful search impressions and visits alongside received enquiries and their fit. Keep test traffic and internal checks separate from real visitor data where possible, so a number is not quietly inflated by your own team checking the page.
Record the page, query, date and location for any manual AI-answer observation. One mention is an observation, and one absence is not proof that a business is invisible everywhere. Improve the underlying information and review patterns over time, without promising a position you have not measured.
Write down what changed and when, the way I have tried to in this guide: a dated change, an honest note about what was not yet measured, and a plan for when to check again. That habit matters more here than any single technical fix, because search and AI systems change their own behaviour on a schedule nobody outside them controls.
