Before You Buy GEO Services, Ask These Questions

Before buying GEO services, ask which platforms the work concerns, what the provider will actually change, how visibility will be measured and what the evidence cannot prove. A screenshot of your name in an AI answer is not a guarantee of continued inclusion, a recommendation or a commercial result. The useful service is inspectable work and accountable review, not a claim to control someone else's answer system.

GEO usually refers to work intended to improve discovery and representation in generative search experiences. Providers also use terms such as AEO and AI SEO. Those labels do not establish the scope. One proposal may concern Google search eligibility. Another may concern ChatGPT discovery, content accuracy or a prompt-monitoring dashboard.

This guide is for founders and managers evaluating those proposals. It separates documented requirements from recommendations and sampled observations. The examples are original teaching scenarios, not findings from a representative AI-search study or private client programme.

Download the GEO provider evaluation workbook or the CSV template pack. Use the same questions across providers. The aim is to compare evidence and responsibilities rather than the number of unfamiliar terms in a pitch.

Ask what GEO means in this proposal

Request a plain-language scope. Which discovery surfaces are included? Which pages and company records will be inspected? What technical changes, content work and measurement will happen? What is excluded? A provider should be able to answer without saying that everything is proprietary.

For an engineering company, useful work may involve making actual capability and limitations clear. For a marine supplier, it may involve accurate product information and operating coverage. For a construction consultancy, it may involve explaining appointment responsibility. Those are buyer-information problems even if the provider calls the work GEO.

Do not dismiss legitimate work because the label is new. Equally, do not accept an old content package merely because it has been renamed. Ask what the proposed investigation will discover that the current programme has missed, and which decisions it will support.

Separate discovery from representation

Being mentioned is one observation. Being described accurately is another. A business can appear in an answer with obsolete services or an incorrect location. A programme that celebrates every mention without reviewing accuracy can make the business harder to assess.

Record the exact statement and the supporting source. If an answer claims a marine service operates in a location where it does not, the useful response is to investigate the source information and public ambiguity. It is not to count the answer as a visibility success and ignore the commercial consequence.

Ask whether the proposal includes correcting your own maintained records. The provider cannot edit every third-party source or force an answer to change, but it can identify inconsistencies and propose appropriate corrections. That responsibility should be stated rather than hidden beneath a broad optimisation claim.

Which platform's requirement are they quoting?

Google's AI-features guidance says no special AI schema or new machine-readable file is required for its AI Overviews and AI Mode. That statement concerns Google's features. It does not establish identical access controls or reporting for every other platform.

OpenAI documents distinct crawler purposes in its crawler overview. Search access and training controls should not be treated as the same switch. Before changing them, identify the business's intended choice and the relevant current documentation.

Anthropic also publishes crawler guidance. Do not assume a Google configuration has settled every platform's behaviour. Record the actual control, its purpose and the date reviewed.

Requirements, hypotheses and preferences

Every recommendation should carry a claim type. A documented platform requirement is one type. A plausible editorial recommendation is another. An observation from repeated prompt tests is a third. A provider's aesthetic preference is different again.

For example, “this intended public page carries an unintended indexing exclusion” is an inspectable technical finding. “A comparison table may help a buyer understand appointment scope” is an editorial recommendation. “The page appeared in three recorded answers” is a sample observation. None implies a guarantee of future citations.

This labelling makes the programme easier to evaluate. It also protects useful recommendations from false justification. Clear tables can be worthwhile because readers need them. The provider does not need to invent an algorithm rule to explain that value.

What will the provider inspect before writing?

A useful programme begins with the company's real offer and information. Which services exist? Who can assess a requirement? What territories can be supported? Which credentials are current and public? Which technical claims need approval? These are not questions an AI draft can answer from a company name alone.

Request an evidence inventory. Include service records, approved project material, relevant documents, current contact routes and the owners who can confirm facts. Public competitor pages can reveal how others explain a subject. They are not evidence of your business's capability.

Beware of manufactured authority

Do not permit fabricated staff biographies, invented projects or unsupported claims of market leadership. An article claiming to be reviewed by an engineer needs a real appropriate reviewer and an actual review. A dashboard screenshot needs an identified source and date. A synthetic chart needs a visible illustrative label.

The provider should explain how sources are chosen and checked. External citations belong next to the claims they support. A recognised organisation's homepage is not sufficient evidence for a specific statement about a material, procurement rule or performance result.

Ask how withdrawn information is handled. A certification can expire. A partner arrangement can end. A service can stop. Continued visibility of obsolete information is not progress. The maintenance plan should include review triggers and responsibility for updating your own pages.

Does the content answer a buyer's decision?

A page can be readable and still be unhelpful. A buyer needs conditions, comparisons, evidence and a next step. For an engineering capability, the page might need to state which input information is required for assessment. For a construction appointment, it may need to distinguish scope from exclusions.

Ask the provider to explain the purpose of each proposed page. Who is reading it? Which decision does it help? What original information or reasoning will it contain? Where does the reader go next? A keyword list is not enough to answer those questions.

Google's people-first content guidance is a relevant reference for content quality. It should support a page-specific editorial decision, not become a copied checklist that substitutes for one.

Depth should have a job

Long guides are worthwhile when they explain a complex decision. Tables, formulas and source notes should help the reader inspect the reasoning. A long article assembled from repeated definitions can still be thin in substance. Word count does not establish expertise.

Ask for an outline before bulk production. A credible outline includes worked examples, evidence gaps and review needs. It does not promise a fixed quantity of impressive statistics regardless of what the subject supports. Sometimes the right chart is a process diagram rather than a numerical claim.

For international pages, require an actual difference in information. Singapore, Malaysia, Australia, Germany, France and the UK can involve different delivery arrangements and buyer questions. A page that changes only the country name does not become a distinct useful answer.

Are technical foundations included or assumed?

Content cannot compensate for an unintended public-page exclusion or missing information in the rendered site. Ask whether the provider will inspect actual response behaviour, crawl access, indexing directives, canonical signals and relevant internal links. They should state which checks are possible with the access available.

The robots.txt introduction, noindex guidance and canonical documentation address different controls. A proposal that lumps them into “AI-friendly website” makes its work hard to verify.

Ask who implements and who verifies

An audit is not an implementation. A recommended tag change is not a published change. A local build is not a public verification. Ask the provider to identify the owner of each stage and the evidence used to mark it complete.

If the provider does not control development, the proposal should include an actionable handover. Name the affected URLs, current state, expected state and test. If it includes implementation, require checks on the actual public visitor path rather than only a preview screenshot.

The same principle applies to content. Approval in a document does not prove the site shows the approved statement. Verify the published page, related cards and downloadable documents where relevant. The commercial claim can appear in more than one place.

What exactly counts as visibility?

Define each metric before collecting it. A brand mention can be neutral. A recommendation can concern an unsuitable service. A citation can support a general statement without endorsing the business. A referral can arrive without becoming an enquiry. Those are different observations.

If a provider combines them into one score, ask for the formula, weighting and raw records. A proprietary composite can help organise work. It should not conceal which observation changed or imply that an unvalidated score measures commercial value.

Platform reporting is not interchangeable

Microsoft's AI Performance announcement describes reporting across supported Microsoft and partner surfaces. Its citation measures should not be relabelled as universal AI market share or Google AI visibility.

Microsoft later described additional AI visibility insights. Check the currently available definitions and scope in the authorised account. A vendor tool may offer a different sample, not the same population in another interface.

OpenAI's publisher FAQ documents referral tagging for ChatGPT links. That can assist visit analysis. It does not capture every possible exposure or establish what happened before and after the visit. A commercial record is still needed.

How will prompt testing be designed?

A provider can obtain a favourable answer by selecting a flattering prompt, supplying the company name or repeating tests until the result looks good. That is not a fair baseline. Define the prompt set before reviewing the answers and preserve unfavourable or empty results.

Group prompts by buyer decision. Include service selection, technical suitability, comparison and preparation questions where relevant. Do not claim researched demand unless demand was actually researched. A manually chosen prompt panel should be labelled as such.

Record context and repetition

Retain the exact prompt, platform, available model or mode label, test date, language, supplied context and repeat identifier. If a platform changes its interface or reporting, record that too. The reader should be able to tell whether two periods were measured comparably.

Repeated answers can vary. A small panel can be useful for checking examples, but it does not represent every buyer or every response. State the sample size and scope. Do not present a result from ten hand-picked questions as the percentage of all AI buyers who will see the company.

Keep branded and unbranded tests separate

“Is Company X suitable for this work?” and “Which firms could assess this requirement?” test different tasks. Supplying the brand changes the context. A proposal should not imply broad discovery success because the assistant can discuss a company the tester named.

Use branded tests to inspect accuracy and unbranded tests to observe discovery within the defined sample. Neither is a guarantee. Record whether the answer cites your page, another source or no source at all. Source choice can help identify what information needs investigation.

What is the denominator in the chart?

An attractive percentage can hide an unstable sample. Ask whether the denominator is prompts, answers, citations, tested services or something else. Ask whether every scheduled test is included. Ask whether missing answers and refusals remain in the record.

Consider a hypothetical panel of twenty buyer questions, repeated three times. All sixty planned observations are successfully collected and valid in this example. Twelve mention the business and forty-eight do not, giving a panel mention share of 20%. That is a result for this defined panel only. It is not 20% of all AI search or a forecast of buyer exposure.

These invented counts demonstrate a measurement convention. They are not observations of Creatif Work or a competitor. If failed tests occur, report both the planned panel and the successfully observed subset. Explain any revised calculation rather than quietly changing the denominator.

Do not compare incompatible periods

If one month uses Singapore English service prompts and the next adds broad global questions, the score can change because the sample changed. Keep a stable panel for comparison and a separate exploratory panel for new questions. Record when and why the panel is revised.

Similarly, changing the test platform, prompt wording or supplied context can alter the result. A report should annotate these changes. It should not attribute every difference to the latest page update simply because both happened in the same month.

Which claims should stop the buying conversation?

Guaranteed placement in a third-party AI answer deserves immediate scrutiny. So does a claim that the provider controls a platform's recommendations. Ask for the exact written basis. If the basis is merely a private tactic or a favourable screenshot, the guarantee is not established.

Be cautious when a provider says secret schema, hidden text or mass-produced pages are required. Google's structured-data policies require appropriate implementation, while its spam policies identify manipulative practices. Do not accept a tactic just because it carries an AI label.

A reasonable uncertainty statement is not incompetence

A provider can say, “We cannot guarantee inclusion, but we can correct these inspected information gaps and track the defined observations.” That is a stronger basis for accountability than certainty that cannot be verified.

The service should still have concrete outputs and decision points. Uncertainty does not excuse vague work. The provider should explain the evidence, proposed change, owner and public check. It should also explain what would make a recommendation wrong.

Ask for examples of rejected recommendations. A team that refuses an unnecessary page or unsupported claim demonstrates judgement. A proposal that approves every possible keyword opportunity may produce a lot of content without a maintained information structure.

Who reviews AI-assisted content and analysis?

The concern is not whether a tool was used. The concern is whether someone competent checked the claim, source, calculation and business interpretation. Ask for the review workflow and the responsibilities assigned to your own service owners.

An AI tool can help draft an outline or classify records. It should not invent operating territories, credentials or commercial outcomes. Google's generative-AI content guidance supports useful assistance while stressing accuracy and value. A programme should reflect those responsibilities in its actual approval process.

What happens when the model is wrong?

Request a correction procedure. Where are source notes stored? Who can pause publication? How are live corrections checked? Which affected pages and assets are reviewed? An agency should not rely on the next automated draft to repair the previous unsupported statement.

For technical subjects, identify the appropriate owner before writing. A construction method claim needs qualified input. A marine capability statement needs approval from the actual operating business. The provider's marketing reviewer cannot substitute for that responsibility merely by using a confident tone.

Keep confidential material out of unapproved tools. Ask how access, data minimisation and retention are handled. A proposal that requests entire CRM exports for a broad visibility report should explain why that information is needed. Public source work and private commercial measurement have different access requirements.

What will the monthly review decide?

A report should connect observations to next actions. If a page is repeatedly cited for a topic the business no longer offers, the next decision may be correction rather than celebration. If discovery is absent in a limited prompt panel, inspect relevant information and access before commissioning another large content batch.

Keep work states distinct. Recommended, approved, implemented, published and publicly checked are different states. The review should show what changed on the site, what was inspected and what remains uncertain. It should not use activity totals to imply commercial results.

Set useful continuation conditions

Before starting, agree what evidence would justify continuing, changing scope or pausing. Conditions can include unresolved factual gaps, unavailable approval capacity or a measurement design that cannot support the claim being sold. Do not define success only after the report arrives.

For a young programme, the first useful outcome may be a corrected service inventory and verified public access. That is worthwhile but should not be advertised as proven AI leadership. Later reviews can inspect answer observations and commercial records on their own terms.

The provider should not require indefinite patience without learning. Search outcomes can take time, but the team can still show what it investigated, changed and checked. A delay in observed inclusion is not permission to repeat a generic monthly explanation forever.

Compare proposals through responsibilities

Use a common evaluation sheet. Ask each provider who owns source verification, technical implementation, content approval, measurement and correction. Compare the depth and relevance of those responsibilities, not only the number of articles or dashboard screenshots included.

Do not buy visibility unrelated to the business

A general mention can be irrelevant to the buyer you need. An engineering firm cited for a student definition may gain exposure without gaining suitable enquiries. A construction consultancy recommended outside its actual responsibility can attract requests it cannot serve.

Choose topic and prompt scope according to the real offer. The provider should be able to explain why a proposed page helps a suitable decision-maker. Broad popularity alone does not settle commercial relevance. A small but useful audience can matter, while a large unrelated audience can consume receiving time.

Ask what happens when the engagement ends

Your company should retain access to its own site, accounts and agreed records. Clarify ownership of content, source registers, prompt definitions and measurement exports. A dashboard subscription may end, but the underlying work should not become impossible to understand.

Request a handover format before signing. The next team needs to know what changed, what was approved and which observations were collected. A proprietary score without its definition is a weak handover. An inspectable decision record is useful even if the provider changes.

An example buying decision

Run a small proposal demonstration

Before commissioning broad production, ask a provider to explain one proposed page in detail. Give them approved public information, a known buyer question and the current page. Ask what they would inspect, which claim needs additional approval and what would count as a useful improvement. The demonstration can be paid work where appropriate; it should not require disclosing confidential records unnecessarily.

Watch the reasoning rather than only the polished output. A credible provider may discover that the existing page needs a clearer scope statement and no new article. They may identify a missing technical source. They may conclude that a proposed chart has no suitable numerical basis and use a labelled process diagram instead. Those decisions demonstrate judgement that a long generic draft can conceal.

Ask them to show the source trail for one substantive statement. The trail should include the exact claim, the source record, the relevant conditions and what the writer added through interpretation. Then inspect one technical finding. Can the provider reproduce it and describe a bounded fix? The aim is not to test whether they know every platform detail from memory. It is to see whether they verify what matters.

Finally, inspect the measurement proposal. Ask them to classify one recorded answer as a mention, recommendation or citation and justify that classification. Ask what remains unknown. If the answer becomes “this proves all AI users will see your business,” the provider has jumped beyond the evidence. If they preserve the context and limitations, you have a record that can support a fair future comparison.

Assess the burden on your team

An ambitious proposal can fail because your business cannot supply the needed approvals. A technical service owner may have limited time. A founder may be the only person who can confirm partner coverage. A project image may require client permission. Ask for those dependencies before agreeing to a production quota.

Work backwards from the review capacity. If the company can thoroughly review one complex article each week, four unreviewed drafts are not a better outcome. Prioritise the questions that matter most and retain factual approval. The content calendar should reflect the business's ability to keep its statements accurate.

Consider how corrections reach the website. A provider can find an obsolete detail but need a separate development team to publish the change. The proposal should explain the handover and verification. Otherwise a monthly report can repeatedly identify the same issue while the public page stays wrong.

Keep a shared decision record with the minimum access necessary. The business owner should see which facts need confirmation, which changes were approved and which published checks were completed. This record is usually more useful than a dashboard full of unexplained green indicators. It also helps a successor team understand the programme without relying on the original provider's memory.

Imagine a marine service business receives two proposals. One promises guaranteed AI recommendations through a special file and fifty generated articles. The other identifies unclear service coverage, proposes an approved capability inventory, checks intended public access and defines a limited observation panel.

The second proposal is not automatically good merely because it is cautious. Check its actual evidence, responsibilities and review plan. But its claims can be tested. The first needs to establish a guarantee it may not possess and explain how its publishing volume will remain accurate and useful.

The sensible buying decision is to evaluate the inspectable work and its relevance. You do not need to predict every future answer to correct a real information problem. You do need to distinguish that correction from a promised outcome outside the provider's control.

Method and limitations

Use the workbook as a conversation record rather than an automatic purchasing score. Two proposals can cover different problems and require different access. A weak answer to one question may need clarification rather than immediate rejection. An unsupported guarantee needs stronger scrutiny because the promise itself exceeds the evidence. Preserve the reason for each decision so the next reviewer can understand it.

If the provider revises a claim after the discussion, retain the revised scope in writing. The sales conversation and the delivery plan should agree. Otherwise the team can end up buying a broad visibility promise while receiving a narrow set of page edits. Clear responsibility is useful to both parties.

This is an original proposal-evaluation framework. Platform references were reviewed on 3 October 2026. Platform controls and reporting can change, so implementation should use the current official documentation. The hypothetical panel and business examples are not representative market data.

The guide does not establish that any particular GEO provider is dishonest or ineffective. It explains how to evaluate a claim without relying on a label. A real buying decision should inspect the actual proposal and the company's available evidence.

Start with the problem

If a GEO proposal contains promises but does not explain the information gap, bring it to Creatif Work. We can discuss the real buyer question, the evidence available and the work that deserves investigation. Our SEO service includes the distinction between a website foundation and continued search work.

For the evidence structure behind a review, read what a useful SEO audit should tell you. For a financial claim, use the founder's SEO ROI guide. A sound next decision should survive those questions rather than avoid them.

Start with the problem.