How to create a job board website: the three routes, step by step
Published
To create a job board website you need five things: a niche small enough to own, a way to publish job listings, job pages that search engines can read, a way for candidates to apply, and a way to get paid. You can assemble those on a hosted job board builder in a day, on WordPress in a weekend, or as a custom build over a few weeks. The right route depends on one question: is the job board a content site that lists jobs, or a product where candidates and employers do real work?
This guide walks the whole job in order. It says where a no-code tool is enough, where WordPress fits, and what a custom build has to contain. We build ResumeJSON, a CV parsing API, so read the section on applications as written by an interested party. The rest applies whatever you build with.
Step 1: pick a niche before you pick software
General job boards are a scale business, and the large ones already won it. A new board earns its traffic by being the obvious place for one kind of job. Good niches share three traits:
- A named audience. "Remote Rust jobs", "veterinary nurses in Ontario", "climate tech operations roles". A candidate should know in five seconds whether the site is for them.
- Employers who struggle to reach that audience. They are the ones who pay for a listing.
- A supply of jobs you can list on day one. An empty board convinces nobody.
Write down the three filters your candidates will use most (location, seniority, contract type, a skill) before choosing anything else. Those filters are your data model, and every route below has to support them.
Step 2: choose how to build it
There are three honest routes. Compare them on the same rows:
| Hosted job board builder | WordPress plus a jobs plugin | Custom build | |
|---|---|---|---|
| Time to first listing | Hours | A weekend | Weeks |
| Code required | None | Little, mostly theme work | All of it |
| Monthly cost | A subscription | Hosting, plus paid add-ons | Hosting, plus your time |
| Control over the data model | Fixed fields | Custom fields with effort | Total |
| Candidate accounts and CV handling | Whatever the vendor ships | Usually a paid add-on | Whatever you build |
| Best for | Testing a niche quickly | A content site that also lists jobs | A board that is itself the product |
The hosted builder
A hosted builder gives you listing pages, employer checkout, email alerts and a theme out of the box. You trade control for speed. It is the right first move when you do not yet know whether the niche works, because the most expensive mistake in this business is building software for a board nobody visits.
WordPress
If you already run a WordPress site with an audience, adding listings to it keeps the traffic in one place. The best known plugin is WP Job Manager, published by Automattic. As of September 2026 its WordPress.org page lists more than 70,000 active installations and says:
The core WP Job Manager plugin is free and always will be.
The free core covers posting, searching and filtering listings, plus front-end forms so employers can submit and manage their own jobs. Candidate resumes are handled by a separate paid add-on. Check the plugin's own page for current add-on prices before you budget.
The custom build
Build your own when the board is the product: when you want applications to stay on your site, candidate profiles that employers can search, matching, or a workflow no plugin models. The rest of this guide marks what a custom build has to contain. The first two routes handle most of it for you.
Step 3: the pages and the data
A job board is a small site. Every route ends up with the same pages:
- Job list with search and your three filters.
- Job detail, one URL per job. This is the page that ranks.
- Post a job, the employer form, with payment if listings are paid.
- Apply, either a link out to the employer or a form on your site.
- Employer dashboard, to edit, close and renew listings.
For a custom build, four tables carry it: employers, jobs, candidates and applications. Give jobs an explicit status (draft, published, filled, expired) and an expiry date from the start. A job that was filled a month ago and still shows as open is the quickest way to lose a candidate's trust, and the next step shows that search engines care as well.
Step 4: make each job readable by search engines
Most candidates start in a search engine, so your job pages need structured data. Google reads JobPosting markup and can show the listing in its job search experience. As of September 2026, Google's documentation lists five required properties:
| Property | What it holds |
|---|---|
title | The title of the job, without the posting's marketing text |
description | The full job description, in HTML |
datePosted | The date the employer posted it, in ISO 8601 |
hiringOrganization | The employer |
jobLocation | Where the employee reports to work |
Salary (baseSalary), employmentType, validThrough and jobLocationType are recommended, and candidates filter on them. Three rules from the same documentation matter to a new board:
- One job per page. The markup belongs on the job detail page only, never on a list page.
- Expire closed jobs. Set
validThroughin the past, remove the markup, or return a404or410for the page. - Remote means fully remote. A job marked
TELECOMMUTEmust be fully remote, and must say which country applicants can be in.
Hosted builders and the main WordPress plugins emit this markup for you. In a custom build it is a JSON-LD block rendered from the jobs row, and the expiry rule is why that row needs a status.
Step 5: fill the board with jobs
Employers will not pay to post on an empty board, and candidates will not return to one. Solve supply first:
- Post by hand. Find twenty to fifty real openings in your niche and list them with a link to the employer's own apply page. It is slow, and it teaches you what your filters should be.
- Ask employers directly. Offer the first listing free. A short email to a hiring manager in a narrow niche gets answered more often than you expect.
- Import feeds with permission. Many applicant tracking systems publish a feed of a company's open roles. Use one when the employer agrees to it, and keep the link back to their page.
Whichever you use, remove a job when it closes. Freshness is the product.
Step 6: take applications, and decide what to do with the CV
This is where a job board either stays a list of links or becomes a product. You have two options.
Link out. The apply button goes to the employer's site or an email address. You store nothing, which also means you learn nothing about your candidates. For a new board this is a fine start.
Apply on your site. The candidate uploads a CV and you pass the application to the employer. Now you hold candidate data, and the question is what shape it is in. A folder of uploaded files cannot be searched, filtered or matched. A database of fields can.
That is the job a CV parser does. With ResumeJSON it is one request per uploaded file:
curl -X POST 'https://resumejson-resume-cv-parser-api.p.rapidapi.com/v1/parse' \
-H 'x-rapidapi-host: resumejson-resume-cv-parser-api.p.rapidapi.com' \
-H 'x-rapidapi-key: YOUR_KEY' \
-F 'file=@cv.pdf'The response is typed JSON: contact details under basics, each role in work[] with its dates, education[], skills and a computed total_years_experience. A value the CV does not state comes back as null rather than a guess. Once every application carries that record, three features become ordinary database work:
| Feature | What it reads |
|---|---|
| Prefilled application form | basics, the current role in work[] |
| Candidate search for employers | skills, location, years of experience |
| Job alerts that match a profile | skills and titles against new listings |
We have written each of those up separately: job application autofill, candidate matching, and the storage side in how to build an ATS. Store the application even when the parse fails, and show the employer the original file. An odd PDF should never cost a candidate their application.
Holding CVs also makes you responsible for personal data. Say in your privacy policy what you keep and for how long, and give candidates a way to delete their profile.
Step 7: charge for it
Job boards earn money in a few well-worn ways. Start with one:
- Paid listings. The employer pays per post, usually for a fixed number of days.
- Featured listings. A free basic post, with a paid upgrade that pins the job or adds it to the email.
- Employer subscriptions. A monthly fee for a number of posts, which suits employers who hire all year.
- Candidate database access. Employers pay to search profiles. This one only exists if you took applications on your site in Step 6.
Keep listings free until you have steady candidate traffic. A price on an unvisited board only removes the jobs that made it worth visiting.
When you do not need to build a job board at all
Building a site is not always the answer. Skip it when:
- You hire for one company. A careers page, or the hosted page your applicant tracking system provides, does the job.
- Your audience already gathers somewhere. A weekly jobs email or a pinned thread in a community can prove the niche with no site at all.
- You have fewer than a dozen jobs a month. A simple page you update by hand is honest at that size, and you can move to software when updating it becomes a chore.
Start with the smallest thing that gets real jobs in front of real candidates. Move to a builder, then to your own code, when the smaller thing is what holds you back.
Where ResumeJSON fits
ResumeJSON is the CV step from Step 6 and nothing else. It does not host listings, take payments or store candidates. It turns one uploaded CV into one JSON record with the same schema every time, so your board can search and match on fields.
As of September 2026 the API is sold through RapidAPI. The Basic plan is $0 for 100 parses a month with a hard cap, Pro is pay per use at $0.05 a parse, and the first monthly plan is $29 for 1,000 parses. The docs carry the current table and the field reference, and the free parser lets you try one CV in the browser with no signup.