Use one controlled change order for every record event
A clinic move, rename, new site or closure changes more than a contact line. It changes the identity signals by which search systems, maps, directories, pages and answer systems connect a clinic to a place. The practical risk is not merely that one field is wrong. It is that two live records describe different versions of the clinic at the same time.
This standard makes the clinic website the first editable factual record and treats all other surfaces as downstream records. Before an external record is edited, the website must state the new fact clearly enough for a visitor, crawler or reviewer to retrieve it without interpretation. That means a stable page URL, visible business details where relevant, a clear effective-date statement when a transition is underway, and structured data that does not contradict the visible page.
The order is deliberate. An external platform can review, delay, reject, merge or otherwise alter a submitted change. A clinic-controlled page gives the record keeper a dated reference point while that happens. It also reduces the temptation to create a second record simply because an existing record has not yet changed.
Use a separate change ticket for each location. Do not combine a rebrand, a move and a closure under one vague instruction such as "update details". Identify the event, the effective date, the old and new assertions, the responsible record keeper, and the evidence that will prove completion. Where an event includes several changes, record their order explicitly.
For related operating rules, consult the Local hub, the Indexing hub, the Schema hub and the Measurement hub. The pages titled Google Business Profile field control for clinics and Citation consistency and NAP hygiene in the UK provide field-level context. This page concerns the sequence and evidence for a change event rather than routine field maintenance.
Correction order table: the record keeper's screenshot rule
The table is the working rule. "First source" means the first source to be made factually complete, not necessarily the first system in which a submission is entered. A source that cannot yet show the new fact is not evidence that the change is complete.
| Change event | First source to correct | Website must carry before external edits | External record action | What may be reviewed | Old record treatment | Verification |
|---|---|---|---|---|---|---|
| Move to a new address | Canonical location page and organisation contact information | New address, effective status, directions or service-area implications where applicable, consistent structured data | Amend the existing location record where it represents the same operating clinic | Address change or renewed verification | Keep the former location URL addressable and route it to the current location or a move notice | Retrieve the public record and compare its address with the website |
| Rename or rebrand | Canonical organisation and location pages | New public name, continuity statement if useful, updated identifiers and structured data | Update the existing record if the underlying clinic remains the same | Name compliance, supporting evidence or verification | Keep former-name pages or routes addressable where references may persist | Search for both names and inspect the public record |
| Additional location | New, distinct location page | Unique address or service facts, location-specific contact details, opening status and structured data | Create or claim a distinct location record only for a distinct eligible operating location | Eligibility and verification of the new location | Do not alter the existing location into the new one | Confirm each location resolves to its own matching page |
| Closed or merged location | Closing location page and organisation contact information | Closure or transfer statement, effective status, onward route where appropriate, revised structured data | Request the status that matches closure or a genuine merger, rather than leaving obsolete operational details | Closure, duplicate or merger handling | Keep a closure or transfer route addressable for continuing references | Retrieve the old record and URL, then record the displayed status and destination |
Published documentation for the Business Profile product explains that changes to business information can be subject to review and that verification may be required in some circumstances. It does not supply a universal publication timetable. Therefore, do not promise an internal stakeholder that a submitted external change will appear on a particular day.
Event one: a clinic moves to a new address
Start by deciding whether this is the same clinic at a new premises or a separately operating location. The answer governs the record path. A same-clinic move normally requires continuity: the existing identity remains, while its physical location changes. A second operating site requires the additional-location process instead.
Before editing an external record, publish the new address on the canonical location page and ensure the organisation-level contact information does not conflict with it. State the move in plain language where the old address has been widely used. Update location structured data only after the visible page is correct, because markup should describe the page, not anticipate an unpublished change. Check internal links, appointment or contact paths, map embeds if used, downloadable documents and page titles for stale address references.
Then amend the existing external location record. The product documentation states that address edits can be reviewed and may lead to a verification requirement. Treat this as a possible branch in the change plan, not as a fault or a deadline. Preserve screenshots or exports of the submitted facts, but do not treat the editor view as public confirmation.
Keep the former location URL addressable. In most cases, the preferred operational outcome is a permanent route from the former page URL to the current location page, with a clear move statement on the destination where context is needed. If the old URL has a distinct historical purpose, retain a concise move notice instead. Keep that route while external references, search results or referral links may still use it. There is no safe universal removal date.
Verify by retrieving the public website without using an administrative session and by inspecting the public external record. Record the date, displayed address and any pending or review state. A location is not fully landed until the public record and the canonical page agree.
Event two: a clinic renames or rebrands
A rebrand is a name-continuity event unless the legal or operational reality is different. Do not assume that new colours, a new domain or a new trading name automatically justify a second place record. The record keeper must first document whether the same clinic, premises, services and operational entity continue under a changed public name.
Correct the website first. The organisation page and each relevant location page should use the new public name consistently. Where readers may encounter the former name in referrals, old articles or external records, a short continuity statement can reduce ambiguity: it should describe the relationship without claiming more than the clinic can support. Update visible logos, page titles, contact modules, structured data and any sitewide footer details as one controlled release. Do not leave the old name in markup while displaying the new one, or the reverse.
Only then submit the external name change for the existing record. The published Business Profile documentation requires a business name to reflect the name used in the real world. Name changes can be reviewed. Keep evidence that the clinic uses the stated public name, but do not assume a particular evidence type will be requested or accepted in every case.
Keep former-name routes addressable where the site previously had pages branded under the old name. A durable redirect to the current equivalent page is generally clearer than removing the old path. Retain a former-name reference on an appropriate continuity page for as long as it remains necessary to explain legacy mentions, but avoid duplicating full location content under both identities.
Verification requires two retrievals: search the former name and the current name, then inspect whether both lead to an intelligible current record. Log any coexistence of old and new external labels as an unresolved transition, not as a completed rebrand.
Event three: a clinic adds an additional location
An additional location is not an address edit. It begins with a distinct page that proves what is distinct about the location. Before any external record is created or claimed, publish a canonical location page for the new operating site. It should identify the place unambiguously, provide the location's applicable contact and access information, state its opening status, and avoid copying the old location page with only the address swapped.
The website should also make the relationship legible. The organisation page can list the locations, while each location page should stand on its own for someone arriving directly from a search result. Structured data must match each visible page. A single organisation identity may connect the locations, but the location assertions must not collapse into one blended address or one interchangeable page.
Next, deal with the external location record as a distinct location only if there is a genuine distinct operating presence and the platform's eligibility rules are met. The published product documentation describes verification as part of managing a business profile, and a new location may need verification. Do not present a new site as publicly established until public retrieval supports that conclusion.
There is no old address to retire in this event. The preservation task is different: protect the original location from accidental conversion. Check that its page, structured data, contact information and external record continue to state the original facts. The most common sequencing error is editing the existing location record into the new site, then attempting to rebuild the original.
Verify with a two-row comparison. Retrieve each public location record and each canonical location page separately. Each pair must agree internally, and the two pairs must remain distinguishable from one another. Record any review state against the new location only.
Event four: a location closes or merges
Closure is a status change, not a reason to erase history without a route for users. Begin on the website by deciding what the closing location page will say after the effective date. If services transfer to another clinic location, state that destination only where the transfer is real and current. If the clinic ceases operating at the site without a successor, say so plainly. Remove operational claims that are no longer true, including booking prompts or opening information for the closed location.
Revise structured data so that it does not represent the closed site as an active location. The organisation-level page should no longer direct people to the closed premises. Internal links, navigation, contact modules and location selectors must follow the same decision. This work must happen before external changes so that a reviewer or user can find a coherent source record.
Then request the appropriate external status for the old location. Published Business Profile documentation distinguishes changes to business information from the status of a business that is no longer operating. Use the status that describes the real event. A merger should not be used as a convenient label merely because two records appear similar; preserve enough documentation to explain why the records represent one continuing operation, if that is the case.
Keep the closed location URL addressable with a concise closure or transfer notice. If a current location is the proper destination, route users there while preserving the closure context. Do not redirect a closed location to a general homepage where the visitor cannot determine what happened. Retain the route while legacy search results, links, letters or listings could reasonably send someone there.
Verify both the old external record and the old web route. The evidence log should capture the status shown publicly, the effective date stated on the website and the destination reached from the former URL.
What counts as proof, and the dated evidence log to copy
Submission is not proof. Proof is a dated retrieval of the public record, paired with the website page that should govern the fact. Use a private browsing session or another non-administrative view where possible. Record what a normal visitor can retrieve, rather than what an editor can see after signing in.
Use this short log for each location and each event. It is intentionally small enough to maintain during a live change. Add rows rather than overwriting earlier rows, because the transition itself may matter later when a stale result is investigated.
Date and time observed: [YYYY-MM-DD, time zone]
Location identifier: [internal stable identifier]
Event: [move / rename / additional location / closure or merger]
Old assertion: [name, address or status]
New assertion: [name, address or status]
Canonical website page checked: [page title or internal reference]
External surface checked: [surface name]
Publicly displayed result: [exact observed wording]
Review or verification state observed: [none observed / state shown]
Evidence retained: [screenshot, export or archived capture reference]
Next check date: [YYYY-MM-DD]
Record keeper: [role or initials]
A useful decision rule is this: close a change ticket only when the website, the relevant public external record and the retained evidence all describe the same current fact. If any one differs, keep the ticket open and log the discrepancy as a record conflict. The Measurement hub can support a separate review of whether old pages continue to receive impressions or visits after the event; that measurement does not replace factual verification.
Limits of this standard
This standard covers the order and evidence for four clinic record events: a move, a rename, an additional operating location, and a closure or genuine merger. It does not decide whether a clinic is eligible for a particular third-party product, whether a particular category is appropriate, or how a platform resolves disputes. Those questions depend on the published rules and the underlying facts at the time of the change.
It does not apply to a temporary room, a practitioner working across unrelated premises, a service-area claim without a fixed patient-facing location, or a change that is only a typographical correction. Those situations can resemble a location event but may have different eligibility, verification and identity consequences. Nor does this standard provide legal, regulatory or clinical advice.
The standard also cannot guarantee how quickly an external change will publish, how a platform will display it, or whether historical third-party records will update automatically. The record keeper controls the clinic website and the quality of the submission evidence, not every downstream display. Where a public record remains wrong after the website and primary record have been corrected, use the relevant contesting process and preserve the evidence log.
Use the field-control register for ownership boundaries, the citation consistency page for recurring external discrepancies, and the Indexing hub when retired URLs or new location pages are not appearing as expected. This standard is complete only as a change-control method: it is not a substitute for those specialised operational references.