Whatever your role on an SEO team, you have almost certainly used Microsoft Excel or Google Sheets. Hold that fact in mind, because it is the bridge to the single most useful mental model I know for scaling content across a large e-commerce site. Most of the teams I have walked through this framework stopped thinking of it as programming the moment they saw the spreadsheet connection. The same thing is about to happen for you.

If you are a marketer, you do not need to write code to understand this. If you are a programmer, you already understand the mechanism and just need to see why it matters for SEO. If you manage the team, this is the framework that will reorganize how your people spend their time. The Excel metaphor works for all of you, which is exactly why it is the right place to start.

Here is the question that unlocks everything: when you type a formula into a spreadsheet, are you writing content, or are you writing an instruction that produces content?

You are writing an instruction. That distinction is the entire foundation of function-driven content. Here is the full picture of what it unlocks.

What Excel already taught you

When you type =SUM(C2:C6) into a spreadsheet cell, you are using a function. You probably have not thought about it as one. You have thought about it as "the formula that gives me the total." But what you have actually done is more sophisticated than that.

You have written an instruction that does four things:

  1. It identifies a data source (cells C2 through C6).
  2. It performs an operation on that source (addition).
  3. It produces a result (the sum).
  4. It maintains a live link between the source and the result, so that changes to any of the inputs propagate to the output automatically.

Change the value in C4 from $24.50 to $19.99. The TOTAL in your sum cell updates. You do not refresh. You do not rebuild. You do not even close the file. The change is instant because the cell is not displaying a number. It is displaying the output of an instruction, and the instruction is re-running every time the data underneath changes.

Excel works this way because Microsoft figured out, decades ago, that humans cannot maintain consistency at scale by hand. A spreadsheet with 50 hand-typed totals will eventually contain an error. A spreadsheet with 50 SUM functions will not.

Now I will tell you something most marketers do not know: every modern e-commerce website already has this exact capability built into it. It is just not being used for content.

What an SEO function actually does

A function on the web does the same four things a function in Excel does. It identifies a data source. It performs an operation. It produces a result. And it maintains a live link between source and result.

The simplest example is a phone number function. You write something like this:

function telephone_function() {
  return '<a href="tel:+3129759345">(312) 975-9345</a>';
}

Then anywhere on your site you want the phone number to appear, you place a shortcode, which looks like this:

[telephone]

The shortcode is replaced, at the moment the page renders, with the output of the function. If you change your phone number tomorrow, you change it in one file. Every page that contained the shortcode displays the new number. No find-and-replace across 5,000 pages. No content management system update queued for next sprint. One change, everywhere.

This is not advanced programming. WordPress users have been using shortcodes for over a decade. Most enterprise e-commerce platforms have an equivalent. Magento, Shopify Plus, Salesforce Commerce Cloud, custom Java and .NET platforms all support some version of this pattern. The capability is sitting in your platform right now, mostly unused for SEO.

Excel functions and web functions: same logic, different scale.

From phone numbers to title tags

A phone number shortcode is the entry-level example. Function-driven content gets interesting when you apply the same pattern to the SEO-critical elements of a product or category page.

Consider a category page for tactical bipods on an outdoor e-commerce site. The page has six SEO-critical text elements: the title tag, the meta description, the H1 tag, the breadcrumb, the page caption, and the internal-link anchor text used by other pages that link to this one. Six elements per page. Multiply by 800 categories. Multiply by 12 internal-link contexts per page. You have over 50,000 individual strings of text that need to be unique, accurate, and SEO-optimized.

Or you have six instructions, each producing 800 outputs, each output unique because the data feeding into the instruction is unique.

The title tag instruction for the bipod category might look conceptually like this:

[CategoryName] - As low as [LowestPriceInCategory]
- [InStockCount] in stock at [SiteName]

That instruction, applied across 800 categories, produces 800 unique title tags. "Tactical Bipods - As low as $24.50 - 412 in stock at YourBrand." "Long-Range Optics - As low as $89.00 - 38 in stock at YourBrand." Each one specific, each one updatable, each one carrying the incentive signals that lift click-through rate.

When a new product launches at a lower price, the title tag updates. When inventory drops below a threshold, the title tag updates. When the category name changes, the title tag updates. None of this requires a writer. The writer's job moved from typing 800 title tags to writing the one instruction that produces 800 title tags.

The economic shift

You stop paying writers to produce output. You start paying SEOs to produce instructions that produce output. The instructions are reusable. The outputs are infinite. The cost-per-page approaches zero as the catalog grows.

The variables that make this work

For function-driven content to work on a product or category page, you need access to a small set of variables that already exist in your product database. Most teams underestimate how much of this data is already there.

The variables I use on almost every build:

Every one of these lives in your product database already. You are not creating new data. You are exposing existing data to the SEO layer, where it can drive content generation at scale.

The conversation with your programmer

When I propose this to programming teams, I get a predictable question, almost word for word, every time. "Isn't this just programmers doing the SEO team's job for them?"

I have learned to answer the question before it gets asked.

The answer is: yes, there is front-loaded work for the programmer. The instruction engine has to be designed, built, tested, and integrated with the content management system. That is real engineering work, typically two to four weeks for a team that knows the platform.

But the programmer is currently spending their time on something worse. They are spending it on one-off content update tickets. Marketing emails the programmer asking for a sitewide title tag rollout. The programmer writes a migration script. Two weeks later, marketing wants to roll it back. Another script. Two months later, marketing wants to test a different version. Another script. The programmer's calendar fills with ad-hoc content work that has no engineering value.

Function-driven content trades that future work for the front-loaded build. After the build, the programmer's calendar clears. The SEO can change instructions without filing tickets. The programmer goes back to building features. This is the real pitch.

The trap door

Most builds fail in the first six weeks, when the engineering is invisible and the marketing executive starts asking when they will see results. You need an executive sponsor who has agreed in advance that there will be no visible output for the first quarter. Without that agreement, the project gets canceled before the first instruction ships.

The four-phase build

Every function-driven content project I have led follows the same four phases. The names change. The shape does not.

Phase 1: Discovery and Instruction Design. Two to three weeks. The SEO and programmer map out every SEO-critical element on every page template. They decide which elements will be function-driven and which will remain hand-written. They identify the data sources. They write the first instruction set on paper.

Phase 2: Build and Test on One Category. Three to four weeks. The programmer builds the instruction engine. The SEO writes the first set of real instructions. One category goes live as a test. The team measures ranking impact, click-through rate, and any edge-case content failures.

Phase 3: Rollout Across the Catalog. Four to six weeks. The instruction set expands to cover every category. Edge cases get patched. The team starts A/B testing variations. The catalog is now running on instructions.

Phase 4: Iteration and Measurement. Ongoing. The SEO refines instructions based on performance data. The programmer maintains the engine. New product categories are added with new instructions, not with content writing. The team's capacity to ship SEO improvements has multiplied.

The total elapsed time, in my experience, is twelve to fifteen weeks for a catalog of under 10,000 products. For larger catalogs (the largest I have worked on was 800,000 pages), the rollout phase extends, but the discovery and build phases stay roughly the same. The instruction engine does not get more complex when the catalog gets bigger. The catalog gets cheaper to optimize.

What this looks like in numbers

I have run this play often enough to have predictable numbers. On the OpticsPlanet build I led from 2016 to 2019, function-driven content was the foundation that lifted organic revenue from $46 million to $76 million over the three years. That was on a site of 800,000 pages with more than one million product SKUs. The team running that catalog never grew. The output of the team grew dramatically.

On Stop & Shop, a phased function-driven rollout produced a 150% increase in sessions, a 350% increase in visibility, and a 40% lift in organic revenue. Same team, same writers, different mechanism for putting their work onto the page.

On Martin's Foods, the first phase alone (just title tags and meta descriptions, generated from category metadata) produced a 1,500% visibility increase. The full four-phase build lifted organic revenue 160% year over year.

The pattern is consistent. The lever is real.

What this does not solve

Function-driven content is a delivery mechanism, not a strategy. The instructions still need to be written by someone who understands the category, the customer, and the SEO landscape. The data sources still need to be clean. The category structure still needs to be designed well.

If your product database is missing accurate pricing, function-driven title tags will display "As low as $0.00" across half your catalog. If your taxonomy puts unrelated products in the same category, instructions will produce factually wrong page content at scale. The lever is bigger in both directions: better inputs produce dramatically better outputs, and worse inputs produce dramatically worse ones.

This is why I always run a data audit before designing the instruction set. The audit takes a week. It finds the gaps. It tells the team what needs to be cleaned up before the engine ships.

The question to bring to your team this week

Next time your SEO team is sitting in a meeting being asked to optimize a few thousand new product pages, ask the question I have asked in every conference room since the day I learned the Excel metaphor.

Do you actually need 5,000 title tags? Or do you need one instruction that produces 5,000 title tags?

The answer is almost always the second one. The economics are not even close. The only thing standing between most teams and this approach is a six-week stretch of invisible work and one programmer who needs to be convinced. That is a small price for a catalog that updates in minutes instead of months.

That is the Excel lesson. It is the foundation of every function-driven content build I have done. Everything else in Sizzle, the conditional statements, the page captions, the natural-language processing, the social proof patterns, builds on this one mental shift.

Start there.

From the book

This article expands on chapters from Sizzle: An E-Commerce Revolution, which covers the full framework, including the conditional-statement system for generating natural-language sentences from product data, the page-caption pattern that most SEOs ignore, and the specific data variables that drive ranking on enterprise e-commerce sites.