Sixty Landing Pages, One Price Change, and the Week It All Broke

Sixty Landing Pages, One Price Change, and the Week It All Broke

On a Thursday afternoon our head of sales sent a two-line message to the team channel: the starter plan is going up, effective Monday, please make sure the site reflects it. Everyone else reacted with a thumbs up. I sat very still, opened a spreadsheet, and started counting how many pages on our website had that price typed into them by hand. I stopped counting at fifty-eight. Every one of those pages existed because, at some point over two years, I had duplicated the page before it and changed the words.

Who I am

I'm Priya. I run content and demand gen for a small B2B software company - the kind of team where 'the marketing department' means me, a contractor who does design when we can afford it, and a founder with opinions. Our website is WordPress, built in a page builder, and for a long time I was quietly proud of that. I could ship a landing page in an afternoon without filing a ticket with engineering. No dependencies, no sprint planning, no waiting. Just me and a blank canvas and a deadline.

The sections of this article, in order.
The sections of this article, in order.

The Thursday the price changed

Here is what nobody tells you about shipping a landing page in an afternoon: you are going to do it two hundred times. Integration pages. Industry pages. Comparison pages. Event pages for every webinar we ever ran. A page per use case, because a consultant once told us that was how you win long-tail search. Each one was a copy of an earlier one, which was a copy of an earlier one, and somewhere in the middle of every single one of them sat a price, a plan name, a support promise, and a feature list that I had typed out by hand.

We don't have a content problem. We have sixty copies of the same page.

I said that out loud on the Friday standup, and it came out angrier than I meant it to. I had spent the previous evening clicking into page after page in the builder, hunting for a number, finding it in a heading on one page and inside a button on another and buried in a three-column feature block on a third. I missed four of them. I know I missed four because a prospect emailed the following week asking which price was the real one, and attached a screenshot of a page I had built and forgotten I had built. There is no worse feeling in marketing than having your own website contradict you in front of a buyer.

What I tried (and why it failed)

  • Search and replace across the database. It worked for the exact string and nothing else. Prices written with a currency symbol, prices spelled out in a sentence, prices sitting inside a builder widget that stores its content as serialized data - all invisible to it. It also terrified me, because a bad replace on a live site is not something you undo over lunch.
  • A spreadsheet of every page and what was on it. I built it lovingly. I updated it for about three weeks. Then a launch happened, and from that point on the spreadsheet described a website that no longer existed, which is worse than having no spreadsheet at all.
  • Global blocks and reusable sections in the builder. This was the closest to a real fix, and it did help for a shared footer CTA. But it only solved the parts that were identical everywhere. The moment a page needed its own price, its own integration name, its own screenshot, it fell straight back to being a hand-edited copy.

The turning point

It came from a developer we had hired for two weeks of unrelated work. He looked at our integrations section, asked how it was built, and when I told him, he did that small pause polite contractors do before saying something unwelcome. Then he said: these are not pages, they are records. You have sixty rows of a table pretending to be sixty landing pages. He sent me a link to Meta Box and went back to his ticket.

The homepage calls it a framework for dynamic WordPress websites, and the line underneath is about creating, managing, showing and connecting dynamic data with forms and custom fields in WordPress. My honest first reaction was that this was developer software and I would be out of my depth inside ten minutes. I am not a developer. I can read a support doc and I am not scared of a settings screen, but I do not write PHP and I was not about to start. What made me keep reading was a sentence aimed directly at people like me: are you a developer or a website builder? No problem. And the tagline that reframed the whole mess I was in - make WordPress a dynamic CMS.

How I actually use it

Pages stopped being pages and became records

The first thing I built was a custom post type for integrations. Not a page - a type of thing, with its own label and icon and place in the admin menu. Then I gave it custom fields: the partner name, the logo, the category, the short description, the plan it requires, the price. Meta Box advertises over fifty field types and I have probably used eight of them, but those eight changed how the job feels. Adding an integration is now filling in a short form, not opening a canvas and deciding where a headline goes.

  • For me: the price lives in one field, on one screen, and every page that shows it reads from there.
  • For me: a new integration page takes minutes and comes out structurally identical to the last sixty, because it is not a copy - it is the same template with different data.
  • For me: our contractor can add content without being trusted with the layout, which removed an entire category of Monday-morning surprise.

One template instead of sixty copies

The part I expected to block me was the display side. Historically, structured data in WordPress meant somebody writing template files, and that meant a developer, and that meant waiting. Meta Box has Views for exactly this - getting data and displaying it anywhere without touching PHP, building templates and adding your own CSS and JS. The MB Views extension does front-end templates without going near theme files, using Twig, with support for all the field types. Twig took me an afternoon and a lot of documentation tabs, and I will not pretend I loved every minute of it. But I built the layout once, and now sixty pages share it.

  • For me: a design change ships to every page of that type at once, instead of becoming a two-day clicking marathon.
  • For me: no theme files touched, which matters when you are the person who would have to explain a broken site.
  • For me: the list view and the detail page pull from the same fields, so an index can never drift out of sync with the pages it links to.

The builder finally reads my data

This was the objection I had before I even installed it: our site is built in a page builder, our contractor works in a page builder, and I was not going to rebuild two years of website to adopt a plugin. Meta Box says page builder integrations are fully supported and names Bricks, Elementor, Divi and Oxygen - connecting them to dynamic data from Meta Box. That turned out to be the sentence that made the whole thing viable for a team like ours. We did not have to leave the tool we know. We just stopped typing values into it and started pointing at fields instead.

  • For me: the pages our visitors see did not have to change while the way we build them changed completely.
  • For me: our designer kept working the way she already worked, so there was no retraining conversation.
  • For me: the migration happened one content type at a time instead of as one terrifying relaunch.

The parts I grew into later

Meta Box lists more than twenty-five extensions, and I want to be honest that I have not used most of them. The ones I have reached for since: MB Group, which organizes fields into groups so a long form stops feeling like a wall of inputs, and MB Relationships, which creates many-to-many relationships between posts, terms and users - that is how an integration now knows which case studies mention it, without me maintaining the link by hand in both directions. On the shelf, still unopened by me: MB Custom Table, which saves field data to a custom table instead of the default meta tables to reduce database size and increase performance; MB Frontend Submission for editorial forms so people can submit posts from the front end; MB User Profile for front-end register, login and profile editing; MB REST API for pulling meta values into the WP REST API; and MB Blocks for building Gutenberg blocks in PHP. I mention them because when you outgrow the simple setup, the next step already exists rather than becoming a development project.

Explore Meta Box →

The results that mattered

I am not going to invent a number for you, because the honest result was not a metric on a dashboard. It was that the next price change took one afternoon and one field, and I was not awake at eleven at night clicking through a builder hoping I had found the last one. It was that I stopped treating new page types as a cost. Somebody asks for a page per industry now and my first thought is what fields does it need, not how many evenings will this cost me. And it was the end of a specific, low, constant anxiety - the one where you know, without being able to prove it, that your own website is saying something slightly wrong somewhere.

Isn't this just more setup work?

Yes. Genuinely, yes, and I would rather say that than sell you a frictionless story. The first content type took me a weekend I did not really have, most of it spent reading documentation and undoing things. If you need one landing page, do not do this - open your builder and make the page. This pays off when you have a set of things that share a shape and keep multiplying. Meta Box's own pitch is that it saves you hours of work, and their homepage leans on a clean, lightweight codebase and minimal memory use, plus a 4.9 out of 5 rating and over six hundred thousand active installs. Those are their claims and their numbers, not my measurements. Mine is simpler: the weekend I spent setting it up was shorter than the week I had already lost to a single price change.

The new Priya

The old Priya thought speed meant being able to make a page without asking anyone. That is a real kind of speed and it is genuinely useful in the first year of a company. But it quietly builds a website that only one person can maintain, and then it builds a person whose evenings belong to that website. The new version of the job is slower at the start of every content type and dramatically faster for the rest of its life. I think of myself less as someone who makes pages now, and more as someone who decides what our content is made of. That sounds like a small reframe. It has changed what I am willing to take on.

If your site has sixty copies of one page

You will know if this is you. There is a number typed into pages you cannot fully list. There is a section of your site you are scared to redesign because of how many places it lives. There is a request in your backlog - a page per city, a page per partner, a directory somebody promised a customer - that you keep deferring because you know what it would cost you in clicks. There is a free version, Meta Box Lite, alongside the paid all-in-one bundle, so you can find out on a staging site whether this way of working fits your head before anyone spends anything.

Explore Meta Box →

Plain disclosure: I pay for my own tools, and everything above is my genuine experience running marketing for a small software company on WordPress. If you sign up through my link, GrowthGrader may earn a small commission at no extra cost to you - it does not change a word of what I would tell another marketer over coffee. Check the current pricing and what each version includes on their own site before you buy, because those change and my story does not. - Priya

Community discussion

Enjoyed this story? Share your thoughts below.