If your agency runs on Loxo, your jobs already live in one place: the ATS. The open question is how they get from there onto your own website — the page candidates land on after a Google search, a referral, or a post you shared on LinkedIn. Loxo is where you run the pipeline. Your website is where you market. Connecting the two is a decision most agencies make once and then live with for years.

You can also do nothing. Loxo hosts a careers page for every agency at app.loxo.co/your-agency, and pointing the “Careers” link in your menu straight at it is the default a lot of agencies never move off. That is a legitimate choice and a separate conversation. This article is about the other case: you have decided the jobs belong on your own domain. From there you have exactly three routes — embed Loxo’s hosted job board in an iframe, build your own front end against the Loxo API, or install a plugin that syncs jobs into your CMS as native content. Each is the right answer for a different agency, and each has a real cost. What follows is an honest comparison, including the cases where our own WordPress plugin is the wrong choice.

Option 1: Loxo’s embed (iframe)

Of the three, this is the quickest to set up, and Loxo’s own help docs walk through it. You copy a snippet of HTML out of Loxo, paste it into a page on your site, and a job board renders inside a frame. The listings are served by Loxo; your page is just the container around them.

What it gets you:

• It is free. No extra software, no license, nothing to budget for.
• Minutes, not days. Paste the snippet and you are done. No developer required.
• Always in sync. A job posted in Loxo shows up immediately. There is no sync schedule to babysit and no risk of stale listings drifting out of step with the ATS.
• Platform-agnostic. It works the same on WordPress, Squarespace, Webflow, or a hand-written HTML site.

What it costs you:

• Google indexes none of it as your content. An iframe is a separate document loaded from another domain. Search engines attribute that text to the source, not to the page framing it, so as far as Google is concerned your careers page is close to empty. You will not rank for “senior mechanical engineer jobs Manchester” on the strength of a job that only exists inside a frame.
• No Google for Jobs from your own site. Eligibility depends on JobPosting structured data present in the HTML of a crawlable page. Framed content does not put that markup on your URL, so the enhanced job listing — if it appears at all — points somewhere other than your domain.
• Styling stops where the embed stops. You can control the box the frame sits in, not the layout inside it. Matching your brand exactly, rearranging the list, or dropping listings into an existing page section is off the table.
• No analytics on job views. Your Google Analytics property cannot see interactions inside the frame, so you have no way to tell which roles are getting attention or where candidates drop off.
• Applications happen off-site. The candidate leaves your domain to apply, which breaks conversion tracking and hands the last impression of the process to someone else’s interface.

None of that makes the iframe a bad choice. If your website is essentially a brochure and your candidates arrive from job boards, referrals, and outbound rather than from search, the embed does the job for no money and no maintenance. The cost only bites when you expect the website itself to bring candidates in.

Option 2: Build on the Loxo API

Loxo exposes a REST API, so you can pull jobs as data and render them however you like — Next.js, Laravel, Astro, a static site generator, anything. This is the option with no ceiling on it. The jobs become yours to present, and every URL, template, and piece of markup is under your control.

What it gets you:

• Any stack. You are not tied to a CMS or a plugin ecosystem. If your site is a custom application, this is the only route that fits it.
• Any design. Jobs are data on your side, so they can be laid out, filtered, and combined with other content exactly as your designer drew it.
• Full ownership of SEO and analytics. Your URLs, your structured data, your tracking, with nothing sitting between you and the output.

What it costs you: this is a real engineering project, not an afternoon. Before the first job renders in production, someone has to build and then keep running:

• Authentication against the API, plus somewhere safe to store and rotate credentials.
• Pagination through the jobs endpoint, and the error handling for when a request fails halfway through.
• Caching, so a traffic spike does not turn into an API request per page view — and cache invalidation, so an edit in Loxo does not sit unseen for a day.
• A sync schedule (cron or a queue) and reconciliation logic for jobs deleted in Loxo, so removed roles actually disappear from the site.
• Expiry handling. Filled roles left up are bad for candidates and worse for search: search engines treat expired job pages as a quality problem.
• JobPosting schema, generated correctly for every job, plus a sitemap that includes job URLs so new roles get discovered quickly.
• The application path: a form, file uploads, spam protection, and getting the candidate back into Loxo rather than into an inbox.
• Maintenance. Someone owns this when the API changes, when the cron silently stops, or when a schema requirement moves.

Realistically that is a few weeks of a competent developer’s time, then a small permanent line item forever. If you have in-house engineers and a site that is not WordPress, it is the right call and you will end up with exactly what you designed. If the plan is to hire a freelancer once and never think about it again, be honest with yourself about who fixes it eighteen months from now.

Option 3: A WordPress plugin (LoxoWP)

If your site already runs on WordPress, there is a middle path. A plugin pulls jobs out of Loxo and stores them as native WordPress content, so each role becomes a real page on your domain, rendered by your theme, on your URL structure. This is what LoxoWP does. Listings go on any page through a block or a shortcode such as [loxo-jobs], and each job gets its own details page.

What it gets you:

• Indexable content on your domain. Every job title, description, and location is real text on a real page that Google can crawl — the long-tail search traffic an iframe cannot produce.
• SEO plumbing built in. JobPosting schema on every job page, a dedicated job sitemap, and Google Indexing API integration so new and removed roles are picked up quickly instead of waiting on a crawl.
• Applications stay on your site. Candidates apply through an on-site form with reCAPTCHA spam protection, so the whole journey happens on your domain.
• You can see what is working. Application and view tracking tells you which roles draw interest and which are being ignored.
• Stale listings clean themselves up. Job expiration management takes filled roles down on schedule, and a free Auto-Extend add-on handles the ones you want to keep running.
• Near-live updates. Webhooks let Loxo push changes as they happen rather than waiting for the next scheduled sync, and a REST API is there for anything custom.

What it costs you — stated plainly, because these are real limits:

• WordPress only. If your site is Squarespace, Webflow, or a custom application, this option does not exist for you. Go back to option 1 or option 2.
• It is paid software. LoxoWP is a commercial plugin — far less than a custom build, but not free like the embed.
• Jobs are synced copies. Webhooks close most of the gap, but this is a copy of your ATS data on your site, not a live window into it. A missed webhook means a short delay until the next sync.
• One more plugin to maintain. Modest, but not nothing: it needs updating along with the rest of your site.

Side-by-side comparison

	Iframe embed	API build	WordPress plugin
Setup time	Minutes	Weeks of development	An hour or two
Cost	Free	Developer time, up front and ongoing	Annual license
Jobs indexable by Google	No	Yes, if you build it that way	Yes, out of the box
Google for Jobs eligible	No	Yes, if you write the schema	Yes, schema included
Design control	Limited to embed options	Total	Your theme and templates
On-site applications	No, candidate leaves	Yes, if you build the form	Yes, with spam protection
Maintenance burden	None	Yours, permanently	Plugin updates

Which one should you pick?

Choose the iframe if you need jobs visible on the site and search is not part of the plan. Plenty of agencies fill roles through their network, outbound, and the big job boards, and their website is there to look credible when someone checks. If that describes you, spending money and effort on indexable job pages is optimizing something that was never going to be a channel.

Build on the API if you are not on WordPress and you have developers. A marketing site on Next.js or a custom platform, with an engineer who can own the integration, will get a better result from a direct build than from any off-the-shelf tool. The trade is that you are also signing up for the maintenance.

Use a plugin if your site is WordPress and you want the search payoff without the build. This is the common case for recruiting agencies: the marketing site is already WordPress, nobody in the business writes code, and the goal is job pages that Google can actually rank and candidates can apply through without leaving. That combination is exactly what LoxoWP was built for.

Worth saying: these are not permanent decisions. Starting with the iframe while you see whether the site drives any candidate traffic at all is a perfectly reasonable sequence, and moving to indexable job pages later costs you nothing except the time you did not spend ranking in the meantime.

If you are on WordPress and option 3 sounds like your situation, see what LoxoWP does — the full feature list and both license tiers. Already decided? The installation guide takes you from a fresh WordPress site to your first synced jobs.