The marketing website stack, explained⁠

A marketing website is rarely just a website. Behind every page there is a set of tools that store content, capture leads, measure traffic, respect privacy and keep everything online. We call that the stack.

Most problems we see do not come from a bad tool. They come from good tools that were chosen one at a time, by different people, and never connected properly. The result is familiar: leads without a source, reports that disagree with each other, and a cookie banner that quietly switches off half of your analytics.

This is a plain-language map of the stack, what each part is responsible for, and how to tell whether yours is working.

The parts of the stack

• CMS. Where your pages, case studies and articles live, and where your team edits them. A good CMS matches your content model, not the other way around.
• Forms. The moment a visitor becomes a lead. Every submission should be stored, delivered to the right people and protected from spam without punishing real visitors.
• CRM. Where sales picks up the lead. Forms should send data here automatically, including the page, campaign and market it came from.
• Analytics and tag management. How you know what works. Set up to answer specific questions, not to collect everything and hope for insight later.
• Consent. The cookie banner and the rules behind it, so that tracking respects what visitors agreed to and your legal team can sleep.
• Languages. Separate pages, URLs and search settings for every market you sell in.
• Hosting, speed and security. Uptime, backups, monitoring, performance and protection against the usual attacks. Invisible when it works, very visible when it does not.

Why the parts have to be planned together

Each part depends on the others, often in ways that are not obvious at the start.

• Analytics depends on consent. If the banner is misconfigured, your data is either incomplete or not compliant. Often both.
• Lead routing depends on forms and CRM. Field names, required fields and hidden fields such as source and campaign have to match on both sides.
• Localization changes URLs. New language folders affect your analytics filters, your search setup and your redirects.
• The CMS shapes everything else. If case studies are not a real content type, you cannot filter them, reuse them or send their data anywhere.

When these decisions are made one by one, each vendor optimizes their own piece. Nobody owns the connections, and the connections are where things break.

What a healthy stack looks like

You do not need the most expensive tools. You need a stack where:

• Every lead has a source. Sales can see which page, campaign and market it came from, without asking marketing.
• Every number has one definition. A conversion means the same thing in analytics, in the CRM and in the monthly report.
• Consent is respected by design. Tags only fire when they are allowed to, and you can explain how in one paragraph.
• The team can change content without breaking tracking. New pages inherit the right setup automatically.
• Someone owns it. Access, renewals, updates and incidents have a named person, not a shared inbox.

A simple way to check your own stack

Ask these questions, ideally with someone from sales in the room:

1. When a form is sent, where does the lead end up, and how fast does someone respond?
2. Can you see which page and campaign each lead came from, in the CRM?
3. Do your analytics behave the way your legal team expects for visitors who reject cookies?
4. If a form stopped working tonight, how would you find out?
5. If your CMS changed tomorrow, what else would break?

If any answer is “I’m not sure”, the stack needs a blueprint before it needs a new tool.

Blueprint first, tools second

A stack blueprint is a one-page diagram of how data moves: from visitor to form, from form to CRM, from consent to analytics, from CMS to every market. It lists each tool, what it is responsible for and who owns it.

Tools are replaceable. The connections between them are the real system.

With a blueprint, choosing tools becomes much easier. You know which integrations matter, which features you actually need, and where a cheaper tool is perfectly fine. Without one, every new tool adds another connection nobody planned.