GBP Optimization SOP

SOP: Google Business Profile Optimization

Last Updated: 2026-07-23 Owner: GBP Specialist Status: Official Applies to: New SEO, Core 30, Visibility Growth Plan, local SEO, and GBP management clients

What

This SOP standardizes how Tekton audits, plans, approves, implements, and verifies Google Business Profile optimization for new clients.

The goal is not to stuff the profile with keywords. The goal is to make the GBP accurately match the business, its website, its real services, its service area, and its proof. Every profile change must be source-backed, approval-gated when it changes live public data, and verified after implementation.

Core operating rule:

Read, audit, draft, and prepare freely.
Do not change GBP live fields, publish posts, reply to reviews, change services/categories, add products, or update hours without scoped approval for that exact packet.

Who owns it

Primary owner: GBP Specialist

Current operator: Rico owns the client-by-client audit, packet preparation, source checks, approved implementation, verification, and TaskTracker proof trail.

Supporting roles:

• SEO Specialist: Service Truth Map, Core 30 alignment, keyword and location strategy, website handoff, and approval of the exact API implementation packet
• Client Success Manager: client fact clarification, approval routing, missing asset follow-up
• Website Specialist: site page, schema, metadata, CTA, and internal-link fixes discovered during GBP work
• Clawton: visible workflow coordinator, read-only evidence collection, payload/packet QA, validation routing, proof packaging, and TaskTracker closeout support
• Ops Lead/Nick: elevated approval for high-risk fields or unusual Google account/profile issues

Do not hardcode teammate names in task templates. Use the role above, then assign the live TaskTracker user for the current team.

Ownership and approval split

Stage	Accountable role	Required output
Intake and business-truth lock	GBP Specialist	Onboarding/Cosmo facts, website support, access status, and conflicts
Live audit and preserve/gap pass	GBP Specialist	Current live snapshot with keep, change, separate workflow, and high risk classifications
Packet QA and exact payload	GBP Specialist with Clawton support	Exact after-state payload, update mask, not-touched list, and validation plan
Packet approval	SEO Specialist	Exact approval phrase recorded in TaskTracker
High-risk approval	Ops Lead/Nick	Explicit approval naming the high-risk fields and client
Validation and controlled write	GBP Specialist/Clawton	validateOnly result, narrow live write when unlocked, and execution log
Post-write verification	GBP Specialist/Clawton	Live readback, unchanged-field check, proof artifact, Work Log entry when applicable, and TaskTracker closeout

The same person may prepare and operate the packet, but the exact approval must be visible in TaskTracker before validation can unlock a live write. A Discord acknowledgment, client clarification, assignment, or general direction to optimize does not replace the approval phrase.

Official V1 state machine

DRAFT_PACKET
  -> LIVE_SNAPSHOT_LOCKED
  -> AWAITING_APPROVAL
  -> APPROVED
  -> PREFLIGHT_MATCHED
  -> VALIDATING

VALIDATING
  -> VALIDATION_FAILED -> STOPPED_REMEDIATION
  -> VALIDATED -> LIVE_WRITE_GATE

LIVE_WRITE_GATE
  -> WRITING
  -> VERIFYING
  -> VERIFIED_AND_LOGGED

Any stale live state, ambiguous approval, changed payload, API uncertainty,
or unrelated-field drift returns the packet to STOPPED_REMEDIATION.

No state may be skipped. validateOnly passing does not itself approve or perform the live write.

Steps

0. Create the GBP optimization work packet

Create or use one TaskTracker parent task for the client GBP optimization sprint.

Include:

• Client name
• GBP URL, location ID, Place ID, or CID when available
• Website URL and preferred GBP landing page
• Cosmo Sheet or onboarding source link
• Source folders for photos/logo/assets
• Package/phase: onboarding, Phase 1, Phase 2, monthly refresh, or special cleanup
• Approval rule: one subtask packet at a time
• Proof rule: every implemented change needs before state, approval, after state, and QA notes

Default subtasks:

1. Source and access preflight
2. Live GBP snapshot
3. NAP and landing page confirmation
4. Category audit and lock/change packet
5. Service menu audit and packet
6. Service description packet
7. Profile completeness pass
8. Main business description packet
9. Product card decision and packet, if applicable
10. Photo/logo asset pass
11. Three-month GBP post packet
12. Review audit, removal triage, and reply packet
13. Hours, special hours, and attributes packet
14. Website SEO handoff
15. Final QA and proof log

1. Source and access preflight

Gather sources before recommending changes.

Source-of-truth order:

1. Client Cosmo Sheet or onboarding record
2. Live GBP under the correct manager account
3. Client website or preferred landing page
4. Approved client photos, logo, and service assets
5. TaskTracker approval packet and proof log

Check Cosmo/onboarding for:

• Business name and DBA
• Address setup: public address, hidden service-area business, or hybrid
• Phone number
• Website and preferred landing page
• Primary services
• Target cities and service areas
• Hours and known closures
• Attributes, amenities, parking, appointment links, financing, emergency service, or special notes
• Existing GBP URL
• Client photo/logo links

Access path:

1. Sign into Google with the approved manager account, usually info@tektongrowth.com.
2. Open https://business.google.com/locations.
3. Search/select the correct business profile.
4. Confirm business name, city/address setup, phone, and website before doing anything else.
5. If the profile is missing, stop and mark access incomplete. Do not work from screenshots as if access is confirmed.

White-label exception:

• If Tekton should not appear as a visible manager, use the approved partner/client manager OAuth account.
• Verify the OAuth identity first.
• Verify it can list and read the target location before using it for audit work.

2. Pull the live GBP snapshot

Before drafting implementation-ready changes, pull current live state from API or dashboard.

Capture:

• Business name
• Address display and service area setup
• Phone number
• Website and appointment/contact URLs
• Primary category
• Additional categories
• Services and service descriptions
• Business description
• Opening date, if visible
• Regular hours
• Special hours
• Attributes and amenities
• Products, if visible
• Photos/logo/cover state
• Live and scheduled posts
• Reviews and replies
• Profile status, verification, suspension, duplicate, or pending-change warnings

Save the snapshot or a clean summary to the TaskTracker task. The live snapshot is the baseline for every later approval packet.

3. Confirm NAP, landing page, and profile identity

This is the first real decision gate.

Verify:

• The GBP is the right business/location.
• Name, address/address display, phone, website, and primary landing page match Cosmo and the website.
• The service-area setup matches how the business actually operates.
• No duplicate GBP appears to be competing with the canonical profile.

High-risk fields requiring elevated approval before any live change:

• Business name
• Primary category
• Address
• Address display or SAB/public address conversion
• Phone number
• Website URL
• Service area
• Business status
• Ownership or manager access
• Opening date when uncertain
• Anything likely to trigger reverification

If NAP or profile identity conflicts exist, stop the normal optimization flow and build a NAP/profile cleanup packet first.

4. Category audit

Categories are high-impact and can create verification friction, so do this before services.

Steps:

1. Pull live primary and secondary categories.
2. Compare categories against Cosmo, website services, Service Truth Map, and competitor/category lookup.
3. Keep the fewest accurate categories that describe real revenue services.
4. Treat primary category changes as high risk.
5. Avoid category stuffing and do not add categories just to unlock random service labels.
6. Decide one of:
   • lock current categories and make no edit,
   • approve a secondary category cleanup/addition,
   • escalate a primary category change,
   • hold because business truth is unclear.

Output:

• Current primary category
• Current secondary categories
• Recommended category state
• Rationale
• Risk level
• Approval needed or no category edit recommended

5. Service menu audit

Services should be real offerings, not keyword variants.

Steps:

1. Pull live service items and note which category each service belongs to.
2. Separate predefined/structured Google services from freeform services.
3. Check which predefined service types Google exposes for the current categories.
4. Compare services against:
   • Service Truth Map
   • website service pages
   • money services from onboarding
   • proof assets, reviews, and real projects
   • do-not-claim services
5. Group services into:
   • keep
   • convert to predefined service
   • add source-backed service
   • remove duplicate/spam/stale service
   • needs website support first
   • needs client confirmation
   • do not add because source truth does not support it
6. Keep the service list clean. More labels is not automatically better.
7. If service descriptions are also approved and ready, bundle menu and descriptions into one controlled serviceItems save. If not, keep the structural menu packet separate.

Output approval packet:

• Current service count and structure
• Recommended final service list
• Adds, removals, conversions, and unchanged services
• Description status: approved now or separate future packet
• Exact update scope, usually serviceItems only
• Verification plan

6. Service description packet

Every real service should have a clear, short description when Google allows it.

Rules:

• Keep descriptions service-specific.
• Do not city-stuff.
• Do not use fake guarantees, awards, rankings, or unverified years in business.
• Do not repeat the same boilerplate across every service.
• Keep the main business description separate from service descriptions.
• Keep descriptions within Google’s current character limits.

Packet structure:

Service	Current description	Proposed description	Source basis	Risk

Apply only after approval, ideally in one controlled serviceItems payload after a fresh preflight.

7. Profile completeness pass

Audit every GBP field Google exposes for that business type.

Check and fill or flag:

• Business description
• Opening date, only if confirmed
• Website URL
• Appointment/contact links
• Social profiles
• Service areas
• More from the business
• Amenities
• Parking
• Accessibility
• Payment/booking/service options
• Regular hours
• Special hours
• Business attributes

Do not invent details. If Cosmo and the website do not confirm it, mark it as a client question.

8. Main business description packet

Write the profile-level business description after the service menu is understood.

Steps:

1. Pull the current live description.
2. Draft one exact replacement under 750 characters.
3. Ground it in confirmed services, market, and proof.
4. Avoid unsupported claims such as top-rated, best, award-winning, guaranteed, or invented years.
5. Ask for approval of the exact copy.
6. After approval, update only the description field.
7. Re-fetch and verify exact match plus unrelated fields unchanged.

Packet must show:

• Current live description
• Proposed exact replacement
• Character count
• Source basis
• Claims requiring proof, if any
• Update scope

9. Product card decision

Products are conditional offer tiles, not a place to duplicate every service.

Use product cards only when they represent real, useful customer-facing offers, such as:

• core service packages
• promoted service categories
• financing offer
• consultation or estimate offer
• seasonal package
• productized service bundle

Rules:

• Product cards usually require browser/dashboard Product Editor. Do not claim API completion unless verified.
• Use real client photos when possible.
• Leave price blank when optional and unconfirmed.
• Link to the most relevant service, offer, or contact page.
• Get approval for title, category/collection, description, CTA URL, image, and price handling.

10. Photo and logo pass

Photos should build trust and match the real business.

Audit:

• Logo exists and displays cleanly
• Cover image is acceptable
• Real project/job photos exist
• Team, truck, equipment, office, storefront, or jobsite photos exist where applicable
• No obvious stock/generic images dominate the profile
• New approved photos are available from onboarding or client folder

Default new-client target:

• Logo or clean logo fallback
• Cover image or strong work photo
• 5 to 10 real client images if available
• More photos queued for ongoing posting if the client supplied enough assets

Do not upload client photos if ownership/approval is unclear.

11. Three-month GBP post packet

Posts should support real services and real pages.

Steps:

1. Read service truth and website pages first.
2. Build 3 months of post topics around core services, seasonal needs, FAQs, project proof, offers, and trust points.
3. Prefer exact service-page CTA URLs over homepage links.
4. Use real client images or approved branded images.
5. Avoid fake urgency, unsupported best/top-rated claims, fake project locations, keyword stuffing, and heavy text overlays.
6. Build approval packet with schedule, post type, caption, CTA, URL, image source, and QA notes.
7. Schedule only after exact batch approval.
8. Verify scheduled queue count, dates, captions, CTA URLs, media, location/account, and status.

12. Review audit and reply packet

Reviews are sensitive. Always read first, then draft.

Steps:

1. Pull total review count, average rating, newest reviews, and unreplied reviews.
2. For negative reviews, evaluate removal/flagging angle before drafting a public reply.
3. Do not reply publicly if flagging first is the better move.
4. Draft short, varied replies.
5. Reference the service only when the reviewer mentioned it.
6. Do not disclose private customer or job details.
7. Post replies only after exact approval.
8. Re-fetch and verify reply text matches.

Review packet should split:

• positive replies ready for approval
• neutral/negative replies ready for approval
• reviews that need removal/flagging triage before reply
• reviews that need client context before reply

13. Hours, special hours, and attributes

Steps:

1. Verify regular hours against Cosmo, website, and GBP.
2. Check special hours for upcoming holidays and stale entries.
3. Add only confirmed special hours.
4. Do not invent holiday schedules.
5. Check attributes and amenities for accuracy.
6. Remove stale or false attributes.
7. Log any client questions.

Attributes are public facts. Treat uncertain attributes as questions, not assumptions.

14. Approval packet rules

Every live-change packet must include:

GBP approval packet

Client:
GBP location:
Subtask:
Risk level:
Source basis:
Current live value:
Proposed exact change:
Fields/update scope:
What will not be touched:
Client-facing impact:
Verification plan:
Rollback/restore plan:
Website SEO handoff, if any:

Reply:
APPROVE GBP OPTIMIZATION API PACKET
REVISE: [notes]
HOLD

The official normal-risk approval phrase is:

APPROVE GBP OPTIMIZATION API PACKET

It approves only the exact packet, payload, update mask, and not-touched list attached to the TaskTracker work item at the time of approval. Record the approver, timestamp, packet link/version, and payload SHA-256 when a JSON payload exists.

High-risk fields require a separate elevated approval that names the client and exact fields. The normal approval phrase never authorizes changes to business name, primary category, address/address display, phone, website URL, service area, business status, ownership/access, or another field likely to trigger reverification.

Approval for one packet does not approve the next packet.

Examples:

• Approving service menu cleanup does not approve service descriptions.
• Approving post copy does not approve review replies.
• Approving category lock does not approve a later category experiment.
• Client clarification does not equal live-write approval. Revise the packet and get exact approval.

15. Pre-write re-fetch

Immediately before any live write:

1. Re-fetch live GBP state.
2. Confirm the current live value still matches the approved starting value.
3. Confirm prior changes are accepted/current, not pending or in limbo.
4. Confirm unrelated guardrail fields are unchanged:
   • name
   • address/address display
   • phone
   • website URL
   • primary category
   • service area
   • regular hours
   • open status
5. Confirm the approved payload still matches the current live state.
6. Stop if anything changed.

16. Controlled implementation

Implementation rules:

• Use the narrowest update scope possible.
• Prefer one controlled payload for related serviceItems changes instead of many small edits.
• Run validateOnly first where the API supports it.
• Do not retry rejected GBP writes blindly.
• Do not mix unapproved copy into a structural save.
• Do not mark a subtask complete after drafting. Complete means approved, implemented if applicable, verified, and logged.

Execution controls:

• Use one packet ID and one payload hash for the approved write.
• Do not execute the same approved packet/hash twice. If a prior attempt’s result is uncertain, re-fetch first and classify the live state before any retry.
• A changed payload, update mask, or starting state invalidates the approval and requires a revised packet.
• Keep test mode and dry runs pointed at fake/read-only targets. A workflow test must stop at the live-write gate.
• Never paste OAuth tokens, cookies, passwords, API keys, or raw credential files into Discord, TaskTracker, proof artifacts, or Work Logs.

If Google rejects the update:

1. Stop.
2. Save the exact error.
3. Re-fetch to verify no partial change landed when possible.
4. Draft a revised packet.
5. Do not poke individual partial edits to force it through.

Validation failure path

If validateOnly fails or the pre-write live state no longer matches the approved packet:

1. Stop before all live writes. Do not retry, partially edit, or switch to browser clicking.
2. Re-fetch when possible to confirm no change landed.
3. Post a plain-English status in the active Discord operator thread first:

I found one issue before making the GBP update.

What I found:
[plain-English issue]

What I recommend fixing:
[plain-English fix]

I stopped before making any live changes. I updated the TaskTracker item and added a remediation subtask so this can be fixed before we retry.

If the fix changes the approved packet, the revised version needs approval before we run it again.

4. Add the same failure, exact Google/API error, attempted packet ID/hash, and stop confirmation to TaskTracker.
5. Create the TaskTracker subtask Fix GBP validation issue before implementation with the issue, recommended fix, owner, and next check.
6. Revise the packet. If the payload, scope, or claims change, require a fresh APPROVE GBP OPTIMIZATION API PACKET comment.
7. Re-run preflight and validateOnly only after remediation is complete.

17. Post-write QA

After any approved live change:

1. Re-fetch the edited field.
2. Confirm exact approved value landed.
3. Confirm unrelated guardrail fields are unchanged.
4. Screenshot or save API/dashboard proof where possible.
5. Log proof in TaskTracker.
6. Mark only that subtask complete.
7. Preflight again before the next GBP change.

Post-write verification must prove all of the following before the write is called complete:

• The API/dashboard accepted the write.
• The edited fields match the exact approved after-state after a fresh live read.
• The primary category matches exactly and secondary category IDs match as a set when Google reorders them.
• Service items and descriptions match the approved normalized set when services were changed.
• Guardrail fields remain unchanged: name, address/address display, phone, website URL, primary category unless separately approved, service area, hours, and open status.
• No pending/limbo or partial-write state makes the result uncertain.
• The proof artifact and TaskTracker record contain the same packet ID, approval phrase, update mask, and outcome.

If readback does not match, mark the result verification failed or final state unclear, stop, and escalate. Never report success from the write response alone.

Proof log template:

GBP change proof

Client:
Subtask:
Approval phrase/source:
Preflight facts:
Update scope:
Before:
After:
Google/API/dashboard result:
Post-write QA:
Unrelated fields checked:
Evidence links/paths:
Remaining next step:

TaskTracker proof requirements

Every implemented packet must leave one durable TaskTracker proof comment containing:

• Client, GBP profile/location ID, and scoped subtask.
• Packet ID/version and approval phrase/source.
• Approver and approval timestamp.
• Payload SHA-256 when a JSON payload exists.
• Pre-write live snapshot facts and preflight result.
• validateOnly result, including the exact error when it failed.
• Exact update mask and fields touched.
• Explicit fields not touched.
• Before and after values or a linked machine-readable proof artifact.
• Post-write readback result and unrelated-field checks.
• Google/API/dashboard status, including pending state when applicable.
• Evidence links or artifact paths.
• Client Work Log Sheet link and verified row number when the work changed a client-visible GBP.
• Remaining blockers, website handoff, or next recurring maintenance date.

TaskTracker status rules:

• Mark only the implemented and verified subtask complete.
• Keep the parent open when later packets, posting, reviews, photos, products, hours, or website handoffs remain.
• Complete the parent only when the full definition of done is met.
• A draft, approval, validation pass, write response, screenshot, or Work Log row alone is not complete proof.

18. Website SEO handoff

GBP work often exposes site gaps. Do not silently ignore them.

Create a website handoff when you find:

• evidence-backed service coverage gaps
• weak service pages
• mismatched service names
• unsupported service/city claims
• missing or weak schema
• weak title/H1 packaging
• missing internal links
• GBP posts needing better CTA pages
• service pages needed before adding GBP services
• photo/proof gaps that should be requested from the client

Classify each handoff item:

• safe internal prep
• site preview branch needed
• client approval needed
• Nick/Jakob approval needed before live deploy/indexing
• client fact/photo request needed

19. Final QA and closeout

Before closing the GBP optimization task, verify:

• Correct GBP was audited under the correct manager account
• Cosmo/onboarding was checked
• Live GBP snapshot was captured
• NAP and landing page were confirmed or escalated
• Categories were locked or approved/verified
• Services were cleaned up or packeted
• Service descriptions were approved/implemented or queued
• Profile completeness fields were filled or flagged
• Main business description is source-backed and policy-safe
• Products were skipped or created only where useful
• Photos/logo were audited and approved assets were used
• Three-month post packet was approved/scheduled or queued
• Reviews were replied to, queued, or escalated for removal/client context
• Hours, special hours, and attributes were checked
• No high-risk field changed without elevated approval
• Every live change has before/after proof
• Exact approval phrase, packet ID/version, and payload hash are in TaskTracker
• validateOnly result and post-write live readback are in TaskTracker
• Unrelated guardrail fields were checked and recorded
• Client Work Log row is linked and read back when the GBP changed live
• Website handoff exists for site-side gaps
• TaskTracker proof/comment is complete

Definition of done

GBP optimization is done when all of the following are true:

1. The correct live GBP profile was verified and audited.
2. The profile was compared against Cosmo/onboarding, the website, and approved service truth.
3. Every recommended change is either implemented with proof, queued in an approval packet, or intentionally held with a reason.
4. No high-risk field was changed without elevated approval.
5. The profile has clean categories, real services, safe descriptions, accurate hours, accurate attributes, and approved visual assets where available.
6. A three-month post packet is scheduled or ready for approval.
7. Review replies are posted, queued for approval, or escalated for removal/client context.
8. Website-side gaps are handed off as clear tasks or approval packets.
9. TaskTracker contains the proof log and final closeout summary.

Closeout summary format:

GBP optimization closeout

Client:
Profile checked:
Sources used:
Implemented changes:
Queued approval packets:
Held or blocked items:
Website handoff:
Proof links/paths:
Next recurring maintenance date:

New client quick-start checklist

Use this when setting up the first GBP sprint for a new client.

• Create TaskTracker parent task
• Attach Cosmo/onboarding source
• Confirm GBP access
• Pull live snapshot
• Confirm NAP and landing page
• Audit categories
• Audit services
• Draft service menu packet
• Draft service description packet
• Draft business description packet
• Decide products yes/no
• Audit/upload approved photos
• Draft 3-month post packet
• Pull reviews and draft replies/triage
• Check hours, special hours, and attributes
• Get approval for exact packets
• Implement one approved packet at a time
• Re-fetch and verify after each write
• Log proof
• Create website handoff
• Close out with next maintenance date