Cara Membuat Situs Web Agregator: Panduan Praktis

Pendapat kami: kami adalah Geonode dan kami menjual proxy, yang merupakan salah satu masukan bagi agregator dan hal yang paling sering dilebih-lebihkan oleh banyak panduan. Jadi, mari kita jelaskan secara jujur sejak awal — proxy adalah hal terakhir yang harus Anda beli, bukan yang pertama. Sebagian besar data yang dapat diagregasi tersedia melalui feed, API, dan peta situs yang gratis, terstruktur, stabil, dan secara eksplisit ditawarkan untuk tujuan ini. Membuat crawler untuk konten yang dipublikasikan seseorang sebagai feed RSS adalah pekerjaan yang sia-sia, dan membeli bandwidth sebelum Anda menyadari hal itu adalah pemborosan uang. Proksi menjadi relevan pada titik tertentu — ketika Anda melakukan crawling dalam volume besar, dari berbagai wilayah, terhadap situs-situs yang menerapkan batasan laju (rate-limit) — dan titik tersebut datang lebih lambat daripada yang diasumsikan kebanyakan orang. Ada bagian di bawah ini yang menjelaskan secara tepat di mana batas tersebut berada.

Jenis Aggregator: Empat Model

Keempat model ini memiliki dinamika ekonomi dan risiko hukum yang berbeda-beda, dan menyamakan semuanya adalah kesalahan pertama.

Aggregator tautan mengumpulkan judul berita dan menyertakan tautan ke sumbernya. Kebutuhan penyimpanan rendah, risiko hukum rendah, dan biaya peralihan yang rendah bagi pengguna. Nilainya sepenuhnya terletak pada kurasi dan kecepatan. Sebagian besar agregator berita dan konten berada di kategori ini.

Agregator daftar mengumpulkan catatan terstruktur — lowongan kerja, properti, mobil, acara — dan menyajikannya sebagai basis data yang dapat dicari. Nilai lebih tinggi, upaya lebih besar, dan model di mana deduplikasi menjadi masalah teknik utama.

Agregator harga melacak harga barang yang sama di berbagai penjual. Ini yang paling sempit dan sulit: mencocokkan produk di antara pengecer yang mendeskripsikannya secara berbeda adalah masalah yang benar-benar rumit, dan persyaratan keaktualan sangat ketat karena harga yang sudah kadaluwarsa lebih buruk daripada tidak ada harga sama sekali.

Agregator ulasan dan penilaian menggabungkan data opini. Cakupan yang terbatas, pekerjaan normalisasi yang berat, dan paling rentan terhadap tuduhan menyalahartikan sumber.

Pilihlah salah satunya dengan sengaja. Arsitekturnya berbeda, analisis hukumnya berbeda, dan “agregator untuk segala hal” adalah cara proyek menjadi tak pernah selesai.

Dapatkan Data dengan Cara yang Mudah Terlebih Dahulu

Berdasarkan urutan prioritas. Telusuri daftar ini dari atas ke bawah dan hentikan begitu menemukan yang berhasil.

API Resmi. Jika sumbernya menyediakan API resmi, gunakanlah. API ini stabil, terstruktur, disahkan, dan akan diperbaiki oleh pihak terkait jika terjadi gangguan. Baca persyaratannya — kebanyakan membatasi redistribusi, durasi penyimpanan cache, dan penggunaan komersial, dan pembatasan tersebut akan memengaruhi produk Anda.

Umpan mitra atau afiliasi. Banyak industri menerbitkan umpan massal khusus untuk agregator, karena agregator mengirimkan lalu lintas ke mereka. Papan lowongan kerja, portal properti, pengecer, dan operator perjalanan sering kali memiliki program mitra yang memberikan seluruh kumpulan data kepada Anda. Ini adalah sumber yang paling jarang dimanfaatkan di bidang ini, dan alasannya adalah orang-orang mencari "cara meng-scrape X" alih-alih mengirim email ke X untuk menanyakan apakah mereka memiliki feed. Tanyakan saja. Jumlah yang mengejutkan akan menjawab ya.

Feed RSS dan Atom. Masih banyak diterbitkan, masih ideal untuk agregasi tautan. Terstruktur, murah, dirancang khusus untuk tujuan ini, dan ditawarkan secara jelas untuk dikonsumsi.

Peta situs. sitemap.xml memberikan daftar URL lengkap beserta cap waktu lastmod, yang memungkinkan Anda melakukan perayapan secara efisien daripada dengan metode brute force. Bahkan jika Anda harus melakukan perayapan, peta situs akan memberi tahu Anda apa yang telah berubah sehingga Anda hanya mengambil data tersebut.

Data terstruktur di halaman. Sebelum menulis parser HTML, periksa keberadaan JSON-LD dalam blok <script type="application/ld+json">. Markup Schema.org untuk JobPosting, Product, Event, dan Recipe sudah tersebar luas karena mendukung fitur pencarian, dan memberikan data terstruktur yang rapi dari halaman yang memang akan Anda ambil. Markup ini juga lebih tahan terhadap perombakan desain dibandingkan selektor CSS.

Parsing HTML. Pilihan terakhir. Rentan, membutuhkan perawatan tinggi, dan hal yang mengubah pekerjaan pengumpul data menjadi pekerjaan tetap.

Urutan lebih penting daripada item individu mana pun. Tim yang memulai dari bagian bawah daftar ini akan membangun crawler terlebih dahulu, lalu baru menemukan feed enam bulan kemudian.

Saat Anda Harus Melakukan Crawling: robots.txt Kini Telah Menjadi Standar

robots.txt tidak lagi sekadar konvensi sejak tahun 2022. RFC 9309 menstandarkan Protokol Pengecualian Robot, dan jika Anda sedang mengembangkan crawler, dokumen ini mendefinisikan perilaku yang harus Anda terapkan.

Empat persyaratan yang perlu dipahami dengan tepat:

Pencocokan didasarkan pada spesifisitas, bukan urutan. "Pencocokan yang paling spesifik yang ditemukan HARUS digunakan. Pencocokan yang paling spesifik adalah pencocokan yang memiliki oktet terbanyak." Bukan 'pencocokan pertama yang menang', yang sering diasumsikan oleh banyak parser buatan sendiri.

Simpan dalam cache tidak lebih dari 24 jam. "Crawler SEBAIKNYA TIDAK menggunakan versi yang disimpan dalam cache selama lebih dari 24 jam, kecuali jika berkas robots.txt tidak dapat diakses." Mengambilnya sekali pada saat deployment tidak memenuhi ketentuan.

Kesalahan server berarti harus berhenti. "Jika berkas robots.txt tidak dapat diakses karena kesalahan server atau jaringan... crawler HARUS menganggapnya sebagai larangan total." Kode status 5xx berarti harus mundur sepenuhnya. Sebaliknya, kode status 404 berarti tidak ada pembatasan — tidak ada berkas, jadi tidak ada yang dilarang.

Parsing minimal 500 KiB. "Batas penguraian HARUS setidaknya 500 kibibytes." Situs besar memiliki berkas-berkas besar.

Gunakan pustaka yang terawat daripada menulisnya sendiri. Aturan pencocokan spesifisitas saja sudah sering menjadi sumber bug, dan crawler yang salah membaca robots.txt adalah crawler yang menimbulkan keluhan.

Selain file itu sendiri, ikuti etika umum: identifikasi diri Anda dengan user agent asli yang menyertakan URL kontak, patuhi Crawl-delay jika ada, segera hentikan permintaan saat mendapat respons 429 dan 503, serta gunakan cache agar Anda tidak pernah mengambil konten yang tidak berubah dua kali. Permintaan bersyarat dengan If-Modified-Since atau If-None-Match tidak membebani sumber apa pun dan tidak membebani Anda apa pun. Sebagian besar situs yang memblokir agregator melakukannya karena perilaku, bukan karena keberadaannya.

Aspek Hukum: Hak Cipta, Penolakan TDM, dan Hak atas Basis Data

Ini bukan nasihat hukum, dan yurisdiksi memegang peranan yang sangat besar. Namun, ada empat hal yang perlu dipahami sebelum Anda mulai membangun.

Fakta pada umumnya tidak dilindungi hak cipta; yang dilindungi adalah ekspresinya. Jabatan, gaji, harga, dan tanggal adalah fakta. Deskripsi yang ditulis untuk mempromosikan lowongan pekerjaan tersebut merupakan ekspresi. Menggabungkan fakta-fakta tersebut jauh lebih aman daripada mereproduksi ekspresi tersebut. Perbedaan tunggal ini membentuk desain agregator yang paling masuk akal: simpan fakta-fakta yang terstruktur, dan berikan tautan ke sumber untuk teks deskriptifnya.

Panjang cuplikan itu penting. Mereproduksi judul dan satu kalimat dengan tautan adalah hal yang berbeda dari mereproduksi sebuah artikel. Beberapa yurisdiksi telah mengadili di mana batasnya, dan jawabannya berbeda-beda. Semakin pendek semakin aman, dan menautkan daripada mereproduksi adalah yang paling aman.

Uni Eropa memiliki opsi penolakan (opt-out) untuk penambangan teks dan data yang dirancang agar dapat dibaca oleh mesin. Pasal 4 dari Direktif (UE) 2019/790 mengizinkan penambangan teks dan data oleh siapa pun, asalkan pemegang hak tidak secara tegas membatasi hak mereka "dengan cara yang sesuai, misalnya dengan menggunakan sarana yang dapat dibaca mesin". Untuk konten yang tersedia secara publik di internet, direktif tersebut menganggap pembatasan yang dapat dibaca mesin — "termasuk metadata serta syarat dan ketentuan situs web atau layanan" — sebagai cara yang tepat. Pengecualian ini juga mensyaratkan bahwa materi tersebut diakses secara sah.

Implikasi praktis bagi crawler: pembatasan yang dinyatakan dalam bentuk yang dapat dibaca mesin dimaksudkan untuk dihormati, dan UE telah berupaya menstandarkan protokol untuk menyatakan pembatasan tersebut. Membangun crawler yang mengabaikan pembatasan yang dapat dibaca mesin berarti menanamkan masalah kepatuhan ke dalam fondasi Anda.

UE juga memiliki hak basis data yang terpisah. Di luar hak cipta, Direktif Basis Data menciptakan hak sui generis yang melindungi investasi substansial dalam memperoleh, memverifikasi, atau menyajikan isi basis data — terlepas dari apakah isi tersebut sendiri dapat dilindungi hak cipta. Hal ini sangat relevan bagi agregator, karena mengekstrak bagian substansial dari basis data daftar milik seseorang dapat melanggar hak tersebut, bahkan jika setiap daftar individu hanyalah fakta mentah.

Selain itu, ada ketentuan layanan, yang bersifat kontraktual bukan undang-undang, dan yang digunakan banyak situs untuk melarang akses otomatis secara tegas. Apakah suatu ketentuan mengikat Anda meskipun Anda tidak pernah mengklik apa pun merupakan pertanyaan yang benar-benar diperdebatkan dan bervariasi menurut yurisdiksi. Bacalah ketentuan tersebut: ketentuan tersebut memberi tahu Anda apa yang akan dilakukan situs terkait hal tersebut, yang seringkali lebih relevan secara langsung daripada apa yang akan diputuskan pengadilan.

Ringkasan praktisnya: utamakan sumber yang disahkan, simpan fakta daripada teks, berikan tautan daripada menyalin, patuhi batasan yang dapat dibaca mesin, dan mintalah nasihat untuk hal-hal yang memiliki dampak komersial.

Arsitektur: Empat Tahap dan Tahap yang Sulit

Setiap agregator memiliki empat tahap yang sama, dan hanya satu di antaranya yang sulit.

Pengambilan. Mengambil konten mentah. Hal-hal yang perlu diperhatikan: penjadwalan, pembatasan laju, upaya ulang, penyimpanan dalam cache, permintaan bersyarat. Selalu simpan respons mentah — ketika parser rusak, Anda ingin mengurai ulang data historis daripada mengambilnya kembali.

Penguraian. Mengubah konten mentah menjadi catatan terstruktur. Hal-hal yang perlu diperhatikan: kerentanan dan deteksi perubahan. Berikan peringatan ketika bentuk keluaran parser berubah, bukan ketika terjadi kesalahan, karena kegagalan yang paling merugikan adalah ketika parser secara diam-diam mulai mengembalikan lebih sedikit bidang.

Normalisasi dan deduplikasi. Tahap yang sulit. Dijelaskan secara rinci di bawah ini.

Sajikan. Pencarian, penyaringan, penayangan. Rekayasa web standar, dan bagian yang paling sering diinvestasikan berlebihan oleh tim pada tahap awal karena ini adalah bagian yang terlihat.

Penghapusan duplikat adalah kunci keberhasilan atau kegagalan agregator. Lowongan pekerjaan yang sama diposting di empat papan lowongan dengan judul yang berbeda. Properti yang sama muncul melalui tiga agen dengan harga yang berbeda. Produk yang sama memiliki nama berbeda di setiap pengecer. Pengguna menilai Anda hampir sepenuhnya berdasarkan hal ini: situs daftar yang menampilkan hal yang sama enam kali akan dianggap bermasalah, terlepas dari seberapa lengkapnya.

Pendekatan yang berhasil bersifat berlapis, mulai dari yang paling murah:

Pengidentifikasi yang tepat. ISBN, nomor bagian, nomor registrasi, ID sumber. Jika tersedia, gunakanlah dan hentikan di situ — hal ini menyelesaikan masalah sepenuhnya.

Kunci yang dinormalisasi. Buat kunci kanonik dari bidang yang diubah menjadi huruf kecil, spasi dihapus, dan tanda baca dihilangkan: nama perusahaan ditambah jabatan ditambah lokasi; kode pos ditambah jumlah kamar tidur ditambah luas lantai. Mencakup sebagian besar data dengan biaya rendah.

Pencocokan kabur. Kemiripan berbasis token pada judul dan deskripsi, dengan ambang batas yang Anda sesuaikan berdasarkan sampel yang diberi label secara manual. Ini diperlukan namun mahal; batasi penggunaannya pada kandidat yang sudah memiliki kunci kasar yang sama, atau ini akan menjadi perbandingan semua pasangan yang tidak terjangkau biayanya.

Peninjauan manual untuk kasus-kasus ambigu di tengah. Terimalah bahwa sebagian kecil data memerlukan intervensi manusia. Siapkan antrean peninjauan sejak dini, bukan setelah pengguna mengeluh.

Dua keputusan desain yang akan menghemat masalah di kemudian hari: simpan setiap catatan sumber secara terpisah dan hubungkan ke entitas kanonik, bukan dengan menggabungkannya secara destruktif — Anda akan melakukan penggabungan yang salah dan perlu membatalkannya. Dan catat alasan mengapa dua catatan digabungkan, karena “mengapa daftar ini menampilkan harga yang salah” adalah pertanyaan yang akan diajukan kepada Anda dan tidak dapat dijawab hanya berdasarkan data yang telah digabungkan.

Kesegaran, Jadwal, dan Biayanya

Persyaratan kesegaran sangat bervariasi dan memengaruhi seluruh struktur biaya Anda.

Kesalahan yang merusak anggaran adalah merayapi semua konten dengan frekuensi yang dibutuhkan oleh item yang paling sering berubah. Solusinya adalah pengelompokan: perbarui yang sering berubah dengan sering; perbarui yang jarang berubah dengan jarang; dan gunakan lastmod dari peta situs serta permintaan bersyarat untuk melewati konten yang tidak berubah sepenuhnya.

Deteksi penghapusan adalah masalah keaktualan yang jarang direncanakan. Lowongan yang sudah terisi atau rumah yang sudah terjual harus menghilang, dan sumber jarang mengumumkannya. Anda memerlukan sinyal (halaman menampilkan 404, bidang status berubah) atau kebijakan (catatan yang tidak terdeteksi dalam tiga kali pengindeksan ditandai sebagai tidak aktif). Jika salah menangani hal ini, agregator Anda akan dipenuhi dengan daftar yang sudah tidak berlaku, yang merupakan alasan kedua paling umum mengapa pengguna berhenti mempercayai agregator setelah duplikat.

Biaya sebanding dengan jumlah pengambilan data, bukan dengan jumlah catatan. Sepuluh ribu daftar yang diperiksa setiap jam berarti 240.000 pengambilan data per hari; daftar yang sama yang diperiksa setiap hari berarti 10.000 pengambilan data. Data yang sama, namun perbedaan bandwidth dan beban yang Anda berikan pada sumber mencapai dua puluh empat kali lipat. Setiap jam keterlambatan yang dapat diterima berarti kerugian finansial.

Kapan Proksi Diperlukan dan Kapan Tidak

Bagian akhir dari alur kerja kami, dijelaskan seakurat mungkin.

Anda tidak memerlukan proxy jika: Anda mengakses feed atau API, volume akses Anda tidak terlalu besar, Anda melakukan crawling dari satu lokasi terhadap sumber yang tidak menerapkan batasan laju (rate-limit), atau Anda masih dalam tahap pengembangan dan pengujian. Hal ini mencakup sebagian besar agregator pada tahap awal.

Anda membutuhkannya jika: Anda melakukan crawling dalam skala yang cukup besar sehingga satu alamat IP terkena batasan kecepatan; kontennya berbeda-beda menurut wilayah dan Anda perlu mengakses beberapa wilayah; Anda menjalankan crawler terdistribusi dan ingin agar crawler tersebut terlihat seperti klien yang berbeda-beda, bukan satu mesin dengan beberapa thread; atau Anda memerlukan akurasi geografis untuk harga dan ketersediaan yang spesifik berdasarkan wilayah.

Jenis mana: pusat data untuk sebagian besar pengambilan data, karena harganya jauh lebih murah dan halaman daftar publik biasanya tidak memerlukan lebih dari itu. Layanan kami mulai dari $0,14/GB, ditagih berdasarkan lalu lintas, bukan per IP. Naikkan ke layanan perumahan — mulai dari $0,79/GB — hanya jika pusat data terbukti gagal atau jika Anda memerlukan geolokasi jaringan konsumen. Akun baru mendapatkan 1 TB lalu lintas perumahan gratis, yang cukup untuk menentukan apakah Anda benar-benar membutuhkannya. Angka-angka dari halaman harga kami, diperiksa pada September 2026.

Faktor biaya yang tidak pernah direncanakan: browser headless. Jika sumber Anda memerlukan rendering JavaScript, browser akan mengunduh setiap gambar, font, dan skrip, sehingga penggunaan bandwidth meningkat secara signifikan dibandingkan dengan HTTP biasa. Blokir jenis sumber daya yang tidak Anda butuhkan. Pada koneksi dengan kuota bandwidth, ini adalah faktor penghemat terbesar yang tersedia, dan kami telah membahas aspek ekonomi yang lebih luas dalam panduan harga proxy.

Dan batasannya yang sebenarnya: proxy memecahkan masalah distribusi. Proxy tidak memecahkan masalah ketentuan layanan, tidak memecahkan masalah hak atas basis data, dan tidak membuat sumber data ingin Anda berada di sana. Jika sebuah situs telah meminta Anda untuk tidak merayapinya, menambah alamat bukanlah jawaban atas hal itu; itu hanyalah cara untuk mengabaikannya dengan lebih efisien.

Mengapa Sebagian Besar Aggregator Gagal

Bukan karena alasan teknis.

Tidak ada nilai unik. Menggabungkan apa yang sudah dikumpulkan oleh orang lain hanya akan menghasilkan versi yang lebih buruk dari situs yang sudah ada. Nilai tersebut harus terletak pada cakupan yang tidak dimiliki orang lain, pengorganisasian yang tidak ditawarkan oleh pihak lain, atau ceruk pasar yang terlalu kecil bagi pemain lama.

Konten duplikat. Sudah dibahas di atas dan layak diulang. Ini adalah alasan utama pengguna pergi.

Data usang. Daftar yang tidak aktif menghancurkan kepercayaan lebih cepat daripada daftar yang hilang, karena daftar yang hilang tidak terlihat, sedangkan daftar yang tidak aktif hanya membuang-buang waktu pengguna.

Beban pemeliharaan yang melebihi nilainya. Dua puluh parser HTML yang ditulis tangan adalah pekerjaan paruh waktu yang tak berujung. Setiap sumber yang Anda tambahkan meningkatkan biaya tetap yang berkelanjutan. Pilihlah sumber yang memiliki feed; bersiaplah untuk menghapus sumber yang pemeliharaannya melebihi kontribusinya.

Masalah ayam dan telur. Aggregator membutuhkan cakupan untuk menarik pengguna, dan pengguna diperlukan untuk membenarkan cakupan tersebut. Solusinya adalah menjadi lengkap dalam bidang yang spesifik daripada sekadar sebagian dalam bidang yang luas.

Masalah hukum yang muncul terlambat. Perintah penghentian dan penarikan setelah Anda membangun bisnis berdasarkan satu sumber jauh lebih mahal daripada diskusi dengan mitra sebelum Anda memulai. Bicaralah dengan sumber-sumber terbesar Anda sejak dini; beberapa di antaranya akan senang dengan lalu lintas yang dihasilkan, dan yang tidak senang lebih baik diketahui sejak hari pertama.

Pertanyaan Lainnya

Apakah membangun situs web agregator itu sah secara hukum?

Hal itu tergantung pada apa yang Anda agregasikan, dari mana asalnya, dan bagaimana caranya. Fakta umumnya tidak dilindungi hak cipta, sedangkan ekspresi dilindungi, itulah sebabnya menyimpan data terstruktur dan menautkan ke sumbernya merupakan desain yang lebih aman. Di Uni Eropa, pengecualian penambangan teks dan data, hak yang dapat dibaca mesin, serta hak basis data terpisah semuanya berlaku. Mintalah saran untuk segala hal yang signifikan secara komersial.

Dari mana agregator mendapatkan datanya?

Berdasarkan urutan prioritas: API resmi, umpan mitra dan afiliasi, RSS dan Atom, peta situs, data terstruktur yang tertanam dalam halaman, dan baru kemudian penguraian HTML. Sumber yang paling sering terlewatkan adalah umpan mitra — banyak industri menerbitkan kumpulan data lengkap untuk agregator karena agregator mengarahkan lalu lintas ke mereka. Mintalah izin sebelum Anda membuat crawler.

Apakah saya memerlukan proxy untuk membangun agregator?

Awalnya tidak. Feed dan API tidak membutuhkannya, dan crawling dalam skala kecil dari satu lokasi biasanya juga tidak. Proxy menjadi diperlukan ketika volume memicu batasan laju (rate limit), ketika Anda perlu mengakses konten spesifik wilayah, atau ketika Anda menjalankan crawler terdistribusi. Bandwidth pusat data adalah pilihan default yang masuk akal; gunakan koneksi perumahan hanya jika benar-benar diperlukan.

Bagaimana agregator menangani daftar duplikat?

Pencocokan berlapis, prioritaskan yang paling murah: pengenal yang persis sama jika ada, kemudian kunci yang dinormalisasi yang dibangun dari bidang yang telah dibersihkan, kemudian kemiripan kabur dalam kelompok kandidat kasar, lalu tinjauan manusia untuk sisa yang ambigu. Pisahkan catatan sumber dan tautkan ke entitas kanonik, bukan dengan menggabungkannya secara destruktif.

Apa yang harus saya lakukan sesuai robots.txt?

Sejak RFC 9309, ini merupakan standar, bukan sekadar konvensi. Lakukan pencocokan berdasarkan spesifisitas, bukan urutan; perbarui berkas setidaknya setiap hari; anggap kesalahan server sebagai larangan penuh; anggap kode status 404 sebagai tanpa batasan; dan parsing setidaknya 500 KiB. Gunakan pustaka yang terawat daripada menulis parser sendiri.

Seberapa sering agregator harus memperbarui datanya?

Sesedikit mungkin sesuai dengan kebutuhan kasus penggunaan Anda, karena biaya sebanding dengan jumlah permintaan. Berita membutuhkan pembaruan setiap beberapa menit, lowongan kerja membutuhkan pembaruan setiap beberapa jam, dan acara membutuhkan pembaruan setiap beberapa hari. Kelompokkan sumber Anda berdasarkan volatilitas, gunakan peta situs lastmod dan permintaan bersyarat untuk melewati konten yang tidak berubah, serta miliki kebijakan eksplisit untuk mendeteksi daftar yang dihapus.

Bisakah saya mengumpulkan konten dari situs yang memblokir scraper?

Secara teknis mungkin bisa; namun, apakah sebaiknya Anda melakukannya adalah pertanyaan lain. Pemblokiran adalah pernyataan niat, dan mengelakinya tidak mengubah syarat, hak atas basis data, atau hubungan tersebut. Langkah yang lebih baik adalah menanyakan tentang feed — banyak situs yang memblokir crawler dengan senang hati menyediakan data mitra.

Apa bagian tersulit dalam membangun agregator?

Penghapusan duplikat dan keaktualan, dengan selisih yang sangat jauh. Pengambilan dan penguraian data adalah masalah yang sudah terpecahkan dengan adanya pustaka. Menentukan bahwa dua daftar dengan kata-kata yang berbeda adalah hal yang sama, dan menyadari ketika salah satunya diam-diam tidak ada lagi, adalah tempat di mana upaya teknik dan kepercayaan pengguna berada.

Kesimpulan

Keterampilan dalam membangun agregator terletak pada kemampuan mengenali masalah mana yang sesungguhnya. Mengambil konten bukanlah salah satunya — feed, API, peta situs, dan data terstruktur yang disematkan mencakup cakupan yang jauh lebih luas daripada yang diperkirakan orang, dan tim yang langsung mulai menulis parser HTML biasanya sedang memecahkan masalah yang sebenarnya sudah diselesaikan untuk mereka.

Masalah yang sesungguhnya ada di tahap selanjutnya. Deduplikasi menentukan apakah pengguna mempercayai data Anda. Deteksi penghapusan menentukan apakah mereka akan mempercayainya untuk kedua kalinya. Beban pemeliharaan menentukan apakah proyek ini bertahan saat berhadapan dengan dua puluh sumber yang mengubah markup mereka secara mandiri. Dan aspek hukum — hak cipta atas ekspresi, reservasi TDM yang dapat dibaca mesin, hak basis data UE, syarat dan ketentuan layanan — menentukan apakah keseluruhan proyek ini merupakan bisnis atau beban hukum.

Mulailah dari cakupan yang sempit dan selesaikan terlebih dahulu, daripada cakupan yang luas namun tidak tuntas. Prioritaskan sumber yang disahkan setiap kali memungkinkan, termasuk dengan meminta langsung kepada sumbernya, karena umpan dari mitra dapat menghilangkan seluruh kategori masalah sekaligus. Tambahkan infrastruktur — termasuk proxy — pada titik di mana Anda dapat menunjukkan batas yang telah Anda capai, bukan sebelumnya.