A job site continuously publishes and removes listings. Unlike a showcase site where pages remain stable for months, a job offer portal sees its content change every day: new publications, filled positions, archived listings. Exploring all these pages requires understanding how they are organized, indexed, and sometimes hidden.
XML Sitemap on a job site: what this technical page really reveals
The XML sitemap is a file that lists the URLs a site wants to make visible to search engines. On a job portal, this file plays a particular role because the listings have a short lifespan.
When a listing expires, the corresponding URL must be removed from the sitemap or return an appropriate HTTP code. Without this update, search engines continue to index outdated pages, which degrades the browsing experience for candidates.
Accessing the sitemap of a job site allows for quickly distinguishing active pages (current offers, job descriptions, category pages) from static pages (legal notices, about). To access it, you generally just need to add /sitemap/ or /sitemap.xml to the end of the domain name. In fact, by consulting this type of page, one can see all the pages of Tous un Job and measure the true extent of the catalog of offers provided.
Indexing API and structured data JobPosting: the mechanism reserved for job offers
Google recommends that sites publishing job offers use the Indexing API rather than waiting for the classic Googlebot crawl. This mechanism allows for directly notifying Google that a page has been published, modified, or deleted.
The benefit is clear: a listing posted on Monday morning can appear in search results much faster than with a simple sitemap. However, the sitemap remains necessary to cover the entire site.
The concrete limits of the Indexing API
The API provides an initial quota intended for testing and integration. For large-scale use, additional approval is required. According to Search Engine Journal (September 2026), several job sites have reported delays or a lack of response regarding these quota increase requests.
This gap between Google’s official recommendation and operational reality creates a frustrating situation for small to medium-sized publishers. Large portals have the technical resources to manage these constraints, while more modest sites remain dependent on classic crawling.
On the structured data side, the JobPosting markup (schema.org) allows engines to identify the job title, location, salary, and publication date directly in the page code. This markup feeds the “job offers” snippets that appear in Google search results.
Orphan pages and expired listings: the invisible areas of a job site
On an active job site, a significant proportion of pages are accessible neither from the main menu nor from internal search results. These orphan pages technically exist but are not linked to any other page on the site.
They typically appear in three cases:
- A listing has been removed from the main listing but its URL remains active, without redirection or a 410 (Gone) code
- A category page has been renamed or restructured, leaving old URLs without incoming links
- An application form or confirmation page remains after the recruitment process has closed
Why a simple noindex is not always enough
Adding a noindex tag prevents the page from appearing in search results, but it remains physically present on the server. Google can continue to visit it without indexing, which consumes crawl budget.
For expired listings, permanent removal with a 410 code or a 301 redirect to a page of similar offers remains the cleanest method. A 410 code explicitly indicates that the resource no longer exists, which speeds up the cleaning of the index.
Tools to explore all pages of an online job site
Several approaches allow for a comprehensive inventory of the URLs of a job portal, each with its strengths and blind spots.
- The search operator
site:in Google (for example,site:example.fr) displays indexed pages but ignores those blocked by the robots.txt file or marked noindex - The robots.txt file, accessible at the root of the site, indicates which directories are prohibited from crawling. On a job site, certain folders (candidate space, back-office) logically appear there
- A crawler like Screaming Frog or Xenu traverses the site link by link and generates a comprehensive list of accessible URLs, including non-indexed pages that are technically linked
- The Google Search Console, accessible only to the site owner, provides the list of indexed pages, those with errors, and those intentionally excluded
Combining the sitemap with an external crawler provides the most complete view. The sitemap shows what the site wants to make visible. The crawler shows what is actually accessible by following the links.
Structured data and faceted navigation: the hidden architecture of job portals
Job sites heavily utilize faceted navigation: filters by city, contract type, industry, experience level. Each combination of filters potentially generates a distinct URL.
A portal offering filters by region, profession, and contract type can theoretically create thousands of URL combinations. Most of these filtered pages are intentionally excluded from indexing to avoid duplicate content, but they do exist on the server.
For a candidate, understanding this mechanism allows for more efficient navigation. Instead of browsing results page by page, directly modifying the URL parameters allows access to precise filter combinations that the interface does not always clearly offer.
The structure of a job site reflects a constant compromise between comprehensiveness and readability. The sitemap, structured data, and management of expired pages form a technical ecosystem whose quality directly determines how easily a candidate finds the offer that suits them.
