Adding the Application Form to Your Own Site

Setup is two lines: a container div where the form should appear, and our hosted loader script on the page. The div does not create the frame, the script does. The loader scans every container div on the page and places a frame in each one, so several postings can live on the same page.

The code comes in four formats, because not every site is raw HTML: HTML, PHP, JavaScript and React/Next. All four build the same frame; the only thing that changes is how the div is created. You pick the posting in the panel, the code is generated with that posting address, and you copy it.

Because the loader is served from our domain, its behavior can be fixed later without you ever touching the code on your site again. Which loader version a page is running can be read from the browser console.

An iframe is normally a fixed box, and content that does not fit produces its own scrollbar. Not here: the page inside the frame measures its own content box and reports the height outward, and the loader writes it onto the frame. No inner scrollbar appears.

The measurement deliberately runs on the content box rather than on the root element of the page. Because the root element is floored at the frame own height, the frame could grow but never shrink; when a long form gave way to a short confirmation screen, empty space would be left underneath.

There are two more bridges. As your page scrolls, the region actually visible on screen is streamed into the frame, so a dialog inside the form centers on what the user sees rather than on the middle of the page. When an application is submitted, the frame asks the page to scroll; the loader waits a moment so it does not race the height update, then verifies the target once more.

• Every message between the page and the frame is locked to a single origin, and a message from any other origin is dropped unprocessed
• The background arrives transparent and there is no shell: no menu bar, no footer, no background of its own
• Snippets installed with the old address keep working, the loader maps the old address to the canonical one

The page inside the frame is marked noindex and nofollow and is absent from the sitemap. The concrete consequence: an embedded form creates no new page on your site and your posting text is not indexed on your domain. We write that plainly, because expecting the opposite leads to a wrong setup decision.

Getting a posting into search results is solved by a separate surface: the career page. There, a posting that is Active and whose body passes 300 characters is indexed, enters the sitemap posting by posting and is published together with job posting structured data.

Both can be on at once. A company that wants the embed only switches the career page setting off; every public career URL then returns 404 while the embedded form and the application endpoint keep working.

Every time the frame loads, a health record is written. Your page address is read from the top frame information the browser provides, or from the referrer; the address header of the request itself points at our domain, so looking there would be useless.

The record is one row per company: last load time, the domain where the form was last opened, the slug of the last posting opened and the total load count. This is runtime health, not configuration; it produces no per posting or per site report.

Two metrics sit at the top of the card. "Site where the form opened" comes straight from this record. "Applications in the last 30 days", on the other hand, counts every job application of the company, not only the ones from the embedded form; keep that in mind while reading the number.

The embedded page uses the same data path as the career page. The form posts to the same endpoint, the candidate gets the confirmation email, the CV analysis runs in the background and the result sits on top of the application in the panel. The only thing that changes is the shell.

Security is identical too: bot verification is mandatory on the embedded form, an unverified application is rejected, and the endpoints sit under a 30 requests per minute rate limit. No data is stored on your site, the application goes straight to GoTeam; the privacy notice and the explicit consent both live inside the form.

The decision mechanism does not change either. AI produces rankings and suggestions and never changes the status of an application on its own; HR decides.

• Only a live posting can be embedded; the slug of a draft or closed posting returns 404 inside the frame
• How many postings you can keep open at once depends on your plan, and publishing one spends a slot
• The code sits both on the settings screen and in the "Add to your site" section of the posting detail
• Viewing and changing embed settings requires the company settings permission
• There is a printable setup guide written for your company: seven steps, screenshots and a PDF output

Almost every setup problem falls under five headings. The troubleshooting section of the setup guide follows the same order.

One warning concerns an obstacle that is not on our side: if the security headers of your own site restrict framing, the form will not open. We place no framing restriction on the embed address and the reasoning is written in the code, but the headers of your site have to allow it.

• Pasting only the div or only the script: the two travel together, neither builds a frame on its own
• Leaving the posting slug placeholder in the code: when no active posting exists in the panel, the generated code keeps the placeholder, so replace it with your own posting slug
• Using the slug of a draft posting: the frame shows "posting not found", so publish the posting first
• Putting anything other than hex into data-accent: "rgb(...)", "blue" or a CSS variable is dropped silently and the default color stays
• Writing an incomplete address: add your domain to the allowed origin list with its scheme, it is normalized while saving and the list holds at most 20 addresses