Google Sheets CMS: How to Build Client Websites the Owner Can Actually Update

A friend of mine paid an agency for a restaurant site last year. In March she wanted to change her Tuesday hours. That was the entire request: one line, one day of the week. Nine days and two follow-up emails later the hours were still wrong on the site, and she had printed a sign for the door instead.

That gap is the whole business case for a Google Sheets CMS. Not the technology. The gap between how small a change is and how expensive it is to get someone else to make it.

I build products, not client sites, so I want to be straight about where I sit: I run about fourteen launched products on Supabase and Vercel, and the spreadsheet-as-content-source pattern is something I use for the parts of those products where the person editing is not going to open a code editor. The build details below are what I actually run. The offer details come from the training session that covers this as a service, and I will link the replay where it is relevant.

Every guide I read while researching this covered the same first fifteen minutes and then stopped. They show you how to pull rows out of a spreadsheet. None of them cover the four things that decide whether the site survives contact with a real client: request quotas, caching, the publish trigger, and the handoff.

What does it actually mean to use Google Sheets as a CMS?

Three pieces, and confusing them is where most builds go wrong.

The sheet is the database. One tab per content type. A tab for site settings such as business name, phone, address and hours. A tab for services or menu items. A tab for testimonials. Each row is a record, each column is a field. The client only ever sees this.

A build step reads the sheet. Your site fetches the rows once, at build time, and turns them into static HTML. This is the part the tutorials get wrong when they fetch from the browser on every page view.

A trigger rebuilds the site when the sheet changes. This is the piece nobody covers, and it is the piece that makes the whole thing feel like a CMS instead of a science project.

What the tutorials leave out

I fetched and read the top-ranking guides for this topic before writing. A dev log for a spreadsheet site framework is about 500 words and is really an announcement. The freeCodeCamp React walkthrough is around 1,800 words, published in 2024, and still builds on Create React App while noting in passing that Create React App is no longer recommended. An Atomic Object post from 2022 gives a decent pros and cons list. A vendor blog walks through five steps and then routes you through its own paid delivery layer, and frames spreadsheets as suitable only for cafe menus and sports clubs, which is a convenient conclusion for a company selling the alternative.

Between all four: zero coverage of API quotas, zero coverage of caching, zero coverage of SEO, zero coverage of what happens when the client breaks the sheet, and one throwaway line about selling it. Those are exactly the parts that cost money.

How do you build a Google Sheets CMS without hitting API limits?

Read the sheet at build time. Never from the visitor's browser.

If you fetch the spreadsheet client-side, every single page view spends one API request, and search engines see an empty shell before the JavaScript runs. If you fetch it server-side on every request, you have the same quota problem with better HTML. If you fetch it at build time and cache the result, a thousand visitors cost you one request.

The quota math nobody shows you

Google publishes hard numbers for this, and they are more generous than people assume once you stop reading on every request. The Sheets API usage limits are 300 read requests per minute per project and 60 per minute per user, and Google states plainly that these are per-minute quotas refilled every minute, with no additional daily ceiling as long as you stay inside them.

Read that again in the context of the two architectures. Client-side fetching on a site getting modest traffic will trip 300 reads per minute during any small traffic spike, and every client site you build shares that project quota unless you separate them. Build-time fetching spends one request per rebuild. If a client edits their hours four times a day, that is four requests. You could run several hundred client sites on the free tier and never see a quota error.

Cache it properly, then let it go stale on purpose

On Vercel I use Incremental Static Regeneration for this. The ISR guide describes the mechanism precisely: set a revalidate window, and after it expires the next visitor still gets the cached page instantly while a fresh version regenerates in the background. Those docs recommend a high revalidation time, an hour rather than a second, and on-demand revalidation when you need precision.

That is the right shape here. I set a long window as the safety net, usually an hour, so that even if every trigger in the system fails the site is never more than an hour behind the spreadsheet. Then I use revalidatePath for the actual updates so edits land in seconds.

One detail worth knowing when you are debugging a client who swears the site did not update: the response carries a cache header whose value tells you whether the page was a hit, was stale and regenerating, was a miss, or was regenerated on demand. That header has ended more "it's not working" phone calls for me than any amount of explaining.

The publish trigger is the whole product

Here is the part that turns a spreadsheet into a CMS. In the sheet, add a menu item called Publish. Behind it, an Apps Script function that calls your deploy hook or revalidation endpoint.

The client edits rows, then clicks Publish, then watches the site change. That single loop is what they are paying for, and it is the difference between a site they own and a site they have to email you about.

Two constraints from Google's own Apps Script quotas shape how you wire it. Outbound calls are capped at 20,000 per day on a consumer account and 100,000 per day on a Workspace account. Trigger runtime is capped at 90 minutes per day on consumer accounts and 6 hours per day on Workspace. A manual Publish button is nowhere near either limit. An automatic on-edit trigger that fires on every keystroke-level change absolutely can be, and it will also rebuild your site forty times while someone types an address. Use the button. If you want automation, debounce it into a timed trigger that checks whether anything changed since the last run.

Building the site itself is the fast part now. I describe the sheet's tab and column structure to Claude Code, point it at the design, and let it generate the fetch layer, the types, and the page components. That is the same subagent-style setup I use across my products, and it is why the build stopped being the expensive half of this offer. If you want the full productized version of it, the training session on selling Google Sheet powered client websites walks through the deployment, trigger and handoff workflow end to end, and the full replay of that session is available instantly, so you can watch it tonight rather than waiting for a live date.

How do you hand a spreadsheet-driven site to a non-technical client?

The sheet is not a database that the client happens to see. The sheet is the user interface. Design it like one.

Column names are your entire documentation

Nobody reads the instructions tab. I stopped writing long ones. Instead the column header says exactly what appears on the site: "Headline shown at the top of the home page", not "hero_title". A description of what a field does, written in the header, gets read every time because it is sitting right above the cell.

Validate instead of instructing

Data validation is the most underused feature in this entire pattern. Dropdowns for anything with a fixed set of values. A checkbox column called Show on site, so removing a service is unchecking a box rather than deleting a row and losing the content forever. Conditional formatting that turns a cell red when a required field is empty.

I also add a hidden column with a formula that flags rows that will break the build, and conditional formatting that makes those rows obvious. The client never sees the formula. They see a red row and fix it before they click Publish.

Protect the structure, not the content

Lock the header row and any formula columns with sheet protection. Leave every content cell open. The single most common failure I have seen is a client inserting a column in the middle because it seemed tidier, which silently shifts every field by one. Protected ranges stop that in about ten seconds of setup.

Give them one page, not a manual

The handoff document I use fits on one page: here is your sheet, here is what each tab does, edit cells, click Publish, wait about thirty seconds, refresh. Then a short list of what to call me about, which is anything structural, and what not to call me about, which is anything textual.

This is the difference between a deliverable and a system. I wrote a longer piece on why a prompt you run is not a system you can hand to someone, and client sites are the clearest example I know: the build is the easy artifact, the handoff is the actual product.

Does a Google Sheets website hurt your SEO?

Only if you build it the way the tutorials do.

Client-side fetching is the problem, not spreadsheets. If the page ships an empty div and populates it from an API call in the browser, you are betting your client's local search visibility on JavaScript rendering. Build-time rendering removes the bet entirely: the HTML that ships already contains the business name, the address, the hours, the services.

The spreadsheet actually makes structured data easier, which nobody seems to mention. Google's local business structured data guidance requires only name and address, and recommends telephone, url, opening hours, geo coordinates and price range. Every one of those is a cell in your settings tab. Generate the structured data block from the sheet at build time and the client maintains their own schema markup by editing their hours, without ever knowing the words "structured data".

This matters more than it used to, because those same fields are what gets pulled into AI-generated answers about a local business. I went deep on that in the four-layer system I run for AI search visibility, and the short version is that machine-readable facts about a business now have two audiences, not one.

When is a spreadsheet the wrong CMS?

I would rather you not sell this to the wrong client than have it work for two months.

It breaks down when you need relationships between content types more complex than one lookup. It breaks down when more than about three people edit simultaneously and start overwriting each other. It breaks down for anything with real content workflow, meaning drafts, scheduled publishing, and approval. It breaks down when the client wants to upload images by dragging them in, because image handling through a spreadsheet is always the ugliest part of the build, and my honest answer is that a link column pointing at a Drive folder is a compromise, not a solution.

It also breaks down for e-commerce with inventory, for anything requiring per-user content, and for any client whose site will have more than a few hundred rows of anything.

The clients it fits are exactly the ones the agencies serve badly: a restaurant, a dentist, a landscaper, a gym. Twenty pages of content that changes six times a year, and one owner who wants to fix a typo at 9pm without filing a ticket.

How would I price this as an offer?

I want to be honest here rather than invent numbers I have not billed. I do not run a web design agency, so I am not going to quote you my average client value. What I can tell you is the structure that makes the arithmetic work, and it has two parts.

A build fee for the site itself, quoted as a fixed scope, not hourly. And a small recurring care plan for hosting, domain, backups and structural changes, which is the part that turns a one-time project into something that compounds. The care plan is defensible precisely because you gave the content away: the client is not paying you monthly for text edits, they are paying for the parts they genuinely cannot do.

The reason this works better in 2026 than it did in 2022 is that an agent can now generate the fetch layer, the components and the schema markup from a description of the sheet, which collapses the build hours without collapsing the price a local business will pay. That is the arbitrage, and it does not last forever, which is a reason to run it now rather than a reason to be cynical about it.

The session I linked above covers the offer side in more detail than I can here, including the positioning for local service clients and the handoff sequence. Its replay is instant access.

Get the app, the templates and the live sessions

Everything above is one workflow. The Reinventing AI Accelerator is where the rest of them live: the live training sessions every couple of weeks, plus the vault of AI apps, tools and agents that come with them, including the client-website material this post is drawn from.

If you are building offers rather than collecting tutorials, that is the room. One small ask: go look at what is in the vault before you decide, rather than taking my word for it.

Frequently asked questions

Can Google Sheets really be used as a CMS for a live website?

Yes, with one architectural rule: read the spreadsheet at build time and cache the result, never on every page view. Google's Sheets API allows 300 read requests per minute per project, which client-side fetching burns through during any traffic spike and build-time fetching barely touches. Build-time reading also means the HTML that ships to visitors and crawlers already contains the content.

How does the client publish changes without a developer?

Add a custom menu to the spreadsheet with an Apps Script function that calls your deploy hook or revalidation endpoint. The client edits cells, clicks Publish, and the site updates within seconds. Avoid on-edit triggers that fire automatically, because they rebuild the site continuously while someone is typing and eat into Apps Script's daily trigger runtime quota.

Is a Google Sheets CMS free?

The spreadsheet and the API are free at the volumes a small business site produces. Your costs are hosting, which on a static or incrementally regenerated site is usually free or a few dollars a month, and a domain. The real cost is your build time, which is what you are charging for.

What happens if the client deletes a column or breaks the sheet?

Protect the header row and any formula columns with sheet protection so the structure cannot be edited, and leave every content cell open. Add a validation column with conditional formatting that turns a row red when a required field is empty, so problems are visible in the sheet before a publish is triggered. Also make sure your build fails gracefully and keeps serving the last good version rather than shipping a broken page.

Is a spreadsheet-driven site bad for local SEO?

Not if it renders server-side. The content, the address and the hours are in the HTML at build time exactly as they would be from any other CMS. In practice it can be better, because generating local business structured data from spreadsheet cells means the owner maintains their own schema markup by editing their opening hours, which is a thing almost no small business site keeps current.

How long does it take to build one of these?

The site itself is now the short part, because an agent can generate the data layer and components from a description of the sheet's tabs and columns. The time goes into the sheet design and the handoff, which is where the client's experience of the product actually lives. If you rush that half, you get the emails back.