Site settings

1. 1

   Open Settings in the sidebar

   Open the site, then choose Settings under Manage. It opens on the Checks tab.

2. 2

   Pick a tab

   The tabs are Checks, Ignored issues, Crawl, Schedule, Alerts, Search Console, SDK & CI/CD, Members, History and Danger zone. The tab is saved in the address, so you can bookmark it or send it to a colleague.

   On a narrow screen the tabs become a Settings category menu. Don't see SDK & CI/CD? Only workspace admins see it.

app.pixyscan.com/w/…/s/…/settings

Each scheduled scan is compared with the one before it, and Changes then shows what is new, what was fixed and what is still open.

1. 1

   Open the Schedule tab and press New schedule

   You can also open the menu beside Scan now and choose Schedule scans.

2. 2

   Choose how often, and when

   Give the schedule a name, then complete the sentence: every day, every week on a weekday, or every month on a date from the 1st to the 28th, at a time you pick. The time uses your browser's timezone, which is shown beside the first run date.

3. 3

   Press Create schedule

   The schedule appears as a card with its next and last run. You can pause, edit or delete it there, and deleting it keeps the scans that already ran.

How often should I scan? As often as the site changes. Publish every day? Scan daily. Rarely change it? Monthly is enough.

What if PixyScan was down? Missed runs are run once when service returns, however many were missed.

1. 1

   Choose the email switches

   Email when a scan finishes or fails, and Email when the score drops or a new Critical issue appears, are both on by default. They apply to the whole site, and they also decide which events go to Slack and the webhook.

   The third, Email when search clicks drop after a deploy, is also on by default. It controls the email only: the alert still shows in the app, and Slack and the webhook get it whenever their URLs are set. It needs Search Console connected and a plan that includes Search impact, and it is decided about a week after the deploy. See Search impact for when it fires.

2. 2

   Paste a webhook URL to add a channel

   Slack webhook URL takes a Slack incoming webhook, and Generic webhook URL takes any address that accepts JSON. Both must start with https://, and an empty box turns that channel off.

3. 3

   Press Save notifications

   The new settings apply to the next scan.

Emails go to this site's members and to workspace admins. Each email has a one-click unsubscribe link, which stops alert emails for that one person without changing the settings for anyone else. The alert list itself is on Site alerts.

1. 1

   Create the client secret

   Press Create the secret. It starts with sk_live_ and is shown only once, so save it straight away in your CI provider's secrets. Regenerating it replaces the old one, so any pipeline still using the old secret stops working.

2. 2

   Match your branches to URLs

   Under Which URL each branch scans, press Add environment and enter a name, a branch (or a pattern such as release/*) and the URL to scan. This makes a scan from a preview branch check the preview site, not your live site. A branch with no matching environment is refused.

3. 3

   Add the command after your deploy step

   The SDK scans a live URL, so the site must be deployed before the command runs.

4. 4

   Set the score gate to today's score

   Do not leave it at the default of 97. The warning below explains why.

app.pixyscan.com/w/…/s/…/settings?tab=sdk

- name: PixyScan gate
  run: npx pixyscan-sdk run --client-secret "$PIXYSCAN_SECRET"
  env:
    PIXYSCAN_SECRET: ${{ secrets.PIXYSCAN_SECRET }}

The branch is detected automatically on GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines and Vercel. Under Checks that fail the build you can also list specific checks that fail the build whenever they are found, whatever the score, with pages exempted per check. Leave that list empty to gate on the score alone.

From version 1.2.0 the command also sends the commit each scan ran for. It is read on its own on GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Vercel and Netlify, with a link to the commit where the CI gives one, so there is nothing to set up. A tag build is also labelled with its tag, such as v2.4.0. Nothing else is ever used as a release label. With Search Console connected, each deploy of your production branch is marked on the site's clicks trend with its commit, and a sharp drop in clicks in the 3 days after it sends an alert. If you pin the SDK in package.json, use 1.2.0 or later.

To set the values yourself, pass --commit <sha>, --commit-url <url> or --release <label>. On a GitHub pull_request run, GITHUB_SHA is a merge commit GitHub made, so pass --commit "${{ github.event.pull_request.head.sha }}" to record the pull request's own commit. --no-commit stops the command reading the commit from your CI. A commit value PixyScan cannot use is left out and the scan runs as normal. Only a malformed value you typed as a flag stops the command, with exit code 2.

seo-gate:
  image: node:20
  script:
    - npx pixyscan-sdk run --client-secret "$PIXYSCAN_SECRET"

Changing a crawl setting does not change the scan already on screen. Until you scan again, the site's screens show a notice saying your settings have changed since this scan, with a Rescan button and a link to review the settings. The History tab records what changed, who changed it and when.

app.pixyscan.com/w/…/s/…/settings?tab=history