Skip to content
alikhan.tech

Writing

Geo Search Patterns That Still Matter When Generative Answers Steal the SERP

Muhammad Ali Khan · 31 Oct 2026 · 06 Mins read

Geo Search Patterns That Still Matter When Generative Answers Steal the SERP

A clinic group asked me to turn off the map. Their reasoning was the reasoning I now hear every month. The search results page had an AI answer at the top, the answer already named a clinic, and the geo widget underneath looked like a leftover from 2024. Two weeks later the answer named a clinic that was forty kilometres outside the radius the patient had set, because the answer was a sentence composed from textual attributes and the radius lived on a different request. The SERP had been "stolen" by a perfectly confident paragraph. The paragraph had never run a geo filter.

I wrote up Sitecore Search geospatial in October 2024, and earlier this week I wrote about the attribute and extractor work Questions and Answers actually reads. This post is the pattern that connects them. Generative answers are allowed to summarize a place. They are not allowed to decide which place is inside the radius.

An answer and a geo query are different requests

Sitecore's Questions and Answers feature generates from up to five attributes on the sources you put in the group. Those attributes need textual relevance. The visitor's keyphrase has to qualify as a question or a statement. The response I am willing to render carries an answer, a context passage, and a document_id. The feature, on the documentation I am using, is English-only. None of that is a distance calculation.

A geo attribute is a different type. In 2024 I indexed coordinates on a geo field and applied a geoDistance filter through FilterGeo, with a radius and the user's latitude and longitude. I also made the mistake, in the sample, of AND-ing that filter with a name match against one doctor. The part that aged well is the type. A string that looks like "24.86,67.00" is not a geo value, and two numeric fields called latitude and longitude are not one either, unless you have built a filter that treats them as such. Search will happily textualize whatever you put in a string attribute, and a model will happily read that string as prose. It will not, by doing so, honor a radius.

So the page I ship in 2026 has two widget requests. The answer request uses the Q&A group and the five textual attributes that describe a place in words: name, address as a postal string, services, opening hours, a short note. The results request uses the geo attribute, the radius, and the sort or filter the map needs. I do not add the coordinate string to the Q&A group to "help the model." A model that sees "24.8607,67.0011" in its context will invent a proximity claim. The geo engine is the only thing on the page that knows what a kilometre is.

The place document is its own entity

The failure mode I keep untangling is one Content entity that tries to be an article and a clinic. Articles want content_text. Clinics want a coordinate, a bookable flag, and a city facet. When they share an entity, the Q&A group inevitably includes the long article body, the geo widget facets on a field only half the documents have, and a required attribute drops the clinics that have no marketing article. I split them.

The place source extracts:

  • id, name, url, type=place as the required set.
  • A geo attribute, required for anything that should appear on the map. If the extractor cannot produce it, I want the document out of the geo index, not plotted at null island.
  • address_text, services_text, and hours_text as the textual attributes the answer group may use.
  • A city or region facet as a string, for the people who refuse the browser location prompt. Facet selection is not a radius. I label it that way in the UI.

The article source stays the source I described on 27 October. It can mention a clinic by name and link to the place URL. It does not carry the coordinate. When the answer group for places is built, its source is the place source only. An article about "our expansion plans" must not be eligible to answer "which clinic is open now."

The filter I attach, and the answer I am willing to show

The widget request for places is ordinary Search. The geo clause is the same idea as the 2024 filter, without the extra name predicate that made the sample look like it was searching for one person.

type GeoPoint = { lat: number; lon: number };

export function geoDistanceFilter(point: GeoPoint, radiusKm: number) {
  return {
    type: "geoDistance",
    name: "coordinates",
    distance: `${radiusKm}km`,
    lat: point.lat,
    lon: point.lon,
  };
}

I build that object only after I have a point the user consented to, or a point they dropped on the map. I do not infer a point from the IP address and then let an answer say "near you." If the consent banner has not been accepted, the page runs the city facet and skips setSearchFilter for geo. The 2024 sample always had a hardcoded point. A production page that does the same will look personal and be wrong for everyone except the developer who picked the coordinates.

The answer panel has its own rule. If the Q&A response has no document_id, I render nothing. If it has an id, I look at the ids already returned by the geo request when a radius is active. An answer whose document sits outside that set is not shown above the map. It can be offered as a related question under a heading that does not say "closest." Closest is a geo word. The model does not get to use it unless the filter already did.

type Answer = { documentId?: string; text?: string };

export function answerAllowedOnMap(
  answer: Answer | undefined,
  placesInsideRadius: ReadonlySet<string>,
  radiusActive: boolean
): boolean {
  if (!answer?.documentId || !answer.text) return false;
  if (!radiusActive) return true;
  return placesInsideRadius.has(answer.documentId);
}

radiusActive is the whole product decision. With no radius, a cited answer about hours or services is useful and I show it, still with the document link. With a radius, citation is not enough. The cited document has to be one of the documents the geo filter returned. I would rather show an empty answer slot than a fluent paragraph about a clinic the map correctly excluded.

What generative answers on the wider web do not change

A lot of the pressure to delete the map is coming from outside Sitecore. Google's AI summaries and every other answer box have taught stakeholders that the top of a results page is a paragraph. Sitecore's on-site Q&A is the feature I can actually govern, because I choose the attributes and I get a document id back. An external engine that cites us, or mis-cites us, is influenced by whether our place pages expose the same facts as text: a postal address, hours, a stable URL. That is worth doing, and it is the reason address_text and hours_text exist as real sentences rather than as a coordinate. It does not replace the filter.

I keep the pages crawlable as normal HTML for the place URL. The map is an enhancement over a list that already contains the address. If the geo widget fails to load, the list still came from the same response and still respected the radius when one was sent. An answer-only page with no list is a demo. It fails the moment the keyphrase does not qualify as a question, which is a documented way to get an empty Q&A payload, and the user is left with nothing to click.

Analytics stay split as well. The results widget records onItemClick for the place the user opened. The answer records a click on the citation URL, which is the place URL, not a click on the paragraph. I want CEC to learn which clinic was chosen from the filtered set. I do not want a thumbs-up on a paragraph to look like a geo conversion.

The order I migrate a 2024 geo index

  1. Confirm the coordinate attribute is geo type, required on the place source, and not also stuffed into the article source as a string.
  2. Create the Q&A group with at most five textual attributes from the place source. Leave the coordinate out. Publish the feature configuration and run a question that should cite a known document.
  3. Keep the geo widget request separate. Apply geoDistance only when I have an explicit point, and keep a non-geo facet path for everyone else.
  4. Render the answer only when document_id is present, and only when that id is inside the filtered set if a radius is on.
  5. Leave a list under the answer. The paragraph can steal the top of the page. It does not get to steal the only link.

The 2024 post was about making the filter work. The 27 October post was about making an answer cite a document you extracted on purpose. The pattern that still matters, once a generative block sits where the first result used to sit, is that distance remains a filter and prose remains prose. I will turn the map off on the day Sitecore's answer API accepts a geo constraint and returns the radius it applied. Until that is the documented request, the geo widget stays.

Related notes