Why your job page structure decides whether AI can find your roles

There's a decision buried in every recruitment website that almost nobody makes deliberately.

When a candidate clicks a job on your site, one of two things happens. Either the details open in an overlay on the same page (a modal, in web terms) or the browser navigates to a new page with its own URL.

To a candidate, the difference is barely noticeable. The modal is arguably nicer: it's fast, it doesn't lose their place in the list, and applying feels like one continuous action.

To a search engine or an AI system, the difference is enormous. Only one of these approaches produces something they can index.

Machines index URLs, not interactions

Search engines and AI crawlers work by following links and reading pages. A page is identified by its URL, stored against that URL, and surfaced from that URL.

If a job's content only appears after a candidate clicks something, there is no URL for that content to live at. From a crawler's point of view, your jobs page is a single page containing a list. The individual roles (the actual detail, the salary, the location, the responsibilities) aren't separate documents.

They're only revealed after a user interacts with the page. But crawlers don't interact. So the roles are, effectively, invisible.

This is why "one static, unique URL per job" is one of the most consistent technical recommendations in candidate attraction. It isn't a preference. It's the precondition for everything else.

What a unique URL per job unlocks

Once each role has its own address, a lot becomes possible that simply wasn't before:

Indexing. The role can appear in search results and be pulled into AI-generated answers about who's hiring for what, where.
Structured data. You can implement JobPosting schema in JSON-LD on that page - job title, description, location, employment type, salary range, hiring organisation. Schema removes ambiguity and tells machines exactly what the page is rather than making them infer it from prose.
Keyword relevance in the URL itself. yoursite.com/jobs/digital-marketing-manager-london communicates something. yoursite.com/jobs/28364b4k4o communicates nothing.
Sharing. A consultant can send a link to one specific role. A candidate can send it to a friend. Neither is possible if every link lands on the same list.
Clean measurement. You can see which roles attract traffic, which is impossible when everything sits behind one URL.

There's an ongoing obligation attached to this, worth being honest about. If jobs have their own indexable pages, filled roles need removing promptly and their schema removing with them. An indexed page for a role that closed in March is a trust problem you've created for yourself.

So is the pop-up just wrong?

No, and this is where a lot of SEO advice overreaches.

The pop-up approach has real advantages. Applying without a page load is genuinely lower friction, and friction at the apply step costs you candidates in a way that's easier to measure than lost impressions. It also works universally, on any platform, with no rebuild. For an agency whose website currently shows no jobs at all, a pop-up-based job list is an enormous improvement over nothing, and it's available in a day.

The mistake isn't choosing the pop-up. The mistake is choosing it without knowing you've made a choice, and then wondering why your roles never show up in search.

Framed properly, the question is:

Is your website primarily a destination you send candidates to, or a channel you want candidates to discover you through?

If it's the first, the pop-up is a perfectly sound answer, and speed to launch matters more than indexability.

If it's the second, and organic and AI-driven discovery is somewhere you want to compete, unique URLs aren't optional. Every other technical improvement you make sits on top of them.

How this plays out in idibu

We deliberately offer both.

The jobs listing widget works on any content management system.

It's a lightweight snippet, no developer needed, live in under 24 hours, fully brandable, and it pulls your live vacancies through from idibu automatically. Applications open in a pop-up and route straight back into idibu and your CRM. It's the fastest route from "no jobs on our site" to "all our jobs on our site."

The enhanced WordPress version is built specifically for WordPress and takes the other route.

Each role opens on its own unique page with its own URL, which makes those roles indexable and eligible to be surfaced in search and AI results. It also allows more customisation — for example, salary range sliders or search behaviour tailored to how your candidates actually look for roles.

If organic search and AI visibility are important priorities, our enhanced WordPress solution gives each job its own indexable page. If you're on any other platform, or you need live jobs on your site this week, the widget does that job well.