Open, move, and close location listing playbook

Opening, moving, or closing a location is when listing graphs fork. Staff create a second Google profile "just for the new address," Apple keeps the old pin, and directories resurrect the closed suite for months. This playbook sequences open / move / close work for business listing management so publishers stay aligned with the door.

Use the BLM homepage for the ongoing product definition, source-of-truth thinking on multi-location ops for the steady-state loop, and QA evidence for listing changes before you mark any lifecycle event done.

Follow Google's guidelines for representing your business. When hours or special hours change during a move or soft open, use Google's Help for editing business hours and confirm the live Help article for temporary or permanent status fields before you publish.

What is the open-location listing sequence?

Before launch day:

• Create the internal location ID and canonical NAP, hours, categories, and website URL.
• Claim or create profiles on priority publishers only after the address is real and the phone routes correctly.
• Do not publish the new pin while the build site still uses a contractor's number.
• Schedule verification windows; some publishers need postcards or video.
• Prepare launch photos and attributes without stuffing keywords into the name.

On launch day, push the open status and regular hours together. After launch, re-scan Google, Apple, Bing, and priority directories; ticket mismatches with evidence. Suppress any premature or duplicate profiles created by well-meaning staff.

How should a move be handled without splitting reviews?

A move is not "create new, delete old" by default. Prefer updating the surviving profile's address when the business is the same entity continuing at a new storefront, and when the publisher supports an address change without resetting the place identity.

During the overlap window, document which profile is authoritative. If a second profile is unavoidable, plan the survivor and review protection early using duplicate suppression. Update paid ads and website location pages on the same day as the listing address change so landing pages do not revive the old suite.

How do temporary and permanent closures differ?

Temporary closure keeps the place identity and signals that the business will return—useful for renovations, seasonal pauses, or emergency shutdowns. Update hours/status on priority publishers and set a revisit date. Do not let Apple and Bing keep Friday hours while Google says temporarily closed.

Permanent closure must propagate, or customers keep driving to a dark storefront. Mark closed on priority publishers, update the website, stop ads, and monitor for resurrected directory pages. Do not delete first as a cleanup shortcut; deletion can erase useful signals and still leave aggregator copies behind.

Always record who approved the closure and attach live-check evidence (QA standard).

What is the lifecycle checklist teams can run?

• Internal ID and canonical record updated before any publisher edit.
• Accountable owner named (RACI).
• Priority publisher list defined (at least Google, Apple, Bing).
• Open: verification plan + launch re-scan.
• Move: survivor decision + old-address citation watch.
• Close: status updates + resurrection monitoring window.
• Ads, website, and voice/assistant surfaces updated in the same change window.
• Evidence pack attached before the ticket closes.

FAQ

Should we create a new Google profile for every move?

Only when the place is truly a new business location identity. Many moves should update the existing profile. Creating a second profile is how reviews split.

How long do we monitor after a permanent close?

At least through one full aggregator cycle—often several weeks. Re-scan weekly at first. Resurrections are normal; treat them as tickets, not surprises.

Who triggers the playbook—real estate or marketing?

Either can intake; marketing or the listing Accountable owner must approve the canonical record before publish. Real estate alone should not invent public NAP strings.

Does this playbook replace ongoing listing management?

No. Lifecycle events are spikes on top of the steady-state loop on the homepage and multi-location listing ops article.