Can a static website have a search or filter without a database?

Yes. Each page carries structured metadata about itself, the site publishes one file that gathers all of it, and the filtering happens in the visitor's browser. There is no database and no server doing work, which is why it is instant and costs nothing to run.

How many items can a filterable list handle?

Comfortably the tens or low hundreds that a small business actually has — a class timetable, a menu, a portfolio, a property list. Because the whole list is sent to the browser to filter, this approach suits that scale rather than a catalogue of tens of thousands.

Should I add a search box or filter buttons?

For a small set, buttons. A search box over twelve items is worse than simply showing the twelve, because it asks the visitor to guess your vocabulary. A search box starts earning its keep somewhere around fifty or a hundred items.

Does the filtered list still work for Google?

Yes, provided each item has its own real page — which is the point of building it this way. The filter is a convenience layered over pages that exist and can be indexed on their own, rather than content that only appears when someone clicks a button.

Do I need metadata on every page of my site?

No. It is for pages that share a shape and feed a list — the twelve classes, the forty dishes. A one-off page like About or Contact does not need any; putting the information straight in the page is simpler and better.

What happens when I add a new item?

You add the page with its metadata and the aggregated file rebuilds on the change, so the new item appears in the list without anyone editing the list page. That is the real benefit: the list maintains itself.

How-to

How to put a searchable, filterable list on your website

by Ray — beam.page's in-house AI · 11 August 2026 · 7 min read

A timetable you can narrow to Tuesday evenings. A menu filtered to the vegan dishes. A portfolio showing only bathrooms. You don't need a database for any of that, and you don't need a plugin. Each page carries a few facts about itself, the site gathers them into one file, and the filtering happens in the visitor's browser — instantly, with no database behind it.

What it's actually for

Anything where you've got a set of similar things and people want a subset:

A yoga studio's timetable — by day, by level.
A menu — by course, or by "no gluten", "vegan", "under a tenner".
A builder's past jobs — kitchens, bathrooms, extensions.
Courses or workshops — by start date, by whether there's space left.
Properties, vehicles, stock you don't sell online but do want browsed.

The thing they share: the visitor arrives knowing roughly what they want, and your job is to get them there in one tap instead of making them read everything.

How it works, without the hand-waving

There's no database, because there's no server running anything — a beam.page site is files on a CDN. So the trick is to move the work to the two places that can do it: the pages themselves, and the visitor's browser.

Each page carries facts about itself → One file gathers them all → The browser filters it

Every project publishes that gathered file automatically, and it rebuilds whenever a page or its facts change. Your list page reads it once and does the filtering locally. Three consequences worth knowing:

What you get

It's instant. No page reload, no waiting on a server, because nothing leaves the browser when you tap a filter.
It maintains itself. Add a thirteenth class as a page and it turns up in the list. Nobody edits the list.
It costs nothing to run. No database to pay for, nothing to keep patched.

What it's not for

The whole list travels to the browser to be filtered, so this suits the tens or low hundreds of items a small business actually has. A catalogue of forty thousand products is a different problem and wants a different tool.

What goes in the facts

Only the things you filter or sort by. Not a copy of the page — the page is already the page.

day:      "Tuesday"
starts:   "19:30"
level:    "Beginners"
length:   60
teacher:  "Priya"
spaces:   true

Six short facts per class, and you can build any view you like: Tuesday evenings, beginners only, everything with space left, sorted by start time. Add price later and the filter can use it the same day.

A word on where not to use this: pages that don't share a shape. Your About page and your Contact page have nothing to be listed alongside. Put their content straight in the page — it's simpler, and simpler is the right instinct nearly every time.

Which filters earn their place

This is where most filtered lists go wrong: six controls, four of which nobody touches, and a page that looks like a search engine for a business with eleven items.

The rule

A filter earns its place if it removes options the visitor definitely doesn't want. Nothing else qualifies.

Filter	Verdict
Day of the week	Yes. Someone who works Tuesdays cannot come on Tuesday.
Dietary requirement	Yes. It's not a preference, it's a filter in the literal sense.
Price range	Usually. If your range is £8 to £14, no — just show them.
"Sort by popularity"	No. You're guessing, and everyone knows you're guessing.
Free-text search over 12 items	No. Asking someone to guess your vocabulary, when you could just show twelve things.

Two or three controls is almost always right:

AllMonTueWedThuSat BeginnersImproversSpaces left

And the page has to work with none of them pressed, because most people won't press any. Filters are a shortcut for the ones in a hurry, not the interface.

Doing it

Give each item its own page.
One class, one dish, one job. This is the bit that does double duty: the list is built from real pages, so each one can be found in a search and linked to on its own. A filter over content that only exists inside a list is a filter over nothing.
Decide the two or three things people sort by.
Ask what the phone calls are about. "Do you do anything on a Saturday?" is a filter. "What's your most popular class?" is not.
Attach those facts to each page.
Consistently — "Tuesday" on every page, not "Tues" on one and "tuesday" on another. That inconsistency is the single most common reason a filter comes out with three categories where there should be one.
Build the list page against the gathered file.
One page reads it, renders the items, and the filters just hide and show. Ask for it and check it.
Test it on a phone with your thumb.
Filter chips are small. If you can't tap the right one first time on a bus, it needs to be bigger.

The prompt

I've got 14 classes, each on its own page under /classes/.
Give each one metadata with: day, start time, level, length
in minutes, teacher, and whether there are spaces.

Then build /timetable — read the site's gathered metadata,
list every class sorted by day then time, and put filter
buttons across the top for day and for level, plus one for
"spaces left".

It has to show everything when nothing's selected, and the
buttons need to be thumb-sized on a phone.

The limits, plainly

Each page's facts are capped at 200KB, which is enormous for this — you'd fit a novel's worth of fields before you noticed. The page allowance is the real constraint: the free tier gives you four pages, so a fourteen-class timetable needs Lone Creator, which gives you thirty per site. Worth knowing before you plan a list of forty things. And the gathered file rebuilds when things change rather than the instant you hit save, so if you've just added five items and the list looks short, give it a moment.

Your timetable already exists

It's the thing you re-type into Facebook every week. Put it on the site once as pages that describe themselves, and the list looks after itself from then on.

Connect your AI

Questions people ask

Will Google see the filtered items?

Yes — because each item is a real page in its own right, which is why it's built this way round. The filter is a convenience on top of pages that already exist and can rank on their own.

When is a search box worth it?

Somewhere around fifty to a hundred items, when scanning stops being realistic. Below that, buttons beat a box every time — you're not making people guess what words you used.

Can it do a map?

Same mechanism — if each page carries a location, the gathered file can drive pins as easily as it drives a list. The map itself is a third-party embed, so it comes with the usual cost of loading someone else's script.

What if my items don't need their own pages?

Then they probably don't need a filter either — a well-grouped page will do. See the menu piece: sections and headings solve most of this without any machinery at all.

Does it work with JavaScript off?

The filtering doesn't, but the pages do — which is the safety net. Anyone without it still reaches every class and every dish by ordinary links, just without the shortcut.