A configurable Rekrute scraper for turning job listings into structured records

The challenge is not finding a job page, it is collecting a usable dataset

Job boards expose valuable signals, but their listings are designed for people browsing one opening at a time. A team that wants to monitor hiring by city, contract type, company, or sector needs a repeatable way to move from pages of listings to records that can be filtered, exported, and compared.

MuLIAICHI/rekrute-jobs-scraper is aimed at that workflow for Rekrute.com. The repository describes the project as an Apify Actor that scrapes Rekrute job listings, with use cases including machine-learning datasets, lead generation, recruitment technology, and market analysis. Those are possible applications of the output, not guarantees of what the data will mean. The practical contribution is narrower and useful: it provides a configurable collection job that is intended to return normalized listing details.

For builders working with Moroccan and Francophone African hiring data, that can replace a fragile manual process of copying individual postings or repeatedly checking categories by hand. The project is particularly relevant when the unit of work is a job listing rather than a search result page.

A run starts with scope, then produces listing-level fields

The documented input model is concise. startUrls accepts an optional array of Rekrute category or location URLs. Leaving it empty uses the project's documented global all-jobs feed. That gives operators a simple choice between broad collection and targeted runs, such as focusing on an IT category or Casablanca listings.

maxListings controls the number of job details collected in a run. Its documented default is 100, while a value of 0 is described as collecting every available job. This is a helpful operational control: a small limit can be used to inspect fields and output quality before attempting a larger collection.

The third input, proxyConfiguration, covers routing through a proxy. The README recommends Apify Residential Proxies and notes that the target may present captchas. That recommendation is part of the project's operating guidance, not evidence that any particular configuration will avoid blocking. Teams should still plan for target-site changes, request failures, and the legal and policy constraints that apply to their use case.

The repository says its pagination logic follows next-page controls, including when the document structure changes dynamically. It also describes cleanup steps for text, dates, locations, and missing values. Source code was not included in the supplied evidence, so the implementation details and behavior on a live site cannot be independently assessed here. Still, the intended boundary is clear: retrieve listings, visit their detail pages, and emit a cleaner record for each one.

The output matches common analysis and automation tasks

The README's example output includes job_title, company_name, location, date_posted, contract_type, experience_level, education_level, sector_industry, description, job_url, and scraped_at.

That field set makes several downstream workflows straightforward. A market researcher can group records by location or sector. An HR product team can inspect contract and experience labels. A sales operations workflow could watch for new roles at companies that match a defined segment. The repository also notes that the JSON output can be exported to formats such as CSV, Excel, and XML, or sent into a database.

One detail deserves attention: the example listing is illustrative data in the README. It should not be interpreted as a verified live opening, company, date, or schema guarantee. Builders integrating the Actor should validate field presence, date formats, and category values against their own runs before using them in reporting or automated decisions.

A browser-oriented Node.js stack

The supplied package.json confirms a Node.js project with a minimum version of 20 and an ES module configuration. Its entry point is src/main.js, and the available scripts run it either directly with npm start or through the Apify tooling with apify run.

Three dependencies define the documented technical foundation:

• Apify provides the Actor-oriented runtime and deployment model described in the README. The project documents local runs, a storage directory for results, and deployment using apify push.
• Crawlee is the crawling library in the dependency manifest. In this context, it supports the repository's stated focus on traversing job listings and pagination.
• Playwright is the browser automation dependency. It is suited to sites whose pages require a real browser context or client-side rendering before their content can be collected.

This combination signals a browser-based collection approach rather than a lightweight request-only client. That can be appropriate for dynamic interfaces, but it also introduces practical costs: browser execution generally needs more resources than downloading static HTML, and target-site interface changes can affect selectors and navigation. The README explicitly frames dynamic pagination and blocking as challenges, which makes monitoring runs and testing scoped inputs a sensible implementation habit.

Start small, preserve provenance, and use the data responsibly

The repository's own configuration design suggests a useful rollout pattern. Begin with a narrow startUrls list and a low maxListings value. Inspect whether the returned title, company, location, dates, and descriptions match the needs of the system consuming them. Only then expand the scope or schedule recurring runs.

It is also worth retaining job_url and scraped_at alongside transformed data. The former points back to the listing source, while the latter records when the project says the record was collected. Those two fields can help distinguish a historical observation from a current vacancy when datasets are merged or analyzed over time.

Finally, public availability does not remove compliance obligations. The README asks users to respect local data-protection rules, including Moroccan CNDP and international GDPR frameworks, and the target website's terms of service. Any workflow that stores descriptions, connects records to CRM activity, or trains models should establish its own review of permitted collection, retention, and use.

For builders who need an Apify-based starting point for structured Rekrute listing collection, inspect the documented configuration and dependencies in the verified repository: https://github.com/MuLIAICHI/rekrute-jobs-scraper.