ScrepyDocs

Screpy project and crawler settings

Configure project identity, crawl limits, JavaScript rendering, concurrency, delay, search tracking, uptime, and website analysis access.

Project settings control future website analyses and monitoring. Change settings to solve a specific coverage, rendering, or server-capacity need, then verify the effect in a new completed crawl.

Keep Screpy allowed after infrastructure changes

Firewall, CDN, hosting, or security-plugin changes can block a previously working project. Keep 5.75.247.29 allowed and keep ScrepyBot permitted in robots.txt.

Check the project identity first

Confirm the project name, domain, primary country, language, and reporting timezone. A project should represent one public website or root domain. Do not create separate projects for individual paths unless they are genuinely separate sites.

If the website permanently moves to another hostname, consider how that change affects historical comparisons before editing or replacing the project.

Adjust crawl scope deliberately

The Crawler section controls how Screpy discovers and requests pages.

SettingWhat it controlsIncrease or enable whenReduce or disable when
Max URLsMaximum URLs stored in a crawl.A successful crawl reaches the cap before important sections.You need a smaller focused crawl or plan capacity is limited.
DepthLink levels followed from the starting page.Important pages are linked beyond the current depth.URL paths expand without adding useful pages.
JavaScriptBrowser rendering for client-side content.Important content or navigation is absent from initial HTML.Static HTML already contains the content and faster crawling is preferred.
ConcurrencyRequests that may run at the same time.The server handles parallel requests reliably.Logs show 429, temporary blocks, or load-related failures.
DelayWaiting time between requests.The host requires a slower request rate.The server safely supports faster crawling.

Settings affect the next analysis

Completed crawl data does not change when settings are saved. Keep the old crawl as a baseline, run a new analysis, and compare completed results.

Configure rate limits safely

The preferred solution is to exclude 5.75.247.29 from website rate-limit rules. If an exclusion is not possible:

  1. Lower Concurrency.
  2. Add a Delay.
  3. Save the settings.
  4. Start one new analysis.
  5. Monitor firewall and origin logs for 429, 403, timeout, or load errors.

Avoid changing Max URLs, Depth, JavaScript, Concurrency, and Delay at the same time. One change at a time makes the result understandable.

Configure search tracking

Set the refresh frequency for supported search-tracking features and confirm the project's country and language. Search settings do not control website crawling; diagnose crawling through access and crawler settings instead.

Configure availability alerts

Choose whether uptime monitoring is enabled and where notifications should be sent. Uptime checks and full website crawls are different workflows: an available homepage does not prove that every page is crawlable.

Troubleshoot unexpected crawl results

Delete a project with care

Deleting a project removes it from normal workspace use. Confirm the exact project and retain any reports or records your team needs before deletion. If your only goal is to fix a crawl, keep the project history and resolve the underlying access or configuration issue instead.

On this page