How to Make Landing Pages That Pass Compliance

A landing page can be approved, go live, and become a different communication without anyone deciding to change it. A headline gets rewritten. A button changes during a conversion test. A new offer replaces the old one. Someone updates a form, adds a testimonial, or points a new campaign at it. Each edit seems small, and together they leave the firm with a page that no longer matches what compliance reviewed.

That is the central problem. A page is not a fixed asset. It is a living document that changes after approval, often through routine marketing work that never reaches the compliance team.

This article cannot tell you what your compliance process will approve. Your firm's process decides that, with legal input where necessary. No general article can establish that a particular phrase, disclosure, layout or claim is acceptable for your business, because the applicable requirements depend on the facts and circumstances: what your firm does, what the page says, who sees it and how it is used.

What a practical process can do is remove avoidable reasons for rejection and stop approved pages drifting beyond their approval. That means establishing ownership before launch, controlling changes, maintaining evidence for claims, treating disclosures as part of the design, and preserving records of what visitors actually saw.

These responsibilities run across the category, and the obligations are not interchangeable. For SEC-registered investment advisers, the Marketing Rule under Rule 206(4)-1 governs adviser advertisements and addresses misleading statements, testimonials and endorsements, third-party ratings, performance information and hypothetical performance, with related books and records requirements under Rule 204-2. Other financial services firms operate under different frameworks, which sit outside this article.

The objective is not a page someone declares universally compliant. It is a controlled process that makes review meaningful and keeps later changes accountable.

Why Is Page Compliance Harder Than Video?

Because the content, presentation, audience and supporting elements can all change long after approval.

Video production has a defined sequence. Script, record, edit, submit, publish the approved version. Changes still happen, and the approved file gives a clear reference point.

A page behaves differently. It holds a headline in a CMS, a video from another provider, a form wired to a CRM, a scheduling tool, and a testimonial loaded from an external service. Several people can update any of those independently.

It can also show different content by traffic source, device, visitor characteristics, experiment assignment or personalization rule. A marketing team can believe it is running one approved page while visitors receive several.

Which creates a distinction worth holding onto: approval is a decision about material submitted for review, and governance is how that material is maintained afterward.

Take an advisory firm with an approved retirement planning page. The marketing manager replaces the headline to improve response. A designer adjusts the disclosure layout. A campaign specialist sends traffic from an ad with a different promise. A developer adds a scheduling widget carrying new language. No single change tells the whole story, and the combined result may differ materially from what was reviewed. Whether any of it affects the applicable requirements depends on the circumstances, and the process has already lost control if nobody can identify the differences.

So manage pages as ongoing communications rather than finished design projects. The production workflow in How to Make Video Ads That Pass Compliance addresses the related problem for a fixed asset. Pages need an additional layer, because their published content keeps changing.

How Do You Get a Landing Page Approved?

Your firm's process decides. A defined brief, documented claims, the complete page design and a controlled review make that decision easier to reach.

Most avoidable problems begin before a designer opens the page builder. The team starts with a layout, writes copy toward a conversion outcome, and submits a nearly finished page. Reviewers then find the offer unclear, the evidence missing, or the audience changed.

A controlled process starts with a brief explaining the page's purpose: the product or service, the intended audience, the traffic source, the action expected, the offer presented, and how it fits the wider journey. A bank promoting a business lending consultation needs a different brief from an insurer collecting a policy inquiry.

The brief should also name who is responsible for the business offer, marketing execution, technical implementation and review. Establish who answers questions about product terms, who owns the evidence behind claims, and who holds authority to approve.

Then prepare the substance before treating design as final. Document the claims and the evidence supporting them, and identify the qualifications, limitations and dependencies reviewers need to see in context.

Submit the actual page experience rather than copy in isolation. Reviewers should see the headline, body, imagery, video, form, buttons, disclosures and mobile layouts, and where the page depends on a sequence of interactions, demonstrate the sequence.

Review should also account for where visitors come from, since a page can be accurate alone and create a different impression paired with the advertisement that preceded it.

Finally, record which version was reviewed, the decision, any conditions, and the scope. Do not assume approval for one offer, audience or configuration covers every later use.

What Should You Settle Before Building?

The offer, audience, evidence, disclosure requirements, ownership and approval path, before the build makes them expensive to change.

First, what the business is actually offering. A page can describe a resource, invite a consultation, collect an application, explain a product or prompt a conversation with a representative. Each carries different implications for what the visitor needs to understand.

Second, the audience. A page for existing customers assumes familiarity new prospects lack. A page for business owners approaching a liquidity event uses language that means something different to a general retail audience.

Third, every material claim, identified before it is embedded in the design. Statements about pricing, features, eligibility, outcomes, service capabilities or experience may need different kinds of support, and a claim being common in the industry does not establish that your use of it is appropriate.

Fourth, what disclosures and qualifications the communication needs and how they will be presented. Not left until the page is nearly finished.

Fifth, the review sequence. When copy is ready for review, who reviews the designed page, how technical changes are handled, who authorizes publication, and where the handoffs sit when several teams or vendors contribute.

Record those in a build brief. It need not be elaborate, and it needs to make the decisions visible, because without that reference the designer optimizes for simplicity, the copywriter for persuasion and the campaign manager for bookings. Each does their job well and the result is a page nobody approved.

Are Disclosures Design or Compliance?

The requirements belong to compliance. The presentation has to be designed into the page rather than appended once the layout is finished.

Disclosures often become the last item on a copy checklist: write the message, design the page, add a block of text near the bottom. That creates an unnecessary conflict between the page experience and the information reviewers need.

Treatment affects spacing, reading order, mobile layout, visual hierarchy and the relationship between a claim and its qualifications. Those are design considerations as much as review ones, and the appropriate presentation depends on the circumstances. No universal placement rule exists for this article to give you.

So during planning, identify what reviewers consider relevant and put it into the wireframe before the visual design is finalized.

Then review at the sizes visitors actually use. Text readable on a desktop display becomes difficult on a phone, and a responsive layout can reorder content or separate a qualification from the statement it relates to. Expandable sections, tabs and pop-ups deserve the same attention, since a decision about when information appears changes the experience.

And do not let a designer or developer decide independently that a disclosure can be shortened, moved, hidden or removed because the page looks cleaner. Route those questions to whoever is authorized to answer them.

After approval, treat changes to disclosure wording, location, visibility or behavior as controlled changes. A modification affecting presentation rather than copy is not automatically immaterial.

Does an A/B Test Need Compliance Review?

Your process decides. A variant should never be assumed to inherit approval because it belongs to an approved page.

Testing changes a page to compare responses: headlines, calls to action, forms, images, layouts, offers. Sometimes only a visual detail changes. Sometimes the meaning and overall impression change substantially.

Which matters because a variant is a separate version of the communication presented to a visitor. The team needs to know what changed, why, and whether the existing approval covers it.

A lender has an approved page explaining a loan product and wants to test a headline emphasizing speed. The designer also removes a sentence to make room. The experiment is no longer a headline test. Or an insurer tests a shorter form that drops a question and changes the explanation shown before submission, which affects what gets collected and what visitors understand about the next step. Neither is purely conversion optimization.

So establish a testing protocol before launching. Document the control, each variant, the specific differences, the purpose and the review decision. Where your process requires approval, obtain it before exposing visitors to a new version.

Use a change log connecting every variant to its review record, and keep experiment configurations and publication dates so anyone can establish which version ran when. Do not rely on the testing tool for that record, since those systems preserve assignments and performance data without the page content, disclosures or approval history.

Finally, define what happens when a test ends. A winning variant is not automatically authorized for every future campaign, audience or offer.

Who Should Be Able to Edit a Live Page?

Access should follow defined responsibilities, and permission to edit is not permission to publish substantive changes without review.

CMS access usually gets treated as technical administration. The developer takes administrator privileges, marketing takes publishing access, agencies take whatever makes their work convenient. Operationally efficient, and it can leave the firm without meaningful control over its own approved communications.

Start by identifying everyone and everything that can change the live experience: internal marketers, designers, developers, agencies, contractors and integrations. Check who can edit copy, publish, modify forms, install scripts, change redirects or control experiments.

Then assign permissions to the work each actually performs. A designer prepares a draft without publishing. A campaign manager launches an approved campaign without editing substantive claims. A developer maintains the template without unrestricted authority over approved content.

The principle is separating the ability to make a change from the authority to approve one.

For small firms, full separation is impractical, since one person may write copy, run campaigns and publish. In that case identify the overlapping responsibilities and establish an appropriate independent review or documented control.

Outside agencies need boundaries stated in the contract and in onboarding: who owns the page, who accesses production systems, how changes get submitted, what authorization precedes publication. An agency's ability to make a technical change is not authority to make the firm's compliance decisions.

Review access periodically and whenever responsibilities change, removing unnecessary accounts and departed contractors. And keep a route for urgent corrections, so that when a claim becomes inaccurate or an unexpected version appears, somebody knows who can restrict access and how the action gets documented.

What Counts as Part of the Page?

The complete visitor experience: forms, buttons, confirmation screens, follow-up messages, chat tools and anything else contributing to the communication.

Teams focus on the headline and body copy, and a landing page rarely ends where the design file ends.

Start with form labels and instructions, since a field name, explanatory note, validation message or required checkbox shapes what visitors understand and provide. Then button text and behavior, because a button communicates an intended action and its destination matters, and one labeled for a purpose that redirects elsewhere creates a mismatch between expectation and reality.

Confirmation pages are part of the journey too, describing the next step, setting expectations about contact and sometimes presenting further information. A team that approves the page and ignores the confirmation screen has skipped part of the communication. The same applies to thank-you emails and automated follow-up triggered by the form.

Chat widgets and scheduling tools need attention because their language, prompts and automated responses are controlled outside the page builder, which means a vendor update can change what visitors encounter while your page editor shows no recent changes.

Cookie banners and consent interfaces belong in the inventory as well, with relevance depending on the information involved, the tools, the firm and the jurisdiction. Do not assume a standard vendor configuration addresses every obligation that applies.

So map the journey from incoming link to final action, identify every component that can change what is presented or how data is handled, assign an owner, and decide how each enters review.

How Should You Handle Dynamic Content?

Document, test and review any system that changes what visitors see, rather than treating it as a neutral technical feature.

Dynamic pages show different headlines, images, offers or calls to action depending on campaign parameters, audience segments, location, previous interactions or other rules. Personalization can alter the page using information the visitor supplied.

Which introduces a visibility problem. A reviewer sees one version while visitors receive several, and if the firm cannot identify the rules controlling those differences it cannot establish what was reviewed versus what was published.

Begin with an inventory: which parts can change, what triggers each change, which system controls it, who owns the configuration, and which vendor supplies any external content.

Then document the intended combinations. If the page changes by campaign source, the team should be able to identify the versions tied to each. If an experiment tool assigns variants, preserve the definitions and their approval records.

Review representative configurations before launch, including mobile and the transitions between states.

Personalization also raises data questions, with privacy and handling obligations depending on the firm, the information and the jurisdiction. Identify those with your compliance, privacy, security or legal resources rather than assuming a framework applies.

Do not let a vendor's default settings become an undocumented decision about your communication or your data practices. And where the firm cannot reliably reconstruct what a visitor saw, either reduce the complexity or strengthen the controls. The goal is not eliminating useful personalization. It is keeping variations visible and reviewable.

How Do You Prevent Approval Drift?

Maintain a defined baseline, record changes, and require the review your process establishes before affected changes go live.

Drift starts with a reasonable request. Someone wants a clearer headline, a shorter form, a new testimonial. Small enough to seem routine, so it goes straight into the CMS. Later someone else makes another adjustment. Nobody compares the result with the version originally approved.

The answer is documented change control identifying the current approved version, recording proposed modifications, establishing who evaluates their significance, and showing whether further approval is needed.

Create a baseline record at publication: approved copy, design and layout, disclosures, forms, interactive behavior, associated assets, page address, approval reference, publication date and accountable owner.

When a change is proposed, describe it specifically. Improve the page is not a change record. Replace the headline, remove one form field, change the destination of the primary button gives reviewers something to evaluate.

Then classify. Some changes fit an established routine maintenance route. Others affect substantive claims, disclosures, offers, audience context, data collection or the journey, and your authorized reviewers decide which is which.

Define the categories in advance, and do not create a blanket exemption letting anything labeled minor bypass review. A short change can carry significant effect, while some technical maintenance alters nothing. Correcting a genuine typographical error may fit a routine process. Rewriting the same sentence to make the offer more persuasive is a different kind of change.

Make publication part of the workflow, so that where approval is required the system prevents the change going live until authorization is recorded. Where the technology cannot enforce that, establish another documented control.

After publication, verify the live page matches the reviewed version, because a correct draft still gets implemented incorrectly through a missed content update, a broken responsive layout or an unexpected interaction between components.

And establish an escalation path for changes that cannot wait. Urgency does not remove accountability: record what changed, why, who authorized it and what follow-up review applies.

What Proves What the Page Said?

Versioned evidence connecting the page visitors saw to its content, configuration, publication history and review decision.

A current screenshot cannot establish history. If someone asks what the page communicated during a past campaign, the version visible in the CMS today does not answer it.

Keep the complete approved version, with content and visual captures of the relevant desktop and mobile experiences, covering the material elements of the journey rather than the first screen.

Connect that to the approval documentation: version reviewed, decision and date, conditions, and the people responsible for approval and publication. Where approval applied only to a campaign, audience or offer, preserve that context.

Maintain a change log with the date of each modification, a description, the person or system responsible, the review decision and publication status.

Preserve the actual variants used in testing, because a record of the experiment's name and its conversion results is not the content of each version. The firm should be able to distinguish control from variants and establish when each was live.

Account for external dependencies too, retaining enough to identify the configuration of any video, form, chat tool, scheduling system or dynamically loaded component in use.

For SEC-registered investment advisers, the Marketing Rule and the related books and records requirements under Rule 204-2 should inform the approach, with obligations depending on the circumstances. Other firms determine their own frameworks rather than assuming the adviser rules apply.

Set retention and access with compliance, legal, privacy and technical stakeholders, and do not retain unnecessary personal information simply because the team wants evidence of the page.

Most importantly, make records retrievable. A folder of unlabelled screenshots and old design files is not a version history. The practical test: if someone asks what a visitor could have seen on a specific date, can the firm reconstruct that version and explain why it was published?

How Do You Review Without Reviewing Every Typo?

A risk-based change workflow with clear ownership, predefined routes and a reliable record, leaving substantive decisions to the people authorized to make them.

Send every spacing adjustment through full review and you create delays that teach staff to work around the system. Let marketers publish anything they consider minor and you have the opposite problem. The workable middle is defined by the firm's own requirements.

Distinguish content maintenance from changes that may affect the communication, with a routine route for narrowly defined changes that alter no substantive meaning, provided that treatment suits your process. Questions about whether something qualifies go to the designated reviewer.

Create one place to submit changes, where a short request identifies the page, the proposed edit, the reason, the relevant campaign and the requested publication date, with the changed copy or a comparison attached.

Identify the decision-maker per type of change. Marketing explains the objective. Design and development explain implementation. Compliance and legal address what your procedures assign them. Clear ownership removes repeated requests for information and confusion about final authority.

Use the CMS to support the workflow where it can: draft and production environments, role-based permissions, version histories and approval gates. Those tools do not establish compliance, and they enforce decisions the firm has already documented.

Define the response to unplanned changes, so that when an integration updates unexpectedly or a live page differs from its approved version, the owner knows how to document, assess and route it.

And audit periodically. Compare selected live pages against their records. Check access remains appropriate, variants are documented, and the change log reflects actual publication history. Recurring failures usually point at unclear ownership, wrong permissions, incomplete briefs or an unreliable technical setup rather than carelessness.

Scale all of it to the firm. A small fintech and a large bank do not need the same workflow, and a firm running one static page has different needs from one maintaining several offers, experiments and audiences.

For firms evaluating outside help, landing page expertise has to extend past visual design and conversion optimization to understanding the review process, respecting approval boundaries, documenting changes and working inside the access controls the business set. The buyer's guide to choosing a landing page agency covers that relationship.

Keeping an Approved Page Approved

You cannot guarantee permanent approval by reviewing once. You can keep control by governing changes and preserving an accurate history.

Start with a complete brief, evidence for material claims, and an approval path established before design begins. Build disclosures into the layout with input from reviewers. Include forms, buttons, confirmation pages, follow-up messages and widgets in what gets reviewed.

Before publication, confirm the implemented page matches the reviewed version. Establish who can edit, who can publish, and how vendors and connected systems are controlled. Treat experiments and personalized experiences as variations needing documentation.

After launch, retain the baseline, record changes, preserve variants, and periodically compare the live experience against the records. Give staff a practical way to request edits, so the pressure to improve conversion rates does not route around review.

None of which guarantees a page will be approved or stay appropriate. It makes it easier to identify changes, route decisions to the right people, correct problems and show how the communication evolved.

The shift that matters is from treating compliance as a launch milestone to treating it as an ongoing operating responsibility. An approved page is not permanently frozen, and neither should it be free to change without accountability.

The aim is letting marketing keep working while the firm keeps control of what it communicates, which requires the live page, its approval record and its change history to stay connected. For the structural side of building the page itself, see The Ultimate Guide to Landing Pages for Financial Services. The design will evolve. The firm's ability to explain and govern those changes should not disappear with it.