HubSpot forms not working: check the embed ID

An embed code carries the identifier of one form, and the page keeps showing that form until someone replaces the code. Forms get copied when a team makes a version for a campaign, and a copy has its own identifier, so the page can hold the old one while you edit the new. The visitor sees a form with fields you removed, a thank-you message from the old version, or a field marked required that your current form has dropped. Nothing on the page reports an error, and the form still submits, which is why it is hard to spot from inside HubSpot.

• The form identifier in the embed code on the live page, compared with the form you edit.
• The portal identifier, which tells you which HubSpot account the page draws from.
• Fields a visitor sees on the page that you have since removed from the form.
• The thank-you message after Submit, which should match the current version of the form.
• Two copies of the same form on one site, each embedded on a different page.

Start with the embed code on the live page. It names a portal and a form, and those two identifiers decide which form draws. You can read the same identifiers in the embed options for the form inside HubSpot. If they match the form you are editing, the page is current and the problem lies elsewhere. If they do not match, the page is showing a different form, and no change to the current one will reach it.

Copies cause a common kind of mismatch. A team clones a form to test a new question, edits the clone, and forgets which one the landing page embeds. The page keeps the original, and the edits sit in a form no visitor sees. A code copied from another account can point at a form that does not exist in the account the site now uses. Check the portal identifier as well as the form identifier, because a matching form number alone proves little.

A visitor can only judge what the page draws, so a stale copy shows up on screen. The visitor fills the fields that appear, which may include a question you removed, and misses one you added. A required field from the old version can still block Submit, and the thank-you message may name an offer you no longer run. From the visitor's side the ad and the form do not match, and they leave before the first field.

Compare the screens, not the settings. Load the live page in a private window, write down every field in order, and set the list beside the current form in HubSpot. Then submit once and note the message that follows. A difference in any field or in the thank-you text points to a stale copy. A form that matches exactly but still fails has a cause in its own rules, and the embed is not where to look.

A simulated visitor arrives at the live address from an ad or a search, reads the form, and fills in each field in order. The run records the fields it was shown, the submit attempt and the screen that followed. Because it starts from the live page, it shows the copy a stranger receives, which is the one your ads send people to. It can show a field that is missing or an extra one, but it cannot tell you which identifier the page holds.

Run the same live address again after you replace the embed, on a phone and a laptop, and compare the fields with the first run. The run does not open your HubSpot account, so it cannot list your forms or confirm which contact record a submission lands in. Check those yourself, then use the run to confirm the page now shows the form you meant.

Test a landing page with simulated visitors

Campaign pages are copied from older pages, and the embed code travels with the copy. Each new landing page is a chance for an old form to come back, with its fields and its thank-you text. Rerun the live address for each campaign page after you publish it, on a phone and a laptop, and check the fields against the form you intended.