Scanning Responsibly

Using Octopus Scanner

How to scan with permission, keep the load on a site low and handle the results with care, in plain words that match the Terms and Conditions.

Octopus Scanner runs a real browser against a real website. This guide explains what the Terms and Conditions ask of you and how to meet those terms with the settings in the app. If this page and the Terms ever seem to differ, the Terms apply.

1. Get permission first

Only scan websites you own or are authorised to test. The Terms ask you to confirm that you have the legal right and explicit permission to scan every URL or file you use, and to follow each site's terms of service, robots.txt rules and access restrictions. See User responsibilities and Prohibited uses.

  • Get it in writing for client work: Name the domains, any staging addresses and any signed-in areas you are allowed to test.
  • Check who owns each part of the site: A site you are allowed to test can include content from other providers, such as maps, video players, chat widgets or payment forms.
  • Decide what to do with embedded frames: Scan Iframes is on by default and scans content inside frames, including frames from other sites. If your permission covers only the main site, turn Scan Iframes off, or add the widget to Exclude CSS Selectors. Both are in Advanced Options, and Exclude CSS Selectors needs Show All Settings.

Before each scan, the Before you scan message lists any active settings that change how the scan interacts with the site and asks you to make sure you have permission. With the default settings it appears every time, unless you select Continue and don't show this again.

2. Keep the load low

The Terms note that scans can load target websites, and ask you to configure the app to avoid harm or disruption. Using the app to disrupt a system is a prohibited use. These settings, under Crawl Options, control how hard a scan works a server:

  • Crawl Delay: The pause, in milliseconds, between page loads. Default 0. A value such as 2000 is gentler on small or shared servers.
  • Enable Parallel Processing: Scans several pages at once in separate tabs. Off by default. Leave it off for sites you don't host yourself.
  • Concurrency: The number of pages scanned at once when Parallel Processing is on. Default 4. Lower it if the server struggles.
  • Max Crawl Size: The total number of pages in one report. Default 1,000. Set it to what you need, not the largest number allowed.
  • Exclude URL Patterns: Keeps the scanner away from addresses that contain the text you enter, such as search results, calendars or large archives.
  • Respect robots.txt: Follows the site's Allow and Disallow rules. On by default. The site's Crawl-delay rule is used only when your own Crawl Delay is 0, and is capped at 30 seconds. Keep it on unless the site owner has told you otherwise.

For large scans, scan outside the site's peak hours and tell the site owner or hosting team before you start.

3. Bot protection and Stealth Mode

Many sites treat automated browsers differently from people. Some block them or show a challenge page, so the scan tests the wrong page. Two settings in Advanced Options help the scan see the page a visitor sees:

  • Stealth Mode: Hides automation signals and presents the scan as an ordinary copy of Chrome on your computer, so scans are harder to single out. On by default.
  • Adaptive Networking: If a site starts blocking or slowing the scan, it increases the delay between pages, then restores speed once things settle. On by default. Not available with Parallel Processing.

Use these settings to get accurate results on sites you are permitted to test. They aren't permission to get around protections you aren't authorised to bypass. If a site's firewall or bot protection blocks the scan, ask the owner to allowlist it for the time of the scan, rather than trying harder to get through. The Troubleshooting Guide lists gentle settings to try once you have permission.

4. Signed-in areas and test data

A signed-in scan acts as the account you give it. The Terms ask you not to use interaction features such as Deep Scan on production environments where data could be changed. See User responsibilities.

  • Use a test account: Give it only the access the scan needs, on a staging copy of the site where you can.
  • Avoid production actions: Don't record purchases, deletions or messages in a User Journey unless that is what you mean to test, on a system where it is safe.
  • Know what Deep Scan avoids: Deep Scan never selects controls whose name suggests they would log out, delete, buy, pay or submit something, among others, and skips form submit and reset buttons. It reads names, not intentions, so a badly labelled button can still be pressed.
  • Exclude sign-out and destructive paths: Add addresses such as /logout, /delete or /admin/ to Exclude URL Patterns.

For how to set up a signed-in scan and protect the account, see Protect the account in the sign-in guide.

5. Handle reports with care

Reports can contain page content, HTML snippets, screenshots and addresses, including anything that was on screen in a signed-in area. You are the data controller for any personal data a scan captures, as Privacy and data handling explains.

  • Share only with people who should see it: Keep a client's report within that project.
  • Remove sensitive data before sharing: Check screenshots and snippets for names, email addresses and account details, and edit or remove them.
  • Treat User Journeys and bug data as sensitive: Recordings can capture what you typed, and an Export Bug Data file can include the URLs you scanned.

For what to check before you send a report, see Considerations when sharing reports. For how to edit a report and save a clean copy, see Opening, editing and sharing a report in Report Anatomy.

6. Be clear about what a scan shows

An automated scan finds a meaningful share of accessibility problems, but not all of them. Its results are information for a qualified person to interpret. They aren't a full audit, not legal advice and not a certificate of compliance with any law or standard. See User responsibilities.

When you share results, say what was scanned, when and with which settings. Don't describe a site with no reported issues as accessible. For what automated testing can and can't establish, see Scope of Automated Testing.

7. If a site owner asks you to stop

Stop straight away. Select Cancel Scan, which stops all background browser processes and cleans up temporary scan data. Don't restart the scan with different settings to avoid detection.

Respect the owner's request, even if you believe you had permission. Talk to them, agree what you may scan and when, and get that agreement in writing before you scan again.

Was this page helpful? Email your feedback.