geodirectory/delete-location permanently deletes a location row, its SEO settings and its neighbourhoods. It requires confirm_name matching the city name.
Requires the Location Manager add-on. Without it the locations table does not exist and the ability says so rather than returning an empty list that reads as “no locations configured”.
Before you run it
Listings in the deleted location are not deleted, and that is the problem. They keep their city text while the location archive disappears, so they stop appearing in location-filtered searches and their location links go nowhere. On a directory whose whole value is location filtering, that is a set of listings that quietly become unfindable.
At a glance
| Ability | geodirectory/delete-location |
| Toolset | GeoDirectory — toolset/geodirectory |
| Group | GeoDirectory › Locations |
| Requires | AcrossAI Pro, plus GeoDirectory active on the site |
| Capability | manage_options |
| Safety | Destructive — permanently removes a location row, its SEO settings and its neighbourhoods. Requires confirm_name. |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Pro 0.9.16 and later |
How it works
The orphaning is the whole story. GeoDirectory does not cascade the deletion to listings, and it does not clear their city fields — so a listing in a deleted city still says it is in that city and has nowhere to point.
Those listings still exist and are still reachable directly. What they are not is findable, on a site where finding things by location is the point.
So the sequence before deleting is: list the listings in that location, decide where they go, move them, then delete. geodirectory/list-listings with a city filter answers the first part.
Deleting the default location needs confirm_default_removal as well, because the site then has no default — which affects listing creation and unlocated visitors, not just the archive.
Neighbourhoods under the city go with it.
Not idempotent.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
location_id | integer | Yes | Location row ID, from geodirectory/list-locations. |
confirm_name | string | Yes | Must match the location’s city name exactly as it is on this site. The guardrail against deleting by ID alone. |
confirm_default_removal | boolean | When deleting the default | Required when deleting the site default location. |
confirm | boolean | Yes — must be true | The irreversibility gate. Without it the call is refused before anything is touched. |
What comes back
| Name | Type | What it is |
|---|---|---|
location_id | integer | The location removed. |
orphaned_listings | integer | How many listings still name it. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Remove the city we no longer cover.
It resolves to one call:
{
"ability": "geodirectory/delete-location",
"parameters": {
"location_id": 7,
"confirm_name": "Bristol"
}
}Worth knowing
- Listings are orphaned, not deleted — and become unfindable by location.
- Move the listings first.
- Deleting the default needs a second acknowledgement.
- Neighbourhoods under the city go with it.
Related abilities
- GeoDirectory List Listings — find the listings that would be orphaned
- GeoDirectory Manage Location — set a new default first
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category