PERSIS integration: bringing the job catalogue onto your career site.

What PERSIS is - and where it stops

PERSIS is an applicant-tracking system that is widely used in Germany: posting positions, managing applications, approval workflows, GDPR-compliant processes. For HR departments it does exactly what it should.

The career page PERSIS ships out of the box is rarely a flagship, though: generic layout, foreign domain or subdomain, little employer branding, weak SEO. If you are competing for talent, you want candidates on your own website - in your design, surrounded by your content.

The good news: PERSIS can export the entire job catalogue as an XML feed. That is exactly what we build on.

Iframe or XML integration?

There are two ways to get PERSIS jobs onto your site - and they are not equal.

The iframe route is quick to embed: PERSIS delivers the job list as an embedded page. The price: to Google, the jobs simply do not exist on your domain. No rankings, no Google for Jobs, no custom design, and on mobile you get a frame scrolling inside a frame.

The XML integration pulls the raw data and renders every position as a full page of your website: its own URL, its own title and description, your design, your load time. That is the route we take - while the application itself still runs cleanly through PERSIS.

In practice 1: Klinikum Itzehoe - one job portal for eight companies

For Klinikum Itzehoe we run jobs.klinikum-itzehoe.de: a WordPress portal rendering the PERSIS job catalogue of the entire hospital group - from the clinic itself to outpatient centres and a senior-care home, eight companies in a single portal.

More happens under the hood than meets the eye:

• Two-level filtering by work area and profession - the second dropdown adapts to the first, and selections persist across page loads via localStorage.
• Smart caching: the feed is buffered and refreshed automatically. If the buffer ever comes back empty, the system fetches fresh data on its own - an empty job board simply cannot happen.
• Resilient against feed outages: fetch errors are caught instead of propagated; the site stays up even if PERSIS briefly does not answer.
• Applications without a system break: the PERSIS application form opens in a modal right on the job page - applicant data lands where HR already works.
• HR stays in control: sort priority and visibility are managed in PERSIS, not in the CMS. New positions automatically carry a "NEW" badge.

In practice 2: VBG - the integration as a reusable plugin

For vbg-karriere.de we chose the second route: the PERSIS integration lives in a standalone WordPress plugin that drops into any page via shortcode or Gutenberg block - independent of the theme.

Here too, a dedicated caching layer sits between the website and PERSIS, tuned so positions stay current without putting load on the applicant-tracking system. A few details we are proud of:

• Human-readable URLs per position following the pattern profession-postcode-city - readable for people, strong for search engines.
• SEO per position: canonical, meta description, Open Graph and Twitter tags are set individually for every job, including preview images matched to the entry type.
• "Similar positions" without an AI buzzword: a title-similarity match suggests fitting alternatives at the same location.
• Tone per audience: apprenticeships and dual-study positions are addressed informally, professionals formally - switched automatically.
• Salary figures formatted the German way ("3.456 €" instead of "3456.00") and hidden where they do not belong.
• Share buttons for LinkedIn, X, WhatsApp, Xing and e-mail on every position.

"The actual fetching is the smallest part of the work. It sits in caching, failure modes, SEO and the thousand small details of German job listings."

DUNA Engineering

Caching, calibrated

Both portals run a dedicated caching layer between the website and PERSIS: visitors get fast responses, the applicant-tracking system is spared, and if the feed ever goes down the site keeps serving the last known state. How aggressively we buffer is tuned per project to traffic, feed size and change frequency - the concrete parameters deliberately stay an operational detail.

What you need for a PERSIS integration

• An enabled XML export (job catalogue) with an agreed export profile - which fields, which structure.
• The application URL logic: deep link into the PERSIS applicant portal or an embeddable form.
• A field mapping: what does "location" mean in your setup, what is mandatory?
• A decision on caching and freshness (see above).
• A design for list, filters and detail page - the part applicants actually see.

Frequently asked questions

Does the integration work with every PERSIS setup?

With every setup that provides the XML job catalogue export. Field names differ per export profile - which is exactly why every project starts with a look at your actual feed.

Does the application stay GDPR-compliant inside PERSIS?

Yes. The career site displays the positions; the application itself runs through the PERSIS form or portal - applicant data is never duplicated.

What happens if the PERSIS server is unreachable?

The caching layer keeps serving the last known state; if even that fails, the job board shows a clean message instead of an error. We build both in as standard.

Can several companies or locations share one portal?

Yes - at Klinikum Itzehoe eight companies run in a single portal with filters by area and profession. The mapping comes straight from the PERSIS fields.

We are set on WordPress - can this be a plugin?

That is exactly how we built it for VBG: a standalone plugin, shortcode or block, theme-independent - and transferable to other WordPress projects.