A client wants 50 near-identical landing pages, threatening manual work and burnout. Here’s how a senior DevOps engineer tackles this common, but dangerous, request with scalable, sane solutions.

So, The Client Wants 50 Landing Pages… A Senior Engineer’s Guide to Not Losing Your Mind

I remember it clear as day. It was 4:45 PM on a Friday. A junior dev, bless his heart, slacked our team channel in a panic. “Marketing just dropped a P1 ticket. They need 30 unique landing pages for a campaign that goes live Monday morning. They’re all the same except for a headline and a tracking code.” I watched as he started creating `landing-page-new-york.html`, `landing-page-chicago.html`… and my pager-induced PTSD kicked in. We’ve all been there. A seemingly simple request that secretly contains a mountain of manual work, technical debt, and a guaranteed weekend-ruining typo that will take down the entire campaign.

The “Why”: This Isn’t a Content Problem, It’s an Architecture Problem

When a non-technical stakeholder asks for “50 pages,” they aren’t asking you to manually copy, paste, and edit 50 HTML files. They’re describing a business need: they want 50 distinct entry points for a campaign, each tailored to a specific audience. The breakdown happens when we, as engineers, immediately translate that into the most literal, manual implementation possible.

Every time you manually duplicate a file, you’re creating what I call a “content snowflake.” Like a snowflake server, it’s unique, fragile, and impossible to manage at scale. Need to update the footer copyright year? Now you have to do it in 50 places. Found a typo in the core template? Get ready for a world of pain. The problem isn’t the request; it’s the unscalable, error-prone process that follows.

The Solutions: From Duct Tape to DevOps Nirvana

Let’s break down how to handle this request, from the “I need this done an hour ago” fix to the “let’s build it right so we never have this conversation again” architecture.

Solution 1: The Quick Fix (The “Server-Side Include” Hack)

Okay, it’s crunch time. The campaign launches in hours. You don’t have time to re-architect. This is where you use the tools you already have. If you’re running a web server like Nginx or Apache, you can use Server-Side Includes (SSI) to build pages on the fly from common components.

The idea is simple: you have one main template file (`template.html`) and then tiny snippet files for the parts that change (e.g., `chicago-content.inc`, `seattle-content.inc`).

First, you’d enable SSI in your Nginx config for the location serving the pages:

server {
    listen 80;
    server_name your-campaign-site.com;
    root /var/www/html;

    location / {
        ssi on; # Enable Server-Side Includes
        index index.html;
    }
}

Then, your actual “landing pages” are just shells that include the main template and the unique content block. For example, `chicago.html` would look like this:

<!--# set var="pageTitle" value="Our Amazing Offer for Chicago!" -->
<!--# set var="uniqueContentFile" value="content/chicago.inc" -->
<!--# include file="templates/main.html" -->

Pro Tip: This is a hack, not a strategy. It saves you from copy-pasting the entire file, but you’re still managing a ton of tiny files. It’s a leaky bandage, but sometimes that’s all you need to stop the bleeding and get through the weekend.

Solution 2: The Permanent Fix (The “Static Site Generator” Architecture)

This is the way. You separate content from presentation. Your marketing team can write their content, and your build system will assemble the final static HTML files automatically. This is the core principle of a GitOps or “Infrastructure as Code” workflow, but applied to content.

Here’s the high-level plan:

1. Choose a Static Site Generator (SSG): Tools like Hugo, Jekyll, Astro, or Next.js (in static export mode) are perfect for this. I’m a big fan of Hugo for its sheer speed.
2. Structure Your Content: All your “pages” become simple data files. They can be Markdown for prose or YAML/JSON for structured data.
3. Create One Template: You build a single, beautiful template file that knows how to read the data files and render the HTML.
4. Automate the Build: You set up a simple CI/CD pipeline (GitHub Actions, GitLab CI). When someone merges new content files into the `main` branch, the pipeline automatically runs the SSG, which spits out 50 (or 500) static HTML files.
5. Deploy Anywhere: Those static files are then pushed to their final destination—an S3 bucket, a simple Nginx server on `prod-web-01`, or a CDN like Cloudflare Pages.

Your content directory might look like this:

/content/pages/
├── new-york.md
├── chicago.md
├── seattle.md
└── ... (47 more markdown files)

/layouts/
└── landingpage.html (Your one and only template)

Now, updating the footer means editing one file: `landingpage.html`. Adding a new city means adding one new Markdown file. This is scalable, version-controlled, and sane.

Solution 3: The ‘Nuclear’ Option (Questioning the Premise)

As a Senior, your job isn’t just to take tickets and write code. It’s to provide architectural guidance. Sometimes the best technical solution is to challenge the business request itself—constructively.

This isn’t about saying “no.” It’s about asking “why?”

• “What is the business goal of having 50 distinct URLs?”
• “Are we tracking campaign performance? Could we achieve the same goal with URL parameters on a single page, like `our-product.com/campaign?source=chicago`?”
• “Could we use a bit of JavaScript on a single page to dynamically change the headline based on a URL parameter?”

Often, you’ll find the stakeholder doesn’t actually care about having 50 physical files on a server. They care about tracking and personalization. By showing them a technically simpler way to achieve their *real* goal (e.g., using one dynamic page and UTM parameters), you can dissolve the entire problem. You transform a massive infrastructure task into a small feature request.

Comparing The Approaches

To put it all together, here’s how I see the trade-offs:

My advice? If you’re on fire, use Solution 1. But immediately create a ticket to implement Solution 2 the following week. And always, always start with the questions in Solution 3. You’ll save yourself and your team from a world of hurt, and you’ll graduate from being a code-executor to a true engineering partner.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions