changedetection.io أداة مفتوحة المصدر لمراقبة تغييرات صفحات الويب وإرسال تنبيه عندما يتغير المحتوى الذي يهمك. بدل فتح صفحة سعر أووظائف أوRelease Notes كل يوم، تضيف عنوانها إلى الأداة، تحدد الجزء أوالشرط المطلوب مراقبته، ثم تترك changedetection.io يعيد الفحص دوريًا ويقارن النتيجة بالحالة السابقة.
يمكن تشغيل المشروع ذاتيًا Self-hosted على جهازك أوخادمك، بما في ذلك عبر Docker، كما توجد خدمة مستضافة يديرها فريق المشروع. ويشمل الاستخدام أكثر من مقارنة صفحات HTML؛ فالمشروع يدعم مراقبة JSON APIs وملفات PDF والأسعار وحالة توفر المنتجات، إضافة إلى Visual Selector وBrowser Steps للصفحات التي تحتاج متصفحًا حقيقيًا وتفاعلات قبل الوصول إلى المحتوى.
ما هو changedetection.io؟
changedetection.io هو نظام Website Change Detection يحتفظ بلقطات متعاقبة للمحتوى الذي تراقبه ثم يبحث عن الفرق بينها. عندما يظهر تغيير يطابق إعدادات Watch، يمكنه تسجيل الفرق وإرسال Notification عبر إحدى القنوات التي ضبطتها.
الفكرة مهمة خصوصًا عندما لا توفر الصفحة RSS أوAPI أوتنبيهات خاصة بها. من أمثلة ذلك:
- متابعة تغير سعر منتج أوعودته إلى المخزون.
- اكتشاف إضافة وظيفة جديدة إلى صفحة Careers.
- مراقبة صفحات الإعلانات والقرارات الحكومية.
- متابعة Security Advisories وRelease Notes.
- اكتشاف تغير حقل محدد داخل JSON API.
- متابعة التغييرات النصية في ملفات PDF.
- مراقبة عنصر محدد داخل صفحة كبيرة بدل الصفحة بأكملها.
حتى 25 أغسطس 2026، تعرض صفحة الإصدارات الرسمية الإصدار 0.55.8 كأحدث Stable Release ظاهر للمشروع.
كيف تعمل مراقبة التغييرات؟
دورة المراقبة الأساسية بسيطة:
- تنشئ Watch وتضيف URL.
- تحدد المدة بين عمليات إعادة الفحص.
- يطلب changedetection.io الصفحة أوالمورد.
- يستخرج المحتوى الذي اخترت مراقبته.
- يحفظ Snapshot للحالة.
- عند الفحص التالي يقارن المحتوى بالحالة السابقة.
- تُطبّق Filters وTriggers التي حددتها.
- إذا وُجد تغيير مهم، يسجله النظام ويرسل التنبيه وفق إعداداتك.
المهم هنا أن changedetection.io لا يعرف تلقائيًا دائمًا أي تغيير يهمك. إذا كانت الصفحة تحتوي على عناصر متغيرة باستمرار، فاختيار الجزء الصحيح أهم من زيادة عدد مرات الفحص.
لماذا لا يُفضل مراقبة HTML الصفحة كاملًا دائمًا؟
صفحات الويب الحديثة تحتوي كثيرًا على بيانات ديناميكية لا علاقة لها بالمعلومة التي تبحث عنها، مثل:
- الوقت والتاريخ.
- الإعلانات.
- عدادات المشاهدات.
- معرفات Session عشوائية.
- Recommendations.
- عناصر تتغير حسب المستخدم.
- محتوى يتم تحميله بصورة مختلفة في كل زيارة.
إذا قارنت كل ذلك في كل Check، فقد تحصل على عدد كبير من False Alerts. لذلك يدعم المشروع CSS Selectors وXPath وJSONPath وjq، إلى جانب فلاتر لاستبعاد النصوص أوالعناصر التي لا تريد إدخالها في المقارنة.
Self-hosted أم الخدمة المستضافة؟
| الخيار | Self-hosted | الخدمة المستضافة |
|---|---|---|
| إدارة الخادم | أنت المسؤول | يتولاها مزود الخدمة |
| التحديثات | تقوم بها بنفسك | مدارة لك |
| التحكم بالبيانات | أعلى، لأن البيانات تبقى في بيئتك | تعمل داخل البنية المستضافة |
| Docker | مناسب جدًا | غير مطلوب |
| إعداد Browser backend | قد تحتاج إلى تشغيله بنفسك | Chrome مضمن بحسب الخدمة الرسمية |
| الصيانة | تحتاج بعض المعرفة التقنية | أبسط للمستخدم النهائي |
إذا كنت تراقب قائمة حساسة من URLs أوتريد التحكم الكامل بالبيانات، يكون Self-hosting جذابًا. أما إذا كنت لا تريد إدارة Docker والمتصفح والتحديثات والنسخ الاحتياطية، فالنسخة المستضافة تقلل العبء التشغيلي.
تشغيل changedetection.io باستخدام Docker
يوفر المشروع صورة Docker رسمية، والطريقة المباشرة الحالية الواردة في مستودعه هي:
docker run -d --restart always -p "127.0.0.1:5000:5000" -v datastore-volume:/datastore --name changedetection.io dgtlmoon/changedetection.io
بعد تشغيل Container يمكنك فتح:
http://127.0.0.1:5000
لاحظ أن الأمر الحالي يستخدم:
127.0.0.1:5000:5000
بدل نشر المنفذ مباشرة على جميع Network Interfaces. هذا اختيار مهم أمنيًا: إذا كانت لوحة الإدارة لا تحتاج إلى أن تكون متاحة مباشرة للعالم، فالأفضل إبقاؤها مرتبطة بـlocalhost ثم وضع Reverse Proxy آمن أمامها عندما تحتاج إلى وصول خارجي.
يوفر المشروع أيضًا ملف docker-compose.yml رسميًا، وهو الخيار الأكثر ملاءمة عادةً عندما تريد إضافة Browser backend أوإدارة الإعدادات كجزء من Stack واحد.
أين يتم حفظ البيانات؟
في المثال السابق يُربط Volume باسم:
datastore-volume
بالمسار:
/datastore
هذه البيانات مهمة لأنها تتضمن إعدادات البرنامج وWatches والبيانات اللازمة لاستمرار المراقبة. حذف Container وحده لا يعني بالضرورة حذف Volume، لكن حذف مخزن البيانات نفسه يعني فقدان إعداداتك ما لم تكن لديك نسخة احتياطية.
أمّن لوحة changedetection.io قبل إتاحتها خارجيًا
وجود Self-hosting لا يعني أن التطبيق آمن تلقائيًا لمجرد تشغيله داخل Docker. إذا أردت الوصول إليه من الإنترنت، تعامل معه كأي لوحة إدارة أخرى.
- لا تعرض منفذ الإدارة مباشرة للعالم إذا لم تكن هناك حاجة.
- اضبط Password من إعدادات التطبيق؛ ويوثق المشروع ميزة Password Protection.
- استخدم HTTPS عند توفير وصول عن بعد.
- ضعه خلف Reverse Proxy مضبوط بصورة صحيحة عند الحاجة.
- حدّث صورة Docker بانتظام.
- عامل Notification URLs وAPI Keys وكلمات المرور كبيانات حساسة.
- احمِ النسخ الاحتياطية ومجلد
/datastore.
يمكنك كذلك مراجعة أفضل ممارسات الأمن السيبراني إذا كان الخادم الذي تستخدمه يستضيف أكثر من خدمة داخلية أوواجهة إدارة.
التحديث ليس خطوة اختيارية
هذا مهم بصورة خاصة مع changedetection.io لأن المشروع أصلح عدة مشكلات أمنية خلال 2026. على سبيل المثال، توثق NVD الثغرة CVE-2026-35490، وهي Authentication Bypass أثرت في الإصدارات الأقدم من 0.54.8 وأُصلحت في 0.54.8.
لذلك لا تأخذ Docker Compose قديمًا من شرح سابق ثم تتركه دون تحديث لسنوات.
عند استخدام Docker Compose، يوفر المشروع طريقة تحديث مباشرة:
docker compose pull && docker compose up -d
إنشاء أول Watch لمراقبة صفحة
بعد فتح Dashboard، السيناريو الأبسط هو إضافة URL لصفحة ثابتة نسبيًا ثم ترك changedetection.io يجلب أول Snapshot.
- أدخل URL الذي تريد مراقبته.
- أضفه إلى قائمة Watches.
- انتظر اكتمال أول Fetch.
- افتح إعدادات Watch.
- حدد Recheck Interval المناسب.
- اضبط Filters إذا كانت الصفحة تحتوي على أجزاء متغيرة لا تهمك.
- أضف Notification channel.
- اختبر التنبيه قبل الاعتماد عليه.
لا تجعل أول اختبار على صفحة معقدة تحتاج تسجيل دخول وJavaScript وCAPTCHA. ابدأ بصفحة عادية حتى تفهم دورة Watch وDiff وNotification، ثم انتقل إلى السيناريوهات الأكثر تعقيدًا.
استخدام Visual Selector لمراقبة عنصر محدد
Visual Selector مفيد عندما تعرف بصريًا ما تريد مراقبته لكنك لا تريد كتابة CSS Selector أوXPath يدويًا.
على سبيل المثال، صفحة منتج قد تحتوي على:
- اسم المنتج.
- السعر.
- التقييمات.
- المنتجات المقترحة.
- عدادات وحملات تسويقية.
إذا كان هدفك السعر فقط، فمن غير المنطقي مقارنة الصفحة كلها. باستخدام Visual Selector تختار العنصر الذي يعرض السعر، فيركز التغيير على ذلك الجزء بدل بقية الصفحة.
وفق وثائق المشروع، يحتاج Visual Selector في السيناريوهات المعتمدة على المتصفح إلى Playwright content fetcher. لذلك لا تتوقع أن تصبح كل إمكاناته متاحة في تثبيت Self-hosted بسيط يعتمد فقط على HTTP fetcher.
CSS وXPath أم Visual Selector؟
Visual Selector مناسب للبدء بسرعة، لكن CSS وXPath يظلان مهمين عندما تحتاج إلى إعداد دقيق أوقابل للنقل.
يمكنك استخدام الفلاتر من أجل:
- استخراج Element محدد.
- استبعاد Header أوFooter.
- إزالة إعلان يتغير باستمرار.
- تجاهل نصوص أوأنماط معروفة.
- استخدام Regular Expressions في السيناريوهات المناسبة.
الهدف ليس استخراج أكبر كمية من الصفحة، بل إنتاج أصغر تمثيل مستقر للمعلومة التي تريد مراقبتها. كلما كان المحتوى المستخرج أكثر تحديدًا، انخفضت احتمالات التنبيهات الكاذبة.
HTTP Fetch أم متصفح حقيقي؟
| الحالة | HTTP Fetch | Browser / Playwright |
|---|---|---|
| المحتوى موجود في HTML مباشرة | مناسب | غالبًا غير ضروري |
| المحتوى يحتاج JavaScript | قد لا يظهر | أفضل |
| الحاجة للنقر على زر | غير مناسب | مناسب |
| تسجيل الدخول | يعتمد على API والجلسة | Browser Steps أسهل في بعض الحالات |
| استهلاك الموارد | أقل | أعلى |
| Visual Selector | قدرات محدودة | مصمم للعمل مع Browser backend |
إذا كان النص الذي تبحث عنه موجودًا أصلًا في استجابة HTTP، لا تشغل Chrome لكل Watch بلا سبب. تشغيل Browser Processes لعدد كبير من الصفحات يزيد استهلاك RAM وCPU ويعقّد الإدارة.
ما هي Browser Steps؟
Browser Steps تسمح بتنفيذ سلسلة تفاعلات داخل الصفحة قبل استخراج المحتوى الذي ستتم مراقبته.
يمكن استخدامها مثلًا من أجل:
- النقر على Cookie consent.
- فتح قائمة مخفية.
- ملء حقل بحث.
- اختيار خيار من الصفحة.
- تسجيل الدخول إلى بوابة في الحالات المناسبة.
- الضغط على زر حتى يظهر المحتوى المطلوب.
بعد تنفيذ الخطوات يصل المتصفح إلى الحالة التي تريد مراقبتها، وبعدها يبدأ استخراج المحتوى وإجراء المقارنة.
تشير وثائق Browser Steps الرسمية إلى أن هذه الميزة تتطلب Playwright متصلًا. كما أن الخطوات تعاد عند كل عملية Check، ولذلك يجب أن تكون مستقرة وقابلة للتكرار.
Browser Steps في Self-hosting
في ملف Docker Compose الحالي للمشروع توجد إعدادات لاستخدام sockpuppetbrowser مع:
PLAYWRIGHT_DRIVER_URL=ws://browser-sockpuppet-chrome:3000
ويصف الملف هذا الخيار بأنه الموصى به حاليًا لجلب الصفحات باستخدام Chrome. أما Selenium/WebDriver القديم فما يزال ظاهرًا كخيار بديل في الملف لكنه موصوف هناك بأنه Deprecated وذو قيود، منها مشكلات في Screenshots وVisual Selector.
لذلك إذا كان هدفك Browser Steps وVisual Selector في تثبيت Self-hosted جديد، اتبع Docker Compose الحالي للمشروع بدل نسخ إعداد Playwright قديم من تدوينة عمرها سنوات.
مراقبة JSON APIs
إذا كانت الخدمة التي تراقبها توفر JSON API مستقرة، فمراقبة البيانات المنظمة قد تكون أفضل كثيرًا من Parsing صفحة HTML.
changedetection.io يدعم JSONPath وjq لاستخراج البيانات التي تريد مراقبتها.
لنفترض أن API يعيد شيئًا مثل:
{"product":"Router","price":79.99,"stock":"available"}
يمكنك تركيز المراقبة على قيمة price أوstock بدل مقارنة JSON كامل يحتوي على عشرات الحقول الأخرى.
يوضح المشروع أن jq مناسب بصورة خاصة للحالات التي تحتاج Filtering أوLogic أكثر تعقيدًا، بينما JSONPath مناسب لاختيار مسارات البيانات.
كما يوفر changedetection.io نفسه REST API موثقة لإدارة Watches وموارد أخرى برمجيًا، ما يسمح بإدماجه داخل Automation أكبر بدل إدارة كل Watch يدويًا من الواجهة.
مراقبة ملفات PDF
يدعم المشروع مراقبة PDF، بما في ذلك اكتشاف التغير في النص، كما يذكر المشروع إمكانية متابعة حجم الملف وChecksums.
هذا مفيد في حالات مثل:
- لوائح تنظيمية يتم تحديثها كملفات PDF.
- قوائم أسعار.
- مستندات سياسات.
- تقارير حكومية.
- نسخ جديدة من مستند تقني.
لكن من المهم فهم نوع PDF. إذا كان المستند يحتوي على طبقة نصية قابلة للاستخراج، يمكن مقارنة النص. أما PDF الذي يتكون أساسًا من صور ممسوحة ضوئيًا دون نص قابل للاستخراج فلن يقدم نفس جودة Text Diff دون مرحلة OCR منفصلة.
وفي الحالات التي لا يهمك فيها النص نفسه وإنما معرفة أن الملف تغير، يمكن أن تكون مراقبة الحجم أوChecksum أنسب.
مراقبة الأسعار وحالة توفر المنتجات
أحد الاستخدامات الأساسية للأداة هو Price وRestock Monitoring. يمكن للبرنامج تتبع بيانات المنتجات، وتوفر الواجهة خيارات مخصصة لمراقبة تغير السعر أوعودة منتج إلى المخزون عندما تكون بيانات الصفحة قابلة للاستخراج.
ولا يلزم أن يكون Trigger هو "أي تغيير في السعر". يمكن ضبط مراقبة أدق في السيناريوهات المدعومة، مثل الاهتمام بالتغيير عندما يصل السعر إلى نطاق معين بدل إرسال Alert مع كل تعديل صغير.
هذا أكثر فائدة من مراقبة HTML كامل لصفحة متجر، لأن صفحات التجارة الإلكترونية تحتوي عادةً على Recommendations وAds وStock messages وعناصر كثيرة تتغير بصورة مستقلة عن المنتج الأساسي.
الإشعارات في changedetection.io
يعتمد changedetection.io على مكتبة Apprise لدعم عدد كبير من Notification Services. من القنوات التي تظهر في وثائق المشروع:
- Email.
- Discord.
- Slack.
- Telegram.
- Microsoft Teams وOffice 365.
- Webhooks وHTTP endpoints.
- خدمات أخرى يدعمها Apprise.
يمكن إضافة أكثر من Notification URL حسب الحاجة، كما يمكن تخصيص عنوان ومحتوى التنبيه واستخدام Jinja2 templating في السيناريوهات المتقدمة.
لا تضف عشر قنوات لمجرد أن البرنامج يدعمها. اختر Channel تعرف أنك ستلاحظها فعليًا عندما يصل تغيير مهم.
واعتبر Notification URLs سرية، لأن بعضها قد يتضمن Tokens أوCredentials تسمح بالإرسال إلى حساباتك أوخدماتك.
كيف تقلل التنبيهات الكاذبة؟
نجاح نظام Change Detection لا يقاس بعدد التنبيهات، بل بمدى ارتباطها بما كنت تريد معرفته.
1. راقب الجزء المطلوب فقط
استخدم CSS أوXPath أوVisual Selector بدل مقارنة الصفحة كاملة.
2. استبعد العناصر المعروفة بالتغير
مثل الإعلانات والوقت وعدد المشاهدات والـRecommendations.
3. استخدم Ignore Text عند الحاجة
إذا كان جزء صغير من النص يتغير بصورة طبيعية ولا يهمك، استبعده بدل السماح له بإطلاق Alert دائم.
4. استخدم Trigger بدل التنبيه لكل Diff
في بعض السيناريوهات لا يهمك أن الصفحة تغيرت، بل ظهور كلمة معينة أوتحقق شرط معين.
5. استخدم API عندما تكون متاحة
إذا كانت الجهة تقدم API مستقرة ومسموحًا لك باستخدامها، فحقل JSON واحد عادةً أكثر استقرارًا من صفحة HTML مليئة بالعناصر الديناميكية.
6. لا تستخدم Browser Fetch دون حاجة
ابدأ بالـHTTP fetcher. انتقل إلى Browser backend عندما يثبت أن JavaScript أوInteraction مطلوب للوصول إلى المعلومة.
كم يجب أن يكون Recheck Interval؟
لا توجد مدة مثالية لكل المواقع. اختيار Frequency يعتمد على طبيعة المعلومة.
فحص صفحة Release Notes كل عدة ثوانٍ لا يقدم عادة قيمة إضافية، لكنه يزيد الحمل على خادمك وعلى الموقع المستهدف وقد يؤدي إلى Rate Limiting.
في المقابل، مراقبة توفر منتج محدود قد تتطلب Interval أقصر من صفحة سياسة حكومية تتغير مرة كل عدة أشهر.
اختر المدة وفق:
- سرعة تغير المعلومة.
- مدى أهمية وصول التنبيه بسرعة.
- موارد الخادم.
- عدد Watches.
- سياسة الموقع المستهدف وحدود الاستخدام.
يدعم changedetection.io كذلك جدولة عمليات الفحص حسب الوقت والمنطقة الزمنية، وهو مفيد عندما لا توجد فائدة من تشغيل Watch طوال اليوم.
مراقبة صفحات تحتاج تسجيل الدخول
Browser Steps تستطيع تقنيًا إدخال Username وPassword والنقر على عناصر تسجيل الدخول في السيناريوهات المدعومة، لكن هذا يضيف اعتبارات أمنية مهمة.
إذا أضفت Credentials إلى Watch:
- احمِ changedetection.io نفسه جيدًا.
- لا تمنح الحساب الذي تستخدمه صلاحيات أكبر من الحاجة.
- احمِ Volume والنسخ الاحتياطية.
- تجنب استخدام بيانات اعتماد حساب حساس إذا كانت هناك طريقة API أوToken محدود الصلاحيات.
- تذكر أن أي تغيير في صفحة تسجيل الدخول قد يكسر Browser Steps.
وجود إمكانية أتمتة Login لا يعني أنها أفضل حل لكل خدمة.
متى قد تفشل المراقبة؟
changedetection.io قوي، لكنه ليس وسيلة سحرية تجعل كل صفحة قابلة للمراقبة.
قد تظهر مشكلات مع:
- CAPTCHA.
- أنظمة Anti-bot.
- مواقع تغير DOM باستمرار.
- صفحات تحتاج جلسات معقدة.
- محتوى يعتمد على الموقع الجغرافي.
- صفحات تقدم نتائج مختلفة لكل مستخدم.
- APIs ذات Rate Limits منخفضة.
- Selectors تتغير بعد إعادة تصميم الموقع.
إذا توقف Watch عن العمل، لا تفترض مباشرة أن changedetection.io نفسه معطل. تحقق أولًا من HTTP Status، ومحتوى Fetch، والـSelector، وBrowser Steps، وأي تغييرات في الموقع المستهدف.
هل changedetection.io أداة Security Monitoring؟
يمكن استخدام الأداة لمتابعة Security Advisories أوRelease Notes أوحتى اكتشاف تغير غير متوقع في محتوى صفحة، لكن هذا لا يجعلها بديلًا عن SIEM أوIDS أوEDR أومنصة مراقبة بنية تحتية.
وظيفتها الأساسية هي Change Detection. يمكن إدخالها داخل Workflow أمني أكبر، لكن لا ينبغي الاعتماد عليها وحدها لمراقبة أنظمة المؤسسة أوكشف الاختراقات.
متى يكون changedetection.io خيارًا مناسبًا؟
الأداة مناسبة خصوصًا عندما:
- لا يوفر الموقع تنبيهًا أوRSS مناسبًا.
- تريد مراقبة Element محدد داخل الصفحة.
- تحتاج إلى Self-hosting.
- لديك عشرات أو مئات Watches تريد تجميعها في Dashboard واحدة.
- تحتاج JSONPath أوjq لمراقبة API.
- تحتاج Browser Steps للوصول إلى محتوى بعد Interaction.
- تريد إرسال التغييرات إلى Email أوChat أوWebhook.
- تريد الاحتفاظ بسجل Differences بدل معرفة أن الصفحة "تغيرت" فقط.
ومتى تكون أداة أخرى أوAPI أفضل؟
إذا كان المصدر يقدم API أوWebhook أوRSS موثوقًا يؤدي المهمة نفسها، فاستخدام المصدر الرسمي يكون غالبًا أبسط وأكثر استقرارًا من Scraping الصفحة.
كذلك إذا كان المطلوب قياس Uptime وLatency وSSL expiry وServer Metrics، فهذه وظيفة Monitoring مختلفة عن Website Content Change Detection، ومن الأفضل استخدام أداة مصممة لهذه المقاييس.
الخلاصة
changedetection.io يحول مهمة فتح الصفحات يدويًا والبحث عن اختلافات إلى Workflow آلي: يطلب الصفحة أوJSON أوPDF، يستخرج المحتوى المهم، يقارن الحالة السابقة بالحالية ثم يرسل Notification عندما يتحقق التغيير الذي حددته.
للسيناريوهات البسيطة يكفي HTTP fetcher مع Filter جيد. أما الصفحات التي تعتمد على JavaScript أوتحتاج النقر وتسجيل الدخول، فيمكن استخدام Playwright مع Visual Selector وBrowser Steps. ويمكن تشغيل المشروع ذاتيًا عبر Docker، لكن Self-hosting يعني أيضًا أنك المسؤول عن Password Protection وHTTPS والتحديثات والنسخ الاحتياطية وعدم تعريض واجهة الإدارة بلا حاجة.
ابدأ بـWatch بسيط، قلل المحتوى إلى العنصر الذي يهمك، واضبط Interval منطقيًا. بهذه الطريقة تصبح changedetection.io أداة تنبيه دقيقة بدل أن تتحول إلى مصدر جديد لمئات False Alerts.