How we used AI to create landing pages at scale

January 2, 2024
0 minute read

Duda has long offered agencies the ability to rapidly create web pages at scale using little more than a simple spreadsheet via our Dynamic Pages feature. This tool extracts content from a Google Sheet, Airtable, Internal Collection, or External Collection and plugs it into a pre-designed page. Agencies have been using this feature to create team pages, portfolios, property listings, and various other related, database-esque pages. But what about landing pages?


Unlike the traditional use case for Dynamic Pages, landing pages aren’t often structured in a “content library,” or “repository” fashion. However, they can have a similar theme and, most importantly, a shared design.


After the initial design and development process, this approach significantly reduces the amount of effort required to create every subsequent landing page. Significantly might be an understatement, too. With a fully developed Dynamic Page, each page takes only a couple minutes of typing into a database to create an entirely new landing page.


This unlocks a ton of new opportunities. A major benefit is that we can target low-competition keywords that would otherwise be too expensive to create landing pages for, a concept known as Programmatic SEO. Instead of creating one landing page for a high-competition keyword with search traffic in the thousands, we can create dozens of landing pages with search traffic in the hundreds that we are far more likely to rank for—all using the same effort.


Instead of dozens, what if we wanted to create landing pages in the hundreds or even thousands?


We had a discoverability problem


When reviewing our own website, we noticed a glaring issue. Our design team is constantly creating beautiful, high-quality templates to help agencies kick-off their next website. Unfortunately, these templates are not discoverable via search. That’s because all of our templates exist on a singular page and search engines generally prefer to offer unique pages as responses to different queries.


Dynamic Pages seemed like the obvious choice to solve this issue. After all, we already have all of this data so creating the collection would be easy enough. In fact, this is exactly the approach we took when revamping our webinars page.


Unlike webinars, however, templates are not exactly “unique” content-wise. While our webinar pages each present unique descriptions, speakers, and imagery—templates merely change their name and URL. From an SEO perspective, this creates a challenging “duplicate content” problem.


For those unfamiliar, duplicate content is when two web pages are too similar in content for search engines to distinguish between them. In this scenario, Google chooses what it believes is the “primary” landing page and disregards the rest.


With that in mind, it became clear to us that if we wanted to make it easier for agencies to find our templates we were going to need more unique content per page.



a dog is standing on top of a mountain on a website


Creating content that ranks


Let’s start with a clear disclaimer—adding arbitrary content simply for the sake of ranking is a bad idea. Google consistently cracks down on this behavior in their Core Updates and various Spam Updates. User behavior, especially engagement, is an important ranking signal. Slapping junk content onto a page, even if it initially ranks very well, is a shaky foundation.


With that in mind we asked ourselves, how can we add content to our template pages that is genuinely useful? Our solution was to refocus our efforts. Instead of highlighting the templates themselves, we could instead highlight how agencies can use each template.


For example, instead of creating a landing page for our “Architecture Website Template” we could write about “Architecture Website Design,” and include instructional content to help agencies create better websites in this vertical.


This is a great idea in theory, but it doesn’t scale. How can we write quality content for every possible industry vertical that our templates can be used for? Well, the answer became clear pretty quickly. AI.


Supercharging dynamic pages with AI


We realized that we could create a database with a few keywords, such as the industry vertical and template name, then use that information to populate various other fields with AI-generated content. This content would compliment our template, the primary focus of the page, with useful tips and pointers for agencies looking to serve this vertical.


Let’s stick with the architecture example from earlier. A row in our collection begins with “architect” as the “vertical,” and includes our architect template as the CTA. We’ve also embedded a screenshot of the template in our database to enhance the page’s design.


Now, using the information already contained within our database, we needed to answer a few questions.


  • What should I ask architect clients during onboarding?
  • What can my architect clients sell online?
  • What kind of content should I write for my architect clients’ website?
  • What additional services could my agency offer architect clients?


Notice something interesting about these questions? Each one has a predictable structure that can be tailored to virtually any industry vertical—just swap out the word “architect” for, say, “accounting.”


That’s an important detail that helps us scale this content. On the technical side, we’ve populated a Google Sheet with a variety of verticals and used the =CONCAT formula to plug these verticals into these questions automatically. So now our database contains verticals, templates, images, and questions. It’s ready for AI.


Keep in mind, we’re focused on scale here. Copying and pasting each question into an AI tool like ChatGPT alongside training prompts is not a scalable practice. Instead, there are two clever ways we can automate this.


  1. Create an App Script for Google Sheets that plugs into the OpenAI API.
  2. Dump the entire spreadsheet into ChatGPT.


That second option sounds too good to be true, huh. Well, I’m excited to share that it absolutely isn’t. With ChatGPT 4, you can upload the entire spreadsheet as a CSV then using clever prompting to create a brand new spreadsheet that contains the answers to your questions. This takes absolutely no coding or developer experience and, frankly, only takes a couple minutes.


In our scenario, we asked ChatGPT to create four new rows with answers to each of those four questions and to limit each response to a single short paragraph. We also heavily emphasized that the content should be specific to and unique for each vertical. In testing, we found that the responses were too similar otherwise to be genuinely helpful.


After just fifteen minutes of work in total, we had a fully populated database ready-to-go. Of course, we did our due diligence by proofreading all of the content and making corrections as needed but, honestly, it was pretty good out-of-the-box.


These pages actually exist right now. You can see our architecture example live, as well as the accounting version. We’re excited for our gorgeous flex templates to be visible to more agencies than ever before.


Next steps


We began with an initial run of 30 landing pages as a proof of concept. We wanted to see if this concept was scalable enough to use for all of the templates and if the AI generated content that was high enough quality to use. Thankfully, we’re pretty happy with the results.


Going forward, we plan to ramp this project up from just a couple dozen landing pages to a few hundred. Using this approach, we’re confident that we can with minimal effort.


Headshot of Shawn Davis

Content Writer, Duda

Denver-based writer with a passion for creating engaging, informative content. Loves running, cycling, coffee, and the New York Times' minigames.


Did you find this article interesting?


Thanks for the feedback!
By Shawn Davis April 1, 2026
Core Web Vitals aren't new, Google introduced them in 2020 and made them a ranking factor in 2021. But the questions keep coming, because the metrics keep changing and the stakes keep rising. Reddit's SEO communities were still debating their impact as recently as January 2026, and for good reason: most agencies still don't have a clear, repeatable way to measure, diagnose, and fix them for clients. This guide cuts through the noise. Here's what Core Web Vitals actually measure, what good scores look like today, and how to improve them—without needing a dedicated performance engineer on every project. What Core Web Vitals measure Google evaluates three user experience signals to determine whether a page feels fast, stable, and responsive: Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on a page — usually a hero image or headline — to load. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. Where FID measures the delay before a user's first click is registered, INP tracks the full responsiveness of every interaction across the page session. A good INP score is under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability — how much page elements unexpectedly move while content loads. A score below 0.1 is good. Higher scores signal that images, ads, or embeds are pushing content around after load, which frustrates users and tanks conversions. These three metrics are a subset of Google's broader Page Experience signals, which also include HTTPS, safe browsing, and mobile usability. Core Web Vitals are the ones you can most directly control and improve. Why your clients' scores may still be poor Core Web Vitals scores vary dramatically by platform, hosting, and how a site was built. Some of the most common culprits agencies encounter: Heavy above-the-fold content . A homepage with an autoplay video, a full-width image slider, and a chat widget loading simultaneously will fail LCP every time. The browser has to resolve all of those resources before it can paint the largest element. Unstable image dimensions . When an image loads without defined width and height attributes, the browser doesn't reserve space for it. It renders the surrounding text, then jumps it down when the image appears. That jump is CLS. Third-party scripts blocking the main thread . Analytics pixels, ad tags, and live chat tools run on the browser's main thread. When they stack up, every click and tap has to wait in line — driving INP scores up. A single slow third-party script can push an otherwise clean site into "needs improvement" territory. Too many web fonts . Each font family and weight is a separate network request. A page loading four font files before rendering any text will fail LCP, especially on mobile connections. Unoptimized images . JPEGs and PNGs served at full resolution, without compression or modern formats like WebP or AVIF, add unnecessary weight to every page load. How to measure them accurately There are two types of Core Web Vitals data you should be looking at for every client: Lab data comes from tools like Google PageSpeed Insights, Lighthouse, and WebPageTest. It simulates page loads in controlled conditions. Lab data is useful for diagnosing specific issues and testing fixes before you deploy them. Field data (also called Real User Monitoring, or RUM) comes from actual users visiting the site. Google collects this through the Chrome User Experience Report (CrUX) and surfaces it in Search Console and PageSpeed Insights. Field data is what Google actually uses as a ranking signal — and it often looks worse than lab data because it reflects real-world device and connection variability. If your client's site has enough traffic, you'll see field data in Search Console under Core Web Vitals. This is your baseline. Lab data helps you understand why the scores are what they are. For clients with low traffic who don't have enough field data to appear in CrUX, you'll be working primarily with lab scores. Set that expectation early so clients understand that improvements may not immediately show up in Search Console. Practical fixes that move the needle Fix LCP: get the hero image loading first The single most effective LCP improvement is adding fetchpriority="high" to the hero image tag. This tells the browser to prioritize that resource over everything else. If you're using a background CSS image for the hero, switch it to anelement — background images aren't discoverable by the browser's preload scanner. Also check whether your hosting serves images through a CDN with caching. Edge delivery dramatically reduces the time-to-first-byte, which feeds directly into LCP. Fix CLS: define dimensions for every media element Every image, video, and ad slot on the page needs explicit width and height attributes in the HTML. If you're using responsive CSS, you can still define the aspect ratio with aspect-ratio in CSS while leaving the actual size fluid. The key is giving the browser enough information to reserve space before the asset loads. Avoid inserting content above existing content after page load. This is common with cookie banners, sticky headers that change height, and dynamically loaded ad units. If you need to show these, anchor them to fixed positions so they don't push content around. Fix INP: reduce what's competing for the main thread Audit third-party scripts and defer or remove anything that isn't essential. Tools like WebPageTest's waterfall view or Chrome DevTools Performance panel show you exactly which scripts are blocking the main thread and for how long. Load chat widgets, analytics, and ad tags asynchronously and after the page's critical path has resolved. For most clients, moving non-essential scripts to load after the DOMContentLoaded event is a meaningful INP improvement with no visible impact on the user experience. For websites with heavy JavaScript — particularly those built on frameworks with large client-side bundles — consider breaking up long tasks into smaller chunks using the browser's Scheduler API or simply splitting components so the main thread isn't locked for more than 50 milliseconds at a stretch. What platforms handle automatically One of the practical advantages of building on a platform optimized for performance is that many of these fixes are applied by default. Duda, for example, automatically serves WebP images, lazy loads below-the-fold content, minifies CSS, and uses efficient cache policies for static assets. As of May 2025, 82% of sites built on Duda pass all three Core Web Vitals metrics — the highest recorded pass rate among major website platforms. That baseline matters when you're managing dozens or hundreds of client sites. It means you're starting each project close to or at a passing score, rather than diagnosing and patching a broken foundation. How much do Core Web Vitals actually affect rankings? Honestly, they're a tiebreaker — not a primary signal. Google has been clear that content quality and relevance still dominate ranking decisions. A well-optimized site with thin, irrelevant content won't outrank a content-rich competitor just because its CLS is 0.05. What Core Web Vitals do affect is the user experience that supports those rankings. Pages with poor LCP scores have measurably higher bounce rates. Sites with high CLS lose users mid-session. Those behavioral signals — time on page, return visits, conversions — are things search engines can observe and incorporate. The practical argument for fixing Core Web Vitals isn't just "because Google said so." It's that faster, more stable pages convert better. Every second of LCP improvement can reduce bounce rates by 15–20% depending on the industry and device mix. For client sites that monetize through leads or eCommerce, that's a revenue argument, not just an SEO argument. A repeatable process for agencies Audit every new site before launch. Run PageSpeed Insights and record LCP, INP, and CLS scores for both mobile and desktop. Flag anything in the "needs improvement" or "poor" range before the client sees the live site. Check Search Console monthly for existing clients. The Core Web Vitals report surfaces issues as they appear in field data. Catching a regression early — before it compounds — is significantly easier than explaining a traffic drop after the fact. Document what you've improved. Clients rarely see Core Web Vitals scores on their own. A monthly one-page performance summary showing before/after scores builds credibility and makes your technical work visible. Prioritize mobile. Google uses mobile-first indexing, and field data shows that mobile CWV scores are almost always worse than desktop. If you only have time to optimize one version, do mobile first. Core Web Vitals aren't a one-time fix. Platforms change, new scripts get added, campaigns bring in new widgets. Build the audit into your workflow and treat it like any other ongoing deliverable, and you'll stay ahead of the issues before they affect your clients' rankings. Duda's platform is built with Core Web Vitals performance in mind. Explore how it handles image optimization, script management, and site speed automatically — so your team spends less time debugging and more time building.
By Ilana Brudo March 31, 2026
Vertical SaaS must transition from tools to an AI-powered Vertical Operating System (vOS). Learn to leverage context, end tech sprawl, and maximize retention.
By Shawn Davis March 27, 2026
Automate client management, instant site generation, and data synchronization with an API-driven website builder to create a scalable growth engine for your SaaS platform.
Show More

Latest posts