PAP Scraper - Private-Seller Listing Data from pap.fr

What a PAP listing carries

Each detail page embeds a schema.org Product block, so the core commercial fields come out of structured markup rather than guesswork about CSS classes. The rest is read from the page body.

• prix (price) - a plain integer in EUR inside the structured block. The rendered page prints it with a dot as the thousands separator, so 1.870.000 € is one million eight hundred and seventy thousand euros, not a decimal.
• surface (floor area) - a decimal carrying the unit code MTK, beside nombre de pièces (room count) and type de bien (property type). Cards add nombre de chambres (bedroom count).
• DPE and GES (energy and greenhouse gas labels) - drawn as a list of the letters A to G with only an active state marking the real class, so plain text extraction returns all seven letters. The tooltip carries the numeric band behind the letter, for example 251 to 330 kWh per m2 a year.
• charges (service charges) and taxe foncière (property tax) - usually typed into the free-text description rather than a field. One listing we read states charges de copropriété of 472 euros per quarter inside the body text.
• étage (floor level) - not a structured field. It turns up in the title or description where the owner mentions it, and on the search side only as a dernier étage (top floor) filter.
• Address - street, locality, postal code and country in the structured block, plus coordinates.
• Reference and date - each page prints a PAP reference code, the publication date and a price per m2 the site computes itself.
• Photos, and nearby transport as station names with the metro or RER line held in an icon class, not text.

Personal contact details are not part of the output. PAP publishes a private owner's telephone number on the listing page, and every advertiser is a private individual, which makes that number personal data under the GDPR. Our standard build drops the phone number and any personal name before delivery. That is the default, not something you ask for.

What PAP scraping has to handle over time

A listing lives at /annonces/{slug}-r{id}. The slug is cosmetic and not unique: we found two different Paris flats published under the same appartement-75016-jardin-de-45m2 slug with different r ids. The r number is the stable key, and requesting the path with the slug left out redirects to the current canonical URL, so an id kept from an earlier run can be re-resolved later.

Search paths look like /annonce/{slug}-{place}-{code}-g{id}, and one g namespace covers every level: Île-de-France is g471, the Paris departement is g439, Paris 16e is g37783. Communes carry g ids too, and PAP's per-commune price pages reuse them, which turns the join between a listing index and its local reference price into a lookup rather than a match on place names.

Pagination is a trailing path segment rather than a query parameter, and the slug prefix rotates between pages. On one archived Paris lettings run, page 12 sat under recherche-location, page 13 under locations-particuliers, page 14 under location--logement and page 15 under logement-louer, all sharing the same g439 tail. A crawler that increments a page number against a fixed slug drifts off the result set, so ours follows the rendered links.

Withdrawn listings do not stay addressable. A removed advert returns 404 rather than a sold or let marker, so time on market, price cuts and disappearance dates are reconstructed by re-checking ids already held and stamping first-seen and last-seen dates on each one.