How Screpy measures website signals

Screpy helps you investigate website health and search visibility. Its results are evidence for a decision, not a guarantee of search rankings, traffic, conversions, or availability in every location. Always read a result with its URL, configured scope, and collection time.

Website audit

A website audit starts with a Screpy crawl. Pages, links, images, on-page findings, and Quick Wins describe what the crawler could reach and analyze during that completed crawl.

What the data can tell you

• Which crawlable URLs and resources were available within the configured crawl scope.
• Which technical or on-page findings deserve investigation.
• How two completed crawl snapshots differ when their scope is comparable.

What it cannot tell you alone

• Whether every URL on a site is indexed or eligible to rank.
• Whether a blocked, private, or out-of-scope URL is healthy.
• Why a search engine ranked a page in a particular position.

Treat a crawl as a point-in-time snapshot. Robots rules, redirects, authentication, server responses, and crawl limits affect what can be included. For the underlying crawler-access standard, consult Google's robots.txt guide.

Core Web Vitals

Core Web Vitals data in Screpy is lab-based and should be read per URL and date. It is most useful for finding a repeated page or template pattern, then validating a focused change with a new measurement.

Use it for

• Prioritizing user-facing performance work on important pages.
• Separating likely loading, responsiveness, and layout-stability issues.
• Comparing the same URL before and after a documented change.

Do not use it as

• Field data representing every visitor's experience.
• Proof that a single deployment caused one isolated result.
• A standalone prediction of search performance.

Google defines the industry metrics and their user-experience thresholds in its Core Web Vitals documentation. Screpy results provide the page and time context needed for investigation; your template, delivery setup, cache state, and third-party code still need to be checked directly.

Uptime

Uptime monitoring asks whether a configured public URL is reachable over time. It is an availability signal, not a full synthetic user journey or a guarantee that every visitor, region, browser, or authenticated workflow can reach the service.

Review the target URL, response behavior, check time, and surrounding deployment or DNS changes. Repeated or sustained failures are stronger incident evidence than a single failed check. A redirect is not automatically downtime if it reliably reaches the intended public destination without a loop or error.

Search visibility

Rank tracking compares selected keywords within the configured context over time. Location, language, device, personalization, search features, and time can all affect a search result.

Use rank movement to decide what to investigate, then compare it with the landing page, Search Console data, crawl findings, and relevant site changes. It does not explain a ranking change by itself or represent every keyword variation your audience may search.

Google's ranking systems guide explains why no single metric can describe how a page ranks.

Data freshness and corrections

The date in a guide indicates when its content was last updated. A Last reviewed label appears on pages the documentation team has explicitly checked for product accuracy. If a result seems inconsistent with current product behavior, treat the product interface and API response as the immediate source of truth and report the discrepancy through Screpy support.