Zillow Scraper GitHub: Wat werkt in 2026 (en wat stukgaat)

Als je nu zoekt op "zillow scraper github", vind je . Klinkt veelbelovend — tot je ziet dat al meer dan een jaar niet zijn bijgewerkt.

Ik heb veel tijd gestoken in het beoordelen van deze repos, het testen ervan op live Zillow-pagina's en het doorlezen van GitHub-issues en Reddit-threads waarin ontwikkelaars hun frustratie delen over wat er deze keer weer kapotging. Het patroon is telkens hetzelfde: een repo krijgt in het begin veel sterren omdat hij eindelijk werkt, en dooft daarna stilletjes uit zodra Zillow de DOM wijzigt, de anti-botbeveiliging aanscherpt of een intern API-eindpunt afschaft. Eén gefrustreerde ontwikkelaar op Reddit vatte het perfect samen: “scraping projects need to be on constant maintenance due to changes on the page or api.” Dit artikel is de audit die ik zelf had willen hebben vóór ik mijn eerste Zillow-scraperrepo kloonde — een eerlijke, actuele blik op wat in 2026 echt nog werkt, wat stukgaat en waarom, en wanneer het slimmer is om het GitHub-konijnenhol helemaal over te slaan en in plaats daarvan een tool zoals te gebruiken.

Wat is een Zillow Scraper GitHub-project (en wie heeft er één nodig)?

Een “zillow scraper” is elk script of elke tool die automatisch gegevens over woningen verzamelt van de website van Zillow — zoals prijs, adres, aantal slaapkamers, aantal badkamers, vierkante meters, Zestimate, advertentiestatus, dagen op de markt en soms diepere gegevens van detailpagina's zoals prijsgeschiedenis of belastinggegevens. Mensen zoeken specifiek op GitHub omdat ze iets gratis, open source en aanpasbaars willen. Fork een repo, pas de velden aan en stuur de output naar je eigen pipeline. In theorie krijg je dan het beste van twee werelden.

De doelgroepen zijn behoorlijk verschillend:

• Vastgoedinvesteerders die deals per postcode volgen — zij willen prijsdalingen, verschillen met de Zestimate en gegevens over dagen op de markt om kansen te filteren
• Makelaars die prospectlijsten opbouwen — zij hebben listing-URL's, contactgegevens van makelaars en wijzigingen in advertentiestatus nodig
• Marktonderzoekers en analisten die gestructureerde vergelijkingsdata verzamelen — adres, prijs per vierkante voet, verkoopprijs versus vraagprijs, aantal beschikbare objecten
• Ops-teams die prijzen of voorraad in verschillende markten op vaste momenten monitoren

De gemene deler: iedereen wil gestructureerde, herhaalbare data — geen eenmalige kopieer-plakklus. Dáárdoor is scrapen aantrekkelijk. En precies daarom wordt het onderhoud zo pijnlijk wanneer een repo stopt met werken.

De Zillow Scraper GitHub-audit van 2026: wat doet het nog echt?

Ik heb GitHub doorgespit op de populairste en meest geforkte Zillow-scraperrepos, de laatste commitdatums gecontroleerd, open issues gelezen en ze getest op live Zillow-pagina's. De methode is simpel: als een repo as van april 2026 nauwkeurige listingdata kan teruggeven van Zillow-zoekresultaten of detailpagina's, krijgt hij de status “working”. Als hij draait maar onvolledige data teruggeeft of na een paar pagina's blokkades raakt, is hij “partially working”. Als hij volledig faalt of de maintainer aangeeft dat hij dood is, is hij “broken”.

De harde realiteit: de meeste repos die 12–18 maanden geleden veelbelovend leken, zijn inmiddels stilletjes stukgegaan.

Gecureerde vergelijkingstabel: top Zillow Scraper GitHub-repos

Het patroon is duidelijk: het GitHub-ecosysteem bevat nog steeds levende code, maar de meeste zichtbare repos zijn tutorials, historische artefacten of dunne wrappers rond een workflow die afhankelijk is van proxies.

Wat “working”, “broken” en “partially working” betekenen

Ik wil deze labels nauwkeurig houden, omdat ze belangrijker zijn dan het aantal sterren:

• Working: geeft op de testdatum succesvol nauwkeurige listingdata terug van Zillow-zoekpagina's en/of detailpagina's, zonder dat de maintainer het project als dood heeft aangemerkt
• Partially working: draait, maar geeft onvolledige data terug, loopt vast na een paar pagina's of werkt alleen op bepaalde paginatypes — meestal is proxy-infrastructuur en voortdurende afstelling nodig
• Broken: geeft geen data terug, gooit fouten of is expliciet als niet-functioneel gemarkeerd door de maintainer of community

Een repo met 170 sterren en de status “broken” is slechter dan een repo met 10 sterren die wél data teruggeeft. Populariteit is historische context, geen kwaliteitsindicator.

Waarom Zillow Scraper GitHub-projecten stukgaan (de 5 meest voorkomende faalmodi)

Begrijpen waarom Zillow-scrapers stukgaan bespaart je meer tijd dan welke README dan ook. Als je begrijpt waarom Zillow-scrapers stukgaan, kun je er een robuustere bouwen of besluiten dat de onderhoudslast het simpelweg niet waard is.

1. DOM-herstructurering (Zillow's React-frontend)

De frontend van Zillow is gebouwd in React en verandert regelmatig. Class names, componentstructuur en data-attributen verschuiven zonder waarschuwing. Een scraper die vandaag div.list-card-price target, kan morgen merken dat die classnaam verdwenen is. Zoals een opmerkt, “the class names vary from page to page” op Zillow.

Het gevolg: je script draait, geeft lege velden terug en je merkt het pas nadat je een week lang blanco waarden hebt verzameld.

2. Wijzigingen in interne API- en GraphQL-eindpunten

De slimmere repos slaan HTML helemaal over en raken Zillow's interne GraphQL- of REST-API's aan. De repo gebruikt bijvoorbeeld expliciet Zillow's interne API en splitst kaartgrenzen recursief op om resultaatlimieten te omzeilen. Een slim ontwerp — maar Zillow herstructureert deze eindpunten regelmatig. Dan geeft je scraper 404's of lege JSON terug zonder foutmelding.

Dit is een subtielere vorm van stukgaan. De code is prima. Alleen is het doel verplaatst.

3. Anti-bot en CAPTCHA-escalatie

Zillow heeft zijn botdetectie de afgelopen jaren steeds verder aangescherpt. Tijdens mijn eigen tests in april 2026 leverden simpele requests.get()-calls naar zowel zillow.com als zillow.com/homes/Chicago,-IL_rb/ op — zelfs met een Chrome-achtige user-agent en Accept-Language-header. Communityrapporten sluiten daarop aan: één gebruiker meldde dat zijn reverse-engineered API-flow na ongeveer 403's begon terug te geven.

Scrapers die bij lage volumes prima werken, kunnen ineens falen zodra je opschaalt. Dat is een nare verrassing als je 200 listings over 3 postcodes probeert te volgen.

4. Loginmuren rond premium data

Bepaalde datapunten — zoals Zestimate-details, belastinggegevens en sommige prijshistorieën — zitten achter authenticatie. Open-source scrapers verwerken inlogflows zelden goed, waardoor deze velden leeg terugkomen. Als jouw use case afhangt van prijshistorie of getaxeerde belastingwaarden, loop je hier snel tegenaan.

5. Afhankelijke pakketten verouderen en repos worden niet onderhouden

De issues in de bevatten installproblemen zoals No module named 'unicodecsv'. De beschrijft handmatige ellende met drivers en GIS-afhankelijkheden. Updates van Python-bibliotheken breken compatibiliteit. Repos die al 6+ maanden niet zijn bijgewerkt, falen vaak al op een schone installatie voordat ze überhaupt aan Zillow's anti-botstack toekomen.

Zillow anti-botmaatregelen in 2026: waar je echt tegen vecht

“Gebruik gewoon proxies en roteer headers” was in 2022 nog prima advies. In 2026 is dat niet meer genoeg.

Verder dan IP-blokkering: TLS-fingerprinting en JS-challenges

Zillow blokkeert niet alleen IP's. Communityrapporten beschrijven dat Zillow achter Cloudflare zit met die verder gaan dan simpele rate limiting. TLS-fingerprinting identificeert niet-browserclients via hun “digitale handdruk” — de manier waarop ze encryptie onderhandelen. Zelfs met een frisse proxy kan je scraper worden gemarkeerd als de TLS-signatuur niet overeenkomt met die van een echte Chrome-browser.

JavaScript-challenges voegen een extra laag toe. Headless browsers die JS niet volledig uitvoeren of automatiseringsmarkeringen tonen (zoals navigator.webdriver = true) worden eruit gefilterd.

Zoekpagina's versus detailpagina's van woningen: verschillende beschermingsniveaus

Niet alle Zillow-pagina's zijn even goed beveiligd. Het maakt expliciet onderscheid tussen een “Fast Mode” die detailpagina's overslaat en een langzamere “Full Mode” met rijkere data. Ook Thunderbit's scheidt de eerste listing-scrape van “Scrape Subpages” voor verrijking via detailpagina's.

De praktische conclusie: je scraper kan prima werken op zoekresultaten, maar falen op individuele woningpagina's, waar Zillow zwaardere bescherming toepast omdat die data waardevoller is en vaker wordt gescrapet.

De HTTP-only-kamp: waarom sommige ontwikkelaars browserautomatisering vermijden

Er is een stevige groep ontwikkelaars die nadrukkelijk HTTP-only-aanpakken willen — geen Selenium, geen Playwright, geen Puppeteer. De redenen zijn praktisch: browserautomatisering is traag, zwaar voor resources en lastiger op schaal te deployen.

De eerlijke conclusie: in 2026 zijn pure HTTP-aanpakken tegen Zillow steeds moeilijker zonder geavanceerd beheer van headers en fingerprints. Het bewijs uit de community wijst erop dat browser-rendering voor targets zoals Zillow de standaard aan het worden is, niet de uitzondering.

Concrete anti-blokbest practices voor Zillow

Als je het zelf wilt bouwen, helpt dit echt — en dit juist niet:

• Gerandomiseerde request-timing die menselijk browsegedrag nabootst — dus geen vaste pauzes, maar variabele intervallen met sessieachtig gedrag
• Realistische headerconfiguraties inclusief Accept-Language, Sec-CH-UA-familieheaders en correcte referer-ketens — maar wees eerlijk: realistische headers zijn noodzakelijk, niet voldoende
• Sessierotatie — gebruik niet steeds dezelfde proxy/cookiecombinatie voor honderden requests
• Weet wanneer je moet overstappen op browser-rendering — als je HTTP-only-aanpak na 50 requests 403's teruggeeft, vecht je een verloren strijd

Geloof geen artikel dat suggereert dat één magische headercombinatie Zillow in 2026 oplost.

regelt dit allemaal automatisch — met roterende infrastructuur in de VS/EU/Azië en beheer van rendering en anti-bot — zodat gebruikers het proxyconfiguratie-konijnenhol helemaal overslaan. Het gaat erom waar de operationele last ligt.

Best practices om je Zillow Scraper GitHub-opzet toekomstbestendig te maken

Voor lezers die toch voor de GitHub/DIY-route kiezen: dit zijn de werkwijzen die scrapers die maanden meegaan onderscheiden van scrapers die al na dagen stukgaan.

Ontkoppel selectors van kwetsbare class names

Als een repo afhankelijk is van Zillow's automatisch gegenereerde CSS-class names, beschouw dat dan als een rood vlaggetje. Die namen veranderen vaak — soms wekelijks. Doe in plaats daarvan het volgende:

• Target elementen via aria-label, data-*-attributen of tekst van nabijgelegen koppen
• Gebruik waar mogelijk selectors die op tekstinhoud gebaseerd zijn
• Geef de voorkeur aan JSON-first-extractie boven HTML-parsing wanneer Zillow gestructureerde data in de paginabron levert

Voeg geautomatiseerde health checks toe

Behandel Zillow-scraping als productie-monitoring, niet als een eenmalig script. Zet een cronjob of GitHub Action op die:

1. Je scraper dagelijks op één bekende listing laat draaien
2. De output-schem a valideert (zijn alle verwachte velden aanwezig en niet leeg?)
3. Een alert triggert als de output foutief of leeg is

Zo ontdek je problemen binnen 24 uur in plaats van na weken.

Pin afhankelijkheidsversies en gebruik virtuele omgevingen

Pin altijd je Python- of Node-afhankelijkheden op specifieke versies. Gebruik virtuele omgevingen of Docker-containers. De oudere repos in onze audit laten zien hoe snel installatieregressies optreden — kapotte dependencies zijn vaak het eerste wat faalt, nog vóór Zillow's anti-botstack überhaupt in beeld komt.

Houd het scrapevolume conservatief

Die is niet universeel, maar wel een geloofwaardige herinnering dat volume het gedrag verandert van een scraper die in tests prima leek. Spreid je requests over meerdere sessies. Gebruik gerandomiseerde vertragingen. Probeer niet 10.000 listings in één run te scrapen.

Weet wanneer DIY de moeite niet meer waard is

Als je meer tijd kwijt bent aan het onderhouden van je scraper dan aan het analyseren van je data, zijn de economische verhoudingen omgeslagen. Dat is geen mislukking — het is een signaal dat je een beheerde oplossing moet overwegen.

Zillow Scraper GitHub (DIY) versus no-code tools: een eerlijke beslismatrix

De doelgroep voor “zillow scraper github” valt grofweg uiteen in twee groepen: ontwikkelaars die code-eigenaarschap willen, en vastgoedprofessionals die gewoon data in een spreadsheet willen. Beide zijn legitiem. Zo vallen de afwegingen in de praktijk uit.

Vergelijking naast elkaar

De realiteit van proxykosten

Het argument “de repo is gratis” wordt minder overtuigend zodra je proxykosten meerekent. Huidige publieke prijzen voor residential proxies:

De repo is misschien gratis, maar een Zillow-workflow op proxies is dat meestal niet.

Wanneer je voor een GitHub-repo kiest

• Je vindt het leuk om code te schrijven en te onderhouden
• Je hebt hyper-specifieke aanpassing nodig (aangepaste datatransformaties, integratie in een eigen pipeline)
• Je hebt de tijd en technische vaardigheden om problemen op te lossen
• Je bent bereid proxy-infrastructuur te beheren

Wanneer je voor Thunderbit kiest

• Je wilt vandaag betrouwbare data, zonder installatie of onderhoud
• Je bent een makelaar, investeerder of ops-teamlid — geen ontwikkelaar
• Je wilt zonder exportcode te schrijven
• Je wilt subpage scraping (listings verrijken met data van detailpagina's) zonder extra configuratie
• Je wilt geplande scraping in gewone taal kunnen beschrijven

Stap voor stap: Zillow scrapen met Thunderbit (geen GitHub nodig)

De no-code route lijkt totaal niet op het GitHub-installatieproces.

Stap 1: Installeer de Thunderbit Chrome-extensie

Ga naar de , installeer Thunderbit en meld je aan. Er is een gratis versie.

Stap 2: Ga naar Zillow en open Thunderbit

Ga naar een willekeurige Zillow-zoekresultatenpagina — bijvoorbeeld koopwoningen in een specifieke postcode. Klik op het Thunderbit-extensie-icoon in de werkbalk van je browser.

Stap 3: Gebruik de Zillow Instant Scraper-template (of laat AI velden suggereren)

Thunderbit heeft een — geen configuratie nodig, gewoon één klik. De template dekt de standaardvelden: adres, prijs, slaapkamers, badkamers, vierkante meters, naam van de makelaar, telefoonnummer van de makelaar en listing-URL.

Je kunt ook op “AI Suggest Fields” klikken; de AI leest de pagina en stelt kolommen voor. In mijn ervaring detecteert hij meestal , inclusief de Zestimate.

Stap 4: Klik op Scrape en bekijk de resultaten

Klik op “Scrape”. Thunderbit verwerkt paginering, anti-bot en datastructurering automatisch. Je krijgt een gestructureerde tabel met resultaten — geen 403-fouten, geen lege velden, geen proxyconfiguratie.

Stap 5: Verrijk met subpagedata (optioneel)

Klik op “Scrape Subpages” zodat Thunderbit elke detailpagina van een listing bezoekt en extra velden ophaalt: prijsgeschiedenis, belastinggegevens, perceelgrootte, schoolscores. In een GitHub-opzet zou dit een complexe tweede scrape-ronde zijn met eigen selectorlogica en anti-bothandling. Hier is het één klik.

Stap 6: Exporteer je data gratis

Exporteer naar Excel, Google Sheets, Airtable of Notion — allemaal gratis. Download als CSV of JSON als je dat liever hebt. Geen exportcode om te schrijven.

Dat verschilt wezenlijk van de GitHub-gebruikersreis, die meestal begint met het opzetten van de omgeving en eindigt met het oplossen van 403's.

Van CSV naar inzicht: wat je echt moet doen met je Zillow-data

De meeste gidsen eindigen bij “hier is je CSV”. Dat is alsof je iemand een hengel geeft en wegloopt zonder uit te leggen hoe je de vis moet bereiden.

Scrapen is stap één. Dit is de rest.

Stap 1: Scrape — verzamel listingdata

Kernvelden uit zoekresultaten: prijs, slaapkamers, badkamers, sqft, adres, Zestimate, listingstatus, dagen op de markt, listing-URL.

Stap 2: Verrijk — haal detailpaginadata op via subpage scraping

Extra velden van detailpagina's van woningen: prijsgeschiedenis, belastinggegevens, perceelgrootte, VvE-kosten, schoolscores, contactgegevens van de makelaar. Thunderbit's subpage scraping regelt dit in één klik. In een GitHub-opzet zou je een aparte scrape-ronde nodig hebben met eigen selectors en anti-botlogica.

Stap 3: Exporteer — stuur naar je favoriete platform

• Google Sheets voor snelle analyse en delen
• Airtable voor een mini-CRM of dealtracker
• Notion voor een teamdashboard
• CSV/JSON voor aangepaste pipelines

Stap 4: Monitor — plan terugkerende scrapes

Dit is het pijnpunt dat in meerdere forumthreads als onopgelost wordt genoemd. Je wilt niet alleen de data van vandaag — je wilt prijsdalingen, statuswijzigingen (actief → in behandeling → verkocht) en nieuwe listings zien zodra ze verschijnen.

Thunderbit's geplande scraper laat je intervallen in gewone taal beschrijven (bijv. “elke dinsdag en vrijdag om 8.00 uur”). Voor een GitHub-opzet zou je zelf een cronjob moeten bouwen, authenticatie persistent houden en foutafhandeling beheren.

Stap 5: Handel — filter op deals en voed outreach-workflows

Hier wordt data omgezet in beslissingen:

• Voor investeerders: filter op prijsdalingen >5% in 30 dagen, dagen op de markt >90, prijs onder Zestimate
• Voor makelaars: markeer nieuwe listings die passen bij kopercriteria, verlopen/ingetrokken listings voor prospecting
• Voor onderzoekers: bereken trends in prijs per sqft, verhouding verkoopprijs versus vraagprijs, snelheid van voorraadverloop

Praktijkvoorbeeld: een investeerder die 200 listings in 3 postcodes volgt

Zo zien de datavelden eruit per use case:

De investeerder zet een wekelijkse scrape op over drie postcodes, exporteert naar Google Sheets en past voorwaardelijke opmaak toe voor prijsdalingen en uitschieters in DOM. De makelaar exporteert naar Airtable en bouwt een prospecting-pipeline. De onderzoeker haalt de data in een spreadsheet voor trendanalyse. Dezelfde scrape-stap, drie verschillende workflows.

Juridische en ethische overwegingen bij het scrapen van Zillow

Kort, maar noodzakelijk.

verbieden expliciet geautomatiseerde queries, waaronder screen scraping, crawlers, spiders en het omzeilen van CAPTCHA-achtige voorzorgsmaatregelen. Zillow's sluit brede paden uit, waaronder /api/, /homes/ en URL's met query state.

Tegelijkertijd is de Amerikaanse webscrapingwet niet terug te brengen tot “alle scraping is illegaal”. De lijn van zaken rond hiQ v. LinkedIn is relevant voor scraping van openbare data onder de CFAA. Een van Haynes Boone merkt op dat het Ninth Circuit opnieuw LinkedIn's poging afwees om scraping van openbare ledenprofielen te blokkeren. Maar dat neemt afzonderlijke contract-, privacy- of anti-omzeilingsargumenten niet weg, en maakt Zillow's ToS niet irrelevant.

Wat dat voor jou betekent:

• Scraping van openbare pagina's kan juridisch sterker staan dan veel website-eigenaren suggereren
• Zillow verbiedt het contractueel nog steeds
• Het omzeilen van technische barrières verhoogt het juridische risico
• Heb je een commerciële of grootschalige use case, vraag dan juridisch advies
• Ongeacht het juridische landschap: scrape verantwoord, respecteer rate limits, overbelast servers niet en gebruik geen persoonsgegevens voor spam

De juiste tool kiezen voor je Zillow-workflow

Het Zillow-scraper GitHub-landschap in 2026 is dunner dan het lijkt. De meeste zichtbare repos zijn verouderd, kwetsbaar of stuk. Een klein aantal nieuwere repos — met name — werkt nog steeds, maar alleen met voortdurend proxy- en anti-botonderhoud.

De echte keuze is niet open source versus closed source. Het is controle versus operationele last.

• Als je volledige controle wilt en het leuk vindt om scrapers te onderhouden, zijn GitHub-repos krachtig — maar reserveer tijd voor proxybeheer, selectorupdates en health monitoring.
• Als je vandaag betrouwbare data wilt zonder onderhoud, brengt je in minuten van zoekresultaat naar spreadsheet. De AI leest de paginastructuur elke keer opnieuw, dus hij leunt nooit op hardcoded selectors die stukgaan.

Beide routes zijn legitiem.

De slechtste uitkomst is uren besteden aan het opzetten van een GitHub-scraper, om vervolgens te ontdekken dat hij vorige maand al stukging en niemand de README heeft bijgewerkt.

Als je de no-code route in actie wilt zien, — scrape Zillow-listings in ongeveer 2 klikken en exporteer naar elk platform dat je team al gebruikt. Wil je eerst zien hoe het werkt? Op het staan walkthroughs.

Veelgestelde vragen

Is er in 2026 een werkende Zillow scraper op GitHub?

Een paar repos werken gedeeltelijk — vooral johnbalvin/pyzill, dat nog steeds data teruggeeft maar rotating residential proxies en voortdurende afstelling nodig heeft. De meerderheid van de repos met sterren (waaronder ChrisMuir/Zillow met 170 sterren en scrapehero/zillow_real_estate met 152 sterren) is stuk door Zillow's anti-botwijzigingen en DOM-updates. Kijk in de audittabel hierboven voor de actuele status.

Kan Zillow GitHub-scrapers detecteren en blokkeren?

Ja. Zillow gebruikt IP-blokkering, TLS-fingerprinting, JavaScript-challenges, CAPTCHA's en rate limiting. In tests gaven zelfs simpele HTTP-requests met Chrome-achtige headers 403 terug via CloudFront. GitHub-scrapers zonder goede anti-detectiemaatregelen — residential proxies, realistische headers, browser-rendering — worden snel geblokkeerd, vaak al binnen 100 requests.

Welke data kun je van Zillow scrapen?

Veelvoorkomende velden zijn prijs, adres, slaapkamers, badkamers, vierkante meters, Zestimate, listingstatus, dagen op de markt, listing-URL en contactgegevens van de makelaar. Met scraping van detailpagina's kun je ook prijsgeschiedenis, belastinggegevens, perceelgrootte, VvE-kosten en schoolscores ophalen. De exacte velden hangen af van de mogelijkheden van je scraper en of je zoekresultaten of individuele woningpagina's target.

Is Zillow scrapen legaal?

Dat is genuanceerd. Scraping van publiek beschikbare data staat juridisch sterker na de hiQ v. LinkedIn-zaken, maar Zillow's Terms of Use verbieden geautomatiseerde toegang expliciet. Het omzeilen van technische barrières (zoals CAPTCHA's en rate limits) voegt extra juridisch risico toe. Voor persoonlijk onderzoek is het risico doorgaans laag. Voor commerciële of grootschalige use cases: raadpleeg juridisch advies. Scrape altijd verantwoord, ongeacht de situatie.

Hoe scrapt Thunderbit Zillow zonder stuk te gaan?

Thunderbit gebruikt AI om de paginastructuur bij elke run opnieuw te lezen — het vertrouwt niet op hardcoded CSS-selectors of XPaths die stukgaan wanneer Zillow zijn frontend bijwerkt. Daarnaast heeft het een vooraf gebouwde voor extractie met één klik. Cloud scraping handelt anti-bot automatisch af met roterende infrastructuur, zodat gebruikers geen proxies hoeven in te stellen of browser-rendering zelf te beheren. Wanneer Zillow de lay-out wijzigt, past de AI zich aan — geen repo-update nodig.

Meer weten