Quick answer eBay Kleinanzeigen's search pagination has two different URL shapes, and only one of them is safe to string-template. The keyword-search shape this Actor builds on — /s-{slug}/k0 for page 1, /s-seite:{N}/{slug}/k0 for page N — held up under a real test: three consecutive pages of fahrrad returned 27 unique ad ids each, zero overlap between page 1 and page 3, and only a handful of promoted listings repeating on adjacent pages. The sibling category-browse shape does not hold: guessing /seite:{N}/ there returns a 302 redirect or a 200 with an empty results shell, because the real page-2+ URL carries a hidden per-category segment only the page's own pagination widget knows (a smartphones category's real page 2 lives under handy-telekom , not smartphones ). This is a Kleinanzeigen scraper for Germany's #1 classifieds site — one row per listing card (title, price, location, image, seller type) — at $2.70 per 1,000 results , no login needed. Why does Kleinanzeigen have two different page-2 URLs, and why does only one of them work? Because Kleinanzeigen serves keyword search and category browsing on shapes that only look alike. Keyword search takes a query slug: /s-fahrrad/k0 for page 1, /s-seite:2/fahrrad/k0 for page 2. Category browsing takes a category slug plus a numeric category id — /s-smartphones/k0c173 — and the obvious next-page guess, /s-smartphones/seite:2/k0c173 , is the trap. We confirmed both of its failure modes live: a 302 redirect back to page 1, and separately a 200 with an empty results shell that looks like a genuine zero-match page but isn't. The real second page for that category exists at a completely different, undocumented segment — handy-telekom , not smartphones — obtainable only by parsing the <div id="srchrslt-pagination"> widget the first page actually renders. We don't ship category browsing in v1, so this Actor never touches that trap. But we still write the lesson into the code as a standing warning, because the keyword shape holding today is not proof it holds forever. A URL shape that works today because you guessed right is still a guess. Parse the page's own pagination link when one is available — never string-template a page number and assume next month's redesign leaves it alone. How do you prove a paginator actually advances instead of quietly repeating page 1? Comparing page 1 to page 2 isn't enough — a small legitimate overlap there can look identical to a broken pager that's serving the same page twice. Kleinanzeigen runs promoted/featured listings pinned near the top of consecutive result pages, a normal classifieds pattern, and that alone produced an 8-of-27 overlap between page 1 and page 2, and a 6-of-27 overlap between page 2 and page 3, on the same live fahrrad search. If we'd stopped there, that overlap could plausibly be mistaken for a pager quietly repeating results. The check that actually settles it is comparing pages that are two steps apart: page 1 against page 3 came back at zero overlap , 27 fresh ids on both sides. That's the real signal that the result set is advancing — the adjacent-page overlap is pinned inventory, not a bug, and the dataset dedupes every row by ad_id across the whole run regardless, so a promoted listing that resurfaces on two pages is written once. A small overlap between adjacent pages doesn't prove your pagination is broken — sponsored slots do that legitimately. Diff pages that are further apart before you file a pagination bug. Why is price_amount sometimes null when price_raw is always filled in? Because "no numeric price" is a real, common answer on Kleinanzeigen, not a parse failure to paper over. A listing can show a Euro amount ("150 €"), the negotiable marker "VB" — often riding along with an amount, as in "390 € VB" — a bare "VB" with no number at all, a "Zu verschenken" (give-away) phrase, or nothing. We keep price_raw as the always-populated, exact source text and let price_amount be null whenever there's no number to parse. If your pipeline treats a null price as missing data instead of "negotiable" or "free," it will silently drop real listings that are worth exactly as much attention as the priced ones. How do you tell the listing's location apart from a near-identical date stamp sitting right next to it? By anchoring on the one element that's actually unique: the pin-icon SVG ( svg[data-title="locationOutline"] ). Kleinanzeigen's result cards place a calendar/timestamp element structurally right next to the location <span> , close enough in markup shape that "grab the next span" would silently pull the wrong text on a meaningful fraction of cards. We confirmed this against real captured HTML, not hand-typed fixtures, before writing the extraction rule — the pin icon is the only anchor we trust. What happens when a keyword search returns nothing? The run finishes successfully with zero rows for that keyword and moves on to the next one. Kleinanzeigen's own "answered" signal ( #srp-breadcrumb-summary ) renders on both a real match and a genuine zero-match page — with matching German copy on the empty case — so a search that ran and matched nothing gets treated exactly like what it is: a completed search, not a failure. A run given several keywords keeps going even if one of them comes up empty. Is this target defended, and what happens if that changes? Not today, based on what we measured. No anti-bot signature turned up across a batch of live requests on Kleinanzeigen's keyword search pages during recon. That's a measured-today claim, not a permanent one — so the Actor still ships with a residential proxy pinned to Germany by default, browser-fingerprint rotation across Chrome and Firefox TLS profiles on every request, and exponential backoff with up to 5 retries on 408 / 429 / 5xx . If Kleinanzeigen starts pushing back tomorrow, that machinery is already wired in; nothing about the input needs to change. What do you get back? One row per listing card: ad_id , title , description_snippet , price_amount + price_raw , currency , location + postal_code (parsed out when it cleanly splits), image_url , url , is_shipping_available (a DHL marker on the card), is_commercial_seller (PRO/shop badge), and an ISO-8601 scraped_at timestamp. Search as many keywords as you like in one run — results merge and dedupe by ad_id across every page and every keyword. Pricing Pay-Per-Event : $0.20 per run (a flat warm-up charge, fired once) + $0.0025 per listing row written to your dataset. 1,000 results run about $2.70 . No subscription, no minimum — Apify hands every new account $5 of free trial credit. FAQ Do I need to log in or provide cookies? No. Kleinanzeigen's keyword search and result cards are public — no account, cookies, or login required. Can I search multiple keywords in one run? Yes. Add as many entries to keywords as you like; results merge and dedupe by ad_id across the whole run. What happens if a keyword has no results? The run succeeds with zero rows for that keyword and continues — an empty search is not an error. Why is price_amount null on some rows? Because the listing genuinely has no numeric price — "VB" (negotiable) or a give-away — not because parsing failed. Check price_raw for the verbatim text. Does this support category browsing instead of keyword search? Not in v1. Category-browse pagination needs a different, undocumented URL segment per category that only the page's own pagination widget reveals — a documented hazard we chose not to build on yet. 😈 Kleinanzeigen Listings Scraper turns a keyword into deduplicated rows off Germany's #1 classifieds site — title, price, location, image, DHL flag, private-vs-PRO seller. $2.70 per 1,000 results , pay only for results that land, no card required to try. No captcha on this one — just two page-2 URLs that look like the same idea and aren't. We built on the one we could prove. 😈
İlgili Haberler
Kaynak: Dev.to
Alinti: Bu haber Dev.to tarafindan yayinlanmistir. Haberin tamamini ziyaret ederek okuyabilirsiniz.
Guncelleme: 21.09.2026 06:01 – Barış Tekin haber derlemesi