Memex as a Headless Catalog Layer for WordPress & WooCommerce

Memex·7 min

WordPress is slow. Memex makes it fast, and wise.

WordPress paired with WooCommerce is a great editor and a great storefront, but a poor data layer. Product data lives in wp_posts and wp_postmeta as unversioned, serialized key-value rows: slow to query, painful to expose, and unreadable to an AI. Memex sits behind the site as a headless catalog backend. WordPress stays the editor and the checkout; Memex becomes the memory and the brain.

Two words describe what that buys you.

Fast. Typed, indexed database columns replace wp_postmeta joins. Listing, search, filtering, and compare are served by an API built for reads, not by WP_Query against a meta table that also happens to be handling checkout.

Wise. Memex remembers the price and cost history WordPress throws away, and it speaks AI, serving the catalog as Markdown an LLM can browse natively. Your catalog becomes something Claude or ChatGPT can be pointed at and asked questions about.

In one line: Memex turns a WordPress catalog into a queryable, versioned, AI-ready API, without touching the storefront.

The problem: why WordPress needs this

WordPress / WooCommerce today	With the Memex catalog layer
Products scattered across `wp_postmeta`: serialized values, one row per meta key	One row per product: typed columns + JSONB blobs
No price or cost history, updates overwrite in place	Append-only price history plus cost/margin records, a full temporal trail
Category and attribute filtering means slow `tax_query` joins	Indexed `sku` / `upc` / `brand` / `category` columns + a flat category-tree endpoint
No clean way to hand the catalog to an AI	`.md` endpoints designed to drop straight into an LLM context window
Sharing a curated view means building a page and managing access	Mint a share token → a revocable, read-only public URL in seconds
Every catalog read hits the same overloaded MySQL as checkout	Reads offloaded to a separate database tuned for queries and analytics

The goal is not to replace WooCommerce. It is to offload read, query, AI, and analytics to a store built for exactly that, and let WordPress keep doing what it is good at.

How to make WooCommerce faster when the catalog is the bottleneck

If you are searching for how to make WooCommerce faster, the honest first step is finding out what is actually slow. On a content site the answer is usually theme or plugin bloat. On a store with a large catalog, the bottleneck is almost always the catalog itself, meaning the way WooCommerce stores and queries product data. Understanding why a WooCommerce catalog gets slow is what tells you which fixes will help and which will not.

Why WooCommerce catalogs get slow

Under the hood, every product is a post in wp_posts, and every attribute, price, stock value, and custom field is a separate row in wp_postmeta. That is an entity-attribute-value (EAV) pattern, so rendering one product page or a filtered listing fans out into many meta lookups. Layered navigation and category filters turn into tax_query JOINs across wp_term_relationships and the taxonomy tables. Because meta_value is an unindexed LONGTEXT column, filtering or sorting by price or any attribute forces the database into full table scans. All of this runs on the same MySQL instance that is simultaneously handling cart sessions, checkout, and wp-admin. Every product you add multiplies the wp_postmeta row count, which is why a store feels fine at 200 products and crawls at 20,000. When a WooCommerce catalog is slow, this data model is usually the reason.

The usual fixes and where they stop helping

The standard troubleshooting ladder helps, up to a point. Page caching and a CDN speed up anonymous browsing, but do nothing for the filtered, searched, and personalized catalog views that are exactly the pages users complain about. Redis object caching softens repeated meta lookups, yet the first cold query stays slow. Index plugins and WooCommerce's own product attribute lookup table improve filtering, but they do not give you price history or a clean way to feed the catalog to anything outside WordPress. Upgrading PHP and hosting raises the ceiling, but it does not change the shape of the query. Each of these treats a symptom. Once you have worked through them and the catalog is still slow, the conclusion is that the data model, not the hardware, is the limit.

The structural fix: move catalog reads off WordPress

The way to actually speed up WordPress and WooCommerce for a large catalog is to stop asking wp_postmeta to answer catalog queries at all. WooCommerce stays the product editor and the checkout, exactly as it is today. The catalog mirrors into a purpose-built store with typed, indexed columns and JSONB, and every read (listing, search, filtering, compare, price history, and AI consumption) is served from there instead of from the meta table.

That is the approach the rest of this article describes. If you have been looking for how to make your catalog faster without re-platforming your store, moving reads off WordPress is the structural answer, and the sections below show exactly how Memex does it.

Architecture at a glance

WordPress → Memex → everywhere

one webhook in · fast JSON and AI-ready Markdown out · hover a flow

Hover to preview · click to pin a flow.

Three flows connect the two systems:

Push (WordPress → Memex). WooCommerce emits product changes; Memex ingests, upserts, and versions them.
Pull (Memex → WordPress). Themes, blocks, shortcodes, and forms render live catalog data from Memex's JSON API instead of slow WP_Query calls.
AI (Memex → LLM). A share token exposes the catalog as interlinked Markdown any AI can crawl as context, with no scraping and no HTML parsing.

What ships today

Everything below exists in the codebase and runs in production behind a live storefront.

Webhook ingestion and upsert

POST /catalog/webhook receives WooCommerce product create and update events. Payloads are mapped and upserted into the catalog keyed by the WooCommerce product ID, so ingestion is idempotent and safe to replay. A backfill path bulk-loads an initial catalog export, so the store is warm from day one instead of waiting for webhooks to trickle in. Every batch and backfill is recorded as an auditable ingest run, the basis for "new this week" feeds.

Typed columns and JSONB storage

The product store deliberately mixes two shapes. Typed, indexed columns hold everything you filter or sort on: sku, upc, brand, category, price, sale_price, stock_status, plus vertical-specific flags and per-product discount fields. JSONB key-value blobs, holding the full source payload, attributes, and restrictions, absorb the long tail. Any product shape from any WooCommerce store is captured with no schema migration.

Price and cost history

An append-only price-history table records every price and stock change per product over time. WordPress overwrites; Memex remembers. That temporal trail powers price-history charts, price-drop detection, "what changed this week," and margin analytics.

JSON API for themes, plugins, and forms

GET /catalog/products                        paginated, filterable listing
GET /catalog/search?q=...                    keyword search
GET /catalog/categories                      category tree
GET /catalog/product/{wc_id}                 full product detail
GET /catalog/product/{wc_id}/price-history   temporal series
GET /catalog/compare?ids=...                 side-by-side compare
GET /catalog/product/{wc_id}/context         LLM-shaped context blob

Markdown API for AI

Token-in-path endpoints serve the catalog as machine-readable Markdown:

GET /catalog/{token}/index.md?page=&limit=&q=   index table
GET /catalog/{token}/search.md?q=term           search as markdown
GET /catalog/{token}/product/{wc_id}.md         one product, full detail

The pages announce that they are machine-readable and cross-link each other, so an LLM can crawl the catalog by following links. The demo is trivially strong: paste a share URL into Claude and ask anything about the catalog.

Mint multiple independent ?t=<token> links per organization, each with its own enabled flag and its own display flags, for example whether sale prices are shown. The full lifecycle runs from a token-administration UI: create, list, edit, regenerate, and disable. Each token is a revocable public view for a specific audience, whether members, partners, or a single AI chat, with no page to build.

Organization layer with Row-Level Security

Organizations, members, and invites model membership, invitations, and roles. Every catalog table is org-scoped under database Row-Level Security, with FORCE RLS and a default-deny stance when the organization context is unset. Tenant isolation is enforced at the database, not in application code. An organization dashboard ships in the web app with price-history views, a new-products feed per ingest run, an ingest-run log, share and token management, and member management.

Public catalog frontend

A token-gated public catalog app already exists as a reference implementation: a product explorer with category filtering, search, a compare view, price-history charts, and a two-column product detail with MSRP, member-price, and MAP labeling. Store links point back to the WooCommerce storefront, because Memex serves discovery and checkout stays on WordPress.

Trust by construction

Four guarantees are structural, not policy:

Tenant isolation is database-enforced. Row-Level Security with a default-deny stance keeps one organization's data unreachable from another's queries.
Cost and margin data is structurally unexposable. Costs live on the ingest and analytics side only; no share token, flag, or endpoint can surface them.
Checkout never moves. Memex handles read, discovery, and AI; WooCommerce keeps the cart, checkout, orders, and payments. There is no platform migration to fear.
Tokens are revocable. Disabling a share token kills the view instantly.

Proof

Memex runs in production today as the catalog layer behind a regulated-industry retailer with a multi-thousand-product catalog. If a compliance-heavy vertical trusts it as the data layer behind its storefront, a simpler catalog can too.