Skip to main content

GHL Asset Handoff to WordPress Dev Team

Purpose​

Every Symphony Core client site is built across two systems: WordPress (pages, layout, content) and GHL (forms, funnels, calendars, chat widget, reviews). When the builder hands the site to the WordPress dev team, they need to know exactly which GHL assets go on which pages, how each should be embedded or linked, and how to verify the result. This SOP is the decision and handoff record that bridges those two sides of the build.

Scope​

Covers:

  • Inventory of the GHL asset types eligible for inclusion on a WordPress site
  • The two hosting models (GHL-hosted vs WordPress-embedded) and when to use each
  • Handoff checklist: what metadata the WP dev team needs per asset before they can embed it
  • Post-embed verification steps per asset type
  • The handoff record itself (where it lives, who owns it)

Does Not Cover:

Context​

Symphony Core client websites are not single-platform builds. Pages live in WordPress, but most interactive elements -- lead forms, appointment calendars, chat, Google review displays, checkout pages, compliance pages -- live in GHL. This split is intentional: GHL is the system of record for contacts, conversations, and automations, so every interactive element that collects or acts on contact data stays in GHL and is surfaced on the website through embeds or subdomain links.

Without a deliberate handoff between the builder (who configures assets in GHL) and the dev team (who renders the WordPress site), predictable problems appear: forms on the wrong page, widgets without the right filter, broken calendar links, or legal pages missing from the footer. Those are never "WordPress bugs" or "GHL bugs" -- they are handoff gaps.

This SOP defines a reusable handoff artifact for any client site build, in any industry. Follow it on every project regardless of the client's vertical: the asset types, hosting models, and verification steps are the same for a law firm, a retailer, or a service business.

Prerequisites​

Key Concept: Two Hosting Models​

Every GHL asset that appears on a client site follows one of two hosting models. The handoff artifact must declare which model applies for each asset.

Hosting ModelWhere the Asset LivesSurfaced on WP Site AsTypical Examples
GHL-hostedgo.[clientdomain]/[path] (GHL funnel)Outbound link from WP button or menuB-series calendar funnels, review request pages, payment/checkout pages, A2P privacy/terms/consent pages
WP-embeddedInside the WordPress page itselfRendered inline via shortcode, iframe, or plugin widgetLead-capture forms, chat widget, calendar booker, Google reviews widget

The rule of thumb: short interactive elements that fit inside a page section (form, chat, widget) are WP-embedded. Full-page flows with their own URL (calendar booking funnel, checkout, consent form, privacy policy) are GHL-hosted and WordPress just links to them.

Part 1 -- GHL Asset Type Inventory​

The following types are in scope for any WordPress site build. Any asset not listed here requires a stack-standard exception per the SC WordPress Stack Standard approval process.

1.1 Lead-Capture Forms (WP-embedded)​

  • What it is: A GHL-built form that captures contact details and routes to GHL CRM / workflows.
  • Embed method: LeadConnector shortcode [ghl_form id="FORM_ID"] or the Elementor LeadConnector widget.
  • Destination pages: Contact, service/practice area pages, landing sections, popups.
  • Replaces: Any WP-native form plugin -- Contact Form 7, WPForms, Gravity Forms, etc. Those are prohibited per the stack standard.

1.2 Appointment Calendars (WP-embedded OR GHL-hosted)​

  • What it is: A GHL calendar where a prospect or client books a time slot.
  • Embed method:
    • Inline: LeadConnector calendar widget in an Elementor section, or the calendar embed code from GHL.
    • Full-page funnel: Link to the B-007 calendar funnel at go.[domain]/schedule (or another configured path).
  • Destination pages: Hero CTA, Contact page, "Schedule a Call" button in header/footer.

1.3 Chat Widget (WP-embedded)​

  • What it is: Sitewide chat bubble that routes messages to GHL Conversations.
  • Embed method: Enabled via the LeadConnector plugin in LeadConnector > Chat Widget. Usually site-wide, not per-page.
  • Destination pages: All pages by default; exclude specific pages if requested (e.g., checkout, legal pages).

1.4 Google Reviews Widget (WP-embedded)​

  • What it is: A GHL Reputation widget that displays Google Business reviews filtered by star rating.
  • Embed method: Iframe or JS snippet pasted into Elementor HTML widget, Gutenberg Custom HTML block, or via LeadConnector shortcode (if available in the installed plugin version).
  • Destination pages: Home (hero or testimonial section), About, dedicated Testimonials page.
  • Build reference: GHL Google Reviews Widget SOP.
  • What they are: The B-series funnels from the Extendly snapshot (B-004 through B-017).
  • Embed method: Published at go.[clientdomain]/[path]; linked from WordPress buttons, menus, or footer.
  • Destination: Specific CTAs on WordPress (e.g., "Book a Consultation" -> /schedule, "Leave a Review" -> /review).
  • Build reference: B-Series Funnel Quality Assurance and Publishing.
  • What they are: SMS-compliance pages required for A2P 10DLC registration.
  • Embed method: Published at go.[clientdomain]/privacy-policy, /terms-of-service, /consent. Linked from WordPress footer and from consent checkboxes inside embedded forms.
  • Build reference: A2P Compliance Legal Pages SOP.

1.7 Surveys and Custom Funnels (case-by-case)​

  • What they are: Purpose-built funnels outside the B-series (e.g., onboarding intake, feedback survey).
  • Hosting model: Usually GHL-hosted at a dedicated path on go.[clientdomain].
  • Process: Add to the handoff record with the same fields as a B-series funnel.

Part 2 -- Handoff Checklist to the WordPress Dev Team​

2.1 Handoff Record Location​

Create one GHL Asset Handoff document per client in the client's working area on Google Drive: Client_Delivery/[client]/work-in-progress/ghl-asset-handoff.md (or a Google Doc equivalent). This is the single source of truth for which GHL assets go on the WP site.

Do not store client-specific handoff records in this repository -- they belong in Google Drive per the repo's content-routing rule.

2.2 Required Fields per Asset​

For each asset, capture the following before the dev team begins embed work:

FieldExampleWhy It Matters
Asset typeLead-capture form / Calendar / Chat / Reviews widget / Funnel page / Legal pageDetermines embed mechanics
Hosting modelWP-embedded / GHL-hostedChanges whether the dev embeds or links
GHL asset name"Contact Us -- Short Form"Identifies the asset inside GHL
GHL asset IDForm ID, Widget ID, Funnel ID, Calendar IDRequired by shortcodes and iframes
Embed snippet or linkShortcode, iframe HTML, or full URLWhat the dev pastes into WordPress
Destination page(s)/ hero, /contact, /practice-areas/divorce, footerWhere on the WP site it appears
Trigger / placementInline section, popup, header CTA, footer linkHow users reach it
Post-submit routingPipeline stage, tag, workflow, redirect URLValidates the backend side of the funnel
Configured filter / constraintReviews 4-star and above; Calendar "30-min consult" onlyPrevents the dev from using a misconfigured version
Brand overridesAccent color, font, border radius per sc-site-config.jsonKeeps the embed on-brand
Consent requirementsRequired consent checkboxes, legal page URLsNeeded for forms that capture SMS opt-in
Owner (GHL side)Builder namePoint of contact if the asset needs changes
StatusDraft / Ready for embed / Embedded / VerifiedTracks handoff progress

2.3 Handoff Ritual​

  1. Builder finishes configuring each GHL asset and fills one row per asset in the handoff record.
  2. Builder sets each row's status to Ready for embed and notifies the WP dev team in Slack with a link to the record.
  3. WP dev team embeds assets in the order declared, updates status to Embedded as each is placed.
  4. QA owner runs Part 3 verification and updates status to Verified per asset.
  5. Any change to an asset's configuration (filter, routing, destination) is made in the record first, then in GHL -- never in GHL without updating the record.

Part 3 -- Post-Embed Verification​

Per asset type, the WP dev team (or QA owner) confirms the following in an incognito browser on both desktop (1440px) and mobile (375px) before marking the row Verified.

3.1 Lead-Capture Forms​

  1. Form renders on the declared destination page, in the declared section/position.
  2. All fields and labels match the GHL form configuration.
  3. Consent checkboxes (if A2P applies) render optional and not pre-checked; Privacy Policy and Terms of Service links resolve to the live A2P pages.
  4. Submit a test entry. Verify:
    • Thank-you / redirect behavior matches the GHL form's post-submit setting.
    • The test contact appears in GHL Contacts with the declared tag and pipeline stage.
    • Any triggered workflow runs (check workflow execution log).

3.2 Appointment Calendars​

  1. Calendar renders available time slots (not blank).
  2. Booking a test slot places a contact on the correct calendar and fires the declared confirmation workflow.
  3. Confirmation email/SMS is received at the test contact's address/number.
  4. If linked via GHL-hosted funnel: button on WP routes to go.[domain]/[path] with no broken link.

3.3 Chat Widget​

  1. Chat bubble appears on every page where it should, excluded from pages where it should not.
  2. Sending a test message routes it to GHL Conversations inbox under the correct sub-account.
  3. Auto-response (if configured) fires as expected.

3.4 Google Reviews Widget​

  1. Widget renders within 2-3 seconds.
  2. Only reviews at or above the declared star threshold appear.
  3. Stars and card styling match brand overrides; no horizontal scroll on mobile.
  4. Browser console shows no CSP / iframe-ancestors errors.
  5. Full verification per Parts 8-9 of the GHL Google Reviews Widget SOP.
  1. Each linked path resolves to the correct published funnel on go.[clientdomain].
  2. SSL is valid (HTTPS padlock) on every linked page.
  3. Footer and in-form links to legal pages work on desktop and mobile.
  4. For funnels: submit a test entry and confirm routing per Section 3.1.

3.6 Cross-Cutting Checks​

  • Analytics/pixel: if the stack standard's SearchAtlas OTTO pixel or a GTM container is present, confirm form submissions and calendar bookings fire the declared events.
  • No duplicate form plugins: LeadConnector is the only form source; the WP install should not have Contact Form 7, WPForms, or similar (per SC WordPress Stack Standard).
  • Mobile tap targets: all embedded CTAs are at least 44px tall and not clipped.

Required Inputs​

  • Approved wireframes with form and CTA placements annotated
  • Approved website copy with CTA destinations
  • GHL sub-account access for the builder (asset creator) and the QA owner
  • WordPress admin / Elementor edit access for the dev team
  • Client branding (colors, fonts, logo) per the client's brand guide
  • Decisions on per-asset filters (e.g., review star threshold, calendar type)

Expected Outputs​

  • A populated GHL Asset Handoff record in the client's Google Drive work-in-progress folder, covering every GHL asset that appears on the WordPress site
  • Each asset embedded or linked on the declared WordPress page(s) at the declared position
  • Each row in the record marked Verified with verification date and verifier name
  • Zero assets configured in GHL that are not captured in the record (or vice versa)

Troubleshooting​

Common Issues​

Issue: Dev team embeds an outdated version of a form or widget Solution:

  1. The handoff record is the single source of truth. Confirm the IDs and embed snippets in the record match what is in GHL today.
  2. If GHL was changed after the record was populated, the builder updates the record first and re-notifies the dev team.

Issue: A form was moved or renamed in GHL; embedded version breaks Solution:

  1. Do not rename or move a form after handoff without updating the record and notifying the dev team.
  2. If a rename is unavoidable, re-capture the new embed snippet from GHL and push it through the handoff record.

Issue: Calendar embed renders but no slots appear Solution:

  1. Confirm the calendar is published in GHL and has availability configured.
  2. Verify the correct Calendar ID is embedded (most common cause: wrong calendar selected during handoff).
  3. Clear any caching plugin (though the SC stack prohibits these) and hard-refresh.

Issue: Chat widget appears on pages where it should not (e.g., checkout or consent) Solution:

  1. In LeadConnector > Chat Widget, configure display rules to exclude the specific page paths.
  2. Update the handoff record to document the exclusion rule so future team members do not re-enable it.

Issue: A2P form missing privacy/terms links Solution:

  1. Check the form configuration in GHL: consent checkbox text must include Privacy Policy and Terms of Service links pointing to the live A2P URLs (per the A2P Compliance Legal Pages SOP).
  2. Republish the GHL form and refresh the WordPress page.

Exceptions and Edge Cases​

  • Case A: Client has no SMS use case -- A2P legal pages are still recommended for the website footer; skip only the consent form embed. Document the decision in the handoff record.
  • Case B: Client has an existing WordPress site with legacy forms -- Legacy forms must be retired before handoff; the stack standard does not allow parallel form systems. Document the migration in the record.
  • Case C: Client uses a third-party booking tool instead of GHL calendar -- Requires stack-standard exception approval per SC WordPress Stack Standard; once approved, list the third-party asset in the handoff record with the same required fields.
  • Case D: Multi-location client -- Each location may need its own calendar, review widget, or contact form. Create one row per location per asset in the handoff record; do not share IDs across locations.
  • Case E: Rebuild or content refresh on a live site -- The handoff record is updated in place, not recreated. Preserve the Status column so the team can distinguish new work from already-verified assets.

Revision History​

DateVersionChange DescriptionAuthor
2026-04-171.0Initial version, triggered by Moots Law site build handoff needs and confirmed in 2026-04-17 Tanu/Rohit/Taruna meetingSymphony Core Systems Team