Customers kept asking me the same question: “Varun, what do you recommend for a directory layer on WordPress?” And for years my honest answer was a shrug. The market has a few well-known plugins, none of them felt right to recommend without a long list of caveats. So I stopped recommending and started building. Listora and Listora Pro are what came out the other side.

This post is the developer-and-owner version of the announcement. The product page on wbcomdesigns.com tells you what Listora does. This one tells you why I built it the way I did, what I optimised for, what I deliberately left out, and what I learned about directory UX along the way.

The problem I kept running into

A WordPress directory plugin has three audiences and they all hate the current state of the art:

  • Visitors who want to find one listing fast. They land on a directory and immediately face a filter sidebar that does not actually filter, a map that needs a Google API key the owner forgot to set up, and a card grid that resets their query every time they click anything.
  • Listing owners who try to submit their business. They hit a 14-field form on one page, no draft recovery, no duplicate check, and a photo upload that bounces them to wp-admin.
  • Admins and moderators who try to approve fifty submissions before lunch. They have one tool: their main admin account. There is no scoped moderator role, no audit log, no claim workflow.

Every directory plugin I evaluated solved one of these three audiences acceptably and one of the others poorly. Most of them outsourced the rest to a paid add-on. The cumulative add-on cost was often higher than the base licence, and the experience still felt stitched together. I did not want to keep telling customers “buy this plugin, then buy these eight add-ons, then write some CSS to make it stop looking weird.”

What I optimised for

One constraint: every one of those three audiences should be able to finish their job without ever opening wp-admin, without ever reading documentation, and without ever feeling like the directory was a different product from the rest of the site.

That single constraint cascaded into most of the technical decisions:

  • Gutenberg blocks, not shortcodes. Every directory surface (grid, search, map, detail, submission, dashboard, categories, featured, calendar, card, reviews) is a block. The site builder uses the editor they already know. Some of the philosophy behind that choice is something I wrote up separately in Shipping and Maintaining Gutenberg Blocks at Portfolio Scale.
  • Interactivity API for the frontend behaviour. No jQuery, no per-plugin JS soup. Search, filters, map, infinite scroll all wired through the Interactivity API. Saves bytes, plays nicely with modern themes, and means the frontend inherits theme tokens automatically.
  • OpenStreetMap by default. No required API key in free. The number of WordPress directory sites broken because someone never set up Google Maps billing is honestly staggering. Google Maps is in Pro as an opt-in for sites that actually need Places autocomplete and marker clustering.
  • Ten listing-type packs out of the box. Business, restaurant, real estate, hotel, job, event, classified, healthcare, education, place. Each ships its own fields, schema, and filters. The alternative was a generic post type plus a custom-fields plugin plus a schema plugin plus a search plugin. No.
  • Schema.org JSON-LD baked in. LocalBusiness, Restaurant, RealEstateListing, Event, LodgingBusiness, MedicalBusiness, on every detail page, in free. If Google is going to surface your stars and prices, that work belongs in the plugin, not in a separate SEO add-on.

None of these are exotic. They are mostly the obvious choices once you decide the goal is “a directory that a normal person can launch and use without a developer in the room.” The directory plugin space has been weirdly slow to make those choices. Some of the same design-tokens-not-styles thinking shows up in The Block Design Contract: Tokens, Primitives, and the Same-Family Rule.

The submission flow was the hardest part

The single biggest leak in every directory I looked at was a half-completed submission. The pattern: owner starts adding their cafe, hits a field they do not have data for (often “hours” or “social profiles”), switches tabs to look something up, comes back, page is gone. Listing is gone. They never come back.

I spent more time on this flow than any other surface. The result is four small things, all of which are obvious in retrospect:

  • Stepped form. A long form chunked into stages makes the task feel finite. People who would have bailed on a 14-field wall happily finish a 5-stage flow.
  • Duplicate check before submit. The form looks up the address while the owner is still typing and warns them if a matching listing already exists. This sounds boring; it is the reason a moderator does not have to spend their Tuesday merging duplicates.
  • Photo upload in the same flow. No detour to wp-admin. No separate gallery page. The owner uploads where they are.
  • Draft reminder. If a user leaves halfway, we remember where they were and prompt them to finish on return.

In Pro the flow gains a plan picker (so the owner picks Free / Featured / Premium during submission) and Google Places autocomplete for addresses. Both pay back the moment you start charging for listings.

Filters that actually filter

A directory with 300 listings is unusable without good filters. A directory with 30,000 listings is unusable without great ones. Most plugins shipped a generic filter sidebar that took a full page reload to apply, lost the visitor’s query mid-click, and broke on mobile.

Listora’s filters live in a sidebar that stays visible while results refresh in place. The full-text search index runs server-side, but the result update is reactive through the Interactivity API, so the visitor never sees a full page reload. Filters are scoped per listing type: a restaurant filter has cuisine, price band, hours, dietary tags. A real-estate filter has beds, baths, price, square footage. A job filter has salary band and location radius. You do not configure this. It is what each pack ships.

Pro adds two patterns that are honestly more important than they sound:

  • Saved searches with daily email digest. A visitor saves “Italian restaurants in Brooklyn under $$$, rated 4+” and we email them when new matches land. It is a retention mechanic disguised as a feature.
  • Compare side-by-side. Up to four listings in a comparison table with their key fields stacked. The difference between a restaurant directory and a restaurant-shopping experience.
The owner is the highest-value user, not the visitor.
The owner is the highest-value user, not the visitor.

The free / Pro line I drew

I had a clear rule for myself: free Listora has to be a complete directory plugin that you can run a real business on, indefinitely. Not a demo, not a feature-gated trial, not a teaser.

So free ships: ten listing types, eleven Gutenberg blocks, frontend submission with duplicate-check, business claims, 5-star reviews with helpful votes and owner replies, full-text search with filters, OpenStreetMap, Schema.org JSON-LD on every listing, and 39 REST endpoints for headless work. You can launch a city directory on free Listora tomorrow and never pay me a cent. That has to be true.

Pro is the business-model layer on top:

  • Credit-based listing plans, coupons, webhook payment receiver (Stripe, PayPal, Paddle, custom).
  • Contact Owner lead forms on every listing.
  • Saved searches with email digests.
  • Per-listing analytics (views, phone, website, email, directions clicks).
  • Verification badges, scoped moderator role, audit log.
  • White-label admin, Coming Soon mode, Private mode.
  • Needs Marketplace (reverse directory where visitors post needs and businesses respond).
  • Side-by-side compare, auto-generated SEO landing pages per type-in-location.

The rule of thumb I tell people: start on free, move to Pro the day you want to charge for listings, capture leads, or run more than one person on the team. If none of those three are happening, you do not need Pro.

Migration was the unlock

The biggest blocker to anyone trying a new directory plugin is the existing data they already have. Switching directory plugins is normally a bloodbath. URLs break, custom fields go missing, images do not transfer, Google rankings tank.

So I built one-click migrators for the four big incumbents: Business Directory Plugin, Directorist, GeoDirectory, and ListingPro. The migrator reads the source plugin’s database tables directly, transfers listings, categories, custom field values, and images, and preserves URLs so existing rankings survive. Sites under a thousand listings finish in minutes. Larger sites run through Action Scheduler in the background, so the admin never times out.

This is the single thing I would point any existing directory site owner to. The cost of trying Listora is bounded. If you do not like it, the source data is still on your site. If you do, the migration was painless. That asymmetry is the whole pitch.

What I learned about directory UX

Three lessons that surprised me, in order of how much they changed the product:

  1. The owner is the highest-value user, not the visitor. Every directory I had ever seen optimised for the visitor and treated the owner like an annoying form-filler. Wrong. The owner is the one who pays you, who keeps the listing accurate, who responds to reviews, who renews next year. The frontend owner dashboard is the most-edited screen in the whole plugin for a reason.
  2. Schema.org markup is worth more than any SEO add-on. Listings with proper LocalBusiness or Restaurant JSON-LD show up in Google with stars, prices, and hours before a click ever happens. Click-through rate on those listings is materially higher. This is mostly free if you do it once in the plugin and it is mostly broken if you outsource it to a generic SEO plugin.
  3. The moderator role is the difference between a hobby and a business. The moment you grow past one admin, you need scoped permissions and an audit log. Without them, you either give every helper full admin (terrifying) or you remain the bottleneck (exhausting). Pro shipped the scoped moderator role for that one transition.

What is next

A few things I am working on or pondering:

  • More headless examples. The 39 REST endpoints are there, I want to ship a reference Next.js frontend that talks to a Listora backend.
  • Deeper BuddyPress integration for sites that combine a community and a directory. The owner dashboard already sits next to BuddyPress profile screens; the next step is letting an activity stream surface new listings cleanly.
  • Smarter duplicate detection. Address-string match catches the obvious cases; fuzzy match on name + city would catch more.
  • Listing translations as a first-class concern. Multi-language directory sites are an under-served use case.

If you have feedback, install the free version and tell me what is broken. The roadmap is built from real user tickets, not from my imagination.

Try it

Listora works on any WordPress theme. If you are tired of recommending a directory plugin you do not actually like, give this one a spin. If you find a way it breaks, tell me. That is how the next version gets better.