How to publish Google Business Profile posts at scale

A Google Business Profile post is one of the few things a multi-location brand can put in front of a customer on Search and Maps without paying for the impression. The catch is that it decays: Google archives posts that are older than six months unless the post carries a date range, so the "post once and forget it" approach quietly deletes your profile's newest content for you. For a brand running fifty stores, posting is a publishing operation with a cadence, not a one-off task. This post walks through how we think about that operation, and the honest way to run it at scale.

Why posting at scale is a publishing problem, not a content problem

Google's own documentation frames posts as updates customers find on Search and Maps, and it is explicit about the lifecycle: posts older than six months are archived unless a date range is set (Google's help article on creating and managing Business Profile posts, accessed August 2026). Every published post is therefore on a clock. A single store can hand-post weekly updates and stay current. A forty-store chain doing the same by hand is spending the better part of a working day every week just on freshness, before a single offer is designed.

The second constraint is approval. Google reviews each post against its posts content policy before it goes live, and the statuses a post passes through are live, pending, or not approved (Google's posts content policy, accessed August 2026). A post that fails review does not fail silently; it sits in a not-approved state until someone reads why. At scale, that means someone has to look at the rejections, because a post that quietly fails on ten stores is ten stores with stale content.

What the Business Profile API actually exposes

The reason this is automatable at all is that Google exposes posts as a first-class API resource. The local posts resource in the Business Profile API supports create, get, list, patch, delete, and a reportInsights method for post-level performance, and each post carries a scheduled time so a post can be written now and published later (the local posts resource in the Business Profile API reference, accessed August 2026). The post types are standard updates, events, offers, and alerts, and a post's call-to-action button can be BOOK, ORDER, SHOP, LEARN_MORE, SIGN_UP, or CALL — each mapping to a customer action rather than a generic link.

Two practical consequences follow from that shape. First, scheduling is a first-class capability: you can prepare a month of posts and let each one publish on its date, which is exactly the workflow a publishing calendar needs. Second, the CTA types mean the post is a conversion surface, not a status update: the same offer can be a "call this store" post or a "book an appointment" post depending on the location's role.

How to publish posts across every location

This is the procedure we use for an estate, whether it is ten locations or a hundred. It treats the six-month archive clock, the content-policy review, and the API's scheduling capability as the three facts the workflow has to respect.

1. Audit the estate before you post anywhere. Run a scored audit of every Google Business Profile first. A post published to a listing with missing hours or a wrong phone number amplifies the problem instead of fixing it, and the free PlaceOptimizer audit gives you the per-location list of what is broken before you spend the effort on content.
2. Match the post type and CTA to the offer, not to a template. Offers need dates and times, events need a schedule, and the CTA should name the action you actually want — CALL for a store where the phone drives walk-ins, BOOK for one with appointments. Picking these deliberately per location is what makes a post a conversion surface rather than filler.
3. Schedule the batch, then let the API publish it. Because every post can carry a scheduled time, write the month's posts once, set each location's publish date, and let them roll out on schedule. This is where the six-month archive clock becomes manageable: a calendar with a rolling pipeline keeps every profile's newest post inside the window.
4. Watch the review statuses, not just the publish confirmations. A post that lands in not-approved needs a human to read the policy reason, fix the post, and resubmit — and a phone number in the post description is a documented rejection trigger. Build the check into the routine, or the estate quietly goes stale on the profiles that failed.
5. Route the operation through a management console when the estate is large. The PlaceOptimizer operator console includes a post publishing workflow for every location — update, offer and event posts with a CTA button, targeted per location — the same shape as the API resource above.

Where the console earns its keep

Posting at scale is the kind of work that looks trivial on a demo and turns into a full-time job in production, because the real costs are the cadence, the approvals, and the per-location targeting, not the typing. The console exists to absorb exactly those costs: one workflow that knows which locations exist, which are healthy enough to post on, and what each one is allowed to do. If you want to see the audit half of that pipeline running on your own brand, the free PlaceOptimizer audit scores every location Google returns for you, and what the audit checks today lists every check behind that score.

A final note on scope. Post publishing and bulk CSV diff-and-apply ship in the console today; AI-assisted review replies and scheduled recurring posts are on the roadmap rather than live.