Skip to content
System nominalUTC --:--:--Articles 124

A Job Board Is a Product, Not a Plugin Install

A job board plugin gives you a post type, a submission form and a listing. It cannot give you a moderator, an expiry policy or a reason for an employer to pay.

Martin Kiel · @mkiel

WordPress internals

Topic
WP
Section
WordPress Internals
Published
17 OCT 2026
Reading time
9 MIN
Words
2071W
Technical cover graphic for A Job Board Is a Product, Not a Plugin Install
Generated schematic — WP series, REV 2.6.

The request arrives as a single line in a planning call: can we add a job board? Somebody has seen a competitor with one, or a partner organisation wants to post roles, and the assumption underneath the question is that this is a plugin decision like adding a contact form. So the plugin goes in on a Friday. By the second week there are sixty listings, two of which are real, and nobody has opened the approval queue since the day it was switched on.

I have watched this on a local news site, on a membership site for a trade association, and on a regional magazine that had a genuine audience and still could not make the board work. The pattern is steady. Month one brings enthusiasm and a submission form. Month two brings a trickle of listings, several obviously spam, one a commission-only role advertised as a graduate scheme. Month three brings a page of dead links, and the board starts making the rest of the site look neglected.

Nobody decided to abandon it. The work was never assigned to a named person, and work that is nobody's job does not happen on a schedule.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the free plugin core is named as the right answer for most of the situations described here, and the case for not building a board at all is made below in full.

What the software actually installs

The gap between what the plugin delivers and a working board is the whole article, so it is worth being precise. The plugin gives three things.

The first is a post type. In WP Job Manager that is job_listing, with its own admin screens, its own capabilities, and two taxonomies for category and job type. Listings are rows in the posts table with metadata attached, which means they inherit search, revisions, feeds and the REST API without anybody writing code for it.

That is a complete posting mechanism, and it is not a board. A board is a publication with a supply side, an editorial standard, a lifecycle and a price, and the plugin addresses only the mechanical part in the middle. The three things it leaves out are the three that decide whether it survives its first quarter.

The three things it does not install

Nobody moderates the listings

The approval toggle exists. The standard does not. A moderator has to read every submission and answer questions the software has no opinion about: does this employer exist as a legal entity, is the role real rather than a pipeline-building exercise, is the salary claim plausible, does a remote-only posting from another continent belong on a board for one city, is this agency advertising the same role it posted last month under a different title. Each is a judgement, and a judgement needs a person with authority to reject a submission from somebody the site knows.

The volume is easy to underestimate. Twenty minutes per submission is realistic once the looking-up is counted, and a board taking thirty submissions a month is ten hours of work before it has earned anything. That is why the queues that get cleared are the ones full of obvious spam: deleting a link farm is fast and feels like moderation. The expensive cases are the plausible ones, and they sit in the queue while the site owner is on holiday. A submission that waits four days is a submission that does not come back, because the employer already paid a recruiter to fill the role.

Nothing expires them

The plugin will calculate an expiry date from the duration setting configured at install, and it will close listings when that date passes. What it cannot do is know that the finance role was filled in eleven days and the advertised closing date was eight weeks out. So the board fills with listings that are technically open and practically dead, and the damage runs in two directions.

The first is the reader, who is the only asset the board has. One dead listing is noise. Twelve teach the audience that checking is a waste of a click, they stop checking, and the traffic that would justify charging never arrives. The second is the archive. Four hundred expired listings left public are four hundred thin pages competing with the pages that matter, unless somebody decides in advance whether they 404, redirect to their category, or stay up with the status changed. That decision is a policy, not a setting, and the default of leaving them published is the worst of the three options.

The renewal loop is where this becomes a staffing question again. An employer who filled a role three weeks ago has no reason to log in and close the listing, so the board either expires everything on a short cycle and accepts that some live roles disappear, or it expires nothing and rots. A short duration with a renewal prompt a human answers is the version that works, and only if somebody is answering.

No employer has a reason to pay

Free posting is the right default at launch and the wrong default forever. It attracts the employers who value the board least, the ones posting a vague role to every free board they can find, and it gives the employers worth charging nothing to react to. Meanwhile the board has no revenue line at all, which makes the moderation hours a donation from whoever owns the site.

The order of operations is not negotiable. Audience first, curation second, price third. Asking an employer to buy a posting on a board with no readers is asking them to buy nothing, and most will refuse politely, which is worse than a hard no because it wastes a sales conversation. The mechanism for charging is the easy part: WP Job Manager's paid listing add-ons put a price and a checkout in front of the submission form, and the same extension set covers applications routed to the employer, candidate details, alerts and regional sections. Check the current price and the current feature split on their site before planning a budget around it, because both move.

The honest economics

The arithmetic that decides most of these projects is short and worth doing before the plugin goes in. Count hours rather than money, because the hours are what the site owner actually spends.

Take moderation time across a listing's whole life: the initial review, the renewal question, the eventual close or the report from a reader. Fifteen to twenty-five minutes is a fair range. Multiply by the number of live listings the board is trying to sustain and by how often each slot turns over a year. Then add what nobody budgets for: the support email from an employer whose post looks wrong, the sales conversation that goes nowhere, the reconciliation when a payment lands without a listing attached.

Against that, revenue is the listing fee multiplied by paid postings, and a board that charges while most of its catalogue is free is not really charging. What a listing fee is in a given market varies so widely that a figure from an article is worse than useless; check the current rate for the boards your employers actually use. The shape of the equation is the durable part.

Run it and the conclusion is uncomfortable but reliable: below a few hundred live listings, a general job board usually earns less than the time spent moderating it. Not always. A niche board can clear that bar with sixty listings if each posting is worth a lot to a small number of employers, which is the case for specialist trades, senior roles in a single industry, and anything where the alternative for the employer is a recruiter's fee. The exception is real, and it is defined by the value of a filled role, not by traffic alone.

A board with forty listings and no audience earns nothing and costs ten hours a month. That is not poor unit economics. It is a hobby with a database.

When the plugin is the wrong purchase

Do not buy the paid extensions before the free board has traffic. Paid listings in front of an audience of zero converts at zero, and the checkout is not what is missing. Do not buy the application-management side, whatever it is called this year, if nobody is going to read the applications; routing candidates to an employer who has stopped checking is a worse experience than sending them to an address that bounces. And do not buy a candidate database to sit unused, the most common way a job board budget is spent on something never searched.

The free alternative is the plugin's own core, and for a large share of the sites that ask this question it is genuinely enough. A single company advertising its own roles does not need a board at all, and does not need to pay for one. A small community board where applications go to an email address in the listing, where postings are free and the point is service rather than revenue, runs on the free tier indefinitely. A board that will never charge for a post should not buy the machinery for charging.

There is a size below which the entire apparatus is a mistake, and it is bigger than most people expect. If the board will hold five to thirty roles at a time, all from organisations somebody on the site can name, a hand-maintained page beats the plugin on every axis that matters.

The mechanics are unglamorous. One page listing each role with the employer, the location and a link to the original posting. A plain form that emails the site, or simply an email address, instead of a submission workflow. An update every Monday morning that takes fifteen minutes because the list is short enough to read. There is no approval queue, because whoever edits the page is the queue. There are no dead listings, because the same person looks at the page weekly and notices. There is no expiry setting, no taxonomy to groom, and no plugin to break during a core update.

It fits specific cases better than software does: a local scene where everybody knows everybody, a conference job wall, a newsletter where the list of roles is part of the product, a directory of permanent opportunities like apprenticeships or seasonal work that do not expire on a schedule, and any board that exists as a favour to a partner organisation. A single employer's careers page is the extreme version, and it should never be a job board plugin.

The honest limit is around fifty listings, and it is not a listing limit but an attention limit. The page needs somebody editing it every week, and it is the first thing dropped in a busy month, which is at least visible, unlike a plugin board nobody moderates.

The decision rule

Build the plugin version when all three of these are true, and not before.

One: an audience exists that employers already want to reach, demonstrated by replies to a curated page or by people asking where the roles are, not by pageviews. Two: a named person owns moderation as a recurring weekly task, with the authority to reject a submission from a paying customer. Three: the reason an employer pays fits in one sentence that does not mention the software, such as reaching candidates who do not read the big boards.

If one of the three is missing, run the curated page and revisit in a quarter with evidence. If two are missing, do not build a board at all; a page of links that nobody updates is a smaller failure than a board nobody moderates, and it is cheaper to shut down.

What breaks in year two is predictable. The taxonomies multiply. The expired archive becomes a decision somebody avoids. The person who owned moderation changes job, and the queue becomes a backlog easier to delete than to clear. The moment to defend against all three is before the first listing is approved, when the policy costs nothing and an honest no is still possible.

Martin Kiel · @mkiel

WordPress internals

Writes about the load-bearing parts of WordPress: the options table, hook ordering, WP_Query behaviour and the database work that decides whether a plugin scales or falls over.

Continue

Related in WordPress Internals