How Knak Works With Marketo Forms

A Marketo form is built to do one job well: capture a lead and feed it into your programs, your scoring, and your follow-up. What it is not built to do is look good or live comfortably on a polished page. A default Marketo form arrives with rigid markup, styling that fights your brand, and a layout that often breaks on a phone. The form works. The experience around it does not.

Knak is built for exactly that gap: you build the landing page in Knak, import the live Marketo form into it, and control how that form looks and behaves without rebuilding anything or handing it to a developer. The form keeps talking to Marketo, while Knak takes over everything the visitor actually sees. The sections below walk through how that works at each stage, where Marketo's responsibility ends and Knak's begins, and why the split matters.

How a Marketo form gets into a Knak landing page

The connection starts with an active Marketo integration on your Knak account. Once that is in place, a Marketo form is available inside Knak as a live element rather than a copy. You add a Forms element to the landing page, choose Import Form, and select the form you want from a dropdown populated directly from your Marketo account. Selecting Use This Form embeds it, and from that point submissions flow back to Marketo exactly as they would on any other page. The full walkthrough lives in Knak's Marketo Forms 101 guide.

Two behaviors are worth knowing up front, because both follow from the form being a live reference rather than a copy. A form does not auto-sync: if you change its fields in Marketo, you refresh it in Knak by re-importing it or switching to another form and back, so Knak pulls the current version. And a follow-up or redirect URL set in Knak overrides the equivalent setting in Marketo, which means the page you build controls where a visitor goes after submitting.

Styling a Marketo form to match your brand

Once the form is on the page, Knak gives you two ways to handle its appearance, and that choice is the single biggest factor in how the form looks. Custom Style keeps the form's existing Marketo styling, which preserves whatever CSS the form already carries. That CSS is often dated, rigid, and weak on mobile. Knak Style removes the default styling and hands control to Knak's own design tools, which is what makes the form responsive and consistent with the rest of the page.

Under Knak Style, the controls are granular enough to rebuild the form's look from scratch. You can set the form's width and alignment; its background, border, and corner radius; label position (above or left), width, and alignment; input-field colors, padding, corner radius, and placeholder color; button width, color, padding, and corner radius; fonts, heading sizes, link color, and the display and color of required-field asterisks. Marketo forms also support multi-column layouts and those label-position options, which not every MAP allows. Knak's custom form styling guide documents the full set.

The mechanism behind Knak Style is a feature called Strip Custom CSS. It removes the custom CSS attached to the Marketo form so Knak's styles take precedence, which is how a form that looked broken in Marketo becomes clean and mobile-ready in Knak. One caveat matters technically: stripping CSS can affect other scripts that inject styling on the page, such as cookie-consent tools or preference centers. If one of those breaks, the fix is to move the script into the page's Tracking Header so it loads before the form processes. Google Tag Manager is a related edge case, since it can interfere with a form's follow-up URL; the recommendation there is to keep GTM in Knak and update the form after it syncs to Marketo.

What stays in Marketo, and what Knak handles

The cleanest way to think about the integration is as a division of labor. Marketo owns the logic and the data: the fields a form collects, validation rules, lead scoring, consent, and behaviors like progressive profiling and pre-fill are all configured in Marketo and keep working once the form is embedded in Knak. Knak renders that behavior rather than replacing it. Pre-fill, for example, depends on proper Marketo configuration and will not work alongside an embedded-form domain override, and progressive profiling is set up in Marketo while Knak simply displays the resulting fields.

Knak owns the page and the experience: the landing page itself, the form's styling, and how it holds up on mobile. This mirrors the rest of the platform, where the MAP does what it does best and Knak is the production layer that turns its output into something polished and ready to ship.

That boundary is also the line between this piece and its companion. What to ask for, how many fields to use, when progressive profiling helps, and whether a multi-step layout suits the offer are form-strategy decisions that live in Marketo, and we cover them in our companion piece, Marketo Forms Best Practices for Lead Generation. Knak's part begins once you know what the form should say and you need it to look right wherever it lands.

Common rendering issues, and how Knak resolves them

Because a Marketo form brings its own markup and styling, a handful of rendering issues come up often enough that Knak documents them directly. The most common is custom CSS from Marketo interfering with Knak's styling; the fix is either to clone the form in Marketo and remove its custom CSS before reconnecting, or to enable Strip Custom CSS so Knak removes it automatically. A second is label styling not taking effect, which usually means the form uses placeholder text in place of real field labels.

Placeholders are not labels: they weaken accessibility and they break Knak's label-styling controls, so a form should use proper labels and reserve placeholders for example text. A third is a form looking different from one page to another, which happens when Marketo global styles or scripts that lived on the original Marketo page do not carry over, and the resolution is to rebuild the styling with Knak's controls. Knak's form rendering FAQs collect these with their fixes.

One structural limit is worth stating plainly: a Knak landing page holds one Marketo form at a time. The reason is technical. Marketo forms tend to share an underlying ID, which makes the page's HTML invalid when two are present, and the forms' data interferes with each other. Injecting forms is the only route to more than one, and that is not part of Marketo's default functionality, so it is a support conversation rather than a setting. Knak explains the constraint in why a page holds one Marketo form.

Why it matters

The point of putting a Marketo form inside a Knak landing page is the same as the point of marketing production generally: build it once, on brand, in one place, without waiting on a developer or a separate tool. The form keeps every bit of its Marketo intelligence. What you add is a page and a presentation that look like your brand and work on the device most of your audience is actually using.

For a marketing operations team, that turns a recurring chore into a non-event. A new gated asset, a campaign landing page, a refreshed demo request all start from the same place, with the form already styled to match. The lead capture stays exactly as reliable as Marketo makes it, and the experience around it stops being the part you apologize for.

This compounds at enterprise scale, where a team running dozens of landing pages across regions and campaigns cannot afford to restyle a Marketo form by hand every time or to let each page drift off brand. When the page and the form come from the same production layer, brand consistency is the default rather than a review step, and a marketer can stand up a new page with a properly styled form in the time it used to take to file a developer ticket. See how Knak's landing pages and Marketo integration work together.