` — optimize it for feed clicks | | **og:description** | \~150–200 chars | Can be more promotional than the meta description | ## Live preview [#live-preview] Below the checks, the panel renders a **Facebook preview** and a **Twitter preview** from the page's actual tags. Cropping, a missing image, or a truncated title show up as they will in a real feed, not as a list of values. <Screenshot src="/screenshots/extension/extension_fbpreview.webp" alt="The Social panel's AI Social Audit showing required-tags and image-optimization checks passing, above a rendered Facebook preview card built from the page's actual Open Graph tags" caption="The Facebook card renders from live tags, so a crop or missing image is visible as it will appear in-feed — not as a list of values to interpret." width="2582" height="1636" /> <RelatedDocs hrefs="['/docs/chrome-extension/audit-categories/metadata', '/docs/chrome-extension/audit-categories/schema', '/docs/chrome-extension/audit-categories/videos']" /> --- # Videos URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/videos/ The Videos panel detects embedded and hosted video, validates VideoObject schema, and separates real content from decorative background video. The Videos panel finds every video on the page, both embedded players and hosted files. It then checks whether each is set up to earn video rich results. A video with valid VideoObject markup can win a thumbnail in search and appear in the Google video tab. Without it, the same video is invisible to search. This panel shows which videos are eligible and what's missing on the ones that aren't. ## Overview [#overview] The panel opens with a **Videos Overview**: scorecards that summarize how the page's videos are set up before you drill into individual ones. * **Schema markup**: how many videos carry valid VideoObject markup * **Thumbnails**: how many declare a poster image * **Dimensions**: how many declare an explicit width and height * **UX quality**: playback behavior such as autoplay-with-sound, scored as an overall signal ## Filtering and export [#filtering-and-export] Filter tabs, each with a count, narrow the list. **Export CSV** includes the platform, background flag, dimensions, duration, format, poster, and playback attributes. * **All** — every video on the page * **HTML** — native HTML5 `<video>` elements * **Iframe** — embedded players (YouTube, Vimeo, and others) * **Issues** — only videos with a detected problem ## Per-video detail [#per-video-detail] Each video card shows how it is embedded and configured. * **Source type** — HTML5 video or an iframe embed * **Platform** — YouTube, Vimeo, Wistia, and others, plus self-hosted * **Poster**, **duration**, and playback attributes (autoplay, muted, loop). An autoplay video without muted is flagged as poor UX, since browsers block it and users find it jarring * **VideoObject schema** validity for rich-result eligibility. This is the check that decides whether the video can appear as a rich result at all * The specific issues found <Callout type="info"> Decorative background videos are marked with a **Background Video** badge and excluded from issue counts, so a hero-video loop doesn't generate false warnings. </Callout> <Screenshot src="/screenshots/extension/extension_vedios.webp" alt="The Videos panel's AI Video Audit showing a Videos Overview with schema-markup, thumbnails, dimensions, and UX-quality scores, above a video card flagged with a Video Facade pattern and a warning to add VideoObject schema" caption="Schema markup scores 0/3 here while thumbnails pass — the facade-pattern video is rendered but invisible to search without VideoObject markup." width="2580" height="1542" /> <RelatedDocs hrefs="['/docs/chrome-extension/audit-categories/images', '/docs/chrome-extension/audit-categories/schema', '/docs/chrome-extension/audit-categories/social']" /> --- # Brand report URL: https://docs.digispot.ai/docs/cloud/audits/brand/ The Brand report scores how consistently a site presents its brand across titles, descriptions, schema, and icons. The Brand report scores how consistently a site presents its brand across every page. These are the signals that build recognition in search results. They also feed the trust and authority that influence rankings. A site that names itself the same way in every title, description, and schema block reads as one coherent entity to search engines. An inconsistent one dilutes that signal. ## Score and bands [#score-and-bands] The report opens with a **brand score** and its distribution across pages, graded on consistency and authority signals: | Band | Score | | ------------- | ------ | | **Excellent** | 90–100 | | **Good** | 70–89 | | **Critical** | \< 70 | ## What it scores [#what-it-scores] The score splits into two groups. One covers how the brand appears to users. The other covers how it is declared to machines. * **Brand implementation** — the signals a searcher and a SERP see. **Title match** is how often the brand name appears in page titles, as a similarity percentage. **Description match** is the same for meta descriptions. **Brand icons** covers favicon and icon coverage. * **Technical implementation** — the structured-data signals that let search engines connect pages to a single brand entity. This covers **schema coverage**, the count of **schema pages**, and overall **schema markup**. <Tip> A low **title match** score usually points to templated titles that drop the brand name on deep pages. Appending the brand to every page title is a fast, site-wide fix that lifts recognition in the SERP. </Tip> A per-page detail view breaks brand presence and assets down for a single URL. An AI **Brand analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_brandinsights.webp" alt="Cloud Brand report with title, description, and schema consistency" caption="Brand consistency scored across titles, descriptions, and schema." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/audits/content', '/docs/cloud/audits/media', '/docs/cloud/audits/local-seo']" /> --- # Content report URL: https://docs.digispot.ai/docs/cloud/audits/content/ The Content report scores content quality and E-E-A-T, with keyword, schema, and URL analysis. The Content report scores the writing on each page and the signals that make it trustworthy to both readers and search engines. It is where thin or off-topic pages surface. The structured-data and URL work that supports ranking gets graded here alongside the prose itself. ## Scores and panels [#scores-and-panels] The report opens with a content score, a quality overview, and a score distribution, then breaks the grade into four sub-scores so a weak area is easy to isolate. | Sub-score | What it measures | | ----------------- | -------------------------------------------------------------------------------------------- | | **Content score** | Overall quality from readability, structure, and on-page SEO best practices | | **EEAT score** | How well the page demonstrates Experience, Expertise, Authoritativeness, and Trustworthiness | | **Schema score** | Structured-data coverage and validity | | **URL score** | URL structure, length, and readability | Below the scores, the analysis panels expose the underlying signals: * **Content structure** — headings, word count, and the shape of the page * **Keyword frequency** and **density** — the top terms and how heavily each is used, so keyword stuffing or a missing primary term is visible * **Digit distribution** and **URL length** — supporting URL-readability signals * **Schema quality** — valid schemas separated from those carrying errors or warnings <Screenshot src="/screenshots/cloud/content_analysis.webp" alt="Cloud Content report with content score, sub-scores, and analysis panels" caption="The content report — sub-scores over readability, schema, and URL signals." width="3420" height="1890" /> ## Common issues [#common-issues] The report labels recurring problems in plain terms so they can be triaged directly: **low word count**, **non-optimal title or meta length**, **heading structure**, **URL readability**, **trailing slashes**, and **stop words** in the URL. <Tip> Read the EEAT breakdown before rewriting for keywords. On pages where Google weighs trust heavily — health, finance, legal — a strong EEAT signal (named authors, citations, credentials) moves rankings more than another pass over keyword density. </Tip> ## Page detail [#page-detail] A per-page detail view breaks the score into content, schema, and URL analysis for a single URL. It adds keyword and heading visualizations and an AI summary that turns the findings into edits to make. <Screenshot src="/screenshots/cloud/content_schemamarkup.webp" alt="Cloud Content report schema markup analysis for a page" caption="Schema analysis — valid structured data separated from errors and warnings." width="3420" height="1890" /> <Screenshot src="/screenshots/cloud/content_urlreadablity.webp" alt="Cloud Content report URL readability analysis for a page" caption="URL analysis — length, structure, and readability signals." width="3420" height="1892" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-to-analyze-competitor-seo", title: "Competitor SEO analysis: winning strategies" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/audits/crawlability', '/docs/cloud/content-opportunities']" /> --- # Crawlability report URL: https://docs.digispot.ai/docs/cloud/audits/crawlability/ The Crawlability report checks canonical URLs, meta robots, and whether AI crawlers see the same page Googlebot does. The Crawlability report answers a single question in three parts. Can search engines and AI crawlers reach and index a page? And do they all see the same thing when they do? It is the first report to check when a page has good content but no visibility, because a wrong canonical or a stray `noindex` suppresses everything downstream of it. ## Score and bands [#score-and-bands] The report opens with a crawlability score and its distribution across pages. The per-page gauge reads the score into a plain label: | Band | Score | | --------------------- | ------ | | **Excellent** | 85–100 | | **Good** | 70–84 | | **Needs improvement** | 50–69 | | **Critical** | 0–49 | ## What it checks [#what-it-checks] The report splits into three tabs, each isolating one crawl signal. ### Canonical URL [#canonical-url] Whether each page's canonical is **self-referencing** (the healthy default), **cross-domain**, or **non-matching**. It also flags **redirect chains** and whether the canonical target returns **HTTP 200**. A canonical pointing at a redirect or a 404 quietly drops the page from the index. <Screenshot src="/screenshots/cloud/crawlablity_canonical.webp" alt="Cloud Crawlability report Canonical URL tab with self-referencing and redirect status" caption="The Canonical tab — self-referencing, cross-domain, and redirect-chain status." width="3420" height="1890" /> ### Meta robots [#meta-robots] The indexing and following directives declared per page (`index`/`noindex`, `follow`/`nofollow`), so an unintended `noindex` is caught before it costs rankings. <Screenshot src="/screenshots/cloud/crawlablity_metarobots.webp" alt="Cloud Crawlability report Meta robots tab with index and follow directives" caption="The Meta robots tab — indexing and following directives per page." width="3420" height="1892" /> ### LLM vs Googlebot [#llm-vs-googlebot] A crawler-consistency score comparing what an AI crawler renders against what Googlebot sees. It reports **content-length variance**, **navigation and schema consistency**, and any schema present on one side but missing from the other. Divergence here means JavaScript-dependent content that AI answer engines never receive. <Screenshot src="/screenshots/cloud/crawlablity_llmsvsgoogle.webp" alt="Cloud Crawlability report LLM vs Googlebot tab comparing AI-crawler and Googlebot rendering" caption="The LLM vs Googlebot tab — what AI crawlers see versus Googlebot." width="3420" height="1894" /> <Callout type="info"> The **LLM vs Googlebot** tab is increasingly load-bearing. A page that renders fully for Googlebot but ships a thin or schema-stripped version to AI crawlers can rank in Google yet be invisible in ChatGPT, Perplexity, and Gemini answers. </Callout> Each tab carries an understanding guide that covers what it is, what's checked, why it matters, and how to improve. Each also carries an AI insight that reads the findings back as next steps. <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-google-search-works-basics", title: "How Google Search works: crawling, indexing, and ranking" }, { href: "https://digispot.ai/blog/what-is-canonical-url", title: "Canonical URLs for SEO: complete implementation guide" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/site', '/docs/cloud/audits/content', '/docs/cloud/audits/tech']" /> --- # Audits & reports URL: https://docs.digispot.ai/docs/cloud/audits/ Configure crawls, run them at scale on Digispot's servers, and read the results across report categories — one screen per area of SEO. In the cloud, audits run on Digispot's servers rather than your machine. Long crawls don't tie up a laptop, and your whole team sees the same results. ## Audit configurations [#audit-configurations] An **audit configuration** is a reusable crawl setup for a project. You control: * **Configuration name** and **device type** * **Crawl mode** and **page crawl limit** * **Sitemap limit** and **exclude paths** * Optional modules — **Backlinks**, **Local SEO**, **Internationalization**, and **Content opportunities** <Screenshot src="/screenshots/cloud/edit_configuration.webp" alt="Cloud audit configuration screen with crawl mode, budget, device, and optional-module toggles" caption="An audit configuration — a reusable crawl setup for a project." width="3420" height="1886" /> ## Audit runs [#audit-runs] Start a **run** from a configuration. Runs are listed with a status — Queued, Running, Completed, or Failed — alongside their run steps. When a run completes, its results open as a graded dashboard with category score cards and a severity-ranked issue list. ## Report categories [#report-categories] Once a run completes, the results are split into report screens, one per area of SEO. Each has a list view. Most have a per-page detail view, and each offers an AI **"Summarize with AI"** insight. <SectionCards hrefs="[ '/docs/cloud/audits/issues', '/docs/cloud/audits/site', '/docs/cloud/audits/pages', '/docs/cloud/audits/crawlability', '/docs/cloud/audits/content', '/docs/cloud/audits/performance', '/docs/cloud/audits/links', '/docs/cloud/audits/tech', '/docs/cloud/audits/media', '/docs/cloud/audits/brand', '/docs/cloud/audits/local-seo', '/docs/cloud/audits/international-seo', ]" /> <Callout type="info"> Report screens unlock once an audit run has completed. Some also require their module to be enabled in the audit configuration: Local SEO, International SEO, and Backlinks. </Callout> <RelatedDocs hrefs="['/docs/cloud/dashboard', '/docs/cloud/content-opportunities', '/docs/cloud/google-insights']" /> --- # International SEO report URL: https://docs.digispot.ai/docs/cloud/audits/international-seo/ The International SEO report scores hreflang setup and language and region coverage across the site. The International SEO report scores how well a site serves multiple languages and regions. Its core concern is hreflang. That markup tells Google which language and region each page targets, so the right version reaches the right searcher. It also avoids duplicate-content penalties across translations. The report appears once Internationalization is enabled in the audit configuration. ## Score and hreflang [#score-and-hreflang] The report opens with an **International SEO score** and its distribution across pages, driven largely by hreflang implementation. * **Hreflang statistics** — the count of hreflang tags and alternate language pages detected, and whether an **x-default** is declared to catch unmatched locales * **Implementation method** — how hreflang is delivered (HTML tags, HTTP headers, or sitemap), and whether a **language switcher** is present ## Languages and regions [#languages-and-regions] Beyond hreflang, the report reads what the pages actually declare and target. * **Languages** — the primary and content language detected, and whether the site is **multilingual** or single-language * **Regional distribution** — whether the site is **multi-regional** or single-region, and whether geo-targeting is present * **Multilingual and regional features** — the supporting signals that back a correct international setup <Callout type="info"> This report requires the Internationalization module to be enabled in the [audit configuration](/docs/cloud/audits/). Without it, the report stays locked even after an audit run completes. </Callout> <Tip> Hreflang has to be reciprocal: if page A points to page B as its French alternate, B must point back to A. Missing return tags are the most common hreflang error, and they void the whole relationship — check both directions when the score drops. </Tip> A per-page detail view breaks hreflang and language analysis down for a single URL. An AI **International SEO analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_internationalseo.webp" alt="Cloud International SEO report with hreflang statistics and language coverage" caption="Hreflang coverage and language/region distribution across the site." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/react-seo-optimization-guide", title: "React SEO: the complete guide (includes hreflang)" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/local-seo', '/docs/cloud/audits/crawlability', '/docs/cloud/audits/pages']" /> --- # Issues report URL: https://docs.digispot.ai/docs/cloud/audits/issues/ The Issues report aggregates every finding across the audit, grouped by severity and prioritized into quick wins, easy fixes, and critical work. The Issues report is the fix-first queue for the whole audit. Every other report scores a single dimension. This one collapses all of them into one list, grouped by the problem itself rather than by page. The affected URLs sit behind each issue. It is the fastest way to answer "what should be fixed next" without opening each report in turn. ## Prioritization [#prioritization] The same findings are cut two ways so the queue can be read by urgency or by return on effort. Severity ranks how much an issue can hurt rankings. The priority tabs weigh that severity against how hard the fix is. | Severity | What it means | | ------------ | -------------------------------------------------------------- | | **Critical** | Severe problems that can suppress indexing or ranking outright | | **High** | Significant issues with a clear impact on visibility | | **Medium** | Worth fixing, but not urgent | | **Low** | Minor or cosmetic findings | The smart-prioritization tabs re-sort those same issues by payoff: * **Quick wins** — high impact for low effort, the first place to spend time * **Easy fixes** — low-effort changes with an immediate benefit * **Opportunities** — strategic improvements for the longer term * **Critical issues** — severe problems that need attention regardless of effort <Tip> Work the **Quick wins** tab before the severity buckets. A Critical issue that needs an engineering sprint moves the score no faster than several quick wins shipped the same afternoon. </Tip> ## Filters and table [#filters-and-table] The all-issues table lists each issue type with the signals needed to triage it. The filter bar narrows the list to a single owner or fix type. * **Filters** — **category**, **severity**, **priority**, **team**, and **effort**, so a developer can pull only their queue or an SEO can isolate the highest-impact work * **Columns** — each row shows the issue's **category**, the responsible **team**, its **severity** (Critical / High / Medium / Low), its **effort** (High / Medium / Low), and the total **occurrences** across the site * **Priority pages** — a widget that surfaces the URLs carrying the most issues, so a single high-leverage page can be fixed once instead of chasing the same issue across many pages Effort and severity are independent: a Low-effort issue can still be Critical (a stray `noindex`), and a High-effort issue can be Low severity. The priority tabs exist to combine the two into a single ranked order. ## AI explanation [#ai-explanation] Each row carries an AI explanation that turns a flagged issue into a concrete action: **what it is**, **how to fix it**, and how to **confirm it's fixed** once the change ships. Read the confirmation step before deploying, so the follow-up audit checks the right signal. <Screenshot src="/screenshots/cloud/cloud_issues.webp" alt="Cloud Issues report grouping findings by severity with priority tabs" caption="Findings roll up by issue type, with quick-win and critical tabs." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/dashboard', '/docs/cloud/audits/site']" /> --- # Links report URL: https://docs.digispot.ai/docs/cloud/audits/links/ The Links report scores link health, breaks down internal, external, and social links, and flags broken and redirected links. The Links report scores the site's link health and surfaces the pages carrying the most broken or low-quality links. Internal links spread ranking authority and tell search engines how pages relate; broken and redirected links leak that authority and frustrate users. This report separates the working structure from the leaks. ## Score and bands [#score-and-bands] The report opens with a link score and its distribution across pages. The score reads into three bands: | Band | Score | What it signals | | ------------- | ------ | ---------------------------------------------------------------- | | **Excellent** | 90–100 | Strong structure, no broken links, complete social presence | | **Good** | 70–89 | Solid structure with few broken links | | **Critical** | \< 70 | Many broken links, missing social links, unbalanced distribution | The **score distribution** groups pages into **High quality (70–100%)**, **Needs improvement (40–69%)**, and **Critical (0–39%)** so the spread across the site is visible at a glance. ## Status, distribution, and coverage [#status-distribution-and-coverage] The report breaks link health into the signals that make up the score. * **Link status** — links classed as **working**, **broken**, or **redirected**; broken links waste authority and hurt users, and long redirect chains slow both crawlers and visitors * **Link distribution** — the split of **internal**, **external**, and **social** links, so an over-reliance on external links or a shortage of internal ones stands out * **Social media coverage** — which pages carry social links and which are missing them, a supporting distribution and discovery signal * **Leaderboards** — pages with the **most broken links**, high performers, and pages that need attention <Tip> Fix broken **internal** links before external ones. An internal 404 wastes authority you already own and sends crawlers into dead ends; an external broken link is worth cleaning up but doesn't drain your own link equity the same way. </Tip> A per-page detail view breaks the link analysis down for a single URL. An AI insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_linkinsights.webp" alt="Cloud Links report with link health, status, and distribution" caption="Link health, broken links, and internal/external distribution." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/backlink-analysis-a-step-by-step-guide-to-auditing-link-profiles", title: "How to find and analyze backlinks" }, { href: "https://digispot.ai/blog/best-off-page-seo-strategies", title: "Off-page SEO strategies: build authority and links" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/research', '/docs/cloud/audits/crawlability']" /> --- # Local SEO report URL: https://docs.digispot.ai/docs/cloud/audits/local-seo/ The Local SEO report scores local signals — business schema, local keywords, phone, embedded map, and store locator. The Local SEO report scores the signals that decide whether a site surfaces in the local pack and on maps. These signals are structured business data, geographic keywords, and on-page contact and location cues. For any business with a physical presence, they matter as much as the general audit. The report appears once Local SEO is enabled in the audit configuration. ## Score and features [#score-and-features] The report opens with a **Local SEO score** and its distribution across pages, then grades the site on the presence and coverage of each local feature. Each feature is scored on how many pages implement it: | Feature | What it checks | | ---------------------- | ---------------------------------------------------------------- | | **Business schema** | `LocalBusiness` structured-data markup, the machine-readable NAP | | **Local keywords** | Geographic terms that target a location | | **Local phone number** | On-page local contact information | | **Embedded map** | An interactive location map | | **Store locator** | A dedicated location or branch finder | **Business schema** carries the most weight. `LocalBusiness` markup is how search engines read a consistent name, address, and phone number. That consistency is the foundation of local ranking. <Callout type="info"> This report requires the Local SEO module to be enabled in the [audit configuration](/docs/cloud/audits/). Without it, the report stays locked even after an audit run completes. </Callout> A per-page detail view breaks the local signals down for a single URL: location information, schema implementation, and issues. An AI **Local SEO analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_localseo.webp" alt="Cloud Local SEO report with business schema, keywords, and map signals" caption="Local signals — business schema, keywords, phone, map, and locator." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/advanced-local-seo-strategies", title: "Local SEO strategies: dominate your geographic market" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/brand', '/docs/cloud/audits/international-seo', '/docs/cloud/audits/content']" /> --- # Media report URL: https://docs.digispot.ai/docs/cloud/audits/media/ The Media report scores image and video SEO across the site. The Media report covers both images and video, scoring how well each is set up for search and for speed. Media is often the heaviest thing on a page and the least optimized. Unlabeled images miss image search entirely, and legacy formats slow Core Web Vitals, so this report grades the two together. ## Image SEO [#image-seo] The image section carries its own score and distribution. The per-page view grades each image on the signals that decide whether it ranks and how fast it loads. * **With alt text** — the share of images carrying alt text, the primary image-search and accessibility signal * **With srcset** — responsive-image coverage, so the right size is served per device * **With dimensions** — images declaring `width` and `height`, which prevents the layout shift that hurts CLS * **Legacy format** — JPEG, PNG, and GIF images where **WebP** or **AVIF** would be smaller; zero is the target * **Lazy loading** — reported for information, since lazy loading helps below the fold but hurts above it <Screenshot src="/screenshots/cloud/cloud_images.webp" alt="Cloud Media report Image SEO section with alt text, format, and dimension coverage" caption="Image SEO — alt text, responsive images, formats, and dimensions." width="3420" height="1890" /> ## Video SEO [#video-seo] The video section carries its own score and distribution. It grades embeds on the signals search engines use to understand and surface video. * **With title** — videos named for search engines * **With description** — videos carrying descriptive text * **With schema** — videos backed by structured data, which unlocks video rich results * Player distribution — which players are embedded, reported for context <Callout type="info"> For YouTube embeds, the auditor currently reports **title** and **description** as absent even when the video has them, and only reads captions on native HTML5 players. Read low title, description, and caption coverage on YouTube-heavy pages with that caveat in mind. </Callout> Each section has a per-page detail view and its own AI insight that reads the findings back as fixes. These are **Image SEO analysis** and **Video SEO analysis**. <Screenshot src="/screenshots/cloud/cloud_vedio.webp" alt="Cloud Media report Video SEO section with title, description, and schema coverage" caption="Video SEO — title, description, and VideoObject schema coverage." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/image-compression-for-better-seo-speed", title: "Image compression for better SEO and speed" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/performance', '/docs/cloud/audits/content', '/docs/cloud/audits/pages']" /> --- # Pages report URL: https://docs.digispot.ai/docs/cloud/audits/pages/ The Pages report lists every crawled URL with per-dimension scores, and drills into a full per-page breakdown. The Pages report is the row-per-URL view of the audit. Where the dimension reports each answer one question across the whole site, the Pages report answers every question for one URL. It scores each page on every dimension of SEO and drills into a complete breakdown for any single page. It is the report to open when the fix is page-specific rather than site-wide. ## List view [#list-view] The all-pages table is the crawl result in full. Its **status** column separates pages that scored cleanly from those the crawler could not fully process. | Status | Meaning | | -------------- | -------------------------------------------------- | | **Successful** | Crawled and scored across every dimension | | **Errored** | Reached, but something blocked a complete analysis | | **Broken** | Returned an error status and could not be scored | Alongside status, each row carries score columns for **Overall**, **Crawlability**, **Content**, **Performance**, **Links**, **Brand**, **Local**, **Insights**, **Issues**, and **URL**. Supporting metrics such as average crawl depth, broken links, and slow resources sit beside them. Pages group into quality buckets and into prioritization buckets so the list can be read by health or by opportunity: | Bucket | Score range | | ------------- | ----------- | | **Excellent** | 90–100 | | **Good** | 70–89 | | **Fair** | 50–69 | | **Poor** | 0–49 | The **Quick wins** and **Easy fixes** groupings surface the pages where a small change moves the score most. ## Page detail [#page-detail] Opening a page assembles every dimension's finding for that single URL into one view. It is the per-page equivalent of walking each report in turn. It shows per-dimension cards for **Core Web Vitals**, **Brand score**, **Schema markup**, **Social media**, **Image SEO**, **Video SEO**, **Internationalization**, **Local SEO**, **LLM vs Googlebot**, **URL readability**, **Page links**, **Backlinks**, and **Tech stack**, alongside a screenshot preview, the page's metadata, and an AI summary. <Callout type="info"> When Google Search Console is connected, the page detail overlays real GSC and GA4 data: index status, canonical details, mobile usability, referring URLs, and traffic. Measured performance then sits next to the audited signals for the same URL. </Callout> <Screenshot src="/screenshots/cloud/page_insights.webp" alt="Cloud Pages report with per-dimension score columns and filters" caption="Every crawled URL scored across each SEO dimension." width="3420" height="1892" /> <RelatedDocs hrefs="['/docs/cloud/audits/issues', '/docs/cloud/audits/content', '/docs/cloud/audits/performance']" /> --- # Performance report URL: https://docs.digispot.ai/docs/cloud/audits/performance/ The Performance report covers Core Web Vitals, speed metrics, and network diagnostics, with fastest- and slowest-page leaderboards. The Performance report scores how fast pages load and surfaces the pages and resources holding the site back. Page speed is a direct Google ranking signal through Core Web Vitals, and a slow page loses conversions before it loses rankings. This report isolates both which pages are slow and what is slowing them. ## Score and Core Web Vitals [#score-and-core-web-vitals] The report opens with a performance score and its distribution across pages, built from the Core Web Vitals and speed metrics below. Each metric grades against the same thresholds Google uses: | Metric | Good | Needs work | Poor | | ---------------------------------- | -------- | ---------- | ------- | | **LCP** (Largest Contentful Paint) | \< 2.5s | 2.5–4s | > 4s | | **CLS** (Cumulative Layout Shift) | \< 0.1 | 0.1–0.25 | > 0.25 | | **FCP** (First Contentful Paint) | \< 1.8s | 1.8–3s | > 3s | | **Speed Index** | \< 3s | 3–5s | > 5s | | **TBT** (Total Blocking Time) | \< 200ms | 200–600ms | > 600ms | **LCP** and **CLS** are the two Core Web Vitals Google ranks on directly. **FCP**, **Speed Index**, and **TBT** explain *why* a page is slow: render delay, progressive loading, or main-thread blocking. ## Leaderboards and diagnostics [#leaderboards-and-diagnostics] Beyond the scores, the report ranks pages and pinpoints the causes. * **Leaderboards** — **fastest** and **slowest** pages, high performers, and pages that **need attention**, so the worst offenders are one click away * **Network diagnostics** — **DNS issues**, **SSL issues**, slow lookups, and long transfers, the connection-level delays that page-level optimization can't fix * **Industry-leaders benchmark** — a comparison point for how the score reads against strong sites in the same space <Tip> Start from the **slowest pages** leaderboard, not the site average. A handful of heavy templates usually drags the whole distribution down, so fixing them lifts the score across every page that shares the template. </Tip> A per-page detail view breaks the metrics down for a single URL, with resource and HAR-level analysis. An AI insight reads the findings back as fixes. <Screenshot src="/screenshots/cloud/cloud_performance.webp" alt="Cloud Performance report with Core Web Vitals and speed leaderboards" caption="Core Web Vitals sit next to fastest- and slowest-page leaderboards." width="3420" height="1884" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/core-web-vitals-seo-guide", title: "Core Web Vitals SEO: improve LCP, CLS, and INP" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/audits/media', '/docs/cloud/audits/tech']" /> --- # Site report URL: https://docs.digispot.ai/docs/cloud/audits/site/ The Site report covers site-wide signals — health score, robots.txt, sitemaps, security, and llms.txt. The Site report covers the signals that apply to the whole site rather than a single page. These are the foundations that shape how every URL is discovered, trusted, and served. A problem here rarely shows on one page in isolation, which is why it earns its own report: a blocking `robots.txt` rule or an expired certificate suppresses the entire crawl at once. ## Site visualizer [#site-visualizer] The report opens with the **Site visualizer**, an interactive graph of the crawled site. The homepage sits at the center and pages radiate out along their internal links, in a **Radial**, **Tree**, or **Force** layout. Node colour flags status, so pages with problems stand out from the rest. A side rail reads the graph as numbers: * **Coverage** — the share of the site audited, with the counts of pages audited, discovered but not audited, and never reached * **Internal links** — the total across audited pages, and the **orphan** count * **Section health** — the mean page-audit score per URL folder, clickable to drill in * **Needs attention** — pages ranked by issue severity, most critical first Filter the graph to **Problems**, **Content ops**, or **Links**, search for a page, and use **Export fix queue** to send the flagged pages out as a worklist. <Screenshot src="/screenshots/cloud/site_visualizer_cloud.webp" alt="The cloud Site visualizer showing the crawled site as a radial graph with the homepage at the center and pages radiating out, a side rail with percent audited, internal links and orphans, section health by folder, and a needs-attention list, plus Radial/Tree/Force view toggles and an Export fix queue action" caption="The homepage anchors the graph and pages radiate out by internal link; the side rail reports coverage, section health, and the pages needing attention first." width="3420" height="1892" /> ## Health tiles [#health-tiles] Summary tiles give the site-wide read at a glance: the **site health score** plus the status of the four foundations below it: **robots.txt**, **sitemap**, **security**, and **llms.txt**. Each tile is a jump-off point into its detail panel. ## Detail panels [#detail-panels] Each foundation has a dedicated panel that moves from a status summary into the underlying rules and records. ### Robots.txt [#robotstxt] Presence and the crawl rules it declares — which user agents are allowed or disallowed, and the sitemap references it points to. <Screenshot src="/screenshots/cloud/cloud_robots.webp" alt="Cloud Site report robots.txt panel showing crawl rules and user-agent directives" caption="The robots.txt panel — allowed and disallowed paths per user agent." width="3420" height="1894" /> ### Sitemaps [#sitemaps] Sitemaps processed, **valid and invalid URLs**, average URLs per map, section count, duplicates, internal and external links, and link-text quality. Drilling into a single sitemap opens overall-health, content, and URL-structure analysis. <Screenshot src="/screenshots/cloud/cloud_sitemap.webp" alt="Cloud Site report sitemap panel with valid and invalid URL counts and link metrics" caption="The sitemap panel — valid/invalid URLs and link-text quality." width="3420" height="1890" /> ### Site security [#site-security] Certificate status, **HTTPS**, **TLS version**, **HTTP/2** and **HTTP/3** support, **DNSSEC**, **CAA records**, and the certificate issuer and validity dates. <Screenshot src="/screenshots/cloud/cloud_security.webp" alt="Cloud Site report security panel with certificate, TLS, HTTP/2, and DNSSEC status" caption="The security panel — certificate, TLS, and protocol support." width="3420" height="1892" /> ### llms.txt [#llmstxt] Presence and rules for the emerging file that guides AI crawlers to the content worth citing. It carries its own score and metrics. <Screenshot src="/screenshots/cloud/cloud_llms.webp" alt="Cloud Site report llms.txt panel for guiding AI crawlers" caption="The llms.txt panel — guidance for AI crawlers, scored on its own." width="3420" height="1892" /> <Callout type="info"> Security findings gate more than the padlock icon. An invalid or expired certificate, or a downgrade off HTTPS, undermines trust signals across every page the audit scored. Treat it as a site-wide blocker, not a cosmetic warning. </Callout> ## AI insight [#ai-insight] A **Summarize with AI** insight turns the raw site signals into a plain-language health summary, calling out which foundation is weakest and what to address first. <RelatedDocs hrefs="['/docs/cloud/audits/crawlability', '/docs/cloud/audits/pages', '/docs/cloud/audits/tech']" /> --- # Tech stack report URL: https://docs.digispot.ai/docs/cloud/audits/tech/ The Tech report scores technical infrastructure and lists the technologies detected across the site. The Tech report covers the technical infrastructure behind the site and the technologies it runs on. It answers what the site is built with and how soundly that stack is implemented. This is the layer that quietly shapes crawlability, performance, and security across every page without appearing in any single page's content. ## Score and infrastructure [#score-and-infrastructure] The report opens with a **tech score** and its distribution across pages. The score reflects overall quality of the technology implementation, security, and adherence to best practices. The score bands follow the platform's standard grading: | Band | Score | | ------------- | ------ | | **Excellent** | 85–100 | | **Good** | 70–84 | | **Fair** | 50–69 | | **Poor** | 0–49 | An **infrastructure overview** summarizes the hosting and delivery layer the site depends on. ## Technologies [#technologies] The report detects and groups the technologies running across the site, so the stack is visible in one place rather than inferred page by page. * **Frameworks** — the front-end and rendering technologies in use * **CMS** — the content management system, with its distribution across pages * **Server** — the server software detected, and its distribution * **CDN** — the content delivery network fronting the site, and its distribution * **Analytics** and other tooling detected across pages A per-page detail view breaks the stack and its issues down for a single URL. An AI **Tech stack analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_techinsights.webp" alt="Cloud Tech report with infrastructure and detected technologies" caption="The technologies detected across the site, grouped by category." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/technical-seo-checklist-for-2025", title: "The ultimate technical SEO checklist" }, { href: "https://digispot.ai/blog/javascript-seo", title: "JavaScript SEO: complete guide for modern web apps" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/site', '/docs/cloud/audits/performance', '/docs/cloud/audits/crawlability']" /> --- # Content Performance URL: https://docs.digispot.ai/docs/cloud/google-insights/content-performance/ The Content Performance view covers rich results and structured data as seen by Google. The Content Performance view pairs two questions about the content itself: which pages actually hold visitors, and which pages earn enhanced treatment in Google results. The first is a GA4 engagement read. The second is Search Console's take on structured data and rich snippets. <Callout type="info"> Page engagement comes from **Google Analytics 4** and fills in once GA4 is connected. Rich results come from Search Console's **URL Inspection** data and need that permission. Without it the rich-results section shows a locked state while page engagement still renders. </Callout> ## Page engagement [#page-engagement] The first section ranks pages by how well they hold and move visitors, drawn from GA4. * Per-page **engagement** and session behavior * The pages carrying the most engaged traffic — the ones worth protecting and building on ## Rich results and structured data [#rich-results-and-structured-data] The second section reads how the site's markup earns enhanced result types. * The **rich result types** Google recognizes on the site and where each is eligible * Where structured data is present but **blocked or invalid**, so a page misses an enhancement it should qualify for * Schema-type analysis across the pages Google has inspected <Tip> A page that ranks well but shows no eligible rich result is often one valid schema block away from a richer, more clickable snippet. Confirm the markup with the Content and Schema audits, then re-check here after Google re-inspects the page. </Tip> <Screenshot src="/screenshots/cloud/gsc_content_performance.webp" alt="Google Insights Content Performance with rich results and structured data" caption="Rich results and structured data as Google sees them." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/search-performance', '/docs/cloud/audits/content', '/docs/cloud/audits/media']" /> --- # Google Insights URL: https://docs.digispot.ai/docs/cloud/google-insights/ Dashboards built on your connected Google data — Search Console and GA4 — so audits are weighted by real traffic, split across focused views. Connect your Google accounts and the platform turns their data into dashboards that sit alongside your audits. Findings are prioritized by real traffic and rankings, not severity alone. ## Connect your Google data [#connect-your-google-data] Through one-click OAuth, connect: * **Google Search Console** — clicks, impressions, CTR, and position by query, country, device, and URL, plus live URL Inspection verdicts * **Google Analytics 4** — traffic and engagement per URL <Callout type="info"> If a connection's credentials expire, it shows as needing reconnection. Re-run the OAuth sign-in to restore syncing. Google Insights is gated by plan and usage. See [Plans & billing](/docs/cloud/billing/). </Callout> <Screenshot src="/screenshots/cloud/cloud_gsc.webp" alt="Cloud GSC analytics dashboard with Search Console clicks, impressions, and queries" caption="Search Console analytics, built into the platform." width="3420" height="1892" /> ## The views [#the-views] Google Insights groups the data into focused views: <SectionCards hrefs="[ '/docs/cloud/google-insights/overview', '/docs/cloud/google-insights/search-performance', '/docs/cloud/google-insights/traffic-users', '/docs/cloud/google-insights/technical-health', '/docs/cloud/google-insights/content-performance', ]" /> <RelatedDocs hrefs="['/docs/cloud/dashboard', '/docs/cloud/audits', '/docs/cloud/settings']" /> --- # Overview URL: https://docs.digispot.ai/docs/cloud/google-insights/overview/ The Google Insights Overview is the headline picture across Search Console and GA4 — health, position, indexing, and profile signals. The Overview is the top-level read on your connected Google data. It pulls the headline numbers from Search Console and GA4 into one screen. It answers the first questions of any check-in: is the site healthy, is it visible in search, and is Google indexing it. The detailed views behind each area sit one click away, so the Overview works as both a status board and a launch point. <Callout type="info"> The Overview fills in only once a project has Google Search Console or Google Analytics 4 connected. Connect them under **Settings → Projects & Integrations**. An area for a source that isn't linked shows a connect prompt instead of numbers. </Callout> ## Site health [#site-health] The first band summarizes how the site is doing overall, drawn from Search Console's site-health signals. * **Health score** — a single rolled-up figure, with a **healthy** or degraded status * **Manual actions** — the count of active manual actions against the site (any number above zero is worth investigating first) * **Security issues** — active security problems Google has flagged ## Search performance [#search-performance] The next band is the Search Console snapshot — how the site appears in results. * **Average position** and **CTR**, with **mobile position** and **mobile CTR** broken out separately, since mobile and desktop rankings often diverge * Totals for **clicks** and **impressions** across the reporting window ## Indexing and crawl [#indexing-and-crawl] This band reads Google's crawl and index coverage. * **Crawl errors** and **crawl success rate** * **Crawled URLs** and **indexed URLs** — the gap between them is where pages are being seen but not indexed ## Business Profile [#business-profile] When a Google Business Profile is connected and has locations, a profile band appears with **profile views** and **photo views**. It stays hidden for projects without a linked profile. <Tip> Read the Overview top to bottom by leverage: clear any manual action or security issue first, then close the indexing gap, then chase position and CTR. A page that isn't indexed can't rank no matter how strong its search metrics look. </Tip> <Screenshot src="/screenshots/cloud/gsc_overview.webp" alt="Google Insights Overview with health, position, and indexing metrics" caption="The headline read across Search Console and GA4 in one view." width="3420" height="1894" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/search-performance', '/docs/cloud/google-insights/technical-health', '/docs/cloud/dashboard']" /> --- # Search Performance URL: https://docs.digispot.ai/docs/cloud/google-insights/search-performance/ The Search Performance view covers Search Console trends — clicks, impressions, and where you rank, by query and geography. The Search Performance view is the Search Console deep-dive. It shows how pages perform in Google results over time, broken down by the query people searched and the country they searched from. It reads the same data Search Console does, laid out to move from the overall trend down to the individual terms and regions driving it. <Callout type="info"> This view is fully Search Console-scoped and needs the **Search Analytics** permission on the connected property. Without it the page shows a locked state rather than data. A `404 No data found` from Google means the report hasn't populated yet, not that something broke. </Callout> ## Performance analysis [#performance-analysis] The top section is the trend line across the reporting window. It shows the four Search Console core metrics and how each is moving. * **Clicks** and **impressions** over time, with the trend direction called out * **Average CTR** — clicks as a share of impressions * **Average position** — where the site ranks on average for the terms it appears for * A **query breakdown** listing the individual terms, so a rise or fall in the totals can be traced to the queries behind it Read impressions and position together: rising impressions at a worsening position usually means the site is surfacing for new but weaker terms. ## Geographic performance [#geographic-performance] The second section maps the same clicks and impressions by country, so you can see where demand concentrates and where the site under-serves a region it should own. * Impressions and clicks **per country** * A geographic view of where search visibility is strong and where it thins out <Tip> Queries sitting at positions 8–20 with real impressions are the fastest wins: they already rank on or near page two, so a targeted content or metadata fix can push them up without earning visibility from scratch. </Tip> <Screenshot src="/screenshots/cloud/gsc_search_performance.webp" alt="Google Insights Search Performance with clicks, impressions, and queries" caption="Search Console clicks, impressions, and position by query." width="3420" height="1892" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/best-seo-analytics-tools-and-metrics", title: "SEO analytics tools: measure and improve rankings" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/overview', '/docs/cloud/google-insights/traffic-users', '/docs/cloud/google-insights/content-performance']" /> --- # Technical Health URL: https://docs.digispot.ai/docs/cloud/google-insights/technical-health/ The Technical Health view covers crawl activity, security status, mobile usability, and Core Web Vitals from Google. The Technical Health view reads Google's own signals on how crawlable, secure, and fast the site is. It draws on the same data behind the crawl and Core Web Vitals reports in Search Console, plus a live PageSpeed reading. It's Google's opinion of the site's technical shape, which is the opinion that decides rankings. <Callout type="info"> Security status and crawl activity come from Search Console's **URL Inspection** data and need that permission on the connected property. Without it those sections show a locked state. The **PageSpeed** section uses a separate Google API and stays available regardless. </Callout> ## Google security status [#google-security-status] The first section states plainly whether Google has flagged the site. * **Overall health status** and **total issues** * **Manual actions** — penalties applied against the site * **Security issues** — malware, hacked content, or similar problems Anything here outranks the rest of the page. A manual action or security flag can suppress the whole site until it's cleared. ## PageSpeed and Core Web Vitals [#pagespeed-and-core-web-vitals] The middle section is the speed and experience reading. It's taken live from Google's PageSpeed data. * **Core Web Vitals** for both **mobile** and **desktop** — the field metrics for loading, interactivity, and layout stability * The performance scores Google assigns each profile ## Crawl activity [#crawl-activity] The last section monitors how Google is fetching and indexing the site. * **Crawl activity** over time — how often Googlebot visits * **Indexed URLs** and crawl volume * **Crawl errors** — server errors, not-found, robots-blocked, and the other failure types that keep pages out of the index <Tip> Field Core Web Vitals here reflect real visitors over the trailing window, so a fix won't show up immediately. Use the Performance audit for lab data that reacts to a change the moment it ships, and watch this view to confirm the gain lands for actual users. </Tip> <Screenshot src="/screenshots/cloud/gsc_technicalhealth.webp" alt="Google Insights Technical Health with crawl, security, and Core Web Vitals" caption="Crawl activity, security status, and Core Web Vitals from Google." width="3420" height="1888" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-to-submit-urls-to-google-for-indexing", title: "How to submit URLs to Google for indexing" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/overview', '/docs/cloud/audits/crawlability', '/docs/cloud/audits/performance']" /> --- # Traffic & Users URL: https://docs.digispot.ai/docs/cloud/google-insights/traffic-users/ The Traffic & Users view covers GA4 audience and engagement — sources, devices, bounce rate, and geography. The Traffic & Users view is the GA4 side of Google Insights. It covers who visits, where they come from, and how they engage once they arrive. Where Search Performance shows how the site earns visibility in Google, this view shows what happens after the click: audience size, channel mix, and device behavior. <Callout type="info"> This view is Google Analytics 4-scoped. Its widgets fill in only after GA4 is connected and has synced data for the project; until then they show an empty or connect state rather than an error. </Callout> ## User analytics overview [#user-analytics-overview] The first section sizes and segments the audience. * **Total users**, **new users**, and **returning users**, each with its trend * The balance of new versus returning as a read on whether the site is acquiring or retaining ## Traffic sources [#traffic-sources] The second section attributes visits to the channels that produced them. * **Traffic by source and channel** — organic, direct, referral, and the rest * Trends per source, so a shift in the mix is visible over time ## Device performance [#device-performance] The third section splits engagement by device, since mobile and desktop visitors rarely behave the same. * **Mobile, desktop, and tablet** sessions * **Bounce rate** and **average session duration** per device * The **mobile-versus-desktop gap** — where one device engages markedly worse than the other <Tip> A high mobile bounce rate against a healthy desktop rate usually points at a page-experience problem — layout, speed, or intrusive interstitials on small screens — rather than a content problem. Cross-check the affected pages in the Performance audit. </Tip> <Screenshot src="/screenshots/cloud/gsc_traffic_users.webp" alt="Google Insights Traffic and Users with GA4 sources and device split" caption="GA4 traffic sources, devices, and engagement." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/search-performance', '/docs/cloud/google-insights/content-performance', '/docs/cloud/dashboard']" /> --- # Backlink research URL: https://docs.digispot.ai/docs/cloud/research/backlinks/ Profile the domains linking to a site with a health verdict, six headline metrics, and a sortable referring-domains table — generated as part of an audit run. Backlink research profiles the domains linking to a site so both authority and risk stay visible. Open **Backlinks Analysis** in the left sidebar. Unlike keyword and SERP research, it isn't a standalone lookup — the profile is generated when an audit runs with **Backlinks Analysis** enabled. <Callout type="info"> If the page is empty, turn on Backlinks Analysis in the audit configuration, run an audit, then pick that run from the selector at the top of the page. A `NO_DATA` result means the provider hasn't indexed the domain yet — common for new or small sites — not that the site has no links. </Callout> ## Profile health [#profile-health] The page opens with a health verdict for the whole profile — **Healthy**, **Review needed**, or **Critical** — computed from spam score, broken links, and referring- domain count. When something needs attention, it lists the specific issue: * **High spam score** — above 25% is flagged critical; 10–25% is a warning to review low-quality links * **Broken backlinks** — above 300 is critical; 50–300 suggests adding redirects to recover the lost link authority * **Thin link profile** — fewer than 20 referring domains prompts a push for more quality links ## Headline metrics [#headline-metrics] Six cards summarize the profile at a glance. * **Total backlinks** — every inbound link found * **Referring domains** — the unique domains linking in * **Domain rank** — the site's global ranking position * **Spam score** — the share of the profile that looks low-quality, as a percentage * **Referring pages** — the individual pages linking to the site * **Broken backlinks** — inbound links that no longer resolve ## Referring domains [#referring-domains] The referring-domains table is where the profile gets actionable. High-spam domains are hidden by default so a toxic tail doesn't distort the read. * **Domain** — the linking site, opening in a new tab * **Rank** — that domain's authority score * **Links** — how many backlinks it sends * **Spam** — its spam score, colored red above 40% and amber above 20% * **Type** and **placement** — the link's kind and where on the page it sits * **First seen** — when the backlink was discovered * **Status** — active or lost Sort by rank, link count, spam, or first-seen date, filter by link type, and search by domain name. The default spam filter hides domains scoring above 50 — uncheck **Hide high spam** to see them, and the table reports how many are hidden. <Screenshot src="/screenshots/cloud/cloud_backlinks.webp" alt="Cloud backlinks analysis with referring domains and authority signals" caption="The health verdict and six cards sit above a sortable, spam-filtered referring-domains table." width="3420" height="1892" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/backlink-analysis-a-step-by-step-guide-to-auditing-link-profiles", title: "How to find and analyze backlinks" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/links', '/docs/cloud/research/keywords', '/docs/cloud/billing']" /> --- # Research URL: https://docs.digispot.ai/docs/cloud/research/ Keyword, SERP, and backlink research in the cloud — powered by Data credits, with a saved library for what you look up. The Cloud Platform includes research tools that pull live search data. These run on **Data credits**, a pool separate from AI credits. See [Plans & billing](/docs/cloud/billing/). <Callout type="info"> Every lookup spends Data credits. Items saved to your library stay available without re-spending, so save what you plan to revisit. </Callout> ## The three research tools [#the-three-research-tools] Research is split by what you start from — a term, a query, or a domain's link profile. * **[Keywords](/docs/cloud/research/keywords/)** — look up volume, difficulty, intent, and CPC for a term, expand it on a related-keyword graph, pull a competitor domain's rankings, and keep results in a reusable library * **[SERP](/docs/cloud/research/serp/)** — capture a live results page for a query, track how target keywords move over time, and list every query the domain ranks for * **[Backlinks](/docs/cloud/research/backlinks/)** — profile the domains linking to a site, with a health verdict and per-domain authority and spam signals, generated as part of an audit run <RelatedDocs hrefs="['/docs/cloud/google-insights', '/docs/cloud/content-opportunities', '/docs/cloud/billing']" /> --- # Keyword research URL: https://docs.digispot.ai/docs/cloud/research/keywords/ Look up search volume, difficulty, intent, and CPC for any term, expand into related keywords on a relationship graph, pull a competitor domain's rankings, and keep results in a reusable library. Keyword research pulls live search data for a term, expands it into related keywords, and keeps everything you unlock in a reusable library. It runs on **Data credits**, a pool separate from AI credits. See [Plans & billing](/docs/cloud/billing/). Open **Keywords** in the left sidebar. It expands into three tabs: **Research** for a single term, **Domain** for a competitor's rankings, and **Library** for everything you've unlocked. <Callout type="info"> A keyword lookup costs 1 Data credit. Turning on related keywords adds up to 10 more (one per related term returned). Revisiting anything in your Library is free. </Callout> ## Research — one keyword at a time [#research--one-keyword-at-a-time] On the **Research** tab, enter a term, set its **location** and **language**, and toggle **related keywords** on or off before you click search. The result opens with the term's core metrics and a 12-month volume trend. * **Search volume** — monthly searches, with month-over-month, quarter, and year trend deltas * **Keyword difficulty** — a 0–100 score, banded for quick reading * **CPC** and **top-of-page bids** — the low and high Google Ads bid range * **Search intent** — a primary label (informational, navigational, commercial, transactional) plus any secondary intents * **Competition** — level (low / medium / high) and the raw competition index * **SERP features** — which result types appear for the term (featured snippet, People Also Ask, video, local pack, AI Overview, and others) * **Ranking-page averages** — mean backlinks, referring domains, and domain rank across the current top 10 Difficulty is banded so a number reads at a glance: | Band | Score | | --------- | ------ | | Easy | 0–29 | | Possible | 30–49 | | Difficult | 50–69 | | Hard | 70–100 | ### Related-keyword graph [#related-keyword-graph] With related keywords enabled, the seed term anchors a force-directed graph of up to 10 connected keywords. Click any node to re-research it — each drill-down adds to a breadcrumb trail (up to five deep) so you can walk back without re-spending. Filter the graph by **intent**, **difficulty range**, and **CPC range**, and the related-keyword table flags **opportunities** where difficulty is 30 or below and volume is 500 or above. ## Domain — a competitor's keywords [#domain--a-competitors-keywords] On the **Domain** tab, enter a competitor's domain with a location and language to pull the keywords that domain already ranks for — the terms a site should target but may not yet. Results are paginated and carry the same per-keyword metrics as Research, plus word count and referring-domain and backlink counts per term. A domain pull costs 1 credit plus up to 11 for the keywords returned. ## Library — what you've unlocked [#library--what-youve-unlocked] The **Library** tab collects every keyword you look up, and its label shows the running count. Sort by volume, difficulty, CPC, or unlock date, and search by text. Reopening a saved keyword in Research restores it from cache at no cost. Keywords with no volume, difficulty, or CPC are flagged so a niche or mistyped term is obvious. <Screenshot src="/screenshots/cloud/cloud_keywords.webp" alt="Cloud keyword research view with keywords, metrics, and expansion options" caption="The Research tab pairs core metrics with the related-keyword graph for drill-down." width="3420" height="1892" /> ## Credits and plan limits [#credits-and-plan-limits] Related keywords, the domain pull, and batch lookups are gated by plan. | Action | Cost | Plan | | --------------------------- | ------------- | -------------- | | Single keyword lookup | 1 Data credit | Free and up | | + related keywords | up to 10 more | Starter and up | | Domain keyword pull | 1 + up to 11 | Starter and up | | Reopening a Library keyword | Free | Free and up | <FromTheBlog posts="[ { href: "https://digispot.ai/blog/understanding-keyword-search-volume", title: "Understanding keyword search volume" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/research/serp', '/docs/cloud/content-opportunities', '/docs/cloud/billing']" /> --- # SERP research URL: https://docs.digispot.ai/docs/cloud/research/serp/ Capture a live Google results page for any query, track how the project's keywords rank over time, and see every query the domain ranks for — with device, language, and depth control. SERP research captures a live Google results page for a query and tracks how the project's own pages rank over time. It runs on **Data credits**, a pool separate from AI credits. See [Plans & billing](/docs/cloud/billing/). Open **SERP** from the left sidebar. The top-right toggle switches between two views: a one-off **Lookup**, and a **Rank Tracker** that follows the project's target keywords over time and lists every query the domain already ranks for. <Callout type="info"> A new lookup or a manual refresh costs 1 Data credit. Cached results, rank tracking summaries, timelines, and domain positions are free to view. </Callout> ## Lookup — a live results page [#lookup--a-live-results-page] On the **Lookup** view, type a query into the search bar, set the search context in the controls beside it, and click **Search**. * **Location** and **language** — where and in which language the search runs * **Device** — desktop or mobile * **Depth** — top 10, 20, 50, or 100 results The snapshot header reports the total result count, any **spell correction** Google applied, the **related searches** shown, and which **SERP features** are present. Each result card carries its own detail. * **Rank** — absolute position, plus the group rank where it differs * **Result type** — organic, video, featured snippet, knowledge panel, local pack, AI Overview, top stories, and others, each badged * **Title, URL, domain, and snippet** — with any extended or pre-snippet text * **Own-site highlight** — results on the project's domain are marked and tinted * **Rich elements** — star ratings with vote counts and expandable FAQ blocks where Google shows them Results extract from a full Google page, so organic listings, ads, local packs, and AI Overviews are all captured rather than organic-only. <Screenshot src="/screenshots/cloud/cloud_serp_lookup.webp" alt="Cloud SERP lookup showing search context, feature badges, and result cards for a query" caption="The header flags every feature on the page — AI Overview, People Also Ask, video — before the result cards begin." width="3420" height="1890" /> ## Rank Tracker — positions over time [#rank-tracker--positions-over-time] Click **Rank Tracker** in the top-right toggle. It records daily positions and splits into two tabs, **Tracked** and **All positions**. ### Tracked [#tracked] Open the **Tracked** tab. It follows the keywords set as project targets. A KPI bar summarizes the set — **tracked count**, **average rank**, **improved**, **declined**, and **featured** — above a distribution of how many keywords sit in the top 3, top 10, top 50, or aren't ranking. Select a keyword to open its **Position History**: a rank timeline over 7, 30, or 90 days, plus an on-demand view of the latest SERP for that term. Add a keyword to tracking straight from a Lookup with **Track keyword**. <Screenshot src="/screenshots/cloud/cloud_serp_tracker.webp" alt="Rank Tracker Tracked tab with keyword list, KPI summary, and a position-history timeline" caption="Position History plots one keyword's rank across every check, so a steady position reads as a flat line rather than a single number." width="3420" height="1892" /> ### All positions [#all-positions] Open the **All positions** tab. It lists every query where the project's domain appears — tracked and discovered. Filter by keyword text and device to see the ranking URL, position, location, and when each was last checked, and add any discovered query to tracking inline. <Screenshot src="/screenshots/cloud/cloud_serp_positions.webp" alt="Rank Tracker All positions tab listing ranking queries, positions, and ranking pages" caption="Discovered rankings appear alongside tracked ones, surfacing queries the domain ranks for without anyone adding them." width="3420" height="1890" /> ## What each view answers [#what-each-view-answers] | View | Question it answers | Cost | | ---------------------------- | -------------------------------------- | ----------------------- | | Lookup | Who ranks for this query right now? | 1 credit per new lookup | | Rank Tracker · Tracked | How are my target keywords moving? | Free to view | | Rank Tracker · All positions | Which queries does my domain rank for? | Free to view | <RelatedDocs hrefs="['/docs/cloud/research/keywords', '/docs/cloud/google-insights/search-performance', '/docs/cloud/billing']" /> --- # Content tab URL: https://docs.digispot.ai/docs/desktop/reports/content/ The Content tab measures quality, keywords, and authority across three sub-tabs, with intent and industry detection. The Content tab assesses how well a page's writing serves its purpose. It checks whether the page reads clearly, targets the right terms, and carries the trust signals Google and AI answer engines reward. A page identity card at the top shows the detected **intent**, **industry**, and **page type**, each with a confidence percentage. That frames the rest of the tab against what the page is actually trying to do. The detail is split across three sub-tabs. ## Content analysis [#content-analysis] The first sub-tab reports the fundamentals in a metric grid: **word count**, **reading time**, paragraph counts, **text-to-HTML ratio**, **readability grade** (with the Flesch reading-ease score), vocabulary diversity, passive voice, and maximum keyword density. * **Readability grade** — a lower grade reads more broadly; aim to match it to the audience rather than push it as low as possible. * **Text-to-HTML ratio** — a very low ratio can signal a thin or heavily templated page. * **Max keyword density** — the single most-repeated phrase's share of the text, the early-warning signal for keyword stuffing. <Screenshot src="/screenshots/spider/content_analysis.webp" alt="Spider Content tab Content analysis sub-tab with word count, readability, and content metrics" caption="Content analysis — the readability and structure fundamentals." width="3420" height="2072" /> ## Keywords & focus [#keywords--focus] The second sub-tab covers what the page targets: * **Related keywords & entities**, and **focus keywords** drawn from the title and headings * **Keyword density** — a table of one-, two-, and three-word phrases with each phrase's share of the analyzed text * **Keyword placement** — a matrix of each keyword against the title, meta, URL, and heading levels, flagging over- and under-optimization * A keyword-stuffing banner when density exceeds the safe threshold <Callout type="info"> Placement is judged separately from density. A keyword can appear at healthy density yet be missing from the title or H1. The placement matrix is where that gap shows. Closing it usually moves rankings more than adding repetitions. </Callout> <Screenshot src="/screenshots/spider/spider_keywordfocus.webp" alt="Spider Content tab Keywords and focus sub-tab with density table and placement matrix" caption="Keywords & focus — density by phrase length and a keyword-placement matrix." width="3420" height="2076" /> ## Authority & SERP [#authority--serp] The third sub-tab scores ranking potential. It covers an **intent** breakdown, a **content and keyword balance** rubric, **trust signals** (E-E-A-T: experience, expertise, authoritativeness, trust), and **featured-snippet opportunities**. Snippet opportunities are the lists, tables, and definitions the page is structured to win. They matter increasingly because the same structured passages that win a featured snippet are what AI answer engines quote. On paid tiers, the tab's **Content AI Audit** turns all of this into prioritized recommendations. <Screenshot src="/screenshots/spider/spider_authorityserp.webp" alt="Spider Content tab Authority and SERP sub-tab with E-E-A-T trust signals and snippet opportunities" caption="Authority & SERP — E-E-A-T trust signals and featured-snippet opportunities." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-to-analyze-competitor-seo", title: "Competitor SEO analysis: winning strategies" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/headings', '/docs/desktop/reports/links', '/docs/desktop/reports/overview']" /> --- # Headings tab URL: https://docs.digispot.ai/docs/desktop/reports/headings/ The Headings tab validates the H1–H6 outline, flags structural problems, and can fix the structure with AI. The Headings tab maps the page's H1–H6 outline and flags the structural problems that confuse both readers and search engines. A clean heading hierarchy tells Google what a page is about and how its sections nest. A missing or duplicated H1, or a skipped level, weakens that signal and hurts accessibility. Any heading-structure issues appear in a card at the top. The tab's score is the page's **headings score**. ## Count grid [#count-grid] A grid shows the count for each level, H1 through H6, plus a **Structure** cell. Each cell carries a one-word status: * **H1** — **Missing** (zero found), **Multiple** (more than one), or **Good** (exactly one). Google expects exactly one H1 per page. * **H2–H6** — **None**, **Too many** (more than 200 at a level), or **Good**. * **Structure** — the count of failed heading checks, shown as **Issues** or clean. An amber banner appears below the grid when the page does not have exactly one H1, or when the structure has hierarchy issues, spelling out the specific problem. ## Heading structure [#heading-structure] The full outline is listed in document order, indented by level, with each heading's tag, and its position and word count where available. The H1 carries a **primary keyword** chip: green when the extracted focus term is present in the H1, amber when it is missing. Use it to confirm the page's main heading targets its topic. The first 20 headings show by default, with a "Show all" control for longer pages. A **Copy** button exports the outline as indented text. <Callout type="info"> A page can have several H2s and lower levels. That is expected and healthy. The one-per-page rule applies only to the H1. The value of H2–H6 is a logical, unbroken nesting, not a specific count. </Callout> ## AI action [#ai-action] On paid tiers, the **Headings AI Audit** reviews the outline. An AI action can **fix the heading structure**, proposing a corrected hierarchy you can copy into the page. <Tip> Fix the H1 first: a missing or duplicated H1 is the highest-leverage heading problem, since it is the strongest structural signal of what the page is about. Correct skipped levels (an H4 directly under an H2) second. </Tip> <Screenshot src="/screenshots/spider/spider_headings.webp" alt="Spider Headings tab showing the H1-H6 count grid and heading outline" caption="The count grid flags a missing, multiple, or skipped heading level at a glance." width="3420" height="2070" /> <RelatedDocs hrefs="['/docs/desktop/reports/content', '/docs/desktop/reports/metadata', '/docs/desktop/reports/overview']" /> --- # Reports & dashboards URL: https://docs.digispot.ai/docs/desktop/reports/ Read your crawl — the project dashboard, the Visualizer, audit comparison, and the per-page report with a tab for every area of SEO. Once a crawl finishes, Spider gives you several ways to read the results. They range from a site-wide overview down to a single page, and across runs over time. ## Project dashboard [#project-dashboard] The project dashboard is the site-wide overview. It shows the latest run's issue breakdown by severity and category, device-by-device scores, site-health signals, and the trend across previous crawls. It's the fastest way to see what's burning and what to fix first. <Screenshot src="/screenshots/spider/reports_dashboards.webp" alt="Spider project dashboard showing issue breakdowns, device scores, and site-health signals" caption="The project dashboard — a site-wide view of the latest crawl." width="3420" height="2074" /> ## The Visualizer [#the-visualizer] The Visualizer maps your site as an interactive graph, color-coded by depth, status, or issues, and grouped into clusters you can drill into. It's the fastest way to spot orphan pages, over-deep sections, and broken-link clusters at a glance. See [The Visualizer](/docs/desktop/reports/visualizer/) for the full feature set. ## Comparing audits [#comparing-audits] Compare two crawls to see exactly what changed. It reports issues fixed versus newly introduced, and score and page-count deltas. Run it after shipping fixes to confirm they worked, or on a schedule to catch regressions. <Screenshot src="/screenshots/spider/spider_comparison.webp" alt="Spider audit comparison showing issues fixed versus introduced and score deltas between two crawls" caption="Audit comparison — what improved and what regressed between two crawls." width="3420" height="2070" /> ## The per-page report [#the-per-page-report] Open any crawled URL to see its full report. A sticky **SEO score** and issue count sit in the header. The detail is split into tabs, one per area of SEO. Every tab carries a one-click **AI Audit** on paid tiers. Page issues appear on the **Overview** tab rather than a tab of their own. <SectionCards hrefs="[ '/docs/desktop/reports/overview', '/docs/desktop/reports/metadata', '/docs/desktop/reports/headings', '/docs/desktop/reports/content', '/docs/desktop/reports/links', '/docs/desktop/reports/media', '/docs/desktop/reports/schema', '/docs/desktop/reports/social', '/docs/desktop/reports/performance', '/docs/desktop/reports/technical', '/docs/desktop/reports/local-seo', '/docs/desktop/reports/internationalization', ]" /> <Tip> Start with errors on your highest-traffic pages. Fixing one template usually clears the same issue across hundreds of URLs at once. </Tip> <RelatedDocs hrefs="['/docs/desktop/checks-and-scores', '/docs/desktop/google', '/docs/desktop/crawler']" /> --- # Internationalization tab URL: https://docs.digispot.ai/docs/desktop/reports/internationalization/ The Internationalization tab validates hreflang — language and region coverage, self-reference, x-default, and the variant list. The Internationalization tab validates a page's **hreflang** setup: the tags that tell Google which language and region version to serve to each searcher. Get it wrong and Google may show the English page to French users, split ranking signals across duplicate language variants, or ignore the annotations entirely. The tab renders only when internationalization is enabled for the project. On a monolingual site the checks stay off so they cannot false-positive. To turn them on, use Project Settings → Local SEO. ## Coverage [#coverage] A coverage strip summarizes the setup at a glance: the number of **languages** and **regions** declared, whether **x-default** is present, whether the page **self-references**, and the **validation** result — clean, or a count of errors. Any literal hreflang errors are listed explicitly. Three signals decide whether the setup is valid: * **Self-reference** — each page in a language set must include an hreflang tag pointing to itself. A set that omits the self-reference is invalid and Google discards it. * **x-default** — the fallback served when no declared language and region matches the user. Recommended for any multi-region site. * **Reciprocity** — every variant a page points to should point back. A one-directional annotation is ignored, so reciprocity errors are surfaced here. ## Regional language coverage [#regional-language-coverage] When the page targets regional variants, a **regional languages** summary lists the distinct language bases the crawl detected (for example, `en`, `es`, `de`), so you can confirm the intended locales are all represented. ## Hreflang variants [#hreflang-variants] The variants are shown as a table with columns for the language **code**, **region**, **URL**, and a note marking self, x-default, or alternate. For pages with many variants (more than twelve), the list groups into a per-language accordion instead, with x-default pinned to the top, so a large locale set stays readable. <Screenshot src="/screenshots/spider/international-seo.webp" alt="The Internationalization tab showing a coverage strip — 2 languages, 0 regions, x-default present, self-reference present, validation clean — above a Hreflang Variants table listing the en, ta, and x-default codes with their notes" caption="The coverage strip gives the verdict at a glance, and the variant table below lists every declared language and region with its role." width="2854" height="1118" /> <Callout type="info"> Hreflang is reciprocal by design. If page A lists page B as its French variant, page B must list page A in return, and both must self-reference. A single missing back-reference invalidates the pairing, which is why the tab reports reciprocity and self-reference as first-class checks rather than footnotes. </Callout> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/react-seo-optimization-guide", title: "React SEO: the complete guide (includes hreflang)" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/metadata', '/docs/desktop/reports/local-seo', '/docs/desktop/reports/overview']" /> --- # Links tab URL: https://docs.digispot.ai/docs/desktop/reports/links/ The Links tab reports link health, broken and unreachable links, weak anchors, and a filterable table of every link on the page. The Links tab inventories every link on the page and scores its link health. Internal links spread ranking equity and help crawlers discover pages. External links and anchor text shape how both Google and readers understand what a page points to. Broken links waste crawl budget and frustrate users. This tab is where they get caught before they compound across a site. ## Link metrics [#link-metrics] A row of tiles summarizes the page's links: * **Internal** and **External** counts, with nofollow noted * **Broken** links — flagged to fix immediately, since they dead-end users and crawlers * **Unreachable** — links to pages the crawl could not fetch (a timeout or bot wall, distinct from a confirmed 4xx) * **Weak anchors** — empty and generic anchor text such as "click here" or "read more", which carry no topical signal ## Link table [#link-table] The full list is filterable by **All / Internal / External / Other**, with columns for: * **URL** — the destination, marking insecure `http` links * **Anchor** — the visible text, flagging generic or empty anchors * **rel & status** — follow/nofollow and any error code returned On paid tiers, the **Links AI Audit** reviews the link profile and prioritizes what to fix. <Callout type="info"> An unreachable link is not necessarily broken. The crawl could not confirm its status — often a slow response or a bot wall on the target — so verify it in a browser before removing the link. </Callout> <Tip> Rewrite generic anchors before hunting for new links. Descriptive anchor text on the internal links you already have passes a clearer topical signal to the target page, at no extra crawl cost. </Tip> <Screenshot src="/screenshots/spider/spider_links.webp" alt="Spider Links tab with link-health metrics and a filterable link table" caption="Broken and unreachable links are called out before the full table." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/backlink-analysis-a-step-by-step-guide-to-auditing-link-profiles", title: "How to find and analyze backlinks" }, { href: "https://digispot.ai/blog/best-off-page-seo-strategies", title: "Off-page SEO strategies: build authority and links" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/content', '/docs/desktop/reports/media', '/docs/desktop/reports/overview']" /> --- # Local SEO tab URL: https://docs.digispot.ai/docs/desktop/reports/local-seo/ The Local SEO tab checks NAP consistency, LocalBusiness schema, map integration, and location signals — for pages that serve a physical area. The Local SEO tab audits the signals that affect local pack and map visibility, the results Google shows for "near me" and location-qualified searches. For a business that serves a physical area, these signals often matter more than traditional rankings. The tab renders only when local SEO is enabled for the project and the page carries local signals. Otherwise it shows a not-applicable state so it does not false-positive on a non-local page. ## Business identity (NAP) [#business-identity-nap] The identity card reports the **business name**, **address**, **phone**, **email**, and **geo coordinates** (with a Google Maps link), plus a structured breakdown of the address and whether **LocalBusiness schema** is active. NAP stands for Name, Address, Phone. This trio must match exactly across the site, the schema, and external directories for Google to trust the listing. <Screenshot src="/screenshots/spider/local-seo-1.webp" alt="The Local SEO tab's Business Identity (NAP) card showing business name, physical address, phone, email, and geo coordinates, plus a structured address breakdown, with a LocalBusiness schema active badge" caption="The identity card reads the NAP from the page and its schema together, so a mismatch between what a visitor sees and what the markup declares is easy to catch." width="2864" height="1514" /> ## Location signals [#location-signals] A signals card lists the **declared locations** on the page and the **places mentioned** in the content, so you can confirm the page actually names the area it means to rank for. ## Local SEO health [#local-seo-health] A pass/fail checklist covers: * **NAP consistency** — whether name, address, and phone agree across the page * **LocalBusiness schema** — present, and which recommended properties are missing * **Map integration** — an embedded map * **Google reviews** — review signals on the page * **Service area** and **store locator** coverage * **Single- vs multi-location** handling * Whether the location appears in key on-page elements (title, headings, content) The raw schema payload is available under a collapsible technical section. <Screenshot src="/screenshots/spider/local-seo-2.webp" alt="The Local SEO tab's lower half showing declared locations on the page, a Local SEO Health pass/fail checklist (NAP consistency, LocalBusiness schema, map integration, Google reviews, service area all passing, store locator failing), and the raw schema payload" caption="Each local signal is a plain pass or fail, and the raw schema payload sits below for confirming what the markup actually declares." width="2854" height="1740" /> On paid tiers, the **Local SEO AI Audit** reviews these signals and prioritizes fixes. <Callout type="info"> NAP consistency is the foundation. If the address or phone on the page disagrees with the LocalBusiness schema or the business's directory listings, Google discounts the whole set. Resolve any NAP mismatch before adding further local signals. </Callout> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/advanced-local-seo-strategies", title: "Local SEO strategies: dominate your geographic market" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/schema', '/docs/desktop/reports/internationalization', '/docs/desktop/checks-and-scores']" /> --- # Media tab URL: https://docs.digispot.ai/docs/desktop/reports/media/ The Media tab audits images and video — alt text, formats, dimensions, CDN delivery, and VideoObject schema. The Media tab covers both images and video on the page and flags the media that can be optimized for speed and search. Images are usually the single largest slice of page weight and a common cause of layout shift. Missing alt text costs both accessibility and image-search visibility. This tab connects directly to the Performance and Content findings. ## Images [#images] An **optimisation** list surfaces images that could be smaller, judged on format, dimensions, and bytes-per-pixel. An images card reports: * **Total**, **alt OK**, and **no alt** counts, with a three-state alt chip per image — **No alt** (a problem on meaningful images), **Decorative** (an intentional empty `alt`, which is correct), or **Alt** (present) * **Modern vs legacy** format — how many images use next-gen formats (WebP, AVIF) versus older JPEG/PNG * **No dimensions** — images without width and height, a Cumulative Layout Shift risk because the browser cannot reserve space before they load * **Responsive** (`srcset`) and **on CDN**, with the detected CDN provider * A paginated image list with thumbnails, path, format, and dimensions ## Videos [#videos] The videos card reports the **total** videos, **embedded players**, and whether **VideoObject schema** is present, along with detected platforms and poster coverage. It also gives guidance on schema, poster images, and captions. On paid tiers, the **Media AI Audit** reviews the media and prioritizes fixes. <Callout type="info"> A **Decorative** alt state is not a failure. An empty `alt=""` on a purely decorative image is the correct choice, because it tells screen readers to skip it. Only meaningful images flagged **No alt** need attention. </Callout> <Tip> Fixing images that report **no dimensions** and serving next-gen formats usually improves both the CLS and LCP metrics on the Performance tab. Treat this tab and Performance as one workflow. </Tip> <Screenshot src="/screenshots/spider/spider_media.webp" alt="Spider Media tab covering image alt text, formats, and video schema" caption="Images and video are scored together, with per-image alt and format status." width="3420" height="2072" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/image-compression-for-better-seo-speed", title: "Image compression for better SEO and speed" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/links', '/docs/desktop/reports/schema', '/docs/desktop/reports/performance']" /> --- # Metadata tab URL: https://docs.digispot.ai/docs/desktop/reports/metadata/ The Metadata tab audits the title, description, canonical, robots directives, hreflang, and the technical tags behind how a page is indexed. The Metadata tab covers the tags that decide how a page is indexed and displayed. That includes the title and description a searcher sees, plus the technical directives that control whether the page can appear at all. A single wrong tag here can suppress an otherwise strong page. It is usually the first tab to check when a page ranks below its content quality. The tab's score is the page's **indexability score**. Any issues in this category appear in a card above the field grid. ## Redirect chain [#redirect-chain] When the crawled URL redirects, a **redirect chain** card lists every hop in order, numbered top to bottom, with the status code of each and the final `200` destination. It is worth reading because each redirect adds latency. A chain can also leak link equity or, in the worst case, trap crawlers. The card flags three problems explicitly: * **Permanent vs temporary** — a chain built from `301`/`308` hops is marked permanent; a `302`/`307`/`303` hop marks it temporary. A temporary redirect where a permanent one was intended passes less link equity to the destination. * **HTTPS downgrade** — an `HTTPS↓` badge appears when any hop drops from `https://` to `http://`, an insecure and SEO-damaging step. * **Loop** — flagged when the chain returns to a URL it already visited. ## Field grid [#field-grid] Each tag is a row with a status dot and, where relevant, a length chip. Expand a row to see the raw value and a fix hint. Read it top to bottom. The first two rows carry the most weight because they are what a searcher actually sees. ### Title and meta description [#title-and-meta-description] Both are scored on length. The chip shows the **character count** alongside the **SERP pixel width** where available, since pixels are how Google actually decides truncation. Length is treated as an opportunity, not a hard error. Too short under-uses the SERP space and costs click-through. Too long risks truncation. | Tag | Optimal band | Status logic | Why it matters | | -------------------- | ------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Title** | 30–60 characters | Pass 30–63 (5% tolerance), warn outside, fail if missing | The strongest on-page signal and the clickable headline in results. | | **Meta description** | 120–160 characters | Pass 120–168 (5% tolerance), warn outside, fail if missing | Does not rank the page, but a sharp description lifts click-through; a weak one gets rewritten by Google. | ### URL and canonical [#url-and-canonical] * **URL** — shown with its character length; a **URL quality** row appears only when there is something to flag (tracking parameters, session IDs, or a fragment), with the parameter count. * **Canonical URL** — marked **Self** (the healthy default), **Different URL** (correct for a duplicate, a problem if unintentional), **External**, or **Missing**. A wrong canonical is one of the most common causes of a page quietly dropping out of the index. * **Pagination** — a `rel=prev`/`rel=next` row appears only on pages that are part of a paginated set, flagging a broken sequence or a loop. ### Language, robots, and access [#language-robots-and-access] * **Language** — the declared `lang` attribute against the language actually detected in the content, warning on a mismatch (for example, `lang="en"` on Japanese text). * **Character set** — flagged as a warning when missing rather than assumed to be UTF-8. * **Robots** — the meta directive (`index`/`noindex`, `follow`/`nofollow`) plus `noimageindex`, `noarchive`, and `nosnippet` where set. A chip surfaces the **X-Robots-Tag** HTTP header, which can override the meta tag and is invisible in view-source. * **Access** — how the crawler actually read the page (browser vs HTTP fetch, whether it had to escalate past a bot wall), shown only when that provenance exists. ### Hreflang and the rest [#hreflang-and-the-rest] * **Hreflang** — a one-line summary of variant and error counts that links to the Internationalization tab for the full per-variant table. Shows "Not enabled for this project" when internationalization is off. * **Meta keywords** and **Resource hints** (`preconnect`, `dns-prefetch`, `prefetch`, `modulepreload`) appear only when present. * **Built with** — the detected technology stack (frameworks, CMS, analytics, CDN), also available in full on the Technical tab. * **Mobile optimization** — the viewport meta, required for mobile-first indexing. * **Site icon (favicon)** — the detected favicon URL, since the favicon shows next to the result on mobile. <Callout type="info"> An X-Robots-Tag `noindex` set as an HTTP header blocks a page even when its HTML looks fine. It surfaces only in the Robots row's chip, not in view-source, so check it before assuming a page is indexable. </Callout> ## AI actions [#ai-actions] On paid tiers, the **Metadata AI Audit** pill in the header reviews the metadata and returns prioritized findings. At the bottom of the tab, once AI is unlocked, two write-actions — **rewrite title** and **rewrite meta description** — propose replacements you can apply. Both are seeded from the page's top content keywords. <Tip> Work this tab in order of leverage: clear any unintended `noindex` first, then fix the canonical, then the title, then the description. The first three decide whether the page ranks. The description decides whether people click. </Tip> <Screenshot src="/screenshots/spider/spider_metadata.webp" alt="Spider Metadata tab with the title, description, canonical, and robots field grid" caption="Each tag is a status row you can expand for the value and a fix hint." width="3420" height="2072" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/what-is-canonical-url", title: "Canonical URLs for SEO: complete implementation guide" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/headings', '/docs/desktop/reports/technical', '/docs/desktop/reports/internationalization']" /> --- # Overview tab URL: https://docs.digispot.ai/docs/desktop/reports/overview/ The Overview tab summarizes a single page — its SEO score, a Google search preview, category scores, what's working, and the full issue list. The Overview tab is the first thing you see when you open a crawled page. It rolls every other tab into a single verdict: the page's score, how it would look in search, its health by category, what already passes, and the full list of what to fix. It reads top-down. First comes the search preview and a rendering of how the page loads. The page summary follows, then Google's own performance data. Below that are the category scores, what is working, and the issues to act on. ## Google search preview [#google-search-preview] A **Google search preview** renders the page's title, description, favicon, and URL as Google would show them for the crawled device (desktop, mobile, or tablet). Where the page's schema supports them, it adds rich-result affordances: FAQ, breadcrumb, article, rating, and product. Article rich results only preview on editorial pages (an `og:type` of article or a blog-like URL), so a homepage is not wrongly advised to add Article markup. When a page could not be fetched, the preview is skipped rather than showing fabricated "missing title" guidance. ## Visual rendering [#visual-rendering] Beside the search preview, a **visual rendering** thumbnail shows the rendered page for the crawled device, with its Core Web Vitals grades. It puts how the page actually loads next to how it would appear in search. ## Page summary [#page-summary] The summary card leads with three hero tiles bound into one verdict band: * **SEO score** — 0–100 with a verdict of **Good** (≥ 80), **Needs work** (≥ 60), or **Poor** (below 60). A non-page such as a 404 shows its status rather than a misleading "0 · Poor". * **Issues** — the tracked count with Critical, High, Medium, and Low chips. * **Indexability** — the audit state (Indexed, Noindex, Soft-404, Canonicalised, Redirect chain, Near-duplicate, 4xx, 5xx, and more). Below the tiles, a metric grid groups the specifics: **Response** (status, document size, requests, stack), **Content** (title and meta length, words, images missing alt), and **Links & schema** (internal/external links, broken links, schema blocks, freshness). ## Google data [#google-data] When Search Console and GA4 are connected for the project, a **Google performance** card sits below the summary. It adds the page's real clicks, impressions, average position, sessions, and an indexing verdict. This is the one place per-URL Google data surfaces. It is Google's own verdict on the page, distinct from the crawl's audit score. ## Category scores [#category-scores] A **category scores** card lists clickable bars — Indexability, Content, Headings, Media, Links, Schema, Social, Local SEO, and Performance — each jumping to its tab. A category that does not apply to the page (for example, Local SEO on a non-local page) shows a neutral state rather than a red zero. That way it does not drag down the read. ## What's working and page issues [#whats-working-and-page-issues] **What's working** lists the checks the page passed. It is the only place passed checks surface, so the tab is not a wall of red. The **page issues** panel, expanded by default, lists every finding filterable by severity. Each issue states what it is, why it matters, and how to fix it. It also links to every other page in the crawl with the same issue, so a systemic problem can be fixed once at the template level. <Callout type="info"> Issues live only on the Overview tab. There is no separate Issues tab. Each per-category tab shows its own findings in a card, but the complete, filterable list for the page is here. </Callout> <Tip> Start from the severity chips. Clear Critical and High findings first, since those are the ones that block indexing or ranking. Then use the "same issue on N pages" links to batch the fix across the site. </Tip> <Screenshot src="/screenshots/spider/reports_dashboards.webp" alt="Spider project Overview showing the site score, page-level audit scores for desktop, mobile, and tablet, run-over-run changes, and an issues-by-severity breakdown" caption="The Overview rolls the latest run into one verdict, with site and page-level scores and issues broken out by severity." width="3420" height="2074" /> <RelatedDocs hrefs="['/docs/desktop/reports/metadata', '/docs/desktop/checks-and-scores', '/docs/desktop/reports/performance']" /> --- # Performance tab URL: https://docs.digispot.ai/docs/desktop/reports/performance/ The Performance tab reports Core Web Vitals, page weight, and the resources slowing a page down. The Performance tab reports how fast a page loads and what is holding it back. It shows Core Web Vitals plus a full breakdown of page weight and the specific resources that cost load time. Speed is both a ranking signal and a conversion factor. This tab pairs the graded metrics with the named offenders behind them, so the fix is concrete rather than a number to chase. <Callout type="info"> These metrics come from the crawl's own browser render, not real-user data. INP cannot be measured in a crawl because it needs a real user interaction to exist. The tab never claims an INP pass, and for INP it points to field data in Search Console. When a page could not be browser-rendered (for example, blocked by a bot wall), an HTTP-fallback banner explains that Core Web Vitals, page weight, and the screenshot are unavailable. The HTML-level audit is unaffected. </Callout> ## Score and Core Web Vitals [#score-and-core-web-vitals] A **performance score** ring sits beside the Core Web Vitals bars — **LCP**, **INP**, **CLS**, **FCP**, **TTFB**, **TBT**, and **Speed Index**. Each is graded against Google's current thresholds from the measured value. A verdict banner above summarizes the result. It names which of LCP, INP, and CLS actually passed and calls out any it could not measure rather than counting them as passes. Each metric is rated **Good**, **OK** (needs improvement), or **Poor** at these boundaries: | Metric | Good | Needs improvement | Poor | What it measures | | -------- | -------- | ----------------- | --------- | --------------------------------------------------------- | | **LCP** | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s | Time to render the largest element — perceived load speed | | **INP** | ≤ 200 ms | 200–500 ms | > 500 ms | Responsiveness to interaction (field data only) | | **CLS** | ≤ 0.1 | 0.1–0.25 | > 0.25 | Visual stability — how much layout shifts | | **FCP** | ≤ 1.8 s | 1.8–3.0 s | > 3.0 s | Time to first visible content | | **TTFB** | ≤ 800 ms | 800–1800 ms | > 1800 ms | Server response time | | **TBT** | ≤ 200 ms | 200–600 ms | > 600 ms | Main-thread blocking during load (lab proxy for INP) | LCP, INP, and CLS are the three Google ranks on. The rest are diagnostic. Because INP needs a real interaction, it shows in the bars but is sourced from field data, not the crawl. ## Page weight [#page-weight] A **page weight** breakdown shows a stacked proportion bar and per-type rows — **HTML**, **CSS**, **JavaScript**, **Images**, **Fonts**, and **Other**. Each row shows its share and size, plus the total transferred bytes and request count. This is the real page weight, not the HTML document size shown in the page header, so it reflects what actually costs load time. When some responses could not be measured, the total is marked as a lower bound. ## Resource insights and offenders [#resource-insights-and-offenders] **Resource insights** summarize the delivery signals behind the score, each color-coded good, warning, or bad: * **Render-blocking** — the count of blocking scripts and stylesheets (a warning above zero, bad above four) * **CDN** — whether the document and its assets are served from a CDN, with the detected provider and asset coverage percentage * **HTTP version** — flagged when still on HTTP/1.1 * **Cache hit-rate** — a warning below 60% * **Uncompressed text** — the file count and wasted bytes when compression is missing **Resource offenders** name the specific files to fix: the **heaviest resources**, **oversized images**, and **slowest requests**. Each is a short list of URLs with their size or timing. On paid tiers, the **Performance AI Audit** turns the score, weight, and offenders into a prioritized list of the highest-impact fixes. <Tip> Chase the offenders before the score. A single oversized hero image or a render-blocking script usually explains a poor LCP. Fixing it moves the metric far more than incremental tuning. </Tip> <Screenshot src="/screenshots/spider/spider_preformance.webp" alt="Spider Performance tab with Core Web Vitals, page weight, and resource offenders" caption="Page weight and the heaviest resources sit next to the Core Web Vitals." width="3420" height="2070" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/core-web-vitals-seo-guide", title: "Core Web Vitals SEO: improve LCP, CLS, and INP" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/media', '/docs/desktop/reports/technical', '/docs/desktop/checks-and-scores']" /> --- # Schema tab URL: https://docs.digispot.ai/docs/desktop/reports/schema/ The Schema tab detects structured data, validates it, checks rich-result eligibility, and visualizes the entity graph. The Schema tab finds the structured data on a page, validates it against Google's requirements, and shows how the entities connect. Structured data is what earns rich results such as star ratings, FAQ drop-downs, breadcrumbs, and product pricing. It is also increasingly how AI answer engines identify and quote a page's facts. A block that is present but invalid earns nothing. Validation matters as much as coverage. Header chips show which key types (Article, Product, Breadcrumb, Organization) are present or missing. The tab has three inner views. ## Overview [#overview] A type-distribution donut shows the mix of schema types on the page, alongside a **rich-result eligibility** list. Each type is marked **Eligible** or **Ineligible**. An ineligible type lists the specific blockers holding it back, usually a required property that is missing or malformed. This is the fastest path from "I have schema" to "my schema actually qualifies for a rich result". ## Entities [#entities] A per-entity grid marks each block **Valid**, **Has issues**, or **Warning**, and expands to the full properties table or the raw JSON-LD. Use it to find the one malformed entity behind an ineligible type. ## Graph [#graph] An entity graph draws the nodes and the relationships between them (for example, an Organization linked to its Product and its reviews), expandable to full screen. A well-connected graph helps search engines resolve a page into a coherent set of entities rather than isolated blocks. <Screenshot src="/screenshots/spider/schema_graph.webp" alt="The Schema tab's Graph view showing the entity graph — 45 entities and 39 relationships as connected nodes for types like MedicalOrganization, PostalAddress, GeoCoordinates, VideoObject, and FAQPage, with nodes carrying issues marked in red" caption="The graph draws every entity and how it links to the others, so an isolated or orphaned block stands out from the connected set." width="3420" height="2076" /> **Copy all JSON** exports the page's structured data in one click. On paid tiers, the **Schema AI Audit** and an AI action to **validate & fix schema** turn the findings into corrected markup. <Callout type="info"> Eligibility is not a guarantee of a rich result, since Google decides per query. But ineligibility is a guarantee of none. Clearing the listed blockers is the prerequisite, so treat the Ineligible list as the work queue. </Callout> <Screenshot src="/screenshots/spider/spider_schema.webp" alt="Spider Schema tab with entity list, validation, and rich-result eligibility" caption="Rich-result eligibility shows which types are blocked and why." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/advanced-schema-markup-seo-guide", title: "Advanced schema markup for SEO: unlock rich snippets" }, { href: "https://digispot.ai/blog/how-to-validate-and-test-schema-markup", title: "How to validate and test schema markup" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/media', '/docs/desktop/reports/social', '/docs/desktop/reports/local-seo']" /> --- # Site health URL: https://docs.digispot.ai/docs/desktop/reports/site/ The Site health view covers the site-wide checks that run once per crawl — robots.txt, sitemaps, SSL, and llms.txt — and feed the Site Architecture score. Site health covers the checks that apply to the whole site rather than a single page. These are the foundations that decide how every URL is discovered, trusted, and served. A problem here rarely shows on one page in isolation. A blocking `robots.txt` rule or an expired certificate suppresses the entire crawl at once, which is why these checks run once per crawl and are scored on their own. <Callout type="info"> Open Site health from the project **Overview**, via **View site checks** on the Site-level card. These checks are shared across every device in a crawl and roll up into the **Site Architecture** score, separate from the per-page scores. See [Checks & scores](/docs/desktop/checks-and-scores/). </Callout> ## Site Architecture score [#site-architecture-score] A single **Site Architecture** score summarizes the site-wide foundations. It is a composite of the four checks below, so a weak `llms.txt` or a robots.txt block pulls it down without touching any individual page's score. The view opens on this score, then breaks into a tab per foundation. ## Robots.txt [#robotstxt] The **Robots.txt** tab opens with quick answers: whether the file exists, whether **Googlebot** and **AI crawlers** are allowed, whether a **sitemap** is referenced, and the rule count broken into agent groups, disallow, and allow directives. A **crawl blocking impact** panel reports how many of the URLs this audit crawled the file actually blocks. A **per-device fetch** panel shows what each device's user agent retrieved. This is where an accidental site-wide block shows up, such as a `Disallow: /` left over from staging that keeps the whole site out of the index. <Screenshot src="/screenshots/spider/spider_robots.webp" alt="The Site health Robots.txt tab with quick-answer cards for file existence, Googlebot access, AI-crawler access, sitemap reference, and rule count, above a crawl-blocking-impact panel showing 0% of crawled URLs blocked and a per-device fetch panel" caption="Quick answers confirm the file exists and what it allows; the crawl-blocking-impact panel reports how many crawled URLs the file blocked." width="3420" height="2072" /> ## Sitemap [#sitemap] The **Sitemap** tab covers the XML sitemaps the site publishes. Quick answers report whether a sitemap exists, its **total URLs**, whether robots.txt references it, and its **freshness**. A **crawl coverage** panel compares the sitemap against the crawl: URLs in both, **orphans** (crawled but not listed), and URLs listed but not reached. Per-sitemap metrics follow — URL count, video URLs, compression, average priority, and size — along with a **URL composition** breakdown by top directory and declared change frequency. A sitemap that lists URLs no page links to, or that omits pages that matter, is a discovery problem the tab makes visible before it costs indexing. <Screenshot src="/screenshots/spider/spider_sitemap_1.webp" alt="The Site health Sitemap tab with quick-answer cards for existence, total URLs, robots reference, and freshness, above an audit issue flagging URLs found by crawling that are missing from sitemap.xml" caption="The top of the tab: existence, total URLs, robots reference, and freshness, with any audit issue below — here, pages reached by crawling that the sitemap omits." width="3420" height="1758" /> <Screenshot src="/screenshots/spider/spider_sitemap_2.webp" alt="The Sitemap tab's lower panels: crawl coverage counts for in-sitemap-and-crawled, orphans, and in-sitemap-only URLs, the discovered sitemap's metrics, and a URL composition breakdown by directory and change frequency" caption="Crawl coverage separates listed-and-crawled URLs from orphans and uncrawled ones, then breaks the sitemap down by directory and change frequency." width="3420" height="2074" /> ## SSL [#ssl] The **SSL** tab covers the site's transport security. It leads with an **SSL security score** out of 100, then quick answers: whether the site uses **HTTPS**, **days until expiry**, the **TLS version**, and whether **HSTS** is set. The full **certificate** follows — issuer, subject, validity window, chain length and validity, key size, and cipher. These are read once for the site rather than per page. <Screenshot src="/screenshots/spider/spider_security.webp" alt="The Site health SSL tab showing an SSL security score of 80/100, quick-answer cards for HTTPS, days until expiry, TLS version, and an unset HSTS header, above the certificate details — issuer, subject, validity dates, chain length, key size, and cipher" caption="The SSL security score sits above the quick answers and the full certificate; here HTTPS and TLS 1.3 pass, while HSTS is flagged as not set." width="3420" height="2070" /> ## LLMs.txt [#llmstxt] The **LLMs.txt** tab checks the emerging files that guide AI crawlers to the content worth citing: **llms.txt**, its **llms-full.txt** full-content variant, and **ai.txt** crawler directives. Quick answers report which are present and a **completeness** score out of 100, measured against the expected spec shape — an H1 title, a summary blockquote, then link sections. A **spec structure** panel breaks that score down check by check (title, summary, link sections, well-formed links), and **findings** name the specific fix, such as adding a one-line summary blockquote under the title. As ChatGPT, Perplexity, and Gemini send real traffic and citations, a missing or malformed `llms.txt` is a growing gap. <Screenshot src="/screenshots/spider/spider_llms_1.webp" alt="The Site health LLMs.txt tab with quick-answer cards for llms.txt, llms-full.txt, and ai.txt presence and a completeness score, above a spec-structure panel checking the title, summary, link sections, and well-formed links" caption="Quick answers cover llms.txt, llms-full.txt, and ai.txt; the completeness score is graded against the spec shape shown in the structure panel below." width="3420" height="1798" /> <Screenshot src="/screenshots/spider/spider_llms_2.webp" alt="The LLMs.txt tab's file metrics for the served llms.txt — URL, size, lines, link sections, completeness, and llms-full.txt variant — with a findings note to add a one-line summary blockquote under the title" caption="File metrics for the served file, with findings that name the exact fix — here, a missing summary blockquote under the title." width="3228" height="1146" /> <Callout type="info"> Security findings gate more than the padlock icon. An expired certificate or a downgrade off HTTPS undermines trust across every page the audit scored. Treat it as a site-wide blocker, not a cosmetic warning. </Callout> <RelatedDocs hrefs="['/docs/desktop/reports/technical', '/docs/desktop/checks-and-scores', '/docs/desktop/crawler']" /> --- # Social tab URL: https://docs.digispot.ai/docs/desktop/reports/social/ The Social tab validates Open Graph, Twitter/X, and LinkedIn tags and previews how the page looks when shared. The Social tab checks the tags that control how a page looks when shared and previews the share cards before anyone posts. These tags do not affect rankings. But a missing or broken image, title, or description turns a shared link into a bare URL. That directly costs the click-through and referral traffic a social post is meant to earn. ## Status and preview [#status-and-preview] Status dots show whether **Open Graph**, **Twitter card**, and **LinkedIn** are ready. A preview renders the Facebook, Twitter, and LinkedIn share-card mockups from the page's actual tags, so a wrong image or a truncated title is visible before it ships, not after. ## Tag fields [#tag-fields] Two field grids list every tag and flag what is missing: * **Open Graph** — title, description, image (with dimensions and alt), type, locale, site name, and URL * **Twitter / X** — card type, title, description, image and alt, site, and creator A **favicons & app icons** panel checks the favicon, Apple touch icon, and PWA icons. On paid tiers, the **Social AI Audit** reviews the tags and prioritizes fixes. <Callout type="info"> Most platforms fall back to Open Graph tags when their own are absent, so a complete Open Graph set is the priority. The Twitter and LinkedIn cards inherit from it. Fill Open Graph first, then add Twitter-specific tags only where you want a different card. </Callout> <Tip> The image is what a share stands or falls on. Confirm `og:image` is present, at a landscape ratio, and large enough (Facebook and LinkedIn expect roughly 1200×630) using the live preview before treating the tab as clean. </Tip> <Screenshot src="/screenshots/spider/spider_social.webp" alt="Spider Social tab with Open Graph and Twitter validation and share previews" caption="The share previews render from the page's actual tags." width="3420" height="2072" /> <RelatedDocs hrefs="['/docs/desktop/reports/schema', '/docs/desktop/reports/metadata', '/docs/desktop/reports/media']" /> --- # Technical tab URL: https://docs.digispot.ai/docs/desktop/reports/technical/ The Technical tab checks HTTPS, robots, canonical, security headers, cloaking, and the detected technology stack. The Technical tab covers the server- and markup-level signals that affect how a page is crawled, secured, and trusted. These checks decide whether a page can be reached and rendered at all, and whether what a bot sees matches what a browser sees. A content-level audit cannot surface these problems. ## Technical signals [#technical-signals] A field grid reports each signal with a status: * **HTTPS**, **Robots — index**, **Robots — follow**, and **Canonical URL** — the core crawl and index directives * **Hreflang**, **Mobile viewport**, and **Character encoding** * **HSTS** — whether a `Strict-Transport-Security` header is present * **Security headers** — how many of the recommended headers are set, and which are missing * **AI crawler visibility** — a cloaking and render-parity check (see below) ### AI crawler visibility [#ai-crawler-visibility] This check compares what the page serves to a bot over a raw HTTP fetch against what it renders in a browser. It reports a **divergence score** from 0 to 100 where **0 is healthy** (the two match). A high score means significant content appears only after JavaScript runs. That content may never be seen by LLM crawlers such as GPTBot, Claude, and PerplexityBot, or by Googlebot's first render wave. An expandable **static-vs-browser evidence table** breaks the gap down by SEO-weighted signal: words, headings, schema, links, and images. <Callout type="info"> A large static-vs-browser gap is usually a render problem, not deliberate cloaking. It is key content that only exists after JS execution. Either way the effect is the same: crawlers that read raw HTML miss it. Serving that content in the initial HTML (SSR or pre-rendering) is the fix. </Callout> ## Technology stack [#technology-stack] A **technology stack** card lists the detected frameworks, CMS, plugins, analytics, CDN, and libraries, grouped by category with a confidence score. It is the same detection surfaced as "Built with" on the Metadata tab. Here it is shown in full. On paid tiers, the **Technical AI Audit** reviews these signals and prioritizes fixes. <Screenshot src="/screenshots/spider/spider_technical.webp" alt="Spider Technical tab with HTTPS, security headers, cloaking check, and tech stack" caption="The AI-crawler visibility check compares what a bot and a browser each see." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/technical-seo-checklist-for-2025", title: "The ultimate technical SEO checklist" }, { href: "https://digispot.ai/blog/javascript-seo", title: "JavaScript SEO: complete guide for modern web apps" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/metadata', '/docs/desktop/reports/performance', '/docs/desktop/crawler']" /> --- # The Visualizer URL: https://docs.digispot.ai/docs/desktop/reports/visualizer/ The Visualizer maps a crawled site as an interactive graph — color-coded by depth, status, or issues, grouped into clusters, with per-node drill-in and CSV export. The Visualizer maps your site as an interactive, force-directed graph. Every URL the crawl discovered is a node, and internal links are the edges between them. It surfaces structure a table can't: how deep pages sit from the homepage, which act as hubs, and which are orphaned. <Callout type="info"> Open the Visualizer from a crawl — the **Sitemap** tab's Site Structure panel has a **Visualize** action, and it opens as its own view for the run. It can be shared as a link. See [Site health](/docs/desktop/reports/site/). </Callout> ## Color by [#color-by] **Color by** re-shades the graph to answer a specific question: * **Depth** — each ring out from the homepage gets its own hue * **HTTP status** — surface non-200 pages inside the structure * **Top issues** — highlight the sections carrying the most findings * **Inbound / outbound links** — separate hubs (many inbound links) from orphans (zero internal links) The same page looks different under each mode. Reading depth finds pages buried too far from the homepage; reading inbound links finds the orphans no internal link points to. ## Group by clusters [#group-by-clusters] **Group by** collapses the graph into named **territory clusters** by section, so a large site reads as a handful of areas rather than thousands of dots. Each cluster is clickable. * **Drill in** to expand a cluster and see the pages inside it * **Export CSV** to download a cluster's URLs with their `url`, `depth`, `section`, and `sitemap` columns Clustering is what keeps the graph legible on a site with thousands of pages, where an ungrouped node cloud would be unreadable. ## Filters and labels [#filters-and-labels] Narrow the map to focus on one part of the structure: * **Depth** — show a single depth ring, or all depths at once * **Sitemap file** — filter to the URLs in one sitemap * **Label density** — set how many page names print on the map, since every node is hoverable regardless of whether its label shows ## Inspecting a node [#inspecting-a-node] **Double-click a node** to drill in and inspect a single page: * Its **inbound** and **outbound** internal links * For a weakly linked page, suggestions for **where to add a link** to pull it out of the shallows <Tip> Color by inbound links, then look for nodes with no edges into them — those are the orphans. A page with zero internal links is one the crawler only found through the sitemap, and one Google may struggle to discover or rank. </Tip> <Screenshot src="/screenshots/spider/spider-visualizer.webp" alt="Spider Visualizer showing the site as an interactive graph of linked pages, color-coded and clustered by section" caption="The Visualizer maps the crawl as an interactive graph — recolor, cluster, and drill into any node." width="3420" height="2074" /> <RelatedDocs hrefs="['/docs/desktop/reports/site', '/docs/desktop/reports/links', '/docs/desktop/reports']" /> --- # Create URL: https://docs.digispot.ai/docs/cloud/content-studio/create/ The Create screen generates a new AI-written article, grounded in your project data. The Create screen is where a new article begins. A brief goes in and a full draft comes out, grounded in the active project's own context rather than written blind. The header shows how many articles the current AI-credit balance can still afford, so the cost of a generation is visible before it runs. <Callout type="info"> Content Studio is gated on the **Free** plan. It requires **Starter** or above. Each generation is an affordability check against the **AI credit** pool. If the balance can't cover an article, Create shows an upgrade or top-up prompt instead of the form. The Library stays viewable even when credits are exhausted. </Callout> ## The brief [#the-brief] The form collects the inputs the model uses to shape the draft. Most have sensible defaults, so a topic alone is enough to start. | Field | What it controls | | ------------------------------------- | -------------------------------------------------------------------------- | | **Topic** | The subject of the article — the one required field. | | **Keywords** | Terms to target, comma-separated, woven into the draft. | | **Page type** | Blog, service, home, category, or landing — sets the structure and intent. | | **Tone** | Informative, conversational, professional, persuasive, or entertaining. | | **Target audience** | General, beginners, intermediate, experts, or business. | | **Word count** | A slider from 300 to 2,500 words. | | **Include FAQ** | Appends an FAQ section, on by default. | | **Meta description** and **CTA text** | Optional snippet and call-to-action copy. | | **Competitor URLs** | Reference pages the model reads to match or beat. | ## Grounding and model tier [#grounding-and-model-tier] Two controls decide how the draft is produced. * **Personalization** — **fully branded** ties the piece to the project's real products, audience, and audit context. **Semi-generic** keeps it looser and more broadly reusable. * **Model tier** — **Basic** for standard drafts. **Advanced** for higher-quality output at a higher credit cost. ## From draft to editor [#from-draft-to-editor] Generation runs through visible phases and can be stopped mid-run. When it finishes, the article moves into the [editor](/docs/cloud/content-studio/edit/) for section-level refinement, internal linking, and review. Longer or advanced-tier pieces first run through a plan-approval step — see [Plans](/docs/cloud/content-studio/plans/). <Tip> Starting from a gap in [Content opportunities](/docs/cloud/content-opportunities/) pre-fills the topic, keywords, audience, and suggested length from that gap's analysis. The result is a faster, better-targeted brief than writing one from scratch. </Tip> <RelatedDocs hrefs="['/docs/cloud/content-studio/edit', '/docs/cloud/content-studio/plans', '/docs/cloud/content-opportunities']" /> --- # Edit URL: https://docs.digispot.ai/docs/cloud/content-studio/edit/ The Edit screen refines a draft — section by section — with internal-link suggestions and research insights. The Edit screen is where a draft becomes publish-ready. The article opens as individually addressable sections rather than one block, so structure, wording, and internal links can be worked on part by part. The header keeps a running **section count** and **total word count** as the piece changes. ## Section manager [#section-manager] The article is broken into ordered sections, each with its own title, type, and word count, and each editable on its own. * **Rewrite** a single section without touching the rest * **Reorder** sections by drag; the change saves and the numbering renumbers 1..n * **Add** a new section, which lands at the end with the next index * **Delete** a section, after which the remaining ones renumber automatically Working at the section level keeps a targeted regeneration cheap and contained, rather than re-running the whole article for one weak paragraph. ## Internal links and research [#internal-links-and-research] Two aids sit alongside the draft. * **Internal link suggestions** — relevant pages on the same site to link to. The new piece connects into the existing structure instead of orphaning. * **Research insights** — supporting data surfaced against the topic. It strengthens claims as sections are edited. ## Review before publish [#review-before-publish] Longer and advanced-tier articles pass through a **plan-approval** step before the full draft is generated, so a reviewer can sign off on the outline first. The states an article moves through, and how to act on each, are covered in [Plans](/docs/cloud/content-studio/plans/). <Tip> Save section reorders before regenerating. Order is persisted server-side, and a regeneration reads the saved order. Reordering after a regenerate without saving first can leave the two out of sync. </Tip> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/plans', '/docs/cloud/content-studio/library']" /> --- # Content Studio URL: https://docs.digispot.ai/docs/cloud/content-studio/ Content Studio is the AI content suite — create and edit articles, generate infographics, and manage everything through plans and a library. Content Studio is the platform's AI content suite. It produces publish-ready articles and infographics, grounded in your audit and project data. <Callout type="info"> Content Studio is not available on the free plan, and its actions spend AI credits. See [Plans & billing](/docs/cloud/billing/). </Callout> <Screenshot src="/screenshots/cloud/content_studio.webp" alt="Cloud Content Studio for creating and editing AI-written articles" caption="Content Studio — create and edit AI-written articles." width="3420" height="1890" /> ## The workflow [#the-workflow] <SectionCards hrefs="[ '/docs/cloud/content-studio/create', '/docs/cloud/content-studio/edit', '/docs/cloud/content-studio/infographics', '/docs/cloud/content-studio/library', '/docs/cloud/content-studio/plans', ]" /> ## Ask Digispot [#ask-digispot] **Ask Digispot** — the AI SEO Analyst — is the assistant that answers questions grounded in your actual audit data. It is reachable from anywhere in the platform. Ask it what to fix first, which pages are losing traffic, or what changed since the last run. It responds from your project's data rather than generic advice. Conversations are saved. Each message spends an AI credit. <RelatedDocs hrefs="['/docs/cloud/content-opportunities', '/docs/cloud/research', '/docs/cloud/billing']" /> --- # Infographics URL: https://docs.digispot.ai/docs/cloud/content-studio/infographics/ The Infographics studio generates branded infographics with control over palette, icons, typography, and dimensions. The Infographics studio turns an existing article into a branded visual. Pick a source article, then control palette, type, icons, and dimensions so the output matches the site it will sit on. <Callout type="info"> Like the rest of Content Studio, infographics require an active paid plan and aren't available on **Free**. An infographic is built from a saved article, so generate the article first, then select it here. </Callout> ## Source article [#source-article] Generation starts from an **article selector** listing the project's saved pieces. The chosen article's content is parsed into the infographic's structure, so the visual reflects the article rather than a blank template. ## Palette, type, and icons [#palette-type-and-icons] Three controls set the look, each with curated presets. * **Color palette** — named presets such as *Executive Navy*, *Minimal Scandinavian*, and *High Contrast Pro*. They are grouped from corporate to creative, to keep the graphic on-brand. * **Typography** — curated font families organized into categories (sans-serif, serif, display), each with a readability note * **Icons** — an icon selector for the visual accents on each data point ## Dimensions [#dimensions] The output aspect ratio is chosen from presets, each mapping to a fixed pixel size: | Preset | Aspect ratio | Size | | ------------------------------ | ------------ | ----------- | | **Blog Infographic** (default) | 4:3 | 1200 × 900 | | **Long-form** | 2:5 | 1000 × 2500 | | **Square** | 1:1 | 900 × 900 | | **Blog Cover / Hero** | 16:9 | 1600 × 900 | <Tip> Match the dimension to where the graphic will live: **Long-form** for an in-body explainer readers scroll, **Square** for social, and **Blog Cover / Hero** for the header image. The 4:3 default suits a standard mid-article infographic. </Tip> <Screenshot src="/screenshots/cloud/cloud_infographics.webp" alt="Cloud Content Studio infographic generation with palette, icons, and typography controls" caption="Generate infographics with control over palette, icons, and typography." width="3420" height="1894" /> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/library', '/docs/cloud/content-studio']" /> --- # Library URL: https://docs.digispot.ai/docs/cloud/content-studio/library/ The Library holds every piece of AI-generated content, so you can find, revisit, and manage what you've produced. The Library is where every article generated for a project lives, so nothing produced is lost between sessions. It's scoped to the **active project** — switch projects and the list swaps to that project's content. ## Browsing the library [#browsing-the-library] Each entry lists the article with its **type** (blog, service, and the rest), when it was created and by whom, and how many **infographics** are attached to it. A **search** box filters the list by keyword, and results page in batches. ## Acting on an article [#acting-on-an-article] From a library entry the article can be: * **Opened** in the [editor](/docs/cloud/content-studio/edit/) to continue refining sections * **Used as a source** in the [Infographics](/docs/cloud/content-studio/infographics/) studio to build a visual from it * Reviewed for its meta description, research insights, and attached infographics <Callout type="info"> The Library stays viewable even when the **AI credit** balance is exhausted. Running out of credits stops new generation, not access to what's already produced. It does require an active paid plan. Content Studio is unavailable on **Free**. </Callout> <Screenshot src="/screenshots/cloud/content_library.webp" alt="Cloud Content Studio Library listing generated articles" caption="Every generated article, scoped to the active project." width="3414" height="1762" /> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/plans', '/docs/cloud/content-studio']" /> --- # Plans URL: https://docs.digispot.ai/docs/cloud/content-studio/plans/ Content plans organize article work through a review workflow — from draft to approved to completed. A content plan is the outline an article is approved against before the full draft is written. Rather than generating a long piece blind, the studio produces a plan, holds it for review, and only writes the article once the plan is signed off. A team drafts, approves, and completes content in a controlled flow instead of a loose pile of drafts. The Plans screen lists every saved plan for the active project and lets you resume one that's still in progress. ## Statuses [#statuses] Each plan carries a status that drives what you can do with it. | Status | Meaning | Next action | | -------------------- | ----------------------------------------------------- | ---------------------------------------- | | **Draft** | The plan exists but hasn't been submitted for review. | Continue building it. | | **Pending approval** | Submitted and awaiting sign-off. | Continue — review and approve or reject. | | **Approved** | Signed off; ready to generate the article. | Continue to generation. | | **Rejected** | Turned down in review. | Revise or discard. | | **Completed** | The article has been generated from the plan. | Open the article in the Library. | | **Expired** | Aged out before completion. | Start a new plan. | Plans in **pending approval** or **approved** show a **Continue** action to pick up generation where it left off. A **completed** plan links through to its generated article. <Callout type="info"> Plans belong to Content Studio and require an active paid plan. Approving and completing a plan spends **AI credits** on the article it generates. The plan and review steps organize the work, but the draft itself is the credited action. </Callout> <Screenshot src="/screenshots/cloud/content_plans.webp" alt="Cloud Content Studio Plans with plan statuses" caption="Content plans and their approval statuses." width="3420" height="1640" /> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/edit', '/docs/cloud/content-studio/library']" />

# Digispot AI Docs Documentation for Digispot AI — SEO Insights (free Chrome extension), SEO Spider (desktop app), and the Cloud Platform for teams. --- # Introduction URL: https://docs.digispot.ai/docs/ Digispot AI comes as three products — SEO Insights (free Chrome extension), SEO Spider (desktop app), and the Cloud Platform for teams. Digispot AI is three distinct products sharing one account. Start free in your browser, move to the desktop app when you need whole-site crawls, and move to the cloud when a team needs to work on audits together. ## Which product is right for you? [#which-product-is-right-for-you] | | SEO Insights | SEO Spider | Cloud Platform | | -------------------- | ---------------------------------------------- | --------------------------------------- | -------------------------------- | | **Type** | Chrome extension | Desktop app | Cloud | | **Best for** | Page-level audits and quick competitive checks | Whole-site crawling on your own machine | Teams auditing at scale together | | **Audience** | Anyone | Freelancers & consultants | SEO teams & agencies | | **Scope** | One page at a time | Whole site — up to unlimited pages | Shared projects across a team | | **Checks** | 150+ per page | 300+ per page | 300+ per page | | **Runs on** | Chrome & Chromium | Mac & Windows | Any browser, no install | | **Where audits run** | Your browser | Your machine — data stays local | Digispot's servers | | **Price** | Free forever | Free to start, paid plans from Scout | Free plan, paid from Starter | Both **SEO Spider** and the **Cloud Platform** support the MCP server and work with AI agents. Not sure where to start? The [Chrome extension](/docs/chrome-extension/) is free and takes under a minute to install — no signup needed. ## Three products, one account [#three-products-one-account] The same Digispot account activates all three surfaces. Connect it to the Chrome extension to unlock managed AI and premium lookups, activate the desktop Spider with a plan or a free trial, and sign in to the Cloud Platform from any browser. ## Start here [#start-here] --- # Connecting an AI Model URL: https://docs.digispot.ai/docs/chrome-extension/ai-setup/ Bring your own API key (BYOK) to enable AI recommendations, prompt automation, and AI Chat in the extension. The extension uses **BYOK**, short for Bring Your Own Key. You connect your own AI provider API key. There are no extension-imposed usage limits, and you pay only for what you use, typically around **$0.01–0.05 per page**. Every audit check works without AI. Connecting a key adds recommendations, one-click fixes, prompt automation, and AI Chat. Keys are stored in your browser's encrypted storage. They never leave your device and never touch Digispot's servers. Calls go directly from your browser to the provider. ## Supported providers [#supported-providers] Connect any one of four providers with your own key: **OpenAI**, **Anthropic**, **Google (Gemini)**, and **DeepSeek**. One provider is enough. Each offers a range of models. There is a flagship tier for the deepest analysis, a balanced tier, and a fast, economical tier for high-volume auditing. Since you pay the provider directly, the model you pick sets your cost and speed. Providers add and retire model versions over time. For that reason, the extension's model dropdown, not a fixed list, is the source of truth for exactly which models you can select today. Create a key in your provider's console: OpenAI, Anthropic, Google AI Studio, or DeepSeek. Any one provider is enough. Open the extension's settings, choose your provider, and paste the key. Select any model from your provider's dropdown. Since you pay your provider directly, cost and speed depend on which model you choose. The **Output Capacity** slider sets how long each response runs, with four levels: Brief, Balanced, Detailed, and Comprehensive. Use it to trade depth against token cost. ## AI Chat [#ai-chat] Once a key is connected, AI Chat opens alongside your audit results with full context of the page's SEO data. That covers all 150+ results, including metadata, headings, content, schema, links, and Core Web Vitals. Because it sees the actual audit output, answers are page-specific rather than generic: * "What are the top issues hurting my rankings?" * "Rewrite my meta description for higher CTR" * "Suggest internal linking opportunities" * "How do I fix this schema error?" In SERP Intelligence mode, AI Chat answers questions about the search landscape and competitors instead. ## Prompt automation [#prompt-automation] All 150+ audit results feed automatically into prompt templates you define. This lets you run repeatable analyses on any page with one click, without writing code or wiring up an external automation tool. ### Template placeholders [#template-placeholders] Templates use placeholders that are replaced with the current page's data: | Placeholder | Inserts | | --------------- | --------------------- | | `{{content}}` | Page content | | `{{keywords}}` | Detected keywords | | `{{headings}}` | H1–H6 structure | | `{{metadata}}` | Title and description | | `{{schema}}` | Structured data | | `{{images}}` | Image analysis | | `{{links}}` | Link data | | `{{pagespeed}}` | Core Web Vitals | Each audit type has its own applicable placeholders. Write a template once, then reuse it across pages. Good first templates: generate meta descriptions from page content, check search-intent match, or draft the missing schema for a page. ## PageSpeed API key (optional) [#pagespeed-api-key-optional] Core Web Vitals come from Google PageSpeed Insights. The extension works without a key. Adding a free one from the Google Cloud Console removes rate limits and gives faster, more detailed analysis. Like AI keys, it is stored encrypted locally and used only for direct calls to Google. API keys are credentials tied to your billing. Treat them accordingly: do not paste them into shared machines, and rotate any key you suspect is exposed. --- # Managed AI (Extension Key) URL: https://docs.digispot.ai/docs/chrome-extension/extension-key/ Connect a free Digispot account with an Extension Key to run AI through Digispot instead of your own key, and unlock server-side field data, PageSpeed, and domain age. The extension's AI features can run through your own provider or through Digispot. [Bring your own key (BYOK)](/docs/chrome-extension/ai-setup/) connects a provider you already pay for. The free **Digispot Extension Key** is the other option. It runs AI through your Digispot account. It also unlocks a few server-side data lookups the browser cannot fetch on its own. Both are optional. Every audit check works without either. ## BYOK vs Extension Key [#byok-vs-extension-key] | | BYOK | Extension Key | | ------------------- | ---------------------------------------- | ------------------------------------------------ | | **You provide** | Your own provider API key | A free Digispot account | | **Where AI runs** | Direct from your browser to the provider | Through your Digispot account | | **AI billing** | You pay your provider directly | Managed by Digispot | | **Premium lookups** | — | CrUX field data, PageSpeed lab tests, domain age | When an Extension Key is connected, **Digispot AI (managed)** becomes your active provider and your own BYOK providers are turned off. Disconnect the Extension Key to switch back to your own key. ## Connect an Extension Key [#connect-an-extension-key] Sign in at [app.digispot.ai](https://app.digispot.ai), go to **Settings → Chrome extension**, and select **Generate Key**. Copy the value. It starts with `ext_`. Open the extension's **Config → Account** panel, paste the key into the **Extension Key** field, and select **Connect**. The extension validates it and switches AI to the managed provider. ## Premium lookups [#premium-lookups] Some signals need a server call that a browser extension cannot make directly. With an Extension Key connected, the extension can fetch them through Digispot, on demand. They are fetched only when you ask for them. Domain age, for example, shows a **Check domain age** button rather than fetching automatically. The two performance lookups live under **Speed → Performance Analysis**. They sit alongside a **Live** tab that the extension can always measure locally. That way you can compare a browser-measured page load against real field data and a fresh lab run in one place. ### Live measurement (no key needed) [#live-measurement-no-key-needed] The **Live** tab measures Core Web Vitals from your own browser on the current page load, so it works without an Extension Key. It is the local baseline that the premium tabs are compared against. ### CrUX field data [#crux-field-data] **CrUX field data** is aggregated real-user Core Web Vitals from Google's Chrome User Experience Report over the last 28 days. It is a server lookup the browser cannot make on its own. Results are cached for 24 hours. ### PageSpeed lab test [#pagespeed-lab-test] The **Lab Test** tab triggers a fresh Lighthouse run on Google's servers for desktop and mobile. This is a synthetic, controlled page load. It is useful for diagnosing what each render pass costs when field data is unavailable. ### Domain age [#domain-age] **Domain age** is an E-E-A-T trust signal for the site. It runs only on your click, via a **Check domain age** button, rather than fetching automatically. Core audits are fully local. Managed AI and premium lookups are different: they make requests through Digispot's servers. That is the trade-off for not managing your own API keys or vendor access. See [Privacy](/docs/chrome-extension/privacy/). --- # FAQ URL: https://docs.digispot.ai/docs/chrome-extension/faq/ Common questions about Digispot AI SEO Insights — pricing, privacy, browser support, AI keys, and how it differs from SEO Spider. Common questions about SEO Insights: pricing, privacy, browser support, AI keys, and how the extension relates to the desktop SEO Spider. For setup, see [Install the extension](/docs/chrome-extension/install/). ## Is it really free forever? [#is-it-really-free-forever] Yes. The core extension is free, with no trial period and no signup. That includes 150+ SEO checks, schema validation, Core Web Vitals monitoring, and export. Optional premium features and platform integrations may be added in future, but the base extension will remain free. ## Do I need an account or credit card? [#do-i-need-an-account-or-credit-card] No. Install from the Chrome Web Store and start immediately. No registration, no email, no credit card. ## Which browsers are supported? [#which-browsers-are-supported] Google Chrome and all Chromium-based browsers: Microsoft Edge, Brave, Opera, and Vivaldi. All install from the same Chrome Web Store listing. ## Does it work on any website? [#does-it-work-on-any-website] Yes, on any public website — your own, competitors', clients', or prospects'. Browser-internal pages such as `chrome://` cannot be audited. ## How does it work? [#how-does-it-work] Select the extension icon on any page. It runs 150+ checks in under 60 seconds and groups results by category with pass/fail indicators and recommendations. The extension renders pages in a real browser engine, like Googlebot. As a result, it detects JavaScript-rendered content and schema. ## What makes it different from other SEO extensions? [#what-makes-it-different-from-other-seo-extensions] Most free SEO extensions offer basic checklists. This one adds schema graph visualization, AI-powered content analysis, industry-specific recommendations across 38+ sectors, live heading editing, Core Web Vitals integration, video SEO audits, and export. ## Do I need an AI API key? [#do-i-need-an-ai-api-key] No. Every audit check works without one. A key adds AI recommendations, one-click fixes, prompt automation, and AI Chat. See [Connecting an AI model](/docs/chrome-extension/ai-setup/). ## Are my API keys safe? [#are-my-api-keys-safe] Yes. All API keys, from AI providers and Google PageSpeed alike, are stored in your browser's encrypted storage. They never leave your device and never reach Digispot's servers. They are used only for direct calls from your browser to the respective service. ## How is my data encrypted? [#how-is-my-data-encrypted] API keys and settings are encrypted using browser-native standards and stored in Chrome's secure storage APIs. All connections use HTTPS/TLS. The extension follows Chrome Web Store security best practices, undergoes regular security reviews, and has no external dependencies that could leak data. Your information stays on your device, encrypted at rest and in transit. ## Do you collect my data? [#do-you-collect-my-data] No. Digispot does not collect, store, or transmit usage data, API keys, audit results, or browsing activity. The extension operates entirely locally. Analysis happens on your device or goes directly to services you choose, such as OpenAI or Google. Digispot does not track which pages you audit or how you use the extension. ## Do I need a PageSpeed API key? [#do-i-need-a-pagespeed-api-key] It is optional. Core Web Vitals work without one. Adding a free key from the Google Cloud Console removes rate limits and gives faster, more detailed analysis. ## Can I export reports? [#can-i-export-reports] Yes, in TXT format, as a human-readable summary. You can also screenshot Visualize Mode to document issues visually on the page. ## Can I edit headings in the extension? [#can-i-edit-headings-in-the-extension] Yes, with no CMS needed. The live heading editor shows your H1–H6 structure, offers AI rewrite suggestions, and lets you edit directly with a real-time preview. ## What is AEO? [#what-is-aeo] Answer Engine Optimization. It means optimizing for AI platforms such as ChatGPT, Perplexity, Claude, and Gemini. The extension checks structured content formatting, question-answer patterns, entity recognition, topical authority signals, and scannability. ## How is the extension different from SEO Spider? [#how-is-the-extension-different-from-seo-spider] The extension is a free SEO assistant for **page-level** audits. Use it for quick checks, learning, and competitive analysis. It runs 150+ checks on whatever page you are viewing. **Digispot AI SEO Spider** is for operating at scale. It runs **300+ checks per page** across an entire site, crawled in **mobile, tablet, and desktop** modes. Findings are weighted by Google Search Console and GA4, so you fix what is actually costing traffic. It also adds content gap discovery, internal linking, backlink monitoring, and scheduled crawls. Optimizing a few pages? The extension is enough. Competing for organic revenue at scale? You want Spider. ## When do I need SEO Spider? [#when-do-i-need-seo-spider] Consider it if you are auditing 50+ pages weekly, manually comparing mobile versus desktop, regularly exporting reports for multiple clients, or need systematic content gap discovery. Solo? [SEO Spider](/docs/desktop/) runs unlimited crawls on your own machine. On a team? The [Cloud Platform](/docs/cloud/) adds shared projects, GSC and GA4, and audits that run on Digispot's servers. --- # Chrome Extension URL: https://docs.digispot.ai/docs/chrome-extension/ How to install and use Digispot AI — SEO Insights, the Chrome extension for on-page audits and SERP analysis. **SEO Insights** has two modes. The **on-page auditor** checks the page you're currently viewing. **SERP Intelligence** reads a Google results page instead. It breaks the results down by organic listings, AI Overview citations, competitors, and rich results. Both modes can use an optional AI model. The model adds recommendations, one-click fixes, and a chat panel. This section covers installation, each mode, and the full list of checks. To start straight away, install it from the [Chrome Web Store](https://chromewebstore.google.com/detail/digispot-ai-seo-insights/njjbmbinhpipcdocojjniahjgdoljohg) or read about [Digispot AI — SEO Insights, the free Chrome extension](https://digispot.ai/tools/google-chrome-extension-seo-insights). It is free, with no account and no card. Works in Google Chrome and all Chromium-based browsers: Microsoft Edge, Brave, Opera, and Vivaldi. ## Two modes [#two-modes] The extension operates in two distinct modes. Each has its own AI chat. Audits the page you are currently viewing. * 150+ browser engine checks across 11 audit categories * Real browser rendering, like Googlebot, so JavaScript-rendered content and schema are detected * Content and keyword analysis with AI * AI recommendations and 1-click fixes * AI Chat: ask anything about the page's on-page SEO Decodes a Google search results page. * AI Overview citation analysis * Competitor ranking signals * Local pack and map results * Featured snippets and rich results * Breaks down organic results, ads, AI-cited sources, forums, shopping, and video results * AI Chat: ask about the SERP landscape and competitors See [SERP Intelligence](/docs/chrome-extension/serp-intelligence/). ## Three viewing modes [#three-viewing-modes] Switch based on what you are doing. Most people start in Popup for a quick check. They switch to Visualize to demonstrate issues to someone. They use Fullscreen for detailed analysis. | Mode | What it does | Best for | | -------------- | ------------------------------------------------------ | ------------------------------------------------- | | **Popup** | Quick audit in a small window without leaving the page | Fast spot checks | | **Visualize** | Overlays issues directly on the webpage | Showing clients or developers exactly what to fix | | **Fullscreen** | Deep analysis with side-by-side page comparison | Detailed audits and full reports | Light and dark themes are both supported. ## What it audits [#what-it-audits] 150+ checks across 11 categories. Each has its own panel in the results. | Category | Covers | | --------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Content Intelligence** | Search intent detection, industry recommendations (38+ sectors), keyword stuffing, readability, competitor comparison | | **Metadata Audit** | Title length and keyword placement, meta description, canonical, robots directives, SERP preview | | **Heading Structure** | H1–H6 hierarchy, AI rewrite suggestions, live editing, keyword distribution, missing levels | | **Schema Markup** | Interactive schema graph, Google requirements validation, competitor schema, missing schema, developer export | | **Keyword Intelligence** | Density analysis (1/2/3-word), related keywords and entities, significance scoring, authority correlation | | **Image SEO** | Alt text, WebP/AVIF recommendations, lazy loading, file size, LCP impact | | **Video SEO** | Platform detection (YouTube, Vimeo, Wistia), VideoObject schema, thumbnails, transcripts, rich result eligibility | | **Link Architecture** | Internal link depth, anchor text, broken links, redirect chains, link equity flow | | **Social Optimization** | Open Graph, Twitter Cards, live social preview, image dimensions | | **Local SEO** | NAP consistency, LocalBusiness schema, Google Maps, Place ID, location keywords | | **Core Web Vitals & Speed** | LCP, INP, CLS, mobile vs desktop, large images, render-blocking resources | Need this across your whole site? The extension audits one page at a time, in your browser's viewport. **Digispot AI SEO Spider** runs **300+ checks per page** across an entire site, in **mobile, tablet, and desktop** modes, with Google Search Console and GA4 data weighting what to fix first. ## Explore the docs [#explore-the-docs] ## Privacy [#privacy] The extension runs entirely locally in your browser. Digispot does not collect, store, or transmit your usage data, API keys, audit results, or browsing activity. Analysis happens on your device, or goes directly to services you choose, such as OpenAI or Google. --- # Install the Extension URL: https://docs.digispot.ai/docs/chrome-extension/install/ Install Digispot AI — SEO Insights from the Chrome Web Store and run your first on-page audit or SERP analysis in under a minute — no account, no card. **SEO Insights** is Digispot's free browser extension. It audits the page you are on with 150+ checks and analyzes Google results pages. Everything runs in-browser using Chrome's own rendering engine. There is **nothing to install beyond the extension**, no account to create, and nothing to pay for. The extension has two modes that switch automatically: the **On-Page SEO Auditor** on any normal page, and **SERP Intelligence** on a Google results page. Core auditing needs no signup. AI features and server-side lookups are optional add-ons covered in the last two steps. ## Before you begin [#before-you-begin] | What | Do you need it? | | -------------------------------------------- | --------------------------------------------------------------------------- | | **This extension** | A Chromium browser is all you need to start | | **[SEO Spider desktop app](/docs/desktop/)** | Optional. Escalate a single page to a whole-site crawl. **Free Scout tier** | | **[Cloud Platform](/docs/cloud/)** | Optional. Run audits on Digispot's servers and share them with a team | All three share one Digispot account if you later connect one, but the extension works fully on its own. *** ## Step 1 — Install and run your first audit [#step-1--install-and-run-your-first-audit] Open the [Digispot AI — SEO Insights listing](https://chromewebstore.google.com/detail/digispot-ai-seo-insights/njjbmbinhpipcdocojjniahjgdoljohg) directly, or search **digispot ai chrome extension**. The Chrome Web Store listing ranks at the top. [Digispot AI — SEO Insights, the free Chrome extension](https://digispot.ai/tools/google-chrome-extension-seo-insights) covers features and screenshots before you install. On the listing, select **Add to Chrome**, then confirm. Chromium-based browsers install from the same listing: Edge, Brave, Opera, and Vivaldi. Select the extensions icon in the toolbar, then pin Digispot so the icon stays visible. You will be clicking it often. Navigate to any page and select the Digispot icon. The extension runs 150+ checks across 11 categories in under 60 seconds, then groups the results with pass/fail indicators. It renders the page the way Googlebot does, so it catches JavaScript-injected content that source-only tools miss. ## Step 2 — Learn the viewing modes [#step-2--learn-the-viewing-modes] The same audit data renders three ways. Most people start in **Popup** for a quick check. They switch to **Visualize** to show an issue in context on the page. They use **Fullscreen** for a deep audit with charts and AI side by side. See [Viewing modes & overlays](/docs/chrome-extension/viewing-modes/) for the on-page badge system that marks headings, images, and links directly on the page. ## Step 3 — Analyze a Google results page (SERP Intelligence) [#step-3--analyze-a-google-results-page-serp-intelligence] On any of the 17 supported Google country domains, the extension switches automatically to **SERP Intelligence**. It reads the results page and breaks it down by result type: organic, ads, local pack, and AI Overview. This shows you what already ranks for a query. See [SERP Intelligence](/docs/chrome-extension/serp-intelligence/) for the full breakdown of ranking signals and competitor analysis. ## Step 4 — Add AI (optional) [#step-4--add-ai-optional] Connect an AI provider to unlock AI recommendations, one-click fixes, and AI Chat with full page context. This is optional, since every audit check works without it. You have two paths: * **Bring your own key (BYOK):** paste an OpenAI, Anthropic, Google, or DeepSeek key. Requests go directly from your browser to that provider, never through Digispot. * **Digispot Extension Key:** a free managed option that also unlocks server-side CrUX, PageSpeed, and Domain Age lookups. See [Connecting an AI model](/docs/chrome-extension/ai-setup/) for BYOK setup and [Managed AI](/docs/chrome-extension/extension-key/) for the Extension Key. ## Requirements [#requirements] | | | | --------------------- | -------------------------------------------------------------------------- | | **Browser** | Google Chrome, or any Chromium-based browser (Edge, Brave, Opera, Vivaldi) | | **Account** | None for core auditing | | **Payment** | None | | **AI API key** | Optional. Only for AI features, or use a free Extension Key | | **PageSpeed API key** | Optional. Removes rate limits on Core Web Vitals | The extension works on any public website: your own, a competitor's, a client's, or a prospect's. It is equally useful for auditing pages you do not control. ## Verify it is working [#verify-it-is-working] Open any content-heavy page and select the extension icon. You should see results grouped into categories such as Metadata Audit, Heading Structure, and Core Web Vitals. If nothing appears, confirm the extension is enabled at `chrome://extensions`. Also confirm you are on an `http://` or `https://` page. Browser-internal pages like `chrome://` cannot be audited. ## When to reach for the other products [#when-to-reach-for-the-other-products] The extension audits one page at a time. Sometimes a single-page finding turns out to be site-wide, such as a broken template or a missing schema type across every product page. In that case, escalate: * **[SEO Spider desktop app](/docs/desktop/)** crawls the whole site on your own machine, applying the same checks across every URL. The **Scout** tier is free: 100 pages per crawl, no card. * **[Cloud Platform](/docs/cloud/)** runs those crawls on Digispot's servers and shares the reports with a team. --- # Privacy & Data URL: https://docs.digispot.ai/docs/chrome-extension/privacy/ How the extension handles your data — audits run locally, no signup, no tracking, and API keys are stored encrypted on your device. The extension runs entirely on your device. Core audits are local, there is no account to create, and Digispot does not receive any data about what you audit unless you explicitly opt into a feature that requires it. ## Audits run locally [#audits-run-locally] When you audit a page, the extension reads the live page in your browser. It runs all 150+ checks on your machine. Digispot does not collect, store, or transmit your audit results, API keys, browsing activity, or which pages you audit. The analysis never leaves the browser session. ## No account or signup required [#no-account-or-signup-required] The core extension works with **no signup, no email, and no credit card**. Install from the Chrome Web Store and audit any page immediately. Creating a Digispot account is optional. It unlocks managed AI and premium server-side lookups, but none of those fire unless you actively connect a key. ## How API keys are stored [#how-api-keys-are-stored] If you connect an AI provider (BYOK) or a PageSpeed API key, those keys are stored in Chrome's **encrypted browser storage**. This uses `chrome.storage.sync` with AES-GCM encryption, falling back to `chrome.storage.local` on overflow. The keys never reach Digispot's servers. When you make an AI request, it goes directly from your browser to the provider you chose — OpenAI, Anthropic, Google, or DeepSeek. It does not pass through any Digispot infrastructure. API keys are credentials tied to your billing account. Do not paste them on shared machines. If a key is exposed, rotate it immediately in your provider's dashboard. The extension has no record of it to revoke. ## Permissions the extension uses [#permissions-the-extension-uses] | Permission | Why it's needed | | -------------- | ------------------------------------------------------------------------------ | | `activeTab` | Read the current page's DOM to run checks — only fires when you click the icon | | `scripting` | Inject overlay badges and apply live heading edits | | `storage` | Save your settings, API keys, and cached results locally | | `contextMenus` | Add the right-click "Open in Fullscreen" entry | An **optional** broad host permission (`https://*/*`) is requested lazily. It only fires when a feature that needs full-page access runs for the first time on a given site: Fullscreen mode, Live CWV, or heading Apply. It is never requested in Popup mode. You can deny it without losing any other functionality. ## When data does leave your device [#when-data-does-leave-your-device] Everything is opt-in. Three scenarios involve requests leaving the browser: | Scenario | Where the request goes | Opt-in required | | ------------------------------------------ | --------------------------------------------------------------------- | ------------------------------------------------------------ | | **BYOK AI audit or chat** | Directly to your AI provider (OpenAI / Anthropic / Google / DeepSeek) | Connect an API key in Config → AI Provider | | **Managed AI via Extension Key** | Through your Digispot account | Connect an `ext_…` key in Config → Account | | **CrUX, PageSpeed, or Domain Age lookups** | Through your Digispot account | Extension Key required; lookups are on-demand, not automatic | All on-page SEO checks run entirely on your device, with none of the above. This covers every panel in the extension. --- # SERP Intelligence URL: https://docs.digispot.ai/docs/chrome-extension/serp-intelligence/ Decode any Google search results page — who ranks, which sources AI Overviews cite, and what content gaps you can exploit. Open a Google search results page and the extension switches automatically. It moves from auditing a single page to decoding the **entire result set**: every organic result, ad, local listing, and AI Overview citation on the page. ## Automatic activation [#automatic-activation] SERP mode turns on by itself the moment you land on a Google search results page. There is nothing to toggle. It works across **17 Google country domains**: | | | | | | ------------ | ------------- | ------------ | ------------- | | google.com | google.co.uk | google.ca | google.com.au | | google.co.in | google.de | google.fr | google.es | | google.it | google.com.br | google.co.jp | google.co.kr | | google.nl | google.pl | google.ru | google.se | | google.ch | | | | On any other page, including non-Google search engines, the extension stays in on-page audit mode. See [On-Page Panels](/docs/chrome-extension/audit-categories/). ## What it extracts [#what-it-extracts] SERP mode parses the whole page in a single pass, deduplicates results, and classifies each one: * **Organic results**: who ranks, with rich snippets, sitelinks, and breadcrumbs * **AI Overview citations**: which sources Google's AI Overview references * **Ads**: text and shopping ads * **Local pack**: map listings, ratings, hours, and phone numbers * **Featured snippets** and knowledge panels * **People Also Ask** * **Video carousels** and **top stories** * **Discussions**: forums such as Reddit and Quora * **Shopping** carousels * **Related searches** ## Overlay badges [#overlay-badges] SERP mode draws numbered badges directly onto the live search page so you can see the result composition at a glance. Badges are color-coded and numbered by type. Organic results, AI citations, local pack, ads, video, discussions, and shopping each get their own sequence. They persist as you scroll and survive Google's lazy-loading. Use the overlay toggle to turn the on-page badges on or off at any time. ## Statistics [#statistics] A statistics view summarizes the makeup of the result page in real time. It counts organic results, AI Overview citations (with unique URLs and domains), ads, local pack, video, shopping, and featured snippets. This lets you read the competitive shape of a query immediately. ## Results table [#results-table] Every result is also listed in a sortable, searchable table with position, title, URL, type, and SERP features. Rows are numbered to match the on-page badges, for example `V` for video, `D` for discussion, `S` for shopping, and `AI` for AI-cited results. AI-cited results are flagged. ## Export to CSV [#export-to-csv] Export the full result set to a **CSV** file. The file is UTF-8, Excel-compatible, and named after the query and date (for example `serp-best-running-shoes-2026-08-11.csv`). The export includes every classified result and its type, with duplicates filtered. ## Asking the AI [#asking-the-ai] With an [AI model connected](/docs/chrome-extension/ai-setup/), AI Chat analyzes the whole SERP landscape rather than a single page. Useful questions: * "What content gaps can I exploit?" * "Why are these pages ranking and mine isn't?" * "What schema markup are top results using?" It surfaces opportunities the top-ranking pages miss and explains how to build content that fills them. One search query becomes a competitive strategy. ## Optimizing for AI search (AEO / GEO) [#optimizing-for-ai-search-aeo--geo] AI search engines increasingly decide what users see: ChatGPT, Perplexity, Google Gemini, and Claude. The goal shifts from ranking in blue links to **being the source those engines cite**. AI Chat helps in both modes: Evaluates your page's readiness to be cited: * Entity clarity * Question-and-answer formatting * Topical authority signals * Structured data completeness Try: *"Is my content structured for AI citations?"* or *"How can I improve my chances of being referenced by ChatGPT?"* Analyses which pages AI Overviews actually reference, and why. Try: *"Which results are AI-cited?"* or *"What content format do AI engines prefer for this query?"* Pair the two: run SERP mode to see which competitors get cited, then run On-Page mode on your own page to find what it is missing by comparison. --- # Viewing Modes & Overlays URL: https://docs.digispot.ai/docs/chrome-extension/viewing-modes/ Popup, Visualize, and Fullscreen modes — plus visual on-page overlays that mark headings, images, videos, and links directly on the page. The extension has three viewing modes. Most people start in **Popup** for a quick check, switch to **Visualize** to show an issue in context on the page itself, and use **Fullscreen** for a deep audit with side-by-side content. ## The three modes [#the-three-modes] | Mode | How to open | Best for | | -------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | **Popup** | Click the toolbar icon | Fast spot checks without leaving the page | | **Visualize** | Click **Inspect** in the popup | Showing clients or developers exactly where issues are | | **Fullscreen** | Click the external-link icon in the popup, or right-click → "Open SEO Insights in Full Screen" | Detailed audits with full category breakdown, charts, and AI | Light and dark themes are supported in all three modes. ## Popup [#popup] The popup opens in a compact window over the current page without navigating away. It shows the score, the category panels, and quick filters. All 150+ checks run here. The other modes just display the same data differently. ## Visualize (on-page overlays) [#visualize-on-page-overlays] Visualize mode collapses the popup to a compact sidebar (\~80px). It then injects badges directly onto the live page, so problems show up in context rather than buried in a list. Four overlay types each have their own toggle: * **Headings (H1–H6)**: level badges on every heading. A missing H1 or a skipped level is visible at a glance, without reading source code * **Images**: flags missing alt text and other image issues at the image itself * **Videos**: markers on embedded and hosted video * **Links**: indicators on internal and external links, including nofollow Toggle each type independently. **Keyword highlighting** marks where your focus keyword appears on the page with a green indicator. Collapse the sidebar further to keep the page fully visible while you work. On-page badges are the fastest way to show a developer or client exactly which element has a problem: no spreadsheet, no scrolling through a list. Screenshot the page with overlays on to create instant visual evidence for a brief. ## Fullscreen [#fullscreen] Fullscreen opens in a dedicated browser tab and adds: * The **Overview** tab: a full-site score rollup, SERP preview, quick wins, and a **Full Audit** that runs one AI review across all panels at once * Side-by-side **AI Chat** panel * Expanded charts and visualizations * Access to the complete **Config** (AI, prompts, cache, account) Fullscreen can also be opened directly from the right-click context menu on any page. There is no need to open the popup first. ## Visual on-page overlays [#visual-on-page-overlays] When Visualize mode is on, a sidebar shows **OVERLAYS** controls: per-type toggles (H1-H6, IMGS, VIDS, LINKS) and a **CLEAR/RESET** button. The overlays persist as you scroll, and they survive page interactions. --- # Workflows URL: https://docs.digispot.ai/docs/chrome-extension/workflows/ Practical ways to use the extension — competitor analysis, pre-publish checks, client audits, and exporting reports. The extension works on any public website, which makes it as useful for pages you do not control as for your own. ## Competitor analysis [#competitor-analysis] Navigate to a competitor's page and select the extension icon. You see their full on-page strategy: schema markup, Core Web Vitals, content structure, heading hierarchy, meta tags, and internal linking patterns. Export each report to compare competitors side by side and work out why they outrank you. In SERP Intelligence mode, run the audit on the search results page first. This shows who ranks and which results earn AI Overview citations. Then audit the individual pages that win. ## Pre-publish checks [#pre-publish-checks] Run the audit on staging before publishing. It catches missing meta tags, broken schema, slow Core Web Vitals, intent mismatches, and heading structure problems while they are still cheap to fix. Fixing these before launch avoids the far slower cycle of publishing, watching rankings suffer, diagnosing, and re-earning the position. ## Client and agency work [#client-and-agency-work] * Run quick audits during discovery or a pitch * Use **Visualize Mode** on a call to overlay issues directly on the client's page. It is far more persuasive than a spreadsheet * Export reports to share findings with clients, developers, or stakeholders Managing several clients? Spider gives each one an isolated project with its own crawls, history, and Google connections. Save a workflow once and run it across every site you manage. ## Exporting [#exporting] Reports export in **TXT format**. This gives you a human-readable summary suited to sharing with clients, developers, or stakeholders. You can also screenshot **Visualize Mode** to document issues visually, directly on the page. ## Other workflow features [#other-workflow-features] | Feature | What it does | | ---------------------------- | -------------------------------------------- | | **Multi-tab batch audits** | Audit several open tabs in one pass | | **Right-click context menu** | Start an audit without opening the popup | | **Local caching** | Repeat audits on the same page return faster | | **Competitor intelligence** | Compare schema and structure against rivals | ## When to move up to SEO Spider [#when-to-move-up-to-seo-spider] Most people are well served by the free extension for spot checks and occasional audits. **Digispot AI SEO Spider** is worth considering if you find yourself: * Auditing 50+ pages weekly * Manually comparing mobile versus desktop * Exporting reports for multiple clients regularly * Needing systematic content gap discovery | | Chrome Extension | SEO Spider | | ------------------ | --------------------- | --------------------------------------- | | **Scope** | One page at a time | Whole site — 10,000+ pages | | **Checks** | 150+ per page | 300+ per page | | **Device modes** | Your current viewport | Mobile, tablet, and desktop per crawl | | **Prioritisation** | Severity only | Weighted by GSC and GA4 traffic at risk | | **Automation** | Manual, per page | Scheduled crawls and workflows | | **Price** | Free forever | Paid, with a free tier | Working solo? [SEO Spider](/docs/desktop/) runs unlimited crawls locally on Mac or Windows. Working as a team? The [Cloud Platform](/docs/cloud/) adds shared projects and GSC and GA4 integration. Its audits run on Digispot's servers rather than your laptop. Everything on this page is a manual, page-by-page workflow. Spider turns each of them into a repeatable crawl you can schedule, re-run, and compare over time. --- # Keys & connections URL: https://docs.digispot.ai/docs/cloud/api-access/ Manage MCP server keys, Chrome-extension keys, and Spider desktop licenses and seats from your cloud account. Your cloud account is where you connect the rest of the Digispot ecosystem: AI agents, the browser extension, and the desktop Spider. These screens are Admin-only. ## MCP server [#mcp-server] Create and manage **MCP API keys** so AI assistants can query your cloud data: projects and remaining credits, audit results and top issues, keyword and backlink data, Google metrics, and content opportunities. Revoke a key at any time. This is the cloud MCP server. The desktop [Spider also runs a local MCP server](/docs/desktop/mcp/) for querying on-machine crawl data. ## Chrome extension keys [#chrome-extension-keys] Generate **Extension Keys** that tie the [Chrome extension](/docs/chrome-extension/) to your organization. Page audits in the browser then draw on your account's managed AI. Create and revoke keys as needed. ## Spider desktop license [#spider-desktop-license] Manage your **SEO Spider** desktop licenses and **seats**: * Activate the desktop app with a license key * See how many seats are used against your plan's limit * Revoke a seat to free it for another machine * Start a **7-day trial** seat See the [desktop plans](/docs/desktop/plans/) for what each tier unlocks. --- # Plans & Billing URL: https://docs.digispot.ai/docs/cloud/billing/ How Digispot Cloud billing works — plans, the two credit pools (AI and Data), usage tracking, and payments. The Cloud Platform is subscription-based, with a free tier and paid plans. Usage of AI and research features is metered through two separate credit pools. ## Two credit pools [#two-credit-pools] Your account carries two independent pools of credits: | Pool | Spent on | | ---------------- | ------------------------------------------------------------------------ | | **AI credits** | Ask Digispot, AI summaries, and Content Studio articles and infographics | | **Data credits** | Keyword lookups and backlink analysis | The pools are not interchangeable. Running out of one does not affect the other. The server is authoritative and charges credits when an action is recorded. ## Plans [#plans] The Cloud Platform has four plans. A **free** plan lets you get started. Paid plans raise limits and unlock gated features (for example, Content Studio is not available on free). Plans also set resource caps such as the number of projects, team members, and audits, and how long data is retained. | Plan | Monthly (USD) | | ----------- | ------------- | | **Free** | $0 | | **Starter** | $19 | | **Pro** | $49 | | **Agency** | $199 | Quarterly and yearly intervals are also available (yearly is discounted), and prices are shown in **USD or INR** depending on your region. This is the Cloud Platform's own tier ladder. It is separate from the desktop [SEO Spider](/docs/desktop/plans/) plans (Scout / Tracker / Leader). The two are not the same subscription. ## Usage & analytics [#usage--analytics] A usage dashboard breaks down both credit pools and shows usage by source (web, extension, and desktop). It also displays your fixed allocations for the current billing period: projects, team members, and audits. A credits badge in the app header shows your remaining balance at a glance. ## Payments [#payments] Billing is handled through **Razorpay**, in **USD or INR**. You can choose a monthly, quarterly, or yearly interval. You can also upgrade or downgrade, schedule a plan change, or cancel at the end of the period. Billing history lists both subscription charges and credit purchases. --- # Content opportunities URL: https://docs.digispot.ai/docs/cloud/content-opportunities/ Content opportunities finds the gaps in your topical coverage — pages worth writing, mapped to clusters and search intent. Content opportunities points at what to write next. It surfaces the topics the site doesn't cover yet, mapped to the clusters they extend and the search intent they serve. It reads the analysis from an audit run, so the gaps reflect the site's real structure rather than a generic keyword list. Each gap carries enough detail to hand straight to Content Studio. This screen is tied to an **audit run**. It needs a completed run to analyze. If no run exists yet, the page prompts you to create one before it can surface gaps. ## Two views of the same data [#two-views-of-the-same-data] A toggle switches between a **graph** and a **dashboard** view of the same opportunity set. * **Graph** — an interactive cluster map showing the site, its topic clusters, the pages under each, and the gaps hanging off them. Coverage and holes are visible spatially * **Dashboard** — the same clusters and gaps as sortable, filterable lists ## What the dashboard breaks down [#what-the-dashboard-breaks-down] The dashboard organizes opportunities across four tabs. * **Cluster analysis** — how the site's topics group, and which clusters are thin * **Content gaps** — the missing pages, each with a **priority** (high, medium, low), a suggested title, target keywords, key points to cover, and the intended audience; filterable by priority and by cluster * **Search intent alignment** — coverage across the funnel stages **awareness, consideration, decision, and retention**, backed by the query intents (informational, navigational, commercial, transactional) * **Pages** — how existing pages map into the cluster structure When every gap has been addressed, the screen shows an "all gaps addressed" state. Each gap has a **Write** action that opens [Content Studio's Create screen](/docs/cloud/content-studio/create/) pre-filled with the gap's title, keywords, audience, intent, and a length scaled to its priority. It is the shortest path from spotting a gap to drafting the page that fills it. --- # Dashboard URL: https://docs.digispot.ai/docs/cloud/dashboard/ The dashboard is the platform's home — a site-wide view of health, search performance, traffic, and the actions worth taking next. The dashboard is the first screen after signing in. It is a site-wide view that pulls the latest audit run together with connected Google data. The framing is around what to do next rather than raw numbers. It scopes to the **active project**. A run-status banner at the top tracks any audit in progress and refreshes the widgets when it completes. The dashboard needs at least one completed audit run to populate. A fresh project shows onboarding states prompting a first crawl; the search and traffic widgets additionally require Google Search Console and GA4 to be connected. ## Metrics and performance [#metrics-and-performance] The upper widgets summarize where the site stands. * **Top-level metrics** — site health, page score, and headline search performance * **Business performance** and **CXO analytics** — higher-level roll-ups framed for reporting rather than debugging * **Traffic & engagement** — users and sessions by device, a traffic-source breakdown, and Search Console **clicks, impressions, CTR, and position** ## Actions and warnings [#actions-and-warnings] The action-oriented widgets turn findings into a worklist. * **Top actions** — the issues worth fixing first, each tagged **Critical**, **Quick win**, or **Easy fix** so effort and impact are visible at a glance * **Warnings breakdown** — findings grouped by category and severity * **Team performance** — activity across the workspace's members * A **notification center** for run completions and alerts ## AI analysis [#ai-analysis] A **Website health summary** runs across the dashboard. An AI analysis panel breaks the site down by crawlability, content quality, brand presence, content gaps, keyword data, backlinks, and international SEO. Each dimension gets a plain-language read rather than a score alone. Start each session at the **Top actions** strip. It's already ranked by leverage, so the Critical and Quick-win items are the shortest path from the dashboard to a measurable gain. Drill into a category only when an action needs context. --- # Getting Started URL: https://docs.digispot.ai/docs/cloud/getting-started/ Sign up, create your organization, walk through the project wizard, and run your first cloud audit — plus where to install the free Chrome extension and SEO Spider. The **Cloud Platform** is Digispot's team product. It provides shared projects, audits that run on Digispot's servers, and Google Search Console and GA4 dashboards. It works in any browser. **Nothing to install** for the cloud itself. If you are brand new to Digispot, here is the full path from sign-up to your first audit. The other Digispot products run on the same account, and both are **free to start** (paid plans unlock more later). *** ## Before you begin [#before-you-begin] | What | Do you need it? | | ----------------------------------------------------- | ------------------------------------------------------------------------------------- | | **Cloud Platform** (this guide) | A browser and a Digispot account | | **[SEO Insights extension](/docs/chrome-extension/)** | Optional — audit any single page free, no signup | | **[SEO Spider desktop app](/docs/desktop/)** | Optional — crawl whole sites on your Mac or PC; **free Scout tier** (100 pages/crawl) | All three share one Digispot account once you sign up. *** ## Step 1 — Create an account [#step-1--create-an-account] Go to [app.digispot.ai](https://app.digispot.ai) and sign up with **email and password**, or **Continue with Google**. * Signing up creates your **organization** (your company or agency workspace) and makes you its **Admin**. * Email/password sign-ups must click the **confirmation link** in their inbox before the first login. * Google sign-in skips email verification. After login, if you have no projects yet, the dashboard prompts you to **Create Your First Project**. *** ## Step 2 — Create your first project [#step-2--create-your-first-project] A **project** is one website you audit: your own site, a client's, or a brand you manage. Creating a project opens a short **4-screen wizard**. Plan about **3 minutes** if you fill fields manually, or **\~1 minute** if you use **Auto-fill**. You can reopen the wizard anytime from **Settings → Projects → New project**. ### Screen 1 — Project setup (\~30 seconds) [#screen-1--project-setup-30-seconds] Give the project a name your team will recognize. | Field | Required? | What to enter | | ----------------------- | --------- | ------------------------------------------------------------------------ | | **Project name** | Yes | 3–50 characters — e.g. `Acme Marketing Site` or `Client — Bright Dental` | | **Project description** | No | Internal notes — goals, stakeholders, or scope | Click **Let's Start** to continue. ### Screen 2 — Website details (\~1 minute) [#screen-2--website-details-1-minute] Tell Digispot which site this project covers. | Field | Required? | What to enter | | ------------------- | --------- | ------------------------------------------------------------------ | | **Website URL** | Yes | The homepage URL — e.g. `https://example.com` | | **Business domain** | Yes | Your industry vertical (Technology, Healthcare, Ecommerce, etc.) | | **Sitemap URL** | No | Your XML sitemap if you know it — use **Verify** to check it loads | **Auto-fill (recommended):** After you paste the website URL, click the **Auto-fill** button (wand icon). Digispot reads your site and fills in the business domain, sitemap, brand keyword, target country, competitors, keywords, and a short business summary. Fields marked **AI-filled** stay editable. Auto-fill requires a paid plan that includes AI features. On the free plan you enter these fields manually — it only takes an extra minute. When Auto-fill finishes, the wizard usually **jumps ahead to Screen 3** so you can review what it found. Otherwise click **Continue**. ### Screen 3 — Brand & market (\~30 seconds) [#screen-3--brand--market-30-seconds] These fields shape keyword research, competitor tracking, and how reports are labeled. | Field | Required? | What to enter | | ----------------------- | --------- | ---------------------------------------------------------------------------------- | | **Brand keyword** | Yes | Your primary brand name — e.g. `Digispot` | | **Location country** | Yes | The market you optimize for — e.g. United States, India, United Kingdom | | **Primary competitors** | No | One competitor website URL per line | | **Target keywords** | No | Comma-separated phrases you care about | | **Business details** | No | A short summary of what the business does — expand **Edit** to change the AI draft | Click **Continue**. ### Screen 4 — Instant audit (\~15 seconds) [#screen-4--instant-audit-15-seconds] The last screen confirms what happens right after the project is saved. | Option | Default | What it does | | ---------------------------------- | ------- | ---------------------------------------------------------------------------------- | | **Local SEO** | Off | Enable if you serve customers in a geographic area (map pack, NAP, location pages) | | **International SEO** | Off | Enable for multi-country or hreflang sites | | **Start analyzing my website now** | On | Creates a default audit config and **starts the first crawl immediately** | Every audit always includes core checks: content, meta tags, performance, links, schema, images, video, and AI/LLM crawler visibility. It also adds backlinks and content-gap reports. Device type defaults to **Mobile** (Google's mobile-first index). Page limit depends on your plan. * Toggle **Start analyzing…** off if you only want to save the project and configure the audit later. * Click **View & edit full configuration** for advanced settings (device type, max pages, individual toggles). Click **Create project & start audit** (or **Create project** if you turned off the instant run). **Where you land next:** * Audit started → **Audit run** page with live progress * Project only → **Dashboard** or **Audit runs** list *** ## Step 3 — Connect Google (recommended) [#step-3--connect-google-recommended] After the project exists, connect **Google Search Console**, **GA4**, and optionally **Google Business Profile** under **Settings → Integrations**. This is what makes cloud audits useful at scale: issues are **ranked by the traffic they put at risk**, not just listed alphabetically. See [Google Insights](/docs/cloud/google-insights/) for the full setup walkthrough. *** ## Step 4 — Invite your team (optional) [#step-4--invite-your-team-optional] Add teammates from **Settings → Team**. Each person gets an email invite and one of two roles: * **Specialist** — run audits and view reports for assigned projects * **Admin** — manage billing, integrations, and project settings See [Teams & roles](/docs/cloud/teams/). *** ## Step 5 — Review your first audit [#step-5--review-your-first-audit] When the crawl finishes, open the run from **Audit runs** on the dashboard. Reports are grouped by category: crawlability, content, performance, schema, local SEO, and more. Each category carries a grade and a prioritized issue list. To run another crawl or change scope, create or edit an **audit configuration** first. See [Audits & reports](/docs/cloud/audits/). *** ## Install our other products (optional) [#install-our-other-products-optional] The Cloud Platform does not replace every workflow. Many teams use all three Digispot products on the same account: ### SEO Insights — Chrome extension (free) [#seo-insights--chrome-extension-free] Audit **one page at a time** while you browse. 150+ checks, no signup required for core features. | | | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Install guide** | [Install the extension](/docs/chrome-extension/install/) | | **Chrome Web Store** | [Digispot AI — SEO Insights](https://chromewebstore.google.com/detail/digispot-ai-seo-insights/njjbmbinhpipcdocojjniahjgdoljohg) | | **Price** | Free — optional paid features via a Digispot Extension Key | ### SEO Spider — desktop app (free to start) [#seo-spider--desktop-app-free-to-start] Crawl your **whole site** on your Mac or PC. Data stays on your machine, which is good for client work and large sites. | | | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Install guide** | [Install SEO Spider](/docs/desktop/install/) | | **Download page** | [digispot.ai/products/digispot-ai-seo-spider](https://digispot.ai/products/digispot-ai-seo-spider) | | **Free tier** | **Scout** — 100 pages per crawl, mobile rendering, no credit card | | **Paid unlock** | **Tracker** and **Leader** raise page limits, add tablet/desktop modes, AI, MCP, and Google integrations — [see plans](/docs/desktop/plans/) | Cloud Platform plans and Spider plans are separate. A cloud subscription does not automatically unlock Spider desktop features, and vice versa. One account works for both. Each product has its own billing. *** ## Cloud plan limits [#cloud-plan-limits] The cloud **free plan** covers core auditing with limits on pages, AI features, and some modules (such as Content Studio). Paid plans raise crawl limits and unlock AI-assisted project setup, Content Studio, and higher research credits. See [Plans & billing](/docs/cloud/billing/). --- # Cloud Platform URL: https://docs.digispot.ai/docs/cloud/ Digispot AI Cloud Platform — shared projects, GSC and GA4 integration, and long audits that run on Digispot's servers instead of your laptop. **Digispot AI Cloud Platform** is the team product. It provides shared projects and Google Search Console and GA4 integration. Long audits run on Digispot's servers rather than tying up your machine. No install — it runs in any browser. Working solo? [SEO Spider](/docs/desktop/) gives you unlimited local crawls on your own machine, with your data never leaving it. ## Built for teams [#built-for-teams] * **Shared projects** — your whole team works from the same crawls and history. See [Teams & roles](/docs/cloud/teams/). * **Multi-project workspaces** — each client isolated, with separate crawls and Google connections * **Audits run on Digispot's servers** — long crawls do not tie up a laptop. See [Audits & reports](/docs/cloud/audits/). * **Role-based access** — Specialist and Admin roles ## What the cloud adds [#what-the-cloud-adds] * **Google Insights** — dashboards built on your Search Console, GA4, and Business Profile data. See [Google Insights](/docs/cloud/google-insights/). * **Keyword, SERP, and backlink research** — powered by Data credits. See [Research](/docs/cloud/research/). * **Content Studio** — AI article and infographic generation, plus the **Ask Digispot** assistant. See [Content Studio](/docs/cloud/content-studio/). * **Content Opportunities** — systematic content gap discovery * **Keys & connections** — MCP server keys, Chrome-extension keys, and Spider desktop seats, managed from one place. See [Keys & connections](/docs/cloud/api-access/). ## Integrations [#integrations] Connected through one-click OAuth: * **Google Search Console** — queries, impressions, index coverage, and live URL Inspection verdicts * **Google Analytics 4** — traffic and engagement per URL * **Google Business Profile** — local SEO alignment These connections let findings be ranked by traffic at risk rather than severity alone. ## For agencies [#for-agencies] Each client gets an isolated project with its own crawl history and Google connections. Invite your team with scoped [roles](/docs/cloud/teams/) and run the same audits across every site you manage. ## Explore the docs [#explore-the-docs] --- # Settings URL: https://docs.digispot.ai/docs/cloud/settings/ Manage your account, projects, and integrations — and reach the team, billing, and API-key screens — from one Settings hub. Settings is the hub for everything outside the audit itself. It covers your account, your projects and their connections, and the team, billing, and API-key screens. ## Account [#account] The **Account** screen holds your profile and security settings: your details and a password change. It's available to every member regardless of role. ## Projects & integrations [#projects--integrations] The **Projects & Integrations** screen is where you manage the sites you audit and the data sources you connect: * **Projects** — create, edit, and delete projects; set the **active project** that the rest of the console scopes to; and use AI-assisted auto-fill to populate a new project from its site rather than typing every field * **Sitemap verification** for a project, so crawls start from the right URL set * **Integrations** — connect **Google Search Console** and **Google Analytics 4** over OAuth, with **Google Ads** and **Bing Webmaster** connection screens also available Connecting a data source is per-project. Switch the active project and the integration state follows it. Connected Google data powers the [Google Insights](/docs/cloud/google-insights/) dashboards and weights audit findings by real traffic. Search Console gates its reports by the permission granted on the connected property. **Search Analytics** and **URL Inspection** each unlock different Google Insights sections. Connecting the account isn't the same as granting both. A locked section usually means the missing scope, not missing data. ## Other settings screens [#other-settings-screens] The rest of the Settings area is documented with the features it controls: * **User Management** — see [Teams & roles](/docs/cloud/teams/) * **Billing & Subscription** and **Usage & Analytics** — see [Plans & billing](/docs/cloud/billing/) * **Chrome Extension**, **MCP Server**, and **Spider License** — see [Keys & connections](/docs/cloud/api-access/) Some Settings screens are Admin-only: Billing, User Management, and the API-key screens. See [Teams & roles](/docs/cloud/teams/). --- # Teams & Roles URL: https://docs.digispot.ai/docs/cloud/teams/ Organizations, role-based access (Specialist, Admin), inviting members, and switching between organizations. The Cloud Platform is multi-tenant. Everyone works inside a shared **organization**. What each person can do is governed by their role. ## Roles [#roles] There are two roles: | Role | Can do | | -------------- | -------------------------------------------------------------------------------------- | | **Specialist** | Create and manage projects and audits. Can view user management, with limited editing. | | **Admin** | Full access, including user management and billing. | Some areas are Admin-only: user management, billing, and the API-key screens (MCP, Chrome extension). Specialists can view user management but not make changes there. ## Inviting members [#inviting-members] Admins invite teammates by email from **User Management**. An invited user is **pending** until they accept the emailed invite and set a password (or link Google). You can resend or revoke a pending invite. You can also edit a member's role or active status later. A few guardrails apply. The organization owner can't be deleted. Only Admins can grant the Admin role or toggle a member's active status. You can't change your own role or status. ## Multiple organizations [#multiple-organizations] You might belong to more than one organization, for example as a consultant across several clients. You can switch the active organization in-session with the organization switcher, without logging out. --- # AI Features URL: https://docs.digispot.ai/docs/desktop/ai/ AI analysis across pages, crawls, and projects, plus an AI copilot — powered by your own key (BYOK) or Digispot-managed credits. Spider's AI turns raw crawl data into prioritized, plain-English guidance. It's a paid feature, available on **Tracker** and **Leader**. It reads directly from your crawl, so the output is grounded in your actual audit rather than generic advice. AI also powers [Content gaps](/docs/desktop/content-gaps/), [Image Studio](/docs/desktop/image-studio/), and the AI steps in [Recipes](/docs/desktop/recipes/). All of them need a provider connected here first. ## Two ways to power AI [#two-ways-to-power-ai] You connect a provider once, one of two ways. Then you choose the provider and model at runtime for each task. | | Bring your own key (BYOK) | Managed credits | | --------------------- | --------------------------------------------- | ----------------------------- | | **Provider** | OpenAI, Anthropic, Google Gemini, or DeepSeek | Digispot handles it | | **Where requests go** | Straight to the provider | Through your Digispot account | | **Billing** | You pay the provider directly | A shared Digispot credit pool | | **Keys to manage** | Your own key | None | BYOK suits anyone who already has a provider account and wants to control cost and data flow. Managed credits suit anyone who would rather not manage keys at all. ## AI analysis tasks [#ai-analysis-tasks] Spider offers a library of AI tasks scoped to different levels of a crawl: * **Page** — explain a page's issues, summarize what to fix, and how * **Crawl** — summarize a whole run and its most important findings * **Project** — track trends and priorities across runs over time Each task has a built-in default prompt, and you can save your own custom templates. ## AI copilot [#ai-copilot] The AI copilot is a chat assistant that can query your crawl data directly using built-in SEO tools. Ask questions like "what are my highest-impact issues?" or "which pages regressed since the last crawl?" The answers are grounded in your actual audit, not generic advice. ## Usage and cost [#usage-and-cost] Spider tracks AI usage: tokens, latency, and cost. You can see what each analysis costs, whether you're on BYOK or managed credits. --- # Backlinks URL: https://docs.digispot.ai/docs/desktop/backlinks/ The Backlinks module shows your referring domains and link profile, backed by cloud link data. The Backlinks module shows who links to your site and how strong that link profile is. This is the off-page half of SEO that a crawl alone can't see. A local crawl reads your own pages. Backlinks are what other sites do, so this data comes from Digispot's cloud rather than from anything Spider fetches on your machine. Backlinks is a paid module, available on the **Tracker** and **Leader** plans. The free Scout tier shows an upgrade prompt. Link data comes from Digispot's cloud and spends data credits. Each live refresh draws down the credit pool, which is why it is metered separately from the AI features. See [Plans & tiers](/docs/desktop/plans/). ## What it shows [#what-it-shows] * **Metric cards** — referring domains, total backlinks, and authority signals, the top-line summary of how much external link equity the site has * A **backlinks table** — one row per link, so you can see which sites contribute the most authority and where they point Authority here is a domain-strength signal, not Google's internal PageRank. It's useful for comparing referring domains against each other and for judging the overall weight of the profile. Each row carries the detail that decides whether a link is worth anything: * **Referring domain** — the site that links to you * **Target** — the page on your site the link points to * **Anchor text** — the clickable text of the link, a relevance signal for the target * **Rank** — the referring domain's authority, so strong links stand out from weak ones * **Nofollow** — whether the link passes authority or is marked `nofollow` Sort by rank to find your strongest referring domains. Read the target column to see which pages already attract links, and which important pages attract none. ## Data states [#data-states] Because the data is cloud-backed and credit-metered, each row carries a status so you can tell live data from a state that needs attention: * **Not connected** — cloud link data isn't linked to the project yet * **No data** — the domain has no backlinks on record * **Out of credits** — the data credit pool is exhausted; top up to refresh --- # Checks & Scores URL: https://docs.digispot.ai/docs/desktop/checks-and-scores/ SEO Spider runs 300+ checks across 25 categories and produces three distinct scores — Page, Device, and Site. Every crawl runs **300+ checks across 25 categories** on each page, then rolls the results into three separate scores. The checks are the raw findings. The scores are how those findings roll up, so you can judge a page, a device render, or the whole site at a glance. ## The 25 categories [#the-25-categories] Checks are grouped into categories covering the full surface of technical and on-page SEO, including: * **Content**, **Metadata**, and **Headings** * **Links** and **URL structure** * **Images** and **Video SEO** * **Schema markup** and **industry schema** * **Canonical URLs**, **meta robots**, and **robots.txt** * **XML sitemap** and **crawlability** * **Performance** and **mobile responsiveness** * **Security** and **HTML validation** * **Internationalization (hreflang)** and **local SEO** * **Social media**, **accessibility**, and **brand mentions** * **LLMs.txt / LLM optimization** and **answer engine optimization (AEO)** ## Severity [#severity] Each finding maps to one fixed **severity**, so the same problem always carries the same weight and you can work top-down without re-judging each one: | Severity | What it means | | ------------ | ----------------------------------------------------- | | **Critical** | Blocks indexing or ranking — fix before anything else | | **High** | A real ranking or crawl problem, not fatal on its own | | **Medium** | Worth fixing, meaningful but not urgent | | **Low** | Minor polish with limited impact | The [Issues board](/docs/desktop/issues/) uses these same severities to order the fix-first queue, and the **quick wins** panel pulls the high-impact, low-effort findings to the front. ## Three scores [#three-scores] Spider reports three distinct scores. Keeping them separate tells you whether a problem is on one page, one device, or the whole site. | Score | What it measures | | ---------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Page score** | A single page's health, 0–100 with an A–F grade. Indexability-aware — a page that can't be indexed is scored down hard. | | **Device score** | The average of a device's page scores, so you can compare mobile vs desktop vs tablet. | | **Site score** | A site-level composite built from site-wide checks such as SSL/HTTPS, robots.txt, the XML sitemap, and llms.txt. | Indexability problems outrank everything else. A page that can't be indexed can't rank, no matter how good the rest of its SEO is. That's why the page score weights them heavily. --- # Competitors URL: https://docs.digispot.ai/docs/desktop/competitors/ Track rival domains, see where you stand across the field, and read one rival head-to-head. Profiling reads each site's sitemap and robots files, and never crawls their pages. Competitors is where you track rival domains and measure yourself against them. It profiles each rival from their published sitemap and robots files, ranks the field by where you stand, and opens any single rival head-to-head. It never crawls a competitor's pages. Every figure comes from each site's own published files. Scout tracks one competitor and cannot refresh cloud data. Tracker and Leader track up to four and can pull live backlink and search-visibility data. Backlink and market-standing lookups draw on data credits. See [Plans & tiers](/docs/desktop/plans/). ## Tracking a competitor [#tracking-a-competitor] Add a competitor by its domain. Spider profiles it immediately from its sitemap, so you see the read back at once rather than a pending row. Profiling is sitemap-only. It runs no crawl, uses no AI, and costs nothing. A competitor stays tracked even when the read returns little. Each outcome is recorded as data, not as a failure: * **Profiled** — the sitemap was read, so you get its self-declared URL count and sections. * **No sitemap published** — none was found, so size and structure are unknown, not zero. * **Couldn't check** — the read was refused, and the HTTP status is shown beside the label. Size is unverifiable, not small. * **Couldn't reach** — the site could not be reached, so size is unverifiable, not small. * **Not profiled yet** — no read has run. This is not the same as an empty site. ## Where you stand [#where-you-stand] The Competitors screen opens on the whole field. Three tiles summarize it: * **Biggest threat** — the rival that leads on the most sections, and how many of those you have no pages under. * **Your strongest position** — the section where you publish more than any rival read. * **Most contested** — the section where you and a rival publish at a similar depth. Below the tiles, the **Rivals** table sets search performance beside each site's published footprint. Search performance comes from Digispot's cloud and covers estimated monthly search visits, keywords, top-10 count, momentum, and the keyword gap. The footprint comes from each sitemap and covers URL count, sections, referring domains, when it was last profiled, and a verdict of ahead or behind on sections. An **AI Insights** panel ranks the sections and topics a rival publishes that you do not, in the order worth building. Each figure carries its limits on the screen. Topics are inferred from URL wording, not a crawl. Search visits are the provider's estimate of monthly organic clicks, not your analytics. Positions are a distribution across ranking keywords, not rank tracking. ## Comparing one rival [#comparing-one-rival] Opening a rival shows the head-to-head detail. A summary table compares you and the rival on search visits, keywords, sitemap URLs, referring domains, and age, with a standing column for who leads. The rest of the detail is organized into tabs. ### Head to head [#head-to-head] The Overview tab lists every signal both sides could be read on, with who leads and the evidence behind it. There is no blended score, because the signals are not commensurable. Typical rows are the sections you lack, publishing cadence, and markets served. A comparison that is not sound is called out rather than forced. A rival with far more URLs but a large share matched to no topic is not counted as a coverage lead. An **AI rival brief** summarizes where the rival is ahead and behind, and **Next moves** turns the section and keyword gaps into concrete steps. ### The content gap [#the-content-gap] The Content tab measures the sections a rival publishes that your last crawl did not find. It sets their largest cluster aside first, because that cluster is often templated pages, and a lead built on templates is a different problem from one built on articles. Each section shows their page count against yours, a share bar, and a verdict of "they publish more", "they have it, you don't", or "you publish more". Expanding a section lists the specific pages, and pages with no match on your site are marked as drafts you could commission. Two warnings sit on this tab. The gap is matched against the pages in your last crawl, not your whole sitemap, so it can overstate a gap but never understate it. Matches are on URL wording only, so open the pages and verify before commissioning anything. ### AI readiness and markets [#ai-readiness-and-markets] The AI & markets tab reads from robots.txt and llms.txt directly, so it is available even when a sitemap is not. It compares whether each side publishes an `llms.txt` and its completeness score, and how each robots file treats named AI crawlers. The markets section lists the locales each site declares through hreflang alternates in its sitemap. ### Off-page authority [#off-page-authority] The Backlinks tab pulls the rival's referring-domain profile from Digispot's cloud. It reports referring domains, dofollow counts, and domain authority. This data is credit-metered, so a live pull runs only when you ask for it. A missing or failed lookup reads as unmeasured with a reason, never as zero authority. ## Search visibility and keyword gap [#search-visibility-and-keyword-gap] Search performance and the keyword gap come from Digispot's cloud as market standing. They cover estimated organic and paid visibility and the keywords a rival ranks for that you do not. Like backlinks, this is billable and pulled on request. Use **Refresh standing** to update it. A rival you have never looked up shows no standing until you request it. ## Plans and limits [#plans-and-limits] | | Scout | Tracker | Leader | | ------------------- | ----- | ------- | ------ | | Competitors tracked | 1 | 4 | 4 | | Refresh cloud data | No | Yes | Yes | | Backlink gap | No | Yes | Yes | | Market standing | No | Yes | Yes | --- # Content gaps URL: https://docs.digispot.ai/docs/desktop/content-gaps/ Content gaps surfaces new pages worth writing — AI-discovered topics your site doesn't cover yet, mapped to the clusters they extend. Content gaps points at what to write next. It finds topics your site doesn't cover yet but should, discovered by AI from your crawl and market. Each topic is mapped to the topic cluster it extends. Where [Keywords](/docs/desktop/keywords/) works at the term level, content gaps works at the page level: it answers "what page is missing?" rather than "what word should this page target?" Content gaps is an AI feature, available on the **Tracker** and **Leader** plans. On the free Scout tier it shows an upgrade prompt. Because it runs AI, it needs a provider connected first: your own key (BYOK) or managed credits. See [AI features](/docs/desktop/ai/) and [Plans & tiers](/docs/desktop/plans/). ## The workbench [#the-workbench] Content gaps has a **list** view and a **map** view. They are two angles on the same analysis: * The **list** ranks candidate pages worth creating, so you start from the highest-value gap rather than the top of an unordered list * The **map** shows how each gap extends your existing topic clusters, so you can see where a new page reinforces a cluster you already have versus opening a new one * A **Regenerate** action re-runs the analysis as your site and market change, since a gap you fill this month shouldn't keep showing up next month Results are grounded in your [Knowledge](/docs/desktop/knowledge/) store, so the suggestions reflect your actual products, locations, and audience rather than generic topics inferred from page text alone. A thin Knowledge store yields generic gaps. A complete one yields gaps specific to what you sell and who you sell to. --- # The Crawler URL: https://docs.digispot.ai/docs/desktop/crawler/ How SEO Spider crawls a site — HTTP and JavaScript rendering, multi-device crawling, concurrency, and cloaking detection. Spider crawls a whole site from your own machine. It discovers URLs through links and the sitemap, then audits every page it finds. ## Two fetch modes [#two-fetch-modes] Each crawl can run in one of two modes: * **HTTP** — fetches the raw HTML directly. Fast, and closest to how a source-only crawler sees the page. * **JavaScript rendering** — loads each page in a real Chromium browser (Playwright), so client-rendered content, injected schema, and JavaScript-dependent issues are all captured. Rendering mode is the right choice for modern single-page apps and any site where content is assembled in the browser. ## Multi-device crawling [#multi-device-crawling] Spider can crawl in **desktop, mobile, and tablet** modes in a single pass. Site-level checks run once per crawl. Per-page checks run for each device, so you can compare how the same page scores across viewports. This is useful for Google's mobile-first indexing. Multi-device crawling needs a paid plan. The free **Scout** tier is mobile-only. See [Plans & tiers](/docs/desktop/plans/). ## Cloaking detection [#cloaking-detection] Spider can fetch a page both as an HTTP request and as a rendered browser view, then compare the two. Large differences between what a site serves a bot versus a real browser produce a **cloaking score**, flagging pages that may be showing search engines something different from users. ## Concurrency and page caps [#concurrency-and-page-caps] Spider crawls several URLs at once. Both the number of simultaneous requests (concurrency) and how many pages a single crawl can cover are set by your plan: | Plan | Pages per crawl | Concurrency | | ---------------- | --------------- | ----------- | | **Scout** (free) | 100 | 1 | | **Tracker** | 10,000 | 2 | | **Leader** | Unlimited | 4 | A crawl configured above your plan's limits is clamped down to them rather than rejected. A request for more pages or higher concurrency simply runs at the cap. You can start, pause, resume, and stop a crawl at any time without losing what has already been collected. Crawling consumes bandwidth on the target site. Lower the crawl rate before crawling a production site you do not own. ## Scope and authentication [#scope-and-authentication] Restrict a crawl to a domain, include subdomains, or limit it to a path such as `/blog`. For sites behind a login, pass authentication as **custom HTTP headers** under **Advanced → Network**. An `Authorization` header (Bearer or Basic) or a `Cookie` header is sent with every request. Custom headers require the **Tracker** plan. The headers are stored in the project configuration on your machine and are sent only to the site being crawled. --- # Device comparison URL: https://docs.digispot.ai/docs/desktop/devices/ When a crawl runs across desktop, mobile, and tablet, the Devices view compares scores and issues between them. When a crawl covers more than one device, the **Devices** view puts them side by side. You can see where a page behaves differently on mobile than on desktop, which matters because Google indexes and ranks the mobile version. A page that scores well on desktop but drops content, links, or structured data on mobile is being judged on the weaker render. Spider can crawl in **desktop, mobile, and tablet** modes in one pass. **Mobile is always the lead**: it's crawled first because Google indexes mobile-first. Desktop and Tablet are added to compare for indexing gaps. Each device runs as its own crawl, so one audits while the others queue for a free slot. ## What runs once vs per device [#what-runs-once-vs-per-device] Not everything is device-specific. Site-level foundation is shared across every device; the on-page audit runs separately for each viewport. | Layer | Scope | Examples | | ------------------------ | ------------------------------------- | --------------------------------------------------------- | | **Site architecture** | Once per crawl, shared by all devices | SSL, robots.txt, sitemaps, `llms.txt`, crawlability | | **On-page / page score** | Per device | Content, headings, links, schema, images, Core Web Vitals | This split is why a site can show one **Site Architecture** score but different **page scores** per device. The foundation is sound, yet the mobile render drops content the desktop render keeps. ## What it compares [#what-it-compares] * **Category score deltas** — each category scored per device, with the difference between renders highlighted so parity gaps stand out * **Mobile-specific issues** — findings that appear only on the mobile render, such as content or links present on desktop but missing on mobile * **Performance comparison** — Core Web Vitals side by side, where mobile typically lags desktop and is the version Google measures The deltas to act on are the large ones. Small score differences between renders are normal; a category that is several grades worse on mobile usually means content or markup is being dropped from the render Google actually indexes. ## How each device is crawled [#how-each-device-is-crawled] Each device uses its own user agent and viewport: Chrome Mobile for the mobile render, Chrome Desktop for desktop. If a page or `robots.txt` returns a 403, Spider retries once as the device-specific Googlebot before reporting it blocked. These defaults are set per project and can be overridden under **Advanced → Per-device user agent & viewport**. See [The crawler](/docs/desktop/crawler/) for the full option set. Multi-device crawling needs a paid plan. The free **Scout** tier is mobile-only, so device comparison is a Tracker/Leader feature. See [Plans & tiers](/docs/desktop/plans/). --- # Run Your First Crawl URL: https://docs.digispot.ai/docs/desktop/first-crawl/ Crawl a site end to end with the Digispot SEO Spider desktop app, then read the Page, Device, and Site scores and work the issues by severity. This is the path from a fresh install to a finished crawl you can act on. The Spider applies 313 checks across 25 categories to every page. It keeps all data on your machine. It follows one core loop: **Discover → Prioritize → Understand → Act**. This guide assumes the app is installed and your plan is activated. If not, start with [Install the desktop app](/docs/desktop/install/) — the free **Scout** tier crawls up to 100 pages with no card. ## Before you begin [#before-you-begin] | What | Do you need it? | | -------------------------------------- | ------------------------------------------------------------------ | | **SEO Spider installed and activated** | Yes — see [Install](/docs/desktop/install/) | | **A site you can crawl** | Yes — your own, a client's, or any site you're authorized to audit | | **A Google account (GSC / GA4)** | Optional — connect it to weight issues by real traffic | *** ## Step 1 — Create a project [#step-1--create-a-project] Select **New Project**. This opens the **Create New Project** wizard: *"Set up a website to audit. Each project keeps its runs, so you can track SEO improvements over time."* It has three steps: **Basics**, **Local SEO & Languages**, and **Advanced**. Only the first is required. The other two have working defaults. A step rail on the left tracks progress, and you can move back to any completed step. ### Basics [#basics] The essentials of what to crawl. Most projects only need this step. | Field | Required? | What to enter | | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Website URL** | Yes | The site's root URL, e.g. `https://example.com`. It's validated on entry and **cannot be changed after the project is created** | | **Industry** | Yes | Your vertical — drives AI recommendations and industry benchmarks | | **Devices** | — | Desktop, Mobile, Tablet pills. **Scout (free) crawls mobile-only**; Desktop and Tablet need Tracker or Leader | | **Pages per audit** | Yes | Default 100, up to your plan's cap. Paid plans add **Crawl every page in my sitemap** to auto-detect the count | | **Project name** | No | Auto-fills from the domain — leave blank or set 3–50 characters | | **Description** | No | A short note about the site; feeds AI recommendations | | **What we check** | Yes | **Essentials** (recommended — critical, high, and medium issues) or **Also capture low-priority issues** (thorough, paid) | After entering the URL, use **Read my site** to pre-fill the industry, description, and other fields from your homepage. On Scout this read is deterministic; paid plans add an AI-written summary. ### Local SEO & Languages [#local-seo--languages] Skip this step unless the site serves a physical location or multiple languages. Enabling **Local Business SEO** reveals three fields. Enter the **Official Business Name** and match your Google Business Profile exactly. Add an optional **Google Business Profile URL** and one or more **business locations**. A **target languages/regions** selector drives international checks. ### Advanced (optional) [#advanced-optional] Sensible defaults are set for every field here. Open it only to tune the crawl. The settings are grouped into six areas. **Crawler engine & discovery** compares raw HTML vs rendered page, discovers links for orphan pages, and runs post-crawl AI summaries. **Crawl tuning** sets concurrency, delay, and failure and identical-page thresholds. **URL include / exclude filters** limit what gets crawled. **Per-device user agent & viewport** includes a Googlebot fallback on 403\. **Network** holds proxy and custom headers. **Stealth crawling** is the last group. Most of these are Tracker features. See [The crawler](/docs/desktop/crawler/) for what each option does. Click **Create Project** on the last step. ## Step 2 — Start the audit [#step-2--start-the-audit] Right after the project is created, a welcome screen confirms the scope: **"Here's what we'll audit on \[your site]"**. It reads back the industry, devices, page budget, and crawler settings, alongside a **What happens when you click Start** summary. Select **Start audit now**, or **Adjust settings first** to reopen the configuration. Before the crawl begins, a **Ready to audit?** dialog runs a quick check of your machine: network, memory, CPU, and power. Crawl speed and performance metrics are most accurate on a healthy host. The check is advisory and never blocks. Review any warnings, then select **Start audit**. ## Step 3 — Watch the crawl [#step-3--watch-the-crawl] Progress appears live. The run page shows the current status and the **pages audited against those discovered**. It shows the **Site Architecture** score as soon as it's computed. You can **pause or cancel** the run at any point. Each device you selected **runs as its own crawl**. One audits while the others show **Queued · waiting for a free slot**, since Mobile is always crawled first as the lead. Crawling consumes bandwidth on the target site. Lower the concurrency and raise the delay in the project's **Advanced** settings before crawling a production site you do not own. ## Step 4 — Read the scores [#step-4--read-the-scores] When the crawl finishes you land on the project **Overview**. The left sidebar carries the core loop — **Overview**, **Audits**, **Issues**, **Pages**, and **Compare Audits** — alongside growth and setup sections. The Overview leads with two gauges, **Site Architecture** and **Page Score**. Below them sit a severity breakdown and the top burning issues. The Spider reports three distinct scores, so a single number never hides a device- or page-specific problem: | Score | Answers | Where it shows | | ---------------- | ----------------------------------------- | -------------------------- | | **Page score** | How healthy is this one URL? | Per-page reports | | **Device score** | How does the site render per device type? | Overview, device breakdown | | **Site score** | How healthy is the whole site? | Overview rollup | The audit-run **Overview** breaks each score into its contributing categories: content quality, crawl readiness, performance, link strategy, schema, and more. A **What to fix first** panel orders issues by impact rather than count. For how each score is calculated and what a good number looks like, see [Checks & scores](/docs/desktop/checks-and-scores/). ## Step 5 — Work the issues [#step-5--work-the-issues] Open **Issues**. Findings are grouped by severity, so work top-down: errors first, then warnings, then notices. Each issue lists every affected URL, so a single fix to a shared template can clear the finding across hundreds of pages at once. Work the list by severity: | Severity | Meaning | Act when | | ----------- | -------------------------------------------- | --------------- | | **Error** | Actively blocking indexing or breaking pages | Immediately | | **Warning** | Hurting quality or rankings | This sprint | | **Notice** | Worth knowing, not urgent | When convenient | Start with errors on your highest-traffic pages. Connect GSC (below) so the Spider can sort issues by the clicks actually at risk, not just severity. ## Crawling gated sites [#crawling-gated-sites] For staging or members-only sites behind a login, add authentication under the project's **Advanced → Network** settings as **custom HTTP headers**. An `Authorization` header (Bearer or Basic) or a `Cookie` header is passed with every request. Custom headers are a **Tracker** feature. Credentials live in the project configuration on your machine and are sent only to the site being crawled. They never reach Digispot's servers. ## Next steps [#next-steps] * **Weight issues by real traffic** — connect Search Console and GA4 under the project's Google integrations. See [Google integrations](/docs/desktop/google/). * **Compare runs over time** — re-crawl after fixes and use the comparison view to confirm issues dropped. See [Issues](/docs/desktop/issues/). * **Let an AI agent query the crawl** — the Spider ships an MCP server so Claude or Cursor can read this data directly. See [MCP server](/docs/desktop/mcp/). * **Need to share with a team?** The [Cloud Platform](/docs/cloud/) runs the same crawls on Digispot's servers with shared projects. --- # Google Integrations URL: https://docs.digispot.ai/docs/desktop/google/ Connect Google Search Console and GA4 so Spider ranks findings by the traffic actually at risk. Connect your Google data and Spider stops treating every issue equally. It weights findings by the traffic and rankings actually at stake. A crawl tells you what is wrong. Google's data tells you which of those wrongs is costing you real traffic. Together they turn a flat issue list into a priority order. Google integrations are a paid feature, available on **Tracker** and **Leader**. See [Plans & tiers](/docs/desktop/plans/). ## What you can connect [#what-you-can-connect] * **Google Search Console** — clicks, impressions, CTR, and position by query, country, device, and URL * **Google Analytics 4** — traffic and engagement data You connect with a one-click OAuth sign-in. Tokens are stored encrypted on your machine. The connection syncs directly with Google. ## The indexing gap [#the-indexing-gap] Search Console's page-indexing (coverage) report is the one dataset the API can't hand over directly. Import it as a CSV or ZIP. Spider then correlates it against your crawled pages to surface the **indexability gap**: pages you expect to rank that Google isn't indexing. ## Traffic-aware insights [#traffic-aware-insights] With Google connected, Spider can highlight: * **High-traffic pages at risk** — pages with issues that are also earning meaningful traffic * **Query cannibalization** — multiple pages competing for the same query * **Striking-distance queries** — near-page-one queries worth a push * **Period-over-period trends** — what improved or slipped since last time Connect Search Console before working the [Issues board](/docs/desktop/issues/). With traffic data attached, the board can rank a template issue affecting your highest-traffic pages ahead of a critical finding on a page nobody visits. --- # Image Studio URL: https://docs.digispot.ai/docs/desktop/image-studio/ Image Studio manages the reference images and generated images used by a project's AI content workflows. Image Studio is where a project's images live. That covers the brand and reference images you provide, plus the images your AI content workflows generate. It is the image half of the content pipeline. When a [recipe](/docs/desktop/recipes/) writes a blog post and produces a cover image, that image lands here. Image Studio is an AI feature, available on the **Tracker** and **Leader** plans. The free Scout tier shows an upgrade prompt. Generating images runs through the same AI provider as the other AI features, using your own key (BYOK) or managed credits. See [AI features](/docs/desktop/ai/) and [Plans & tiers](/docs/desktop/plans/). ## Two tabs [#two-tabs] * **References** — brand and reference images you upload, so generated images stay on-brand rather than drifting to a generic look * **Generated** — every image produced by the project's workflow runs, kept with the project so you can reuse or refine them ## The reference loop [#the-reference-loop] The two tabs feed each other. That is what keeps output consistent over time: * **Generate with** a reference — produce a new image guided by one you have marked as on-brand * **Save** a generated image back as a reference — promote a result you like so future runs match its style Over several runs this narrows generated images toward a house style instead of each run starting from scratch. --- # Desktop App URL: https://docs.digispot.ai/docs/desktop/ Digispot AI SEO Spider runs real-browser crawls on your own machine — 300+ checks per page in mobile, tablet, and desktop modes. **Digispot AI SEO Spider** is the desktop application. It crawls entire sites from your own machine using a real Chromium browser, running **300+ checks per page** in **mobile, tablet, and desktop** modes. Crawls stay local by default. Your crawl data does not leave your machine, which matters for client work under NDA. One Digispot AI account activates both the desktop app and the [cloud platform](/docs/cloud/). There is no separate license. ## How it differs from the extension [#how-it-differs-from-the-extension] | | [Chrome Extension](/docs/chrome-extension/) | SEO Spider | | ------------------ | ------------------------------------------- | --------------------------------------- | | **Scope** | One page at a time | Whole site | | **Checks** | 150+ per page | 300+ per page, across 25 categories | | **Device modes** | Current viewport | Mobile, tablet, and desktop per crawl | | **Prioritisation** | Severity | Weighted by GSC and GA4 traffic at risk | | **Price** | Free forever | Free to start, with paid plans | The desktop Spider is **free to start**. The **Scout** tier runs the crawler with a 100-page cap. Paid **Tracker** and **Leader** plans raise the limits and unlock AI, MCP, and Google. A **7-day free trial** is available. See [Plans & tiers](/docs/desktop/plans/). ## What it does [#what-it-does] * **Whole-site crawling** in a real Chromium browser, with an HTTP mode and a JavaScript-rendering mode. It catches issues source-only crawlers miss. See [The crawler](/docs/desktop/crawler/). * **300+ checks across 25 categories**, producing separate [Page, Device, and Site scores](/docs/desktop/checks-and-scores/). * **Cloaking detection** — compares what a page serves to a bot versus a browser. * **Project dashboard, Visualizer, per-page reports, and audit comparison** over time. See [Reports & dashboards](/docs/desktop/reports/). * **Pages, issues, and device views** for slicing a crawl — see [Pages list](/docs/desktop/pages/), [Issues](/docs/desktop/issues/), and [Device comparison](/docs/desktop/devices/). * **Keyword research, backlinks, and content gaps**, plus a [Knowledge](/docs/desktop/knowledge/) store that grounds the AI. * **AI analysis and an AI copilot** — see [AI features](/docs/desktop/ai/). * **MCP server** — lets Claude Code, Cursor, and Windsurf query your crawl data. See [MCP server](/docs/desktop/mcp/). * **SEO Recipes** — a workflow engine for repeatable, multi-step audits. See [SEO Recipes](/docs/desktop/recipes/). * **Google Search Console and GA4 sync** via one-click OAuth, so findings are ranked by traffic actually at risk. See [Google integrations](/docs/desktop/google/). ## Explore the docs [#explore-the-docs] ## Requirements [#requirements] | | | | ----------- | ----------------------- | | **macOS** | Apple Silicon and Intel | | **Windows** | 64-bit Windows 10 or 11 | --- # Install the Desktop App URL: https://docs.digispot.ai/docs/desktop/install/ Download, install, and activate Digispot AI SEO Spider on macOS or Windows — then run your first crawl. **SEO Spider** is Digispot's native desktop crawler. It runs on your own machine and keeps all crawl data local, which is why it suits client and NDA work. It installs like any native app. The only online step is activating your plan. ## Before you begin [#before-you-begin] | | | | ----------- | --------------------------------------------------------------------------- | | **macOS** | Apple Silicon or Intel, macOS 12+ (`.dmg`) | | **Windows** | 64-bit Windows 10 or 11 (`.exe`) | | **Linux** | Not shipped — use the [Cloud Platform](/docs/cloud/) instead | | **Account** | A Digispot account (free) — the same one works on the [cloud](/docs/cloud/) | | **Payment** | None to start — the **Scout** tier is free | Pick your platform below. Get the `.dmg` from the [SEO Spider download page](https://digispot.ai/products/digispot-ai-seo-spider). Apple Silicon (M-series) and Intel Macs use different builds — if you are unsure, open the Apple menu and select **About This Mac**. Open the downloaded `.dmg` and drag **Digispot AI SEO Spider** into your Applications folder. The first launch shows a Gatekeeper prompt. Open **System Settings → Privacy & Security**, then select **Open Anyway**. Get the `.exe` installer from the [SEO Spider download page](https://digispot.ai/products/digispot-ai-seo-spider). Spider supports 64-bit Windows 10 and 11. Open the downloaded file and follow the prompts. If SmartScreen appears, select **More info → Run anyway**. Open Digispot AI SEO Spider from the Start menu. Spider checks for updates on launch. You can always reinstall over an existing installation — your projects and crawl history are preserved. ## Activate your plan [#activate-your-plan] Sign in with your Digispot AI account. The same account works across the desktop app and the [cloud platform](/docs/cloud/). There is no separate Spider license to buy. The desktop crawler is **free to start** on the **Scout** tier, with a 100-page cap. Paid **Tracker** and **Leader** plans, or the **7-day free trial**, raise the limits and unlock AI, MCP, and Google. The number of machines (seats) you can activate depends on your plan. See [Plans & tiers](/docs/desktop/plans/). Activation needs an internet connection, even though crawling itself works offline. ## Next step [#next-step] With the app installed and activated, run a crawl end to end and read the results — see [Run your first crawl](/docs/desktop/first-crawl/). Prefer not to install anything, or need to share audits with a team? The [Cloud Platform](/docs/cloud/) runs the same crawls on Digispot's servers in any browser. --- # Issues URL: https://docs.digispot.ai/docs/desktop/issues/ The Issues board is the fix-first queue — every finding across the crawl, grouped by severity and category, weighted by the traffic at risk. The Issues board is where you decide what to fix first. It aggregates every finding across the crawl by the problem itself, not page by page. A template-level issue shows up once, with every affected page behind it. That grouping is the point. A missing meta description repeated across 400 URLs is one fix in a template, not 400 separate tasks, and the board shows it that way. ## Triage boards [#triage-boards] The crawl **Overview** opens with three triage boards — issues **by severity**, **by category**, and **by type** — plus a **quick wins** panel. Each board deep- links into the full issues view, pre-filtered. You can jump straight from a count to the exact findings behind it. * **By severity** — Critical, High, Medium, and Low, the same fixed severities every check maps to in [Checks & Scores](/docs/desktop/checks-and-scores/) * **By category** — which part of SEO the findings sit in, from Content and Metadata to Schema and Performance * **By type** — the specific check that fired, so recurring template problems cluster together * **Quick wins** — findings that are both high-impact and low-effort, the shortlist to clear before deeper work ## The issues view [#the-issues-view] The dedicated issues view groups findings by severity and lets you filter by: * **Severity** — critical and high by default * **Pattern** — for example, mobile-only issues * A **single issue** — focus one finding and see every page it affects Each row explains **what** the issue is, **why** it matters, and **how** to fix it, with a link to every page that has it. A finding carries its own remediation rather than sending you elsewhere to look up what to do. When Search Console is connected, issues are weighted by the traffic actually at risk, so the highest-impact problems rise to the top. See [Google integrations](/docs/desktop/google/). --- # Keywords URL: https://docs.digispot.ai/docs/desktop/keywords/ The Keywords module researches, plans, and organizes the terms your site targets — with opportunities, topics, and a sortable table view. The Keywords module is where you research and organize the terms your site should target. Discovery, planning, and theme organization all live in one workbench. The terms you optimize for stay grounded in real search demand rather than guesses. Keywords is a paid module, available on the **Tracker** and **Leader** plans. The free Scout tier shows an upgrade prompt. Keyword data is enriched from Digispot's cloud and spends data credits. Enrichment and discovery draw down the credit pool, so the volume and difficulty figures are a metered resource. See [Plans & tiers](/docs/desktop/plans/). ## Views [#views] The module presents the same keyword set three ways. Each view suits a different stage of the work. * **Opportunities** — terms worth pursuing, ranked, so you can start from the highest-value gaps rather than reading the whole list * **Topics** — keywords grouped into the themes they belong to, which maps directly to the pages and clusters you would build to cover them * **Table** — a sortable list with **intent** and **source** filters, for slicing by search intent (informational, commercial, and the like) or by where a term came from ## What each term carries [#what-each-term-carries] Every keyword in the table is enriched with the signals you sort and filter on: * **Volume** — average monthly searches, the demand behind the term * **Difficulty** — how hard the term is to rank for, so effort lands where it can pay off * **Intent** — informational, commercial, transactional, or navigational * **Trend** — whether demand is rising or falling over recent months * **Position** — the site's current rank for the term, where it already appears Sort by any column to work a slice at a time. High volume with low difficulty is the usual starting point. A term already sitting in striking distance (position just off page one) is often a faster win than a brand-new topic. ## Building your keyword set [#building-your-keyword-set] There are three ways to populate the module, and they compose. Discover a base set, extend it with an existing plan, then enrich the whole set. * **Discover** new keywords from the cloud, scoped to your market * **Import** a keyword plan via CSV to bring in terms you already track * **Enrich** terms with cloud data for volume and difficulty CSV **import** brings keyword plans in. There is no CSV **export**. Export is disabled across the app, so the Keywords workbench is where the data lives and is worked, not a staging area for spreadsheets. --- # Knowledge graph URL: https://docs.digispot.ai/docs/desktop/knowledge-graph/ A connected map of your site's pages, topics, entities and verified facts. It is the compact context layer AI agents read over the MCP server. The knowledge graph is a connected map of what your site says. It holds your pages, topics, entity hubs, keywords, search queries, competitors and your verified business facts. It is the context layer AI agents read through the [MCP server](/docs/desktop/mcp/). An agent works from this structured map instead of re-crawling the site or guessing from raw page text. The graph is built inside the desktop app. Reading it from an AI agent uses the MCP server, which is available on Tracker and Leader. ## What it maps [#what-it-maps] Every node comes from data the audit already produced: * **Pages**, connected by their internal links and sized by inbound links. * **Topics**, the clusters your pages fall into, each with its pillar page. * **Entity hubs**, the people, places and organizations the site is about. * **Keywords** and **search queries**, mapped onto the pages they target. * **Competitors** tracked against the same topics. * **Content gaps**, topics the site does not yet cover. * **Verified Knowledge**, the business facts you have approved. ## How it is built [#how-it-is-built] The graph is assembled from your latest completed audit. Its layout is deterministic, so no AI calls are needed to generate or position it. It rebuilds automatically when the audit or your Knowledge changes. This keeps it fast to produce and inexpensive to keep current. ## What an AI agent reads [#what-an-ai-agent-reads] Over MCP, the graph is served as a single brief. The brief summarizes the whole site in a few hundred lines. An agent reads that summary instead of ingesting a full crawl. Answers stay grounded in real structure, and they cost fewer tokens. Use **Connect AI agent** on the graph page to point a client at the MCP server. ## Grounded in verified facts [#grounded-in-verified-facts] The graph reads from your [Knowledge](/docs/desktop/knowledge/) store. Every fact carries a reviewed state. AI can propose entries it infers from the site, but a proposal becomes grounding truth only after you approve it. The context stays accurate as it grows. ## Closing the gaps [#closing-the-gaps] The graph flags topics with no verified knowledge and lists content gaps. These are the places where an AI answer would otherwise guess. From there you produce a fix and apply it yourself. Draft a Knowledge entry, generate a JSON-LD block, or write an MDX page draft. Fill in [Knowledge](/docs/desktop/knowledge/) before relying on the graph over MCP. The more verified facts behind it, the more specific and correct an agent's answers become. --- # Knowledge URL: https://docs.digispot.ai/docs/desktop/knowledge/ Knowledge is the store of business facts — products, locations, people, policies — that grounds every AI feature and the generated llms.txt. Knowledge is where you record the facts about your business that Spider's AI can't infer from a crawl. It is the durable context that every AI feature and the generated `llms.txt` are grounded in. It is authored once and reused everywhere, so you describe your business a single time rather than re-explaining it in every prompt. ## What it holds [#what-it-holds] You author facts grouped by category, such as: * **Products** and services * **Locations** and service areas * **People** — the team, authors, and their credentials * **Policies** — shipping, returns, guarantees, and the like ## Reviewed state [#reviewed-state] Each entry carries a **reviewed state**, which keeps the store trustworthy over time. Facts can also be **proposed** by AI. An analysis or an agent working through the [MCP server](/docs/desktop/mcp/) can suggest an entry it inferred from your site. Those proposals wait for you to accept them before they count as Knowledge. Nothing an AI proposes becomes grounding truth until a human reviews it, so the store stays accurate even as it grows automatically. ## Why it matters [#why-it-matters] AI analyses, content generation, and the site's `llms.txt` all read from Knowledge. The more complete it is, the more specific and correct the AI output becomes, instead of guessing from page text alone. The `llms.txt` file it generates is the emerging standard for guiding AI crawlers to your most important content. It is only as accurate as the facts behind it. Fill in Knowledge before running [Content gaps](/docs/desktop/content-gaps/) or AI content workflows. Both read from it directly, so a complete store is the difference between suggestions specific to what you sell and generic topics inferred from page text. --- # MCP Server URL: https://docs.digispot.ai/docs/desktop/mcp/ Connect Claude Code, Cursor, or Windsurf to Spider's crawl data — 64 project-scoped tools, 8 packaged SEO skills, and a hard single-project boundary. Spider runs a built-in **MCP server** so AI coding assistants can query crawl data directly. They read audit results, issues, Google metrics, and site structure without anything being copied out by hand. MCP is paid-only. Scout is denied outright rather than throttled. Tracker and Leader get unlimited calls. See [Plans & tiers](/docs/desktop/plans/). ## Project binding [#project-binding] Every server process is locked to exactly one project. The `--project` argument is mandatory and the server refuses to start without it. There is no mode that reaches every project. The binding is enforced two ways: * **Injected, not accepted** — the bound project id is inserted into every project-scoped tool. Tools take no `projectId` parameter, so an agent has no field through which to name a different project. * **Ownership-validated** — any `crawlId` or `pageId` an agent supplies is checked server-side first. A real id belonging to another project is refused. Call `get_mcp_scope` at the start of a session to confirm which project the server is attached to. ## Connecting a client [#connecting-a-client] Spider generates a ready-to-paste configuration per client. Open a project's **Connect AI agent** action, or Settings → MCP Server, to copy the exact snippet. | Client | Where the config goes | Wrapper key | | ----------------- | ----------------------------------------------------------------- | ------------ | | Claude Code | `claude mcp add` (no file to edit) | — | | Cursor | `~/.cursor/mcp.json` | `mcpServers` | | Windsurf | `~/.codeium/windsurf/mcp_config.json` | `mcpServers` | | VS Code (Copilot) | `.vscode/mcp.json` in the repo | `servers` | | Claude Desktop | `~/Library/Application Support/Claude/claude_desktop_config.json` | `mcpServers` | Claude Desktop has one global config and no per-project scope, so a binding there applies to every Claude Desktop conversation. The desktop app must be running. The access check fails closed, so if the app is starting or busy the tools report that the connection could not be verified rather than silently returning empty results. ## Packaged SEO skills [#packaged-seo-skills] The server registers 8 skills as MCP prompts. Each drives the tools below in a set sequence, so an assistant runs a whole workflow from one instruction instead of calling tools individually and stitching results together. | Skill | What it produces | | ----------------------- | ---------------------------------------------------------------------------- | | `seo-audit` | A graded baseline and a fix plan ranked by traffic-at-risk × severity × ease | | `seo-quick-wins` | The highest-impact, lowest-effort fixes to ship first | | `seo-striking-distance` | A rank-gain plan from near-page-one queries | | `seo-competitor` | A page compared head-to-head against a competitor's | | `seo-content-strategy` | Content gaps, topic clusters, and cannibalization | | `seo-create-content` | A draft grounded in the crawl and the Knowledge base | | `seo-internal-linking` | Orphans, weak anchors, and a source → target link plan | | `seo-progress-report` | Two crawls compared to prove fixes worked | ## Tool reference [#tool-reference] The server exposes **64 tools**. They are read and safe-write only: the only tools that change anything are the crawl controls, `run_workflow`, and the two Knowledge proposals. No tool deletes a project or its data. ### Projects and crawls [#projects-and-crawls] Entry points for finding a project and its crawl history. * `list_projects` — every SEO project in Spider * `get_project` — one project's detail and recent crawls * `list_crawls` — crawl history with status and scores * `get_crawl_summary` — site-wide scores, metrics, and Core Web Vitals spread * `get_crawl_status_summary` — page counts grouped by each status enum * `get_crawl_logs` — crawl events, warnings, and discovered URLs for debugging ### Crawl control [#crawl-control] Start and steer a crawl. Stopping keeps everything already crawled. * `start_crawl` — begin an audit; devices come from the project config * `pause_crawl` — pause and keep progress * `resume_crawl` — continue a paused crawl * `stop_crawl` — end a crawl, retaining crawled data * `wait_for_crawl` — block until a crawl finishes, then return final status * `list_active_crawls` — check before starting another crawl ### Pages [#pages] Page-level detail, from a whole report down to a single tab. * `list_pages` — crawled pages with scores, search, sorting, pagination * `get_page_report` — the full report for one page * `get_page_section` — one section (metadata, headings, links, schema…) * `get_page_category_detail` — the per-tab payload as the app renders it * `get_page_screenshot` — the URL of a page's rendered screenshot * `get_site_graph` — structure, depth, orphans, indexability ### Issues [#issues] Aggregated findings, plus the catalog behind them. * `list_issues` — issues across the site, filterable by category and severity * `get_critical_issues` — critical and high-severity findings first * `get_issue_pages` — every page affected by one issue type * `get_page_issues` — every issue on one page, with fixes * `get_quick_wins` — high-impact, low-effort improvements by ROI * `get_broken_links` — broken links with error types and source pages * `get_redirects` — redirects by type, including chains * `get_duplicates` — duplicate titles, descriptions, H1s, or content * `get_issue_definition` — one issue's severity, impact, and recommended fix * `list_issue_definitions` — the full catalog, independent of any crawl ### Site-level checks [#site-level-checks] Whole-site signals rather than per-page ones. * `get_site_analysis` — robots.txt, sitemap.xml, SSL/TLS, llms.txt compliance * `get_robots_blocked_urls` — the actual blocked URLs and top blocked paths * `get_sitemap_coverage` — orphans, and in-sitemap-but-not-crawled URLs * `get_project_health` — an A+–F grade blending scores, issue load, and trend ### Google data [#google-data] Live OAuth connections and imported Search Console data. * `get_google_metrics` — per-URL GSC or GA4 performance * `get_gsc_import_top_pages` — top pages by clicks or impressions * `get_gsc_import_top_queries` — top queries, site-level * `get_gsc_sitemaps` — Google's own view of submitted sitemap health * `get_url_inspection` — live URL Inspection: indexed state and coverage * `list_gsc_imports` — Page-Indexing CSV imports and exclusion reasons * `get_ga4_sections` — GA4 KPIs and section breakdowns in one call * `get_google_search_incidents` — Search Status Dashboard incidents ### Prioritization [#prioritization] Where traffic data turns a list of issues into an order of work. * `get_issues_with_traffic` — issues ranked by traffic at risk * `get_high_traffic_at_risk` — high-traffic pages that also have issues * `get_google_opportunities` — four-layer audit, GSC, GA4 correlation * `get_link_insights` — which pages should link to under-linked pages * `get_content_opportunities` — new pages worth writing, with outlines * `get_backlinks` — backlink profile and referring domains * `get_keywords` — the keyword universe mapped onto site topics ### Trends and comparison [#trends-and-comparison] Change over time, and across devices. * `get_project_trends` — score trends across crawls * `compare_audits` — two crawls side by side * `get_audit_deltas` — new versus fixed issues since the last audit * `get_device_comparison` — metrics across desktop, mobile, and tablet * `get_device_url_gaps` — per-URL score gaps between devices ### Workflows [#workflows] Spider's recipes, run from the agent. Generated images need the download tool. * `list_workflows` — available workflows and their input specs * `run_workflow` — run one by id; returns a `runId` * `get_workflow_run` — poll for status and results * `list_image_references` — Image Studio reference images and their ids * `download_workflow_image` — save a generated image locally Workflow image URLs carry an auth secret only the server holds. An agent must use `download_workflow_image` rather than fetching the URL directly. ### Knowledge base [#knowledge-base] Owner-authored business facts that ground every AI feature. Writes are review-first by design. * `get_knowledge` — documents, or the exact context block AI calls receive * `propose_knowledge` — propose one document; it lands as an inactive draft * `activate_knowledge` — activate a draft the user confirmed verbatim in chat * `add_competitor` — track and profile a competitor from their sitemaps `activate_knowledge` is off by default and enabled per project under Knowledge → "Allow AI to activate knowledge". It refuses unless the body passed matches the stored draft exactly, so an agent cannot activate text the owner has not seen. ### Connection [#connection] Diagnostics. `get_mcp_status` and `get_mcp_scope` are free and never count against usage. * `get_mcp_status` — connection status and usage * `get_mcp_scope` — the project this server is locked to * `get_mcp_diagnostics` — detailed environment and connection diagnostics --- # Pages list URL: https://docs.digispot.ai/docs/desktop/pages/ The Pages tab lists every crawled URL with toggleable score columns and faceted filters, so you can slice a crawl any way you need. After a crawl, the **Pages** tab lists every URL Spider found, as a sortable grid you can filter down to exactly the pages you care about. It is the working list for a crawl. Sort by the score that matters, filter to the pages that need attention, and open any row for its full page report. ## Columns [#columns] A column picker toggles which scores and stats appear, so you can build the view that fits the task. Every column is sortable, so you can lead with the worst pages on any axis. Sort **Content** ascending to surface the thinnest pages, or **Depth** descending to find pages buried too far from the homepage. * Per-category scores — **Indexability**, **Content**, **Headings**, **Media**, **Links**, **Schema**, **Social**, **Performance**, **Local SEO** * **Word count**, **Depth** (clicks from the homepage), **Response time**, and **Page size** Each category cell shows the same 0–100 score and A–F grade used across [Checks & Scores](/docs/desktop/checks-and-scores/). A red cell points straight at the category to open in the page report. ## Filters [#filters] A faceted filter rail narrows the list to a subset before you start working it: * **Severity** — critical, high, medium, low * **Indexability** — indexable, noindex, canonicalized, robots-blocked, unreachable * **HTTP status** — 2xx, 3xx, 4xx, 5xx Filters combine, so you can isolate a precise cut. For example, indexable pages returning 2xx that still carry a critical issue. Select any page to open its [full report](/docs/desktop/reports/). Start from the **Indexability** filter, not the scores. A page marked `noindex`, `robots-blocked`, or `canonicalized` can't rank regardless of its other columns. Clearing unintended exclusions comes before tuning content or performance. --- # Plans & Tiers URL: https://docs.digispot.ai/docs/desktop/plans/ Scout, Tracker, and Leader — what each Digispot plan unlocks in SEO Spider, including page limits, devices, AI, MCP, and Google integrations. Digispot has three plans. The desktop Spider is **free to start** — the **Scout** tier runs the full crawler with a 100-page cap. Paid **Tracker** and **Leader** raise the limits and unlock AI, MCP, and Google integrations. From Scout you can also start a **7-day free trial** to try the paid features. The 7-day free trial is a time-boxed **Tracker** plan you start from the free Scout tier. When it ends you drop back to Scout unless you upgrade. ## What each plan unlocks [#what-each-plan-unlocks] | | Scout (Free) | Tracker (Paid) | Leader (Paid) | | ------------------------------------------------------ | ----------------------- | ----------------------- | ----------------------- | | **Desktop Spider** | ✓ | ✓ | ✓ | | **Pages per crawl** | 100 | 10,000 | Unlimited | | **Concurrency** | 1 | 2 | 4 | | **Device modes** | Mobile only | Mobile, tablet, desktop | Mobile, tablet, desktop | | **AI analysis & copilot** | — | ✓ | ✓ | | **MCP server** | — | ✓ | ✓ | | **Google (GSC / GA4 / GBP)** | — | ✓ | ✓ | | **Local-SEO business locations** | 1 | 5 | 20 | | **Competitors tracked** | 1 · read-only | 4 | 4 | | **Competitor cloud data** (backlinks, market standing) | — | ✓ | ✓ | | **Free trial** | ✓ — start a 7-day trial | Included | — | Tracker's 10,000-page cap is a finite limit. **Leader** is the only plan with unlimited pages, higher concurrency, and the most business locations. ## Seats [#seats] Your plan determines how many machines (seats) you can activate. A license is bound to the hardware it is activated on; moving to a new computer frees and re-binds a seat. --- # SEO Recipes URL: https://docs.digispot.ai/docs/desktop/recipes/ Build repeatable, multi-step SEO audits with Spider's workflow engine — crawl, analyze, and act in one automated run. **SEO Recipes** is Spider's workflow engine — think "n8n for SEO." Instead of running each step by hand, you chain crawler and AI steps into a single repeatable workflow you can run again and again. **Before you start:** recipes that include AI steps need an AI provider connected first. Use either your own key (BYOK) or Digispot-managed credits. See [AI features](/docs/desktop/ai/) to set that up. AI is available on the **Tracker** and **Leader** plans. See [Plans & tiers](/docs/desktop/plans/). ## How it works [#how-it-works] A recipe is a graph of steps that run in order, passing results from one to the next. For example: crawl a site, pull the critical issues, run an AI summary, and produce a prioritized action list. Runs are durable, so a long workflow can resume rather than start over if it is interrupted. ## Step types [#step-types] Steps fall into a few families, and a recipe mixes them freely: * **Crawler steps** — crawl a site or a single page, then pull the audit data, crawl insights, broken links, or duplicates from the result * **AI steps** — summarize a crawl, audit or compare pages, rewrite copy, draft a blog post, or generate a cover image * **Data steps** — pull Google Search Console data, keyword data, or internal-link structure into the run * **Logic and output steps** — branch on conditions, transform values, and shape the final output Because steps pass their results forward, an AI step reasons over the exact data the crawler step just produced, not a generic prompt. ## Templates and your own workflows [#templates-and-your-own-workflows] * **Template gallery** — start from pre-built recipes for common jobs * **My Workflows** — save and re-run your own * **Run view** — see the workflow graph, step-by-step results, and any errors, and compare results between runs Recipes automate the steps *within* a single run you start: crawl, analyze, act. They are not scheduled or triggered automatically. You run a recipe when you want it, the same as any other crawl. ## Running from an AI agent [#running-from-an-ai-agent] Recipes can also be run through the [MCP server](/docs/desktop/mcp/), so an AI assistant can list and trigger your workflows and read back the results. --- # Developers URL: https://docs.digispot.ai/docs/developers/ Automate Digispot with the MCP server — query crawl data, trigger crawls, and wire SEO findings into AI agents and coding assistants. Digispot exposes its crawl data programmatically through the **MCP server**. AI agents and coding assistants query audits, start crawls, and read findings without copy-paste. MCP is the supported programmatic interface today. The desktop Spider and the Cloud Platform each run their own server. ## MCP server [#mcp-server] The MCP server lets Claude Code, Cursor, Windsurf, and any other MCP-compatible client work directly against your crawl data. An agent can answer questions about a site, pull the top issues from a finished audit, and generate fixes grounded in real findings. It comes in two forms: * **Desktop Spider** — a local stdio server, bound per project, with 64 project-scoped tools. The agent talks straight to the on-machine crawl database, so nothing leaves the machine. * **Cloud Platform** — an HTTP server managed with keys created in Settings. It reaches cloud crawls and reporting, which suits shared team projects. See [MCP server](/docs/developers/mcp/) for setup and the tool reference. ## Which server to use [#which-server-to-use] | Goal | Use | | ---------------------------------------------------- | -------------- | | Query crawl data that stays on your machine | Desktop Spider | | Have Claude Code generate fixes from real audit data | Desktop Spider | | Reach audits shared across a team | Cloud Platform | | Work on client sites under NDA | Desktop Spider | ## Keys and connections [#keys-and-connections] Cloud MCP keys are created and revoked in the Cloud Platform under Keys & connections. The same screen manages Chrome-extension keys and Spider desktop licenses. See [Keys & connections](/docs/cloud/api-access/). --- # MCP Server URL: https://docs.digispot.ai/docs/developers/mcp/ Connect AI agents to Digispot crawl data over the Model Context Protocol — the client list, the config each one expects, and what the server exposes. The Digispot MCP server exposes crawl data to any MCP-compatible AI client. A connected agent queries findings, starts crawls, and drafts fixes without anything being copied between tools. Configuration is generated for you. Open a project in Spider and use **Connect AI agent**, or Settings → MCP Server, then pick your client. The snippets below show the shape so you know what you are pasting. ## Two server variants [#two-server-variants] | | Desktop Spider | Cloud Platform | | ------------- | --------------------------------- | ---------------------- | | **Transport** | stdio (local process) | HTTP (remote) | | **Scope** | One project, enforced | Cloud account | | **Tools** | 64 | Varies by plan | | **Auth** | `--project ` binding | API key from Settings | | **Requires** | Spider running, Tracker or Leader | Cloud Starter or above | Use the Desktop Spider server when crawl data lives on your machine and must stay there. Use the Cloud server when crawls run on Digispot's servers or a team shares access. ## Desktop Spider: local stdio server [#desktop-spider-local-stdio-server] The server is a native binary shipped inside the app. Its filename is architecture-specific (`mcp-macos-arm64`, `mcp-macos-x64`, `mcp-win-x64.exe`, `mcp-linux-x64`), and the app resolves the right one for the current machine. Every server is bound to one project. The `--project` argument takes a **project id** and is mandatory — the server refuses to start unbound, and no tool accepts a project id as a parameter, so an agent cannot reach another project. ### Clients [#clients] Each client reads a different file, and VS Code uses a different wrapper key. | Client | Where the config goes | Wrapper key | | ----------------- | ----------------------------------------------------------------- | ------------ | | Claude Code | `claude mcp add` (no file to edit) | — | | Cursor | `~/.cursor/mcp.json` | `mcpServers` | | Windsurf | `~/.codeium/windsurf/mcp_config.json` | `mcpServers` | | VS Code (Copilot) | `.vscode/mcp.json` in the repo | `servers` | | Claude Desktop | `~/Library/Application Support/Claude/claude_desktop_config.json` | `mcpServers` | For the JSON clients the entry is the same shape. Only the wrapper key changes: ```json title="~/.cursor/mcp.json" { "mcpServers": { "digispot-spider": { "command": "/path/to/mcp-macos-arm64", "args": ["--project", ""] } } } ``` Claude Code registers stdio servers through the CLI instead of a pasted file: ```bash claude mcp add digispot-spider --scope local -- /path/to/mcp-macos-arm64 --project ``` The `--` matters. It separates Claude's own flags from the binary's arguments; without it `--project` is parsed by `claude` and the command fails. Run it from inside the repo so `local` scope binds the server to that folder. Use `--scope project` to write a committed `.mcp.json` the team shares. Claude Desktop has a single global config with no per-project scope, so a binding there applies to every Claude Desktop conversation. Prefer a repo-scoped client when you work across several projects. The server exposes **64 tools** covering crawls, pages, issues, Google data, prioritization, workflows, and the Knowledge base, plus **8 packaged SEO skills** registered as MCP prompts. See [Spider's MCP server](/docs/desktop/mcp/) for the full reference. ## Cloud Platform: HTTP server [#cloud-platform-http-server] The cloud server is reached over HTTP with a key instead of a local binary. It queries cloud data: projects and remaining credits, audit results and top issues, keyword and backlink data, Google metrics, and content opportunities. Create and revoke keys under **API access** in the Cloud Platform, which also shows the connection details for your account. See [Keys & connections](/docs/cloud/api-access/). A cloud key reaches your whole account. Keep it in an environment variable or a secrets manager, never in version control. ## Why connect an agent instead of auditing with one [#why-connect-an-agent-instead-of-auditing-with-one] A language model reading raw HTML cannot run an instrumented audit. Spider applies **313 checks across 25 categories** to every page inside a real Chromium browser. Much of that is measurement, not reading. * **Rendered-DOM checks** need JavaScript to execute first. Fetched source shows the pre-hydration markup, which is a different document. * **Core Web Vitals** are timings. LCP, CLS, and TBT come from instrumenting a live page load, and no amount of markup inspection produces them. * **Device parity** means rendering the same URL at mobile, tablet, and desktop viewports and comparing the results. * **Site-level checks** compare pages against each other — duplicate titles, canonical conflicts, orphan pages, crawl depth. They need the whole graph, not one page at a time. An agent pointed at a site fetches pages one at a time and re-derives what it can on every run. A mid-sized site exhausts the context window before the analysis starts, and results drift between runs because each samples a different subset of pages. Spider does that work first and hands over the finished report. The crawler renders every page, runs the checks, and stores the results, so the agent starts from a complete and settled dataset rather than assembling one. That leaves the model doing what it is actually good at: * **Findings arrive as structured data** — severity, affected URLs, and Google metrics are fields to reason over, not HTML to parse. * **One call replaces a crawl** — a single tool returns what would otherwise take hundreds of page fetches. * **Results are deterministic** — the checks are identical on every run, so an agent's conclusions are reproducible. The division of labour is the point. Spider measures; the model interprets. It decides what to fix first, explains why a cluster of pages fails together, and writes the fix. ## What to ask an agent [#what-to-ask-an-agent] With a project bound, the agent works against real crawl data: * "What are the top 10 issues by severity?" * "Which pages fail Core Web Vitals on mobile?" * "Show pages missing a meta description and draft one for each." * "Start a crawl and tell me when it finishes." * "Which pages get the most traffic but fail structured-data checks?" The last one is where MCP earns its place. The agent pulls traffic data, cross-references failing checks, and returns a prioritized plan in one response. Answering it without MCP would mean exporting two reports and joining them by hand. --- # Integrations URL: https://docs.digispot.ai/docs/integrations/ Connect Digispot to Google Search Console, GA4, and the MCP server so findings are ranked by real traffic and queryable by AI agents. Digispot integrates with external data sources so findings are not just graded by severity — they are ranked by the traffic, rankings, and coverage that actually matter to the site. ## Google Search Console [#google-search-console] Search Console is the highest-leverage integration. Once connected, every page's issues are weighted by the queries and clicks that flow through it, so a broken page on a top-ranking URL rises above a broken page on an orphan. **What it unlocks:** * **Clicks, impressions, CTR, and position** by query, URL, country, and device * **URL Inspection** verdicts — live indexing status per page * **Indexability gap** — pages that Search Console isn't indexing, correlated against the crawl * **High-traffic pages at risk** and **striking-distance queries** * **Query cannibalization** detection **How to connect on the Desktop Spider:** 1. Open the Spider app and load a project. 2. Go to **Google integrations** in the project sidebar. 3. Click **Connect Search Console** and complete the OAuth flow in the browser window that opens. Grant at least Read permissions for the property you want to track. 4. Select the GSC property matching your project's domain. Data loads on the next crawl. **How to connect on the Cloud Platform:** 1. Go to **Settings → Projects & Integrations**. 2. Select your project and click **Add integration → Google Search Console**. 3. Complete the OAuth flow. The property appears in the project's Google Insights section after the next scheduled crawl. *** ## Google Analytics 4 [#google-analytics-4] GA4 adds the engagement layer to technical findings. A page with 10,000 monthly sessions and a broken heading structure is a higher-priority fix than the same issue on a page with 10 sessions. **What it unlocks:** * **Sessions, users, and engagement** per URL * **Traffic sources** — organic vs direct vs referral breakdown * **Mobile vs desktop** split, so device-specific issues are prioritized against real device traffic **How to connect on the Desktop Spider:** 1. In the Spider project, open **Google integrations**. 2. Click **Connect GA4** and complete the OAuth flow. 3. Select the GA4 property and the data stream matching your site. The Spider imports up to 16 months of historical data on first sync. **How to connect on the Cloud Platform:** 1. Go to **Settings → Projects & Integrations → Integrations**. 2. Click **Add integration → Google Analytics 4**. 3. Complete the OAuth flow and select the GA4 property. *** ## Google Business Profile [#google-business-profile] Google Business Profile (GBP) data powers the **Local SEO** checks in both the Spider and the extension. Connecting it lets Digispot verify NAP (name, address, phone) consistency, detect duplicate listings, and confirm opening-hours markup against the live profile. GBP connection is managed through the same Google OAuth flow as Search Console. On the Desktop Spider, go to **Google integrations** and click **Connect GBP**. On the Cloud Platform, add it under **Settings → Projects & Integrations**. *** ## MCP server [#mcp-server] The MCP server is the integration for AI assistants and coding tools. It lets Claude Code, Cursor, or Windsurf query your crawl data directly — so an agent can pull the top issues, start a crawl, or surface content opportunities without any copy-paste. The MCP server comes in two forms: * **Desktop Spider** — a local stdio server, bound per project, with 64 tools. See [MCP server docs](/docs/desktop/mcp/). * **Cloud Platform** — an HTTP server with API keys managed under Settings. See [Keys & connections](/docs/cloud/api-access/). For setup instructions and a tool reference, see [MCP server](/docs/developers/mcp/). *** ## Which integrations are available per product [#which-integrations-are-available-per-product] | Integration | Chrome extension | Desktop Spider | Cloud Platform | | ----------------------- | --------------------------------------- | ----------------------- | ----------------------- | | Google Search Console | Via Extension Key (CrUX/PageSpeed only) | Full OAuth, per project | Full OAuth, per project | | Google Analytics 4 | — | Full OAuth, per project | Full OAuth, per project | | Google Business Profile | — | Full OAuth, per project | Full OAuth, per project | | MCP server | — | stdio, 64 tools | HTTP, via API key | --- # Guides URL: https://docs.digispot.ai/docs/guides/ Task-focused walkthroughs for common SEO work in Digispot — on-page fixes, crawl errors, structured data, and Core Web Vitals across all three products. Practical walkthroughs for the SEO tasks you run most often. Each guide notes which product to use for each step and when it makes sense to escalate from a single-page check to a whole-site crawl. ## Choosing the right tool for the task [#choosing-the-right-tool-for-the-task] | Task | Best surface | | --------------------------------- | --------------------------------------------------------------------------- | | Audit a single page quickly | [Chrome extension](/docs/chrome-extension/) | | Check a competitor's page | [Chrome extension](/docs/chrome-extension/) | | Find issues across a whole site | [SEO Spider](/docs/desktop/) | | Prioritize by real traffic | [SEO Spider + GSC](/docs/desktop/google/) or [Cloud Platform](/docs/cloud/) | | Share audits with a team | [Cloud Platform](/docs/cloud/) | | Query crawl data from an AI agent | [MCP server](/docs/developers/mcp/) | *** ## On-page SEO fixes [#on-page-seo-fixes] On-page issues — missing title tags, duplicate meta descriptions, thin content, broken heading structure — appear at the page level in all three products. The workflow below applies wherever you find them. **1. Spot the issue.** In the Chrome extension, open a page and click the **Metadata/Technical** or **Content** panel. The panel lists every check in that category with a pass/fail badge and a one-line reason. On the Spider or Cloud Platform, open a page report and navigate to the relevant category tab. **2. Understand the impact.** Before fixing, check the **Overview** tab. If the extension is connected to a Digispot account, or the Spider has GSC linked, pages with failing checks are ranked by organic traffic so you fix the highest-impact ones first. **3. Make the fix.** For headings, the Chrome extension lets you edit live: click **Apply** next to any heading change to update the element in the DOM and see the revised score immediately. For title and description changes, the edit happens in your CMS or HTML — the extension shows a real-time preview in the **SERP preview** section. **4. Confirm the change.** After deploying, reload the page and run the extension again. The score for that category should update to reflect the fix. On the Spider, run a re-crawl or re-audit of the affected URL to verify. **5. Sweep the site.** A fix on one page rarely stands alone. On the Spider, use **Issues → filter by check name** to find every other page with the same problem and batch the work. On the Cloud Platform, the audit report groups identical issues across all URLs in one view. *** ## Fixing crawl errors [#fixing-crawl-errors] Crawl errors fall into three types: broken links (4xx), redirect problems (chains or loops), and blocked pages (robots.txt, noindex). The Spider is the primary tool here because it finds these across an entire site in one pass. **Broken links (404s)** 1. Run a Spider crawl with JS rendering enabled so dynamically inserted links are caught. After the crawl, open **Issues → Links → Broken links (4xx)**. 2. Each broken link shows the source page and the broken destination URL. Fix by updating the link in your CMS, or add a 301 redirect on the server if the destination URL has changed permanently. 3. After fixing, re-crawl to confirm the issue count drops. The Spider's **Comparison** view overlays two crawls so regressions are visible at a glance. **Redirect chains and loops** 1. In **Issues → Links → Redirect chains**, the Spider lists every multi-hop redirect. A chain of three or more hops loses link equity at each hop and slows page load. 2. Collapse each chain to a single 301 pointing directly to the final URL. 3. Redirect loops (A→B→A) appear in **Issues → Links → Redirect loops** — they cause crawlers to abort and users to see a browser error. Fix by correcting one of the redirect rules on the server. **Blocked pages** 1. Open **Issues → Technical → Blocked by robots.txt** and **Blocked by noindex**. These are pages the crawler found but that Googlebot cannot index. 2. Cross-reference with GSC data (if linked) to find blocked pages that are actually receiving traffic — a sign of a misconfigured rule rather than an intentional block. 3. Fix robots.txt errors by editing the rule in your server config. Fix noindex errors by removing the meta tag or the `X-Robots-Tag` header. *** ## Structured data [#structured-data] Structured data (schema markup) helps search engines understand page content and enables rich results — FAQ accordions, product ratings, recipe cards, and breadcrumbs in the SERP. The extension validates markup at the page level; the Spider sweeps the site. **Validate a single page** 1. Open the page in Chrome, click the extension icon, and open the **Schema** panel. The panel lists every detected schema type (e.g. `Article`, `Product`, `FAQPage`) with a pass/fail status for each required and recommended property. 2. Warnings in orange are missing recommended properties — rich results are possible but may not show. Errors in red are missing required properties — the type is invalid and will not produce a rich result. 3. Use the one-click **AI Audit** on the Schema panel to get a specific, actionable fix for each error, including the corrected JSON-LD snippet. **Find schema errors across a site** 1. On the Spider, run a crawl and open **Issues → Schema**. Errors are grouped by check — for example, "Article: missing `datePublished`" — across all affected pages. 2. Fix the template or CMS field that generates the markup rather than editing pages one by one. After deploying, re-crawl to confirm. 3. For sites with many schema types (e.g. an e-commerce site with thousands of `Product` pages), use the Spider's AI tab to generate a bulk fix plan targeting the highest-priority issue first. **Verify in Search Console** After fixing, submit updated URLs through Google Search Console's URL Inspection tool to request re-indexing and confirm the rich result is eligible. *** ## Core Web Vitals [#core-web-vitals] Core Web Vitals (CWV) — **LCP** (Largest Contentful Paint), **CLS** (Cumulative Layout Shift), and **INP** (Interaction to Next Paint) — are Google's user-experience ranking signals. Poor scores can suppress rankings even when technical SEO is otherwise clean. **Diagnose a single page** 1. Open the page and click the **PageSpeed** panel in the Chrome extension. The panel shows both **Lab data** (Lighthouse, run on demand) and **Field data** (CrUX, real-user data from Chrome). 2. Field data requires a Digispot Extension Key — it reflects actual user experience. Lab data is available without a key and is useful for debugging but does not match what Google sees in the field. 3. Each failing metric shows the contributing elements: the LCP element (usually a hero image or above-fold text), the CLS-causing shift (often a banner, late-loading font, or ad slot), or the INP trigger (a slow event handler). **Fix LCP** * Preload the LCP element using `` for images. * Serve images in modern formats (WebP, AVIF) sized to the render dimensions. * Use a CDN to reduce server response time. Target LCP under 2.5 s. **Fix CLS** * Set explicit `width` and `height` attributes on all `` elements. * Reserve space for ad slots, embeds, and banners using `min-height`. * Avoid inserting content above existing content after page load. Target CLS under 0.1. **Fix INP** * Break up long tasks (over 50 ms) using `setTimeout` or the Scheduler API. * Defer non-essential JavaScript. Target INP under 200 ms. **Find CWV failures across a site** On the Spider (Tracker or Leader plan), the **Devices** report shows CWV scores per page, per device type. Filter by **Failing** to see the full list. The Cloud Platform surfaces the same data aggregated with GSC traffic so the most-visited failing pages sort to the top. --- # Troubleshooting URL: https://docs.digispot.ai/docs/troubleshooting/ Fixes for common problems across the Chrome extension, SEO Spider desktop app, and Cloud Platform. Problems are grouped by product. If the issue crosses products — for example, a Google connection problem — check both the desktop and cloud sections. ## Chrome extension [#chrome-extension] ### The extension shows no results [#the-extension-shows-no-results] Check that you are on an `http://` or `https://` page — browser-internal pages like `chrome://` and `edge://` cannot be audited. Confirm the extension is enabled at `chrome://extensions`. ### The extension asks to allow access [#the-extension-asks-to-allow-access] The extension needs one-time host permission for the site. Select **Allow & analyze** in the prompt. In fullscreen mode this appears the first time per domain; in popup mode it is handled automatically. ### AI Audit button says "Unlock AI Audit" [#ai-audit-button-says-unlock-ai-audit] No AI provider is connected. Go to **Config → AI Provider**, select a provider, paste your API key, and save. See [Connecting an AI model](/docs/chrome-extension/ai-setup/). ### CrUX, PageSpeed, or Domain Age says "Connect to unlock" [#crux-pagespeed-or-domain-age-says-connect-to-unlock] These lookups require a Digispot Extension Key. Go to **Config → Account** and connect your key. See [Managed AI](/docs/chrome-extension/extension-key/). ### SERP mode does not activate on Google [#serp-mode-does-not-activate-on-google] Check that you are on one of the 17 supported Google country domains (`.com`, `.co.uk`, `.de`, and others). Other search engines are not supported. See [SERP Intelligence](/docs/chrome-extension/serp-intelligence/). *** ## SEO Spider — desktop app [#seo-spider--desktop-app] ### Crawl finds only one page [#crawl-finds-only-one-page] The site is blocking crawlers in `robots.txt`, or the homepage has no crawlable internal links. Open the Technical tab on the homepage report and check the robots.txt and crawlability signals. ### Crawl is very slow [#crawl-is-very-slow] Lower the concurrency in crawl settings. Some servers rate-limit aggressive crawlers, which shows up as slow responses rather than errors. ### Desktop app will not open on macOS [#desktop-app-will-not-open-on-macos] Gatekeeper blocks the first launch. Open **System Settings → Privacy & Security** and select **Open Anyway**. See [Install the desktop app](/docs/desktop/install/). ### License will not activate [#license-will-not-activate] Activation requires an internet connection even though crawling itself works offline. If you are behind a corporate proxy, allow `api.digispot.ai`. Also confirm the system clock is correct — clock skew fails the license signature check. ### AI features show a lock or upgrade prompt [#ai-features-show-a-lock-or-upgrade-prompt] AI analysis requires the **Tracker** or **Leader** plan. The free **Scout** tier does not include AI. See [Plans & tiers](/docs/desktop/plans/). ### MCP server will not start [#mcp-server-will-not-start] The server requires a project binding. Copy the configuration from the Spider app — **Connect AI agent** or **Settings → MCP Server** — rather than writing it by hand. See [MCP server](/docs/desktop/mcp/). *** ## Cloud Platform [#cloud-platform] ### Audit run stays queued or fails immediately [#audit-run-stays-queued-or-fails-immediately] Check the audit configuration has a valid root URL and at least one reachable page. If the root URL returns a 4xx or 5xx, the run will fail to start. See [Audits & reports](/docs/cloud/audits/). ### Google Insights shows no data [#google-insights-shows-no-data] The Google integration may need reconnecting. Go to **Settings → Projects & Integrations → Integrations** and check the connection status. If it shows "Credentials invalid", re-run the OAuth flow. See [Settings](/docs/cloud/settings/). ### Content Studio is not available [#content-studio-is-not-available] Content Studio requires the **Starter** plan or above — it is blocked on the **Free** plan. See [Plans & billing](/docs/cloud/billing/). ### AI credits ran out mid-task [#ai-credits-ran-out-mid-task] AI and Data credits are separate pools. Running out of AI credits stops AI generation but not keyword or backlink lookups. Check both balances under **Settings → Usage & Analytics**. See [Plans & billing](/docs/cloud/billing/). ### Invited team member cannot see a screen [#invited-team-member-cannot-see-a-screen] Check the member's role. **Specialist** can create and manage projects and audits. Admin-only screens — Billing, User Management, Chrome Extension, MCP Server, and Spider License — are hidden from Specialists. See [Teams & roles](/docs/cloud/teams/). --- # Content URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/content/ The Content panel measures the depth, readability, and topical relevance of a page's writing across three sub-tabs. The Content panel assesses how well a page's writing serves its intent. It looks at length, readability, and topical coverage across three sub-tabs. A title and metadata audit can't tell you whether the page has enough substance, whether it reads clearly, and whether it stays on topic enough to satisfy the query and earn a ranking. This panel does. Thin or off-topic copy is a common reason a technically clean page still fails to rank. ## Content analysis [#content-analysis] The default sub-tab reports the fundamentals: **word count**, **reading time**, **readability** (Flesch reading ease and grade level), and paragraph and sentence metrics. It then grades the page against the length bands below. | Band | Word count | What it means | | ------------------ | ---------- | ------------------------------------------------------------------------------------------------ | | **Extremely thin** | under 100 | Flagged as **Critical: Extremely thin content** — too little text to establish topical relevance | | **Thin** | under 300 | Flagged as **Warning: Thin content detected** — usually below what ranks for a competitive query | | **Adequate** | 300–600 | Passes the minimum, but often short of the depth top results carry | | **Optimal** | 600–2,500 | The target range for most informational and commercial pages | | **Long** | over 5,000 | Long-form; check that it stays focused rather than padded | Word count is not a ranking factor on its own. The goal is enough depth to cover the topic. Use the flags to spot pages too thin to compete. Then add the sections, examples, and answers a searcher expects, rather than padding to hit a number. **Readability** reports the Flesch reading ease score and its grade level. A lower grade level (roughly grade 8–10 for a general audience) widens the readership. Very high grade levels signal dense sentences worth breaking up. ## Keywords & focus [#keywords--focus] The second sub-tab surfaces what the page is about. This makes any mismatch between the intended topic and the terms actually emphasized visible. * **Industry detection** — primary and secondary industries with a confidence score * **Focus keywords** — target terms pulled from the title, URL, headings, and meta * **Content relevance** — n-gram analysis toggled between unigrams, bigrams, and trigrams, with frequency, relevance, and density * **Related keywords & entities** — business entities, people, and locations Keyword density has its own dedicated panel with deeper analysis. See [Keywords](/docs/chrome-extension/audit-categories/keywords/). ## Authority & SERP [#authority--serp] The third sub-tab covers trust and ranking potential. These are the signals that decide whether a page is treated as a credible answer, not just a relevant one. * **Performance metric cards** — a snapshot of the page's content scores * **Content topics & coverage** — the subtopics the page addresses versus those a query typically expects, so gaps are visible * **Authority & trust** — an E-E-A-T assessment (experience, expertise, authoritativeness, trust) that flags missing author, source, or credibility signals * **Featured-snippet opportunities** — passages structured well enough to win a snippet, and how to tighten them Work the sub-tabs in order. Fix length and readability first (Content analysis). Next, confirm the page targets the right terms (Keywords & focus). Then close topic and trust gaps (Authority & SERP). Adding depth to a page that already targets the wrong topic wastes the effort. --- # Headings URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/headings/ The Headings panel validates the H1–H6 outline and can rewrite headings with AI, applying accepted changes live on the page. The Headings panel maps the page's H1–H6 outline, flags structural problems, and can generate AI rewrites you apply directly on the live page. Headings are how search engines and screen readers parse a page's structure, and how a searcher scans it. A broken outline weakens topical signals and accessibility at once, so it is one of the faster on-page fixes to make. ## Headings overview [#headings-overview] The panel opens with a **Headings Overview**: a count of how many headings sit at each level H1–H6, an overall **Structure** score, and a list of the issues found. Each level is marked **Good**, **Multiple**, or **None**, so a missing H1 or a stack of H1s stands out at a glance. The structural faults it flags: * **Missing H1**, **multiple H1s**, or **skipped levels**. Every page should have exactly one H1, and levels should descend in order (an H2 followed by an H4 skips a level and breaks the outline) * **Empty** or **duplicate** headings. Headings with no text carry no signal, and identical headings blur the page's structure * **Over-optimized** headings: keyword stuffing, which reads as spam rather than as a clear label * **Keyword distribution** across the outline, so the topic is reinforced in headings rather than buried in body text ## Heading structure [#heading-structure] Below the overview, every heading is listed in its natural order of appearance, with its level, position, and text. Headings are also checked for length. A heading past the warning threshold is long enough to read as a sentence rather than a label. Past the error threshold, it is almost certainly too long to scan. | Level | Warning above | Error above | | ------ | ------------- | ----------- | | **H1** | 50 chars | 100 chars | | **H2** | 60 chars | 120 chars | | **H3** | 70 chars | 140 chars | | **H4** | 80 chars | 160 chars | | **H5** | 90 chars | 180 chars | | **H6** | 100 chars | 200 chars | ## AI recommendations [#ai-recommendations] Switching on **AI headings recommendations** turns the panel from an audit into a rewrite tool. Pick the detected **industry** (with a confidence badge) and **intent**, then generate optimized alternatives. They appear side by side with the originals. * **Accept** or **Reject** each suggestion. You can also drive this from the on-page badges * **Apply selected** writes the accepted headings **live into the page** (this needs one-time access to the current site) * **Accept all**, **Reject all**, or **Reset** to restore the originals * Export the headings and recommendations as **CSV** Applying a heading edits the live page in your browser for preview. It does not change the published site. To make it permanent, update your CMS. --- # Images URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/images/ The Images panel audits alt text, formats, file size, and lazy loading, with filters for the images that need attention. The Images panel lists every image on the page and flags the issues that hurt accessibility, search, and load speed. Images are usually the largest bytes on a page, so they drive load time and Largest Contentful Paint. Their alt text is both an accessibility requirement and the main way image search understands them. This panel finds the images working against all three. ## Overview [#overview] The panel opens with an **Images Overview**: scorecards that summarize the page's image health before you drill into individual files. * **Alt text**: how many images carry alt text * **Dimensions**: how many declare explicit width and height, since missing ones cause layout shift * **Optimized**: how many use a modern, appropriately compressed format * **SEO Health**: an overall score that rolls the cards above together The total **page weight** contributed by images is reported here too, so the size cost and its effect on **LCP** is visible at a glance. ## Filtering and export [#filtering-and-export] Filter tabs, each with a count, narrow the list. **Export CSV** includes the URL, alt, type, element tag, width, height, file size, format, status, and lazy-loaded flag for a full audit trail. * **All**: every image on the page * **No ALT**: images missing alt text * **No size**: images with no explicit width or height (a cause of layout shift) * **Large**: oversized files for their dimensions ## Per-image detail [#per-image-detail] Each image card shows a thumbnail and the checks that matter. * **Alt** text, with a **Missing!** flag when absent. Alt text is required for accessibility and is how image search reads the image. Decorative images should carry empty alt, and content images descriptive alt * **Size** and **Format**. WebP and AVIF compress far smaller than JPEG or PNG at the same quality, so the panel recommends them over older formats * A green **Lazy** badge when lazy loading is used, which defers off-screen images so they don't block the initial load * An overall **Error / Warning / OK** status and the specific issues File size is judged by **bytes per pixel**. A large image is only flagged when it's heavy for its dimensions, rather than by absolute size. Modern formats are held to a stricter bar than legacy ones. | Format | OK | Warning | Error | | ----------------- | ------------------ | ------- | -------- | | **WebP / AVIF** | under 0.8 bytes/px | 0.8–1.5 | over 1.5 | | **JPEG / legacy** | under 1.0 bytes/px | 1.0–2.0 | over 2.0 | Fix the largest images above the LCP fold first. Converting a hero image to WebP or AVIF and setting explicit width and height often improves both LCP and CLS in one change. --- # Audit categories URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/ The on-page auditor groups 150+ checks into categories — one panel per area of SEO. This section documents each category, plus the cross-cutting checks. When you audit a page, the 150+ checks are grouped into categories, one panel per area of SEO. Open a category to see its checks, filters, and export options. Every panel also has a one-click **AI Audit** that turns its raw results into prioritized recommendations. The AI Audit button is optional, and every check runs without it. The button reads **Unlock AI Audit** until you [connect an AI model](/docs/chrome-extension/ai-setup/). After that, it becomes the category-specific action (for example *AI Schema Audit*). These 150+ checks run on the page you are viewing. **SEO Spider** extends the same audit to **300+ checks per page** across every URL on a site. A template-level problem then shows up everywhere it occurs, not just where you looked. ## Each category in detail [#each-category-in-detail] *** # Cross-cutting checks [#cross-cutting-checks] These are audited too. They surface within the categories above rather than as panels of their own. ## Indexability & discoverability [#indexability--discoverability] Whether search engines can reach and index the page at all: * **robots.txt validation** — blocked pages, disallowed paths, syntax errors * **sitemap.xml detection** — presence and accessibility * **Meta robots tags** — `noindex`, `nofollow`, `noarchive` * **Canonical URLs** — ensures Google indexes the right version * **X-Robots-Tag HTTP headers** — server-level directives * **User-agent blocking** — detects if Googlebot or other crawlers are blocked * **Crawl accessibility** — JavaScript-dependent content that may not be crawled Indexability problems outrank everything else in severity. A page that cannot be indexed cannot rank, however good the rest of its SEO is. ## Mobile SEO [#mobile-seo] * Viewport meta tags * Mobile-friendly fonts and touch-target sizes * Core Web Vitals on mobile * Responsive image optimization * Mobile usability issues affecting Google's mobile-first index Comparing mobile against desktop by hand, page by page, gets slow fast. **SEO Spider** crawls in **mobile, tablet, and desktop** modes in a real Chromium browser. It reports scores for each mode per crawl. ## AEO — answer engine optimization [#aeo--answer-engine-optimization] AEO is optimization for AI platforms such as ChatGPT, Perplexity, Claude, and Gemini. The extension checks: * Structured content formatting * Clear question-and-answer patterns * Entity recognition * Topical authority signals * Content scannability --- # Keywords URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/keywords/ The keyword analysis surfaces the terms a page ranks for — density across one-, two-, and three-word phrases, related entities, and authority correlation. Keyword analysis shows which terms a page actually emphasizes and how they relate to what already ranks. It lives in the Content panel's **Keywords & focus** sub-tab. It turns the raw text into ranked phrases. This makes the gap between the term a page is meant to rank for and the term it actually reinforces visible, before that gap costs a ranking. ## Keyword density [#keyword-density] Density is analyzed across **unigrams (1-word)**, **bigrams (2-word)**, and **trigrams (3-word)** phrases. Each phrase shows its frequency, relevance, and density, so both primary terms and long-tail phrases are visible. Toggle the n-gram length to move between broad head terms (unigrams) and the specific phrases searchers type (bigrams and trigrams). Density matters in both directions. Too low, and the page reads as off-topic for its target term. Too high, and it reads as stuffed, which no longer helps and can hurt. There is no single ideal percentage. Read density alongside relevance rather than chasing a fixed number. Density is a diagnostic, not a target to hit. Modern ranking weighs topical coverage and entities over exact-match repetition. Use these numbers to catch a page that never mentions its own topic, not to tune to a percentage. ## Focus keywords [#focus-keywords] The panel combines your focus terms with where they come from: **title tag**, **URL**, **headings (H1–H6)**, and **meta description**. This makes a target term's presence across every high-weight element visible at a glance. A term that appears in the body but is missing from the title or H1 is under-reinforced. Adding it to those elements is one of the higher-leverage on-page fixes. ## Related keywords & entities [#related-keywords--entities] Beyond exact phrases, the panel detects **related keywords**, **LSI variations**, and named **entities** — organizations, people, and locations. Each comes with an entity count and relevance percentage. Covering the entities and related terms a topic implies is how a page demonstrates depth to search engines and reinforces E-E-A-T signals, rather than repeating one keyword. ## Authority & SERP correlation [#authority--serp-correlation] Significance scoring ranks each term by likely impact. Authority signals show how the page's coverage compares against what ranks for the query. The significance grade sorts terms into four bands, so effort lands on the phrases that move rankings. | Grade | Meaning | | ------------- | ---------------------------------------------------------------- | | **Excellent** | Highest-significance terms; the page's strongest topical signals | | **Good** | Solid supporting terms that reinforce the topic | | **Fair** | Present but weak; worth strengthening if it's a target term | | **Low** | Minor or incidental terms; usually noise, not a priority | --- # Links URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/links/ The Links panel breaks down internal, external, and other links with anchor text, rel attributes, and CSV export. The Links panel inventories every link on the page and how it is built: anchor text, rel attributes, and destination. This puts internal structure and outbound signals in one place. Links carry ranking equity between pages and tell search engines how a site is organized. Anchor text tells them what the linked page is about. Getting this right spreads authority to the pages that need it. ## Link stats [#link-stats] A summary bar shows the totals: **internal**, **external**, and **other** links (mailto, tel, anchors). It also gives a follow versus **nofollow** breakdown for internal and external links separately. Reading the split matters. Internal links should almost always be followed, so they pass equity through the site. A **nofollow** on an internal link usually wastes that equity. External nofollows are normal and appropriate for untrusted or paid destinations. ## Filtering and export [#filtering-and-export] Filter tabs, each with a count, narrow the list. **Export CSV** saves the full set for a spreadsheet or a developer handoff. * **All**: every link on the page * **Internal links**: same-site destinations * **External links**: off-site destinations * **Other links**: mailto, tel, and in-page anchors ## Per-link detail [#per-link-detail] Each row shows the specifics that matter for SEO. * **Anchor text**, or a **No text** flag when it is missing. Descriptive anchor text is a ranking signal for the destination. Generic anchors ("click here") and empty ones waste it * The full **URL**, with an external-link marker * **rel** and **target** attributes, and a **nofollow** badge. This makes a link that silently blocks equity easy to spot * **Link depth** (for internal links) and **HTTPS / HTTP**. An HTTP link on an HTTPS page is a mixed-content and trust problem Scan for internal links carrying a nofollow badge and for internal links with no anchor text first. Both quietly waste link equity you have already paid for, and both are cheap to fix. --- # Local SEO URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/local-seo/ The Local SEO panel checks NAP consistency, LocalBusiness schema, and location signals — and only applies its advice to genuinely local pages. The Local SEO panel audits the signals that affect local pack and map visibility. Those are the results that appear with a map and pins above the standard listings for a location-based query. The panel is relevance-gated. Global or SaaS pages are not scored against local-only criteria, so they don't collect irrelevant warnings. ## Relevance gate [#relevance-gate] The panel first decides whether local advice even applies, which keeps its scoring honest. * Pages with no local signals show a **Local SEO data unavailable** state rather than failing checks that don't apply * Borderline pages get a soft "possibly local" banner. It explains the positive and negative signals behind the call, and you can override it when the classification is wrong ## Snapshot [#snapshot] For pages that are local, the panel opens with a **Local SEO Snapshot**: status cards that summarize local readiness at a glance before the detailed checks below. * **NAP** — whether Name, Address, and Phone are complete * **Maps** — whether a map is embedded and linked * **Schema** — whether LocalBusiness schema is present * **Reach** — the service area detected for the page ## What it checks [#what-it-checks] Below the snapshot, the detailed checks follow the order the panel presents them. * **Business information (NAP)** — Name, Address, and Phone, plus email and hours, with a consistency check. NAP consistency is a core local ranking factor. The same details must match across the site, schema, and Google Business Profile, or the signal is diluted * **Google Business & Maps** — Place ID and map signals (business profile, map embed, and Maps link) that tie the page to a verified listing * **Local keywords** — city and state terms, service-area keywords, and their coverage across the title, headings, and body * **LocalBusiness schema** — hours, price range, service area, and geo coordinates. These help Google connect the page to a physical location and can drive rich results NAP consistency is the highest-leverage fix here. Before adding keywords or schema, confirm the name, address, and phone match exactly across the page, the LocalBusiness schema, and the Google Business Profile. A mismatch undercuts every other local signal. --- # Metadata URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/metadata/ The Metadata panel audits the title, description, and technical tags that decide how a page is indexed and shown in search results. The Metadata panel covers the tags that control how a page is indexed and how it appears in search. This includes the title and description a user sees in the results, plus the technical directives that decide whether the page can be indexed at all. It's the first place to look when a page ranks poorly despite good content. A single wrong tag here can suppress everything else. ## AI Audit [#ai-audit] The **AI Metadata Audit** button sits at the top of the panel. Until you connect a provider, it reads **Unlock AI Audit**. Run it, and it reviews your metadata and returns three sections: * **What's working** * **Needs improvement** * **Quick wins** Below the review, it suggests **SERP rewrites**: alternative titles and meta descriptions. Each one has a live character count and a one-click copy. Paste a fix straight into your CMS. ## Basic meta [#basic-meta] The core card lists each tag with a **pass / warning / fail** status and a character count. Read it top to bottom, in the order the panel presents it. The title and description carry the most weight, since they're what a searcher actually sees. At the very top sits **Domain age**: how long the domain has been registered, shown as an E-E-A-T trust signal (for example, *2y 8m, Established*). Fetching it is a server-side lookup, available with a free [Extension Key](/docs/chrome-extension/extension-key/). ### Title and description [#title-and-description] | Tag | Optimal length | Why it matters | | -------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Title** | 50–60 characters | The strongest on-page ranking signal and the clickable headline in results. Too long and Google truncates it; too short and you waste the space. | | **Meta description** | \~120–160 characters | Doesn't rank the page, but a sharp description lifts click-through. Google rewrites weak or missing ones, so you lose control of the snippet. | The panel also checks **keyword placement**: whether the primary term appears near the front of the title, where it carries the most weight. ### Canonical and URL [#canonical-and-url] * **URL**: flagged for length and readability * **Canonical URL**: the panel marks it as **self-referencing** (the healthy default), **different**, or **missing**. A **different** canonical means the page points elsewhere. That is correct for duplicates, but a problem if it's unintentional. A wrong canonical is one of the most common causes of a page silently dropping out of the index. ### Language and internationalization [#language-and-internationalization] * **Language**: the declared `lang` attribute checked against the language actually detected on the page, plus BCP-47 validity. This catches a mismatch, for example `en` markup on French content. * **Alternate pages (hreflang)**: the locale count and sample codes, including `x-default` ### Everything else [#everything-else] * **Character set**, **Author & publisher**, and **Mobile optimization** (the viewport tag, required for mobile-first indexing) * **Built with**: the detected technology stack, including frameworks, CMS, analytics, CDN, and more * **Site icon (favicon)**: type, sizes, and any issues. The favicon now shows next to your result on mobile. Expanding **All meta tags** lists every tag the page declares, verbatim: viewport, charset, description, keywords, robots, Open Graph, and the rest. Use it to spot a stray or conflicting directive that the summarized rows above don't call out. ## Indexation [#indexation] A dedicated card states plainly whether the page is **indexable**. It breaks the verdict into the two signals that decide it: * **Meta robots**: the `` directive (`index`/`noindex`, `follow`/`nofollow`) * **X-Robots-Tag**: the same controls, but set as an HTTP header at the server Seeing them separately matters. A page can look fine in its HTML while an `X-Robots-Tag: noindex` header quietly blocks it. That's a problem you can't spot by viewing source. Indexation outranks everything else on this panel. A page set to `noindex` cannot rank, no matter how strong its title, content, or links are. Clear any unintended `noindex` before optimizing anything else. ## Discovery files [#discovery-files] Checks the files that tell crawlers what exists and what to fetch: **robots.txt** (crawl rules), **sitemaps** (the list of URLs to discover), and **llms.txt / llms-full.txt / ai.txt**. The last group is the emerging set of files that guide AI crawlers to your most important content. ## Crawlability & bot access [#crawlability--bot-access] Shows which crawlers can actually reach the page: **Googlebot**, **Bingbot**, **GPTBot**, **Claude-Web**, **PerplexityBot**, and others. Each one is marked **allowed**, **blocked**, or **restricted**. This is where you catch a page that's accidentally blocking AI crawlers in `robots.txt`. That's increasingly costly as ChatGPT, Perplexity, and Gemini send real traffic and citations. Work this panel in order of leverage: fix indexation blockers first, then the title, then the canonical, then the description. The first three decide whether the page ranks. The description decides whether people click. --- # PageSpeed URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/pagespeed/ The PageSpeed panel reports Core Web Vitals from three sources — live in-browser, lab, and real-user field data — plus resource hints. The PageSpeed panel (labelled **Speed**) reports Core Web Vitals and performance. It splits the data across four sub-tabs, so you can compare the numbers a lab, a browser, and real users each report side by side. Core Web Vitals are a confirmed ranking factor. More importantly, they measure the load and interaction experience that decides whether a visitor stays. The three data sources answer different questions: what one test just measured, what real users experience, and what a controlled synthetic run finds. ## Live [#live] The default sub-tab measures Core Web Vitals **live in the browser** using the Performance API: **FCP**, **LCP**, **INP**, **CLS**, and **TTFB**. It works on any URL. Measuring the current page needs one-time access to the site. Each metric is rated against Google's thresholds below. | Metric | Good | Needs improvement | Poor | | -------------------------- | -------- | ----------------- | --------- | | **LCP** (loading) | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s | | **INP** (interactivity) | ≤ 200 ms | 200–500 ms | > 500 ms | | **CLS** (visual stability) | ≤ 0.1 | 0.1–0.25 | > 0.25 | | **FCP** (first paint) | ≤ 1.8 s | 1.8–3.0 s | > 3.0 s | | **TTFB** (server response) | ≤ 800 ms | 800–1800 ms | > 1800 ms | LCP, INP, and CLS are the three Core Web Vitals Google uses. FCP and TTFB are supporting diagnostics that usually explain a poor LCP. Live is a single sample on the current device and connection. Treat it as a fast directional read rather than the number Google scores the page on. ## CrUX [#crux] The **CrUX** sub-tab shows real-user field data (28-day, 75th-percentile) for **mobile** and **desktop**, drawn from the Chrome User Experience Report. This is the closest view to what Google actually scores, because it reflects real visitors on real devices rather than one test. It requires a connected Digispot account. See [Managed AI](/docs/chrome-extension/extension-key/). ## Lab test [#lab-test] The **Lab test** sub-tab runs a Lighthouse test through PageSpeed Insights. It returns mobile and desktop performance scores with the full metric set. Lab data is reproducible and useful for debugging a fix. Lighthouse simulates a throttled mid-range mobile device. A low mobile score next to a high desktop score usually reflects the simulated conditions, not two broken pages. Lab test also requires a connected Digispot account. ## Resource hints [#resource-hints] The **Resource hints** sub-tab scans the page's HTML, with no external call, for the hints that speed up resource loading. It also adds a script analysis and performance insights. * **`preload`**: fetches a critical resource (a hero image or font) early to improve LCP * **`preconnect`**: opens a connection to a third-party origin ahead of need * **`dns-prefetch`**: resolves a third-party domain's DNS early * **`prefetch`**: fetches a resource likely needed on the next navigation The script analysis flags render-blocking and heavy third-party scripts. These are the usual cause of a poor INP or a delayed LCP. When Live and CrUX disagree, trust CrUX. An example is a fast Live LCP against a slower CrUX mobile LCP. CrUX is the p75 of real users over 28 days. Live is one sample on the current machine. INP replaced FID as a Core Web Vital in March 2024. Older tools may still show FID; INP is the metric Google now uses for responsiveness. --- # Schema URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/schema/ The Schema panel detects structured data, validates it against Google's requirements, and visualizes it as an interactive graph. The Schema panel finds the structured data on a page, checks it against Google's requirements, and shows how the entities connect. Structured data is what makes a page eligible for rich results such as star ratings, FAQ dropdowns, product prices, and breadcrumbs. It also increasingly shapes how AI answer engines cite a page. Valid schema doesn't guarantee those results, but its absence rules them out entirely. ## Detection and validation [#detection-and-validation] The panel reads the page's JSON-LD and reports what's present and whether it's complete enough to qualify. * **25+ schema types** — Organization, Product, Article, FAQPage, LocalBusiness, VideoObject, and more * **Valid** vs **valid-with-warnings** status per block. Valid means it meets every requirement. Valid-with-warnings means it works but is missing recommended properties that would strengthen it * **Required** and **recommended** properties, with missing ones highlighted. Missing a required property disqualifies the block from its rich result. Missing a recommended one only weakens it * **Rich-result eligibility** per type, so it's clear which results a page can actually win A block can be valid JSON-LD and still be ineligible for a rich result if a required property is missing. Read the required-property list, not just the valid/invalid status, before assuming a page qualifies. ## Graph and list views [#graph-and-list-views] A toggle switches between two views. The interactive **graph** is a D3 visualization of the schema entities with node dragging, which makes broken or orphaned entity references easy to see. The **list** view can show the **raw JSON**. ## Export [#export] **Export** saves the structured data as a JSON-LD file. **Copy JSON** copies it to the clipboard. Either output is ready to hand to a developer for implementation or to paste into Google's Rich Results Test for a second check. --- # Social URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/social/ The Social panel validates Open Graph and Twitter Card tags and renders a live preview of how the page looks when shared. The Social panel checks the tags that control how a page looks when shared on social platforms, and previews the result before you post it. Open Graph and Twitter Card tags don't affect Google rankings. They do decide whether a shared link shows a rich card with an image and title or a bare URL, and that difference drives click-through on every share. A missing image tag can quietly halve the appeal of every link to the page. ## Tag validation [#tag-validation] The panel audits both tag sets and highlights what is missing. * **Open Graph** — title, description, image, URL, and type. These are the minimum set for a rich card, so missing any one is a must-fix * **Twitter Card** — the card type and its required fields * A **required tags** section listing the gaps in one place * **Image optimization** — dimensions and aspect ratio checks. A share image that will crop or render small is caught before it ships The image and card-type recommendations follow these bands. | Tag | Recommended | Notes | | ------------------ | --------------------- | --------------------------------------------------------------------- | | **og:image** | 1200×630 px, 1.91:1 | 600×315 is the minimum; below that, or the wrong ratio, is a must-fix | | **twitter:card** | `summary_large_image` | Plain `summary` uses a small square thumbnail and underperforms | | **og:title** | up to \~60 chars | Can differ from the page `` — optimize it for feed clicks | | **og:description** | \~150–200 chars | Can be more promotional than the meta description | ## Live preview [#live-preview] Below the checks, the panel renders a **Facebook preview** and a **Twitter preview** from the page's actual tags. Cropping, a missing image, or a truncated title show up as they will in a real feed, not as a list of values. <Screenshot src="/screenshots/extension/extension_fbpreview.webp" alt="The Social panel's AI Social Audit showing required-tags and image-optimization checks passing, above a rendered Facebook preview card built from the page's actual Open Graph tags" caption="The Facebook card renders from live tags, so a crop or missing image is visible as it will appear in-feed — not as a list of values to interpret." width="2582" height="1636" /> <RelatedDocs hrefs="['/docs/chrome-extension/audit-categories/metadata', '/docs/chrome-extension/audit-categories/schema', '/docs/chrome-extension/audit-categories/videos']" /> --- # Videos URL: https://docs.digispot.ai/docs/chrome-extension/audit-categories/videos/ The Videos panel detects embedded and hosted video, validates VideoObject schema, and separates real content from decorative background video. The Videos panel finds every video on the page, both embedded players and hosted files. It then checks whether each is set up to earn video rich results. A video with valid VideoObject markup can win a thumbnail in search and appear in the Google video tab. Without it, the same video is invisible to search. This panel shows which videos are eligible and what's missing on the ones that aren't. ## Overview [#overview] The panel opens with a **Videos Overview**: scorecards that summarize how the page's videos are set up before you drill into individual ones. * **Schema markup**: how many videos carry valid VideoObject markup * **Thumbnails**: how many declare a poster image * **Dimensions**: how many declare an explicit width and height * **UX quality**: playback behavior such as autoplay-with-sound, scored as an overall signal ## Filtering and export [#filtering-and-export] Filter tabs, each with a count, narrow the list. **Export CSV** includes the platform, background flag, dimensions, duration, format, poster, and playback attributes. * **All** — every video on the page * **HTML** — native HTML5 `<video>` elements * **Iframe** — embedded players (YouTube, Vimeo, and others) * **Issues** — only videos with a detected problem ## Per-video detail [#per-video-detail] Each video card shows how it is embedded and configured. * **Source type** — HTML5 video or an iframe embed * **Platform** — YouTube, Vimeo, Wistia, and others, plus self-hosted * **Poster**, **duration**, and playback attributes (autoplay, muted, loop). An autoplay video without muted is flagged as poor UX, since browsers block it and users find it jarring * **VideoObject schema** validity for rich-result eligibility. This is the check that decides whether the video can appear as a rich result at all * The specific issues found <Callout type="info"> Decorative background videos are marked with a **Background Video** badge and excluded from issue counts, so a hero-video loop doesn't generate false warnings. </Callout> <Screenshot src="/screenshots/extension/extension_vedios.webp" alt="The Videos panel's AI Video Audit showing a Videos Overview with schema-markup, thumbnails, dimensions, and UX-quality scores, above a video card flagged with a Video Facade pattern and a warning to add VideoObject schema" caption="Schema markup scores 0/3 here while thumbnails pass — the facade-pattern video is rendered but invisible to search without VideoObject markup." width="2580" height="1542" /> <RelatedDocs hrefs="['/docs/chrome-extension/audit-categories/images', '/docs/chrome-extension/audit-categories/schema', '/docs/chrome-extension/audit-categories/social']" /> --- # Brand report URL: https://docs.digispot.ai/docs/cloud/audits/brand/ The Brand report scores how consistently a site presents its brand across titles, descriptions, schema, and icons. The Brand report scores how consistently a site presents its brand across every page. These are the signals that build recognition in search results. They also feed the trust and authority that influence rankings. A site that names itself the same way in every title, description, and schema block reads as one coherent entity to search engines. An inconsistent one dilutes that signal. ## Score and bands [#score-and-bands] The report opens with a **brand score** and its distribution across pages, graded on consistency and authority signals: | Band | Score | | ------------- | ------ | | **Excellent** | 90–100 | | **Good** | 70–89 | | **Critical** | \< 70 | ## What it scores [#what-it-scores] The score splits into two groups. One covers how the brand appears to users. The other covers how it is declared to machines. * **Brand implementation** — the signals a searcher and a SERP see. **Title match** is how often the brand name appears in page titles, as a similarity percentage. **Description match** is the same for meta descriptions. **Brand icons** covers favicon and icon coverage. * **Technical implementation** — the structured-data signals that let search engines connect pages to a single brand entity. This covers **schema coverage**, the count of **schema pages**, and overall **schema markup**. <Tip> A low **title match** score usually points to templated titles that drop the brand name on deep pages. Appending the brand to every page title is a fast, site-wide fix that lifts recognition in the SERP. </Tip> A per-page detail view breaks brand presence and assets down for a single URL. An AI **Brand analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_brandinsights.webp" alt="Cloud Brand report with title, description, and schema consistency" caption="Brand consistency scored across titles, descriptions, and schema." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/audits/content', '/docs/cloud/audits/media', '/docs/cloud/audits/local-seo']" /> --- # Content report URL: https://docs.digispot.ai/docs/cloud/audits/content/ The Content report scores content quality and E-E-A-T, with keyword, schema, and URL analysis. The Content report scores the writing on each page and the signals that make it trustworthy to both readers and search engines. It is where thin or off-topic pages surface. The structured-data and URL work that supports ranking gets graded here alongside the prose itself. ## Scores and panels [#scores-and-panels] The report opens with a content score, a quality overview, and a score distribution, then breaks the grade into four sub-scores so a weak area is easy to isolate. | Sub-score | What it measures | | ----------------- | -------------------------------------------------------------------------------------------- | | **Content score** | Overall quality from readability, structure, and on-page SEO best practices | | **EEAT score** | How well the page demonstrates Experience, Expertise, Authoritativeness, and Trustworthiness | | **Schema score** | Structured-data coverage and validity | | **URL score** | URL structure, length, and readability | Below the scores, the analysis panels expose the underlying signals: * **Content structure** — headings, word count, and the shape of the page * **Keyword frequency** and **density** — the top terms and how heavily each is used, so keyword stuffing or a missing primary term is visible * **Digit distribution** and **URL length** — supporting URL-readability signals * **Schema quality** — valid schemas separated from those carrying errors or warnings <Screenshot src="/screenshots/cloud/content_analysis.webp" alt="Cloud Content report with content score, sub-scores, and analysis panels" caption="The content report — sub-scores over readability, schema, and URL signals." width="3420" height="1890" /> ## Common issues [#common-issues] The report labels recurring problems in plain terms so they can be triaged directly: **low word count**, **non-optimal title or meta length**, **heading structure**, **URL readability**, **trailing slashes**, and **stop words** in the URL. <Tip> Read the EEAT breakdown before rewriting for keywords. On pages where Google weighs trust heavily — health, finance, legal — a strong EEAT signal (named authors, citations, credentials) moves rankings more than another pass over keyword density. </Tip> ## Page detail [#page-detail] A per-page detail view breaks the score into content, schema, and URL analysis for a single URL. It adds keyword and heading visualizations and an AI summary that turns the findings into edits to make. <Screenshot src="/screenshots/cloud/content_schemamarkup.webp" alt="Cloud Content report schema markup analysis for a page" caption="Schema analysis — valid structured data separated from errors and warnings." width="3420" height="1890" /> <Screenshot src="/screenshots/cloud/content_urlreadablity.webp" alt="Cloud Content report URL readability analysis for a page" caption="URL analysis — length, structure, and readability signals." width="3420" height="1892" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-to-analyze-competitor-seo", title: "Competitor SEO analysis: winning strategies" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/audits/crawlability', '/docs/cloud/content-opportunities']" /> --- # Crawlability report URL: https://docs.digispot.ai/docs/cloud/audits/crawlability/ The Crawlability report checks canonical URLs, meta robots, and whether AI crawlers see the same page Googlebot does. The Crawlability report answers a single question in three parts. Can search engines and AI crawlers reach and index a page? And do they all see the same thing when they do? It is the first report to check when a page has good content but no visibility, because a wrong canonical or a stray `noindex` suppresses everything downstream of it. ## Score and bands [#score-and-bands] The report opens with a crawlability score and its distribution across pages. The per-page gauge reads the score into a plain label: | Band | Score | | --------------------- | ------ | | **Excellent** | 85–100 | | **Good** | 70–84 | | **Needs improvement** | 50–69 | | **Critical** | 0–49 | ## What it checks [#what-it-checks] The report splits into three tabs, each isolating one crawl signal. ### Canonical URL [#canonical-url] Whether each page's canonical is **self-referencing** (the healthy default), **cross-domain**, or **non-matching**. It also flags **redirect chains** and whether the canonical target returns **HTTP 200**. A canonical pointing at a redirect or a 404 quietly drops the page from the index. <Screenshot src="/screenshots/cloud/crawlablity_canonical.webp" alt="Cloud Crawlability report Canonical URL tab with self-referencing and redirect status" caption="The Canonical tab — self-referencing, cross-domain, and redirect-chain status." width="3420" height="1890" /> ### Meta robots [#meta-robots] The indexing and following directives declared per page (`index`/`noindex`, `follow`/`nofollow`), so an unintended `noindex` is caught before it costs rankings. <Screenshot src="/screenshots/cloud/crawlablity_metarobots.webp" alt="Cloud Crawlability report Meta robots tab with index and follow directives" caption="The Meta robots tab — indexing and following directives per page." width="3420" height="1892" /> ### LLM vs Googlebot [#llm-vs-googlebot] A crawler-consistency score comparing what an AI crawler renders against what Googlebot sees. It reports **content-length variance**, **navigation and schema consistency**, and any schema present on one side but missing from the other. Divergence here means JavaScript-dependent content that AI answer engines never receive. <Screenshot src="/screenshots/cloud/crawlablity_llmsvsgoogle.webp" alt="Cloud Crawlability report LLM vs Googlebot tab comparing AI-crawler and Googlebot rendering" caption="The LLM vs Googlebot tab — what AI crawlers see versus Googlebot." width="3420" height="1894" /> <Callout type="info"> The **LLM vs Googlebot** tab is increasingly load-bearing. A page that renders fully for Googlebot but ships a thin or schema-stripped version to AI crawlers can rank in Google yet be invisible in ChatGPT, Perplexity, and Gemini answers. </Callout> Each tab carries an understanding guide that covers what it is, what's checked, why it matters, and how to improve. Each also carries an AI insight that reads the findings back as next steps. <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-google-search-works-basics", title: "How Google Search works: crawling, indexing, and ranking" }, { href: "https://digispot.ai/blog/what-is-canonical-url", title: "Canonical URLs for SEO: complete implementation guide" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/site', '/docs/cloud/audits/content', '/docs/cloud/audits/tech']" /> --- # Audits & reports URL: https://docs.digispot.ai/docs/cloud/audits/ Configure crawls, run them at scale on Digispot's servers, and read the results across report categories — one screen per area of SEO. In the cloud, audits run on Digispot's servers rather than your machine. Long crawls don't tie up a laptop, and your whole team sees the same results. ## Audit configurations [#audit-configurations] An **audit configuration** is a reusable crawl setup for a project. You control: * **Configuration name** and **device type** * **Crawl mode** and **page crawl limit** * **Sitemap limit** and **exclude paths** * Optional modules — **Backlinks**, **Local SEO**, **Internationalization**, and **Content opportunities** <Screenshot src="/screenshots/cloud/edit_configuration.webp" alt="Cloud audit configuration screen with crawl mode, budget, device, and optional-module toggles" caption="An audit configuration — a reusable crawl setup for a project." width="3420" height="1886" /> ## Audit runs [#audit-runs] Start a **run** from a configuration. Runs are listed with a status — Queued, Running, Completed, or Failed — alongside their run steps. When a run completes, its results open as a graded dashboard with category score cards and a severity-ranked issue list. ## Report categories [#report-categories] Once a run completes, the results are split into report screens, one per area of SEO. Each has a list view. Most have a per-page detail view, and each offers an AI **"Summarize with AI"** insight. <SectionCards hrefs="[ '/docs/cloud/audits/issues', '/docs/cloud/audits/site', '/docs/cloud/audits/pages', '/docs/cloud/audits/crawlability', '/docs/cloud/audits/content', '/docs/cloud/audits/performance', '/docs/cloud/audits/links', '/docs/cloud/audits/tech', '/docs/cloud/audits/media', '/docs/cloud/audits/brand', '/docs/cloud/audits/local-seo', '/docs/cloud/audits/international-seo', ]" /> <Callout type="info"> Report screens unlock once an audit run has completed. Some also require their module to be enabled in the audit configuration: Local SEO, International SEO, and Backlinks. </Callout> <RelatedDocs hrefs="['/docs/cloud/dashboard', '/docs/cloud/content-opportunities', '/docs/cloud/google-insights']" /> --- # International SEO report URL: https://docs.digispot.ai/docs/cloud/audits/international-seo/ The International SEO report scores hreflang setup and language and region coverage across the site. The International SEO report scores how well a site serves multiple languages and regions. Its core concern is hreflang. That markup tells Google which language and region each page targets, so the right version reaches the right searcher. It also avoids duplicate-content penalties across translations. The report appears once Internationalization is enabled in the audit configuration. ## Score and hreflang [#score-and-hreflang] The report opens with an **International SEO score** and its distribution across pages, driven largely by hreflang implementation. * **Hreflang statistics** — the count of hreflang tags and alternate language pages detected, and whether an **x-default** is declared to catch unmatched locales * **Implementation method** — how hreflang is delivered (HTML tags, HTTP headers, or sitemap), and whether a **language switcher** is present ## Languages and regions [#languages-and-regions] Beyond hreflang, the report reads what the pages actually declare and target. * **Languages** — the primary and content language detected, and whether the site is **multilingual** or single-language * **Regional distribution** — whether the site is **multi-regional** or single-region, and whether geo-targeting is present * **Multilingual and regional features** — the supporting signals that back a correct international setup <Callout type="info"> This report requires the Internationalization module to be enabled in the [audit configuration](/docs/cloud/audits/). Without it, the report stays locked even after an audit run completes. </Callout> <Tip> Hreflang has to be reciprocal: if page A points to page B as its French alternate, B must point back to A. Missing return tags are the most common hreflang error, and they void the whole relationship — check both directions when the score drops. </Tip> A per-page detail view breaks hreflang and language analysis down for a single URL. An AI **International SEO analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_internationalseo.webp" alt="Cloud International SEO report with hreflang statistics and language coverage" caption="Hreflang coverage and language/region distribution across the site." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/react-seo-optimization-guide", title: "React SEO: the complete guide (includes hreflang)" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/local-seo', '/docs/cloud/audits/crawlability', '/docs/cloud/audits/pages']" /> --- # Issues report URL: https://docs.digispot.ai/docs/cloud/audits/issues/ The Issues report aggregates every finding across the audit, grouped by severity and prioritized into quick wins, easy fixes, and critical work. The Issues report is the fix-first queue for the whole audit. Every other report scores a single dimension. This one collapses all of them into one list, grouped by the problem itself rather than by page. The affected URLs sit behind each issue. It is the fastest way to answer "what should be fixed next" without opening each report in turn. ## Prioritization [#prioritization] The same findings are cut two ways so the queue can be read by urgency or by return on effort. Severity ranks how much an issue can hurt rankings. The priority tabs weigh that severity against how hard the fix is. | Severity | What it means | | ------------ | -------------------------------------------------------------- | | **Critical** | Severe problems that can suppress indexing or ranking outright | | **High** | Significant issues with a clear impact on visibility | | **Medium** | Worth fixing, but not urgent | | **Low** | Minor or cosmetic findings | The smart-prioritization tabs re-sort those same issues by payoff: * **Quick wins** — high impact for low effort, the first place to spend time * **Easy fixes** — low-effort changes with an immediate benefit * **Opportunities** — strategic improvements for the longer term * **Critical issues** — severe problems that need attention regardless of effort <Tip> Work the **Quick wins** tab before the severity buckets. A Critical issue that needs an engineering sprint moves the score no faster than several quick wins shipped the same afternoon. </Tip> ## Filters and table [#filters-and-table] The all-issues table lists each issue type with the signals needed to triage it. The filter bar narrows the list to a single owner or fix type. * **Filters** — **category**, **severity**, **priority**, **team**, and **effort**, so a developer can pull only their queue or an SEO can isolate the highest-impact work * **Columns** — each row shows the issue's **category**, the responsible **team**, its **severity** (Critical / High / Medium / Low), its **effort** (High / Medium / Low), and the total **occurrences** across the site * **Priority pages** — a widget that surfaces the URLs carrying the most issues, so a single high-leverage page can be fixed once instead of chasing the same issue across many pages Effort and severity are independent: a Low-effort issue can still be Critical (a stray `noindex`), and a High-effort issue can be Low severity. The priority tabs exist to combine the two into a single ranked order. ## AI explanation [#ai-explanation] Each row carries an AI explanation that turns a flagged issue into a concrete action: **what it is**, **how to fix it**, and how to **confirm it's fixed** once the change ships. Read the confirmation step before deploying, so the follow-up audit checks the right signal. <Screenshot src="/screenshots/cloud/cloud_issues.webp" alt="Cloud Issues report grouping findings by severity with priority tabs" caption="Findings roll up by issue type, with quick-win and critical tabs." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/dashboard', '/docs/cloud/audits/site']" /> --- # Links report URL: https://docs.digispot.ai/docs/cloud/audits/links/ The Links report scores link health, breaks down internal, external, and social links, and flags broken and redirected links. The Links report scores the site's link health and surfaces the pages carrying the most broken or low-quality links. Internal links spread ranking authority and tell search engines how pages relate; broken and redirected links leak that authority and frustrate users. This report separates the working structure from the leaks. ## Score and bands [#score-and-bands] The report opens with a link score and its distribution across pages. The score reads into three bands: | Band | Score | What it signals | | ------------- | ------ | ---------------------------------------------------------------- | | **Excellent** | 90–100 | Strong structure, no broken links, complete social presence | | **Good** | 70–89 | Solid structure with few broken links | | **Critical** | \< 70 | Many broken links, missing social links, unbalanced distribution | The **score distribution** groups pages into **High quality (70–100%)**, **Needs improvement (40–69%)**, and **Critical (0–39%)** so the spread across the site is visible at a glance. ## Status, distribution, and coverage [#status-distribution-and-coverage] The report breaks link health into the signals that make up the score. * **Link status** — links classed as **working**, **broken**, or **redirected**; broken links waste authority and hurt users, and long redirect chains slow both crawlers and visitors * **Link distribution** — the split of **internal**, **external**, and **social** links, so an over-reliance on external links or a shortage of internal ones stands out * **Social media coverage** — which pages carry social links and which are missing them, a supporting distribution and discovery signal * **Leaderboards** — pages with the **most broken links**, high performers, and pages that need attention <Tip> Fix broken **internal** links before external ones. An internal 404 wastes authority you already own and sends crawlers into dead ends; an external broken link is worth cleaning up but doesn't drain your own link equity the same way. </Tip> A per-page detail view breaks the link analysis down for a single URL. An AI insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_linkinsights.webp" alt="Cloud Links report with link health, status, and distribution" caption="Link health, broken links, and internal/external distribution." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/backlink-analysis-a-step-by-step-guide-to-auditing-link-profiles", title: "How to find and analyze backlinks" }, { href: "https://digispot.ai/blog/best-off-page-seo-strategies", title: "Off-page SEO strategies: build authority and links" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/research', '/docs/cloud/audits/crawlability']" /> --- # Local SEO report URL: https://docs.digispot.ai/docs/cloud/audits/local-seo/ The Local SEO report scores local signals — business schema, local keywords, phone, embedded map, and store locator. The Local SEO report scores the signals that decide whether a site surfaces in the local pack and on maps. These signals are structured business data, geographic keywords, and on-page contact and location cues. For any business with a physical presence, they matter as much as the general audit. The report appears once Local SEO is enabled in the audit configuration. ## Score and features [#score-and-features] The report opens with a **Local SEO score** and its distribution across pages, then grades the site on the presence and coverage of each local feature. Each feature is scored on how many pages implement it: | Feature | What it checks | | ---------------------- | ---------------------------------------------------------------- | | **Business schema** | `LocalBusiness` structured-data markup, the machine-readable NAP | | **Local keywords** | Geographic terms that target a location | | **Local phone number** | On-page local contact information | | **Embedded map** | An interactive location map | | **Store locator** | A dedicated location or branch finder | **Business schema** carries the most weight. `LocalBusiness` markup is how search engines read a consistent name, address, and phone number. That consistency is the foundation of local ranking. <Callout type="info"> This report requires the Local SEO module to be enabled in the [audit configuration](/docs/cloud/audits/). Without it, the report stays locked even after an audit run completes. </Callout> A per-page detail view breaks the local signals down for a single URL: location information, schema implementation, and issues. An AI **Local SEO analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_localseo.webp" alt="Cloud Local SEO report with business schema, keywords, and map signals" caption="Local signals — business schema, keywords, phone, map, and locator." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/advanced-local-seo-strategies", title: "Local SEO strategies: dominate your geographic market" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/brand', '/docs/cloud/audits/international-seo', '/docs/cloud/audits/content']" /> --- # Media report URL: https://docs.digispot.ai/docs/cloud/audits/media/ The Media report scores image and video SEO across the site. The Media report covers both images and video, scoring how well each is set up for search and for speed. Media is often the heaviest thing on a page and the least optimized. Unlabeled images miss image search entirely, and legacy formats slow Core Web Vitals, so this report grades the two together. ## Image SEO [#image-seo] The image section carries its own score and distribution. The per-page view grades each image on the signals that decide whether it ranks and how fast it loads. * **With alt text** — the share of images carrying alt text, the primary image-search and accessibility signal * **With srcset** — responsive-image coverage, so the right size is served per device * **With dimensions** — images declaring `width` and `height`, which prevents the layout shift that hurts CLS * **Legacy format** — JPEG, PNG, and GIF images where **WebP** or **AVIF** would be smaller; zero is the target * **Lazy loading** — reported for information, since lazy loading helps below the fold but hurts above it <Screenshot src="/screenshots/cloud/cloud_images.webp" alt="Cloud Media report Image SEO section with alt text, format, and dimension coverage" caption="Image SEO — alt text, responsive images, formats, and dimensions." width="3420" height="1890" /> ## Video SEO [#video-seo] The video section carries its own score and distribution. It grades embeds on the signals search engines use to understand and surface video. * **With title** — videos named for search engines * **With description** — videos carrying descriptive text * **With schema** — videos backed by structured data, which unlocks video rich results * Player distribution — which players are embedded, reported for context <Callout type="info"> For YouTube embeds, the auditor currently reports **title** and **description** as absent even when the video has them, and only reads captions on native HTML5 players. Read low title, description, and caption coverage on YouTube-heavy pages with that caveat in mind. </Callout> Each section has a per-page detail view and its own AI insight that reads the findings back as fixes. These are **Image SEO analysis** and **Video SEO analysis**. <Screenshot src="/screenshots/cloud/cloud_vedio.webp" alt="Cloud Media report Video SEO section with title, description, and schema coverage" caption="Video SEO — title, description, and VideoObject schema coverage." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/image-compression-for-better-seo-speed", title: "Image compression for better SEO and speed" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/performance', '/docs/cloud/audits/content', '/docs/cloud/audits/pages']" /> --- # Pages report URL: https://docs.digispot.ai/docs/cloud/audits/pages/ The Pages report lists every crawled URL with per-dimension scores, and drills into a full per-page breakdown. The Pages report is the row-per-URL view of the audit. Where the dimension reports each answer one question across the whole site, the Pages report answers every question for one URL. It scores each page on every dimension of SEO and drills into a complete breakdown for any single page. It is the report to open when the fix is page-specific rather than site-wide. ## List view [#list-view] The all-pages table is the crawl result in full. Its **status** column separates pages that scored cleanly from those the crawler could not fully process. | Status | Meaning | | -------------- | -------------------------------------------------- | | **Successful** | Crawled and scored across every dimension | | **Errored** | Reached, but something blocked a complete analysis | | **Broken** | Returned an error status and could not be scored | Alongside status, each row carries score columns for **Overall**, **Crawlability**, **Content**, **Performance**, **Links**, **Brand**, **Local**, **Insights**, **Issues**, and **URL**. Supporting metrics such as average crawl depth, broken links, and slow resources sit beside them. Pages group into quality buckets and into prioritization buckets so the list can be read by health or by opportunity: | Bucket | Score range | | ------------- | ----------- | | **Excellent** | 90–100 | | **Good** | 70–89 | | **Fair** | 50–69 | | **Poor** | 0–49 | The **Quick wins** and **Easy fixes** groupings surface the pages where a small change moves the score most. ## Page detail [#page-detail] Opening a page assembles every dimension's finding for that single URL into one view. It is the per-page equivalent of walking each report in turn. It shows per-dimension cards for **Core Web Vitals**, **Brand score**, **Schema markup**, **Social media**, **Image SEO**, **Video SEO**, **Internationalization**, **Local SEO**, **LLM vs Googlebot**, **URL readability**, **Page links**, **Backlinks**, and **Tech stack**, alongside a screenshot preview, the page's metadata, and an AI summary. <Callout type="info"> When Google Search Console is connected, the page detail overlays real GSC and GA4 data: index status, canonical details, mobile usability, referring URLs, and traffic. Measured performance then sits next to the audited signals for the same URL. </Callout> <Screenshot src="/screenshots/cloud/page_insights.webp" alt="Cloud Pages report with per-dimension score columns and filters" caption="Every crawled URL scored across each SEO dimension." width="3420" height="1892" /> <RelatedDocs hrefs="['/docs/cloud/audits/issues', '/docs/cloud/audits/content', '/docs/cloud/audits/performance']" /> --- # Performance report URL: https://docs.digispot.ai/docs/cloud/audits/performance/ The Performance report covers Core Web Vitals, speed metrics, and network diagnostics, with fastest- and slowest-page leaderboards. The Performance report scores how fast pages load and surfaces the pages and resources holding the site back. Page speed is a direct Google ranking signal through Core Web Vitals, and a slow page loses conversions before it loses rankings. This report isolates both which pages are slow and what is slowing them. ## Score and Core Web Vitals [#score-and-core-web-vitals] The report opens with a performance score and its distribution across pages, built from the Core Web Vitals and speed metrics below. Each metric grades against the same thresholds Google uses: | Metric | Good | Needs work | Poor | | ---------------------------------- | -------- | ---------- | ------- | | **LCP** (Largest Contentful Paint) | \< 2.5s | 2.5–4s | > 4s | | **CLS** (Cumulative Layout Shift) | \< 0.1 | 0.1–0.25 | > 0.25 | | **FCP** (First Contentful Paint) | \< 1.8s | 1.8–3s | > 3s | | **Speed Index** | \< 3s | 3–5s | > 5s | | **TBT** (Total Blocking Time) | \< 200ms | 200–600ms | > 600ms | **LCP** and **CLS** are the two Core Web Vitals Google ranks on directly. **FCP**, **Speed Index**, and **TBT** explain *why* a page is slow: render delay, progressive loading, or main-thread blocking. ## Leaderboards and diagnostics [#leaderboards-and-diagnostics] Beyond the scores, the report ranks pages and pinpoints the causes. * **Leaderboards** — **fastest** and **slowest** pages, high performers, and pages that **need attention**, so the worst offenders are one click away * **Network diagnostics** — **DNS issues**, **SSL issues**, slow lookups, and long transfers, the connection-level delays that page-level optimization can't fix * **Industry-leaders benchmark** — a comparison point for how the score reads against strong sites in the same space <Tip> Start from the **slowest pages** leaderboard, not the site average. A handful of heavy templates usually drags the whole distribution down, so fixing them lifts the score across every page that shares the template. </Tip> A per-page detail view breaks the metrics down for a single URL, with resource and HAR-level analysis. An AI insight reads the findings back as fixes. <Screenshot src="/screenshots/cloud/cloud_performance.webp" alt="Cloud Performance report with Core Web Vitals and speed leaderboards" caption="Core Web Vitals sit next to fastest- and slowest-page leaderboards." width="3420" height="1884" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/core-web-vitals-seo-guide", title: "Core Web Vitals SEO: improve LCP, CLS, and INP" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/pages', '/docs/cloud/audits/media', '/docs/cloud/audits/tech']" /> --- # Site report URL: https://docs.digispot.ai/docs/cloud/audits/site/ The Site report covers site-wide signals — health score, robots.txt, sitemaps, security, and llms.txt. The Site report covers the signals that apply to the whole site rather than a single page. These are the foundations that shape how every URL is discovered, trusted, and served. A problem here rarely shows on one page in isolation, which is why it earns its own report: a blocking `robots.txt` rule or an expired certificate suppresses the entire crawl at once. ## Site visualizer [#site-visualizer] The report opens with the **Site visualizer**, an interactive graph of the crawled site. The homepage sits at the center and pages radiate out along their internal links, in a **Radial**, **Tree**, or **Force** layout. Node colour flags status, so pages with problems stand out from the rest. A side rail reads the graph as numbers: * **Coverage** — the share of the site audited, with the counts of pages audited, discovered but not audited, and never reached * **Internal links** — the total across audited pages, and the **orphan** count * **Section health** — the mean page-audit score per URL folder, clickable to drill in * **Needs attention** — pages ranked by issue severity, most critical first Filter the graph to **Problems**, **Content ops**, or **Links**, search for a page, and use **Export fix queue** to send the flagged pages out as a worklist. <Screenshot src="/screenshots/cloud/site_visualizer_cloud.webp" alt="The cloud Site visualizer showing the crawled site as a radial graph with the homepage at the center and pages radiating out, a side rail with percent audited, internal links and orphans, section health by folder, and a needs-attention list, plus Radial/Tree/Force view toggles and an Export fix queue action" caption="The homepage anchors the graph and pages radiate out by internal link; the side rail reports coverage, section health, and the pages needing attention first." width="3420" height="1892" /> ## Health tiles [#health-tiles] Summary tiles give the site-wide read at a glance: the **site health score** plus the status of the four foundations below it: **robots.txt**, **sitemap**, **security**, and **llms.txt**. Each tile is a jump-off point into its detail panel. ## Detail panels [#detail-panels] Each foundation has a dedicated panel that moves from a status summary into the underlying rules and records. ### Robots.txt [#robotstxt] Presence and the crawl rules it declares — which user agents are allowed or disallowed, and the sitemap references it points to. <Screenshot src="/screenshots/cloud/cloud_robots.webp" alt="Cloud Site report robots.txt panel showing crawl rules and user-agent directives" caption="The robots.txt panel — allowed and disallowed paths per user agent." width="3420" height="1894" /> ### Sitemaps [#sitemaps] Sitemaps processed, **valid and invalid URLs**, average URLs per map, section count, duplicates, internal and external links, and link-text quality. Drilling into a single sitemap opens overall-health, content, and URL-structure analysis. <Screenshot src="/screenshots/cloud/cloud_sitemap.webp" alt="Cloud Site report sitemap panel with valid and invalid URL counts and link metrics" caption="The sitemap panel — valid/invalid URLs and link-text quality." width="3420" height="1890" /> ### Site security [#site-security] Certificate status, **HTTPS**, **TLS version**, **HTTP/2** and **HTTP/3** support, **DNSSEC**, **CAA records**, and the certificate issuer and validity dates. <Screenshot src="/screenshots/cloud/cloud_security.webp" alt="Cloud Site report security panel with certificate, TLS, HTTP/2, and DNSSEC status" caption="The security panel — certificate, TLS, and protocol support." width="3420" height="1892" /> ### llms.txt [#llmstxt] Presence and rules for the emerging file that guides AI crawlers to the content worth citing. It carries its own score and metrics. <Screenshot src="/screenshots/cloud/cloud_llms.webp" alt="Cloud Site report llms.txt panel for guiding AI crawlers" caption="The llms.txt panel — guidance for AI crawlers, scored on its own." width="3420" height="1892" /> <Callout type="info"> Security findings gate more than the padlock icon. An invalid or expired certificate, or a downgrade off HTTPS, undermines trust signals across every page the audit scored. Treat it as a site-wide blocker, not a cosmetic warning. </Callout> ## AI insight [#ai-insight] A **Summarize with AI** insight turns the raw site signals into a plain-language health summary, calling out which foundation is weakest and what to address first. <RelatedDocs hrefs="['/docs/cloud/audits/crawlability', '/docs/cloud/audits/pages', '/docs/cloud/audits/tech']" /> --- # Tech stack report URL: https://docs.digispot.ai/docs/cloud/audits/tech/ The Tech report scores technical infrastructure and lists the technologies detected across the site. The Tech report covers the technical infrastructure behind the site and the technologies it runs on. It answers what the site is built with and how soundly that stack is implemented. This is the layer that quietly shapes crawlability, performance, and security across every page without appearing in any single page's content. ## Score and infrastructure [#score-and-infrastructure] The report opens with a **tech score** and its distribution across pages. The score reflects overall quality of the technology implementation, security, and adherence to best practices. The score bands follow the platform's standard grading: | Band | Score | | ------------- | ------ | | **Excellent** | 85–100 | | **Good** | 70–84 | | **Fair** | 50–69 | | **Poor** | 0–49 | An **infrastructure overview** summarizes the hosting and delivery layer the site depends on. ## Technologies [#technologies] The report detects and groups the technologies running across the site, so the stack is visible in one place rather than inferred page by page. * **Frameworks** — the front-end and rendering technologies in use * **CMS** — the content management system, with its distribution across pages * **Server** — the server software detected, and its distribution * **CDN** — the content delivery network fronting the site, and its distribution * **Analytics** and other tooling detected across pages A per-page detail view breaks the stack and its issues down for a single URL. An AI **Tech stack analysis** insight reads the findings back as next steps. <Screenshot src="/screenshots/cloud/cloud_techinsights.webp" alt="Cloud Tech report with infrastructure and detected technologies" caption="The technologies detected across the site, grouped by category." width="3420" height="1890" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/technical-seo-checklist-for-2025", title: "The ultimate technical SEO checklist" }, { href: "https://digispot.ai/blog/javascript-seo", title: "JavaScript SEO: complete guide for modern web apps" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/site', '/docs/cloud/audits/performance', '/docs/cloud/audits/crawlability']" /> --- # Content Performance URL: https://docs.digispot.ai/docs/cloud/google-insights/content-performance/ The Content Performance view covers rich results and structured data as seen by Google. The Content Performance view pairs two questions about the content itself: which pages actually hold visitors, and which pages earn enhanced treatment in Google results. The first is a GA4 engagement read. The second is Search Console's take on structured data and rich snippets. <Callout type="info"> Page engagement comes from **Google Analytics 4** and fills in once GA4 is connected. Rich results come from Search Console's **URL Inspection** data and need that permission. Without it the rich-results section shows a locked state while page engagement still renders. </Callout> ## Page engagement [#page-engagement] The first section ranks pages by how well they hold and move visitors, drawn from GA4. * Per-page **engagement** and session behavior * The pages carrying the most engaged traffic — the ones worth protecting and building on ## Rich results and structured data [#rich-results-and-structured-data] The second section reads how the site's markup earns enhanced result types. * The **rich result types** Google recognizes on the site and where each is eligible * Where structured data is present but **blocked or invalid**, so a page misses an enhancement it should qualify for * Schema-type analysis across the pages Google has inspected <Tip> A page that ranks well but shows no eligible rich result is often one valid schema block away from a richer, more clickable snippet. Confirm the markup with the Content and Schema audits, then re-check here after Google re-inspects the page. </Tip> <Screenshot src="/screenshots/cloud/gsc_content_performance.webp" alt="Google Insights Content Performance with rich results and structured data" caption="Rich results and structured data as Google sees them." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/search-performance', '/docs/cloud/audits/content', '/docs/cloud/audits/media']" /> --- # Google Insights URL: https://docs.digispot.ai/docs/cloud/google-insights/ Dashboards built on your connected Google data — Search Console and GA4 — so audits are weighted by real traffic, split across focused views. Connect your Google accounts and the platform turns their data into dashboards that sit alongside your audits. Findings are prioritized by real traffic and rankings, not severity alone. ## Connect your Google data [#connect-your-google-data] Through one-click OAuth, connect: * **Google Search Console** — clicks, impressions, CTR, and position by query, country, device, and URL, plus live URL Inspection verdicts * **Google Analytics 4** — traffic and engagement per URL <Callout type="info"> If a connection's credentials expire, it shows as needing reconnection. Re-run the OAuth sign-in to restore syncing. Google Insights is gated by plan and usage. See [Plans & billing](/docs/cloud/billing/). </Callout> <Screenshot src="/screenshots/cloud/cloud_gsc.webp" alt="Cloud GSC analytics dashboard with Search Console clicks, impressions, and queries" caption="Search Console analytics, built into the platform." width="3420" height="1892" /> ## The views [#the-views] Google Insights groups the data into focused views: <SectionCards hrefs="[ '/docs/cloud/google-insights/overview', '/docs/cloud/google-insights/search-performance', '/docs/cloud/google-insights/traffic-users', '/docs/cloud/google-insights/technical-health', '/docs/cloud/google-insights/content-performance', ]" /> <RelatedDocs hrefs="['/docs/cloud/dashboard', '/docs/cloud/audits', '/docs/cloud/settings']" /> --- # Overview URL: https://docs.digispot.ai/docs/cloud/google-insights/overview/ The Google Insights Overview is the headline picture across Search Console and GA4 — health, position, indexing, and profile signals. The Overview is the top-level read on your connected Google data. It pulls the headline numbers from Search Console and GA4 into one screen. It answers the first questions of any check-in: is the site healthy, is it visible in search, and is Google indexing it. The detailed views behind each area sit one click away, so the Overview works as both a status board and a launch point. <Callout type="info"> The Overview fills in only once a project has Google Search Console or Google Analytics 4 connected. Connect them under **Settings → Projects & Integrations**. An area for a source that isn't linked shows a connect prompt instead of numbers. </Callout> ## Site health [#site-health] The first band summarizes how the site is doing overall, drawn from Search Console's site-health signals. * **Health score** — a single rolled-up figure, with a **healthy** or degraded status * **Manual actions** — the count of active manual actions against the site (any number above zero is worth investigating first) * **Security issues** — active security problems Google has flagged ## Search performance [#search-performance] The next band is the Search Console snapshot — how the site appears in results. * **Average position** and **CTR**, with **mobile position** and **mobile CTR** broken out separately, since mobile and desktop rankings often diverge * Totals for **clicks** and **impressions** across the reporting window ## Indexing and crawl [#indexing-and-crawl] This band reads Google's crawl and index coverage. * **Crawl errors** and **crawl success rate** * **Crawled URLs** and **indexed URLs** — the gap between them is where pages are being seen but not indexed ## Business Profile [#business-profile] When a Google Business Profile is connected and has locations, a profile band appears with **profile views** and **photo views**. It stays hidden for projects without a linked profile. <Tip> Read the Overview top to bottom by leverage: clear any manual action or security issue first, then close the indexing gap, then chase position and CTR. A page that isn't indexed can't rank no matter how strong its search metrics look. </Tip> <Screenshot src="/screenshots/cloud/gsc_overview.webp" alt="Google Insights Overview with health, position, and indexing metrics" caption="The headline read across Search Console and GA4 in one view." width="3420" height="1894" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/search-performance', '/docs/cloud/google-insights/technical-health', '/docs/cloud/dashboard']" /> --- # Search Performance URL: https://docs.digispot.ai/docs/cloud/google-insights/search-performance/ The Search Performance view covers Search Console trends — clicks, impressions, and where you rank, by query and geography. The Search Performance view is the Search Console deep-dive. It shows how pages perform in Google results over time, broken down by the query people searched and the country they searched from. It reads the same data Search Console does, laid out to move from the overall trend down to the individual terms and regions driving it. <Callout type="info"> This view is fully Search Console-scoped and needs the **Search Analytics** permission on the connected property. Without it the page shows a locked state rather than data. A `404 No data found` from Google means the report hasn't populated yet, not that something broke. </Callout> ## Performance analysis [#performance-analysis] The top section is the trend line across the reporting window. It shows the four Search Console core metrics and how each is moving. * **Clicks** and **impressions** over time, with the trend direction called out * **Average CTR** — clicks as a share of impressions * **Average position** — where the site ranks on average for the terms it appears for * A **query breakdown** listing the individual terms, so a rise or fall in the totals can be traced to the queries behind it Read impressions and position together: rising impressions at a worsening position usually means the site is surfacing for new but weaker terms. ## Geographic performance [#geographic-performance] The second section maps the same clicks and impressions by country, so you can see where demand concentrates and where the site under-serves a region it should own. * Impressions and clicks **per country** * A geographic view of where search visibility is strong and where it thins out <Tip> Queries sitting at positions 8–20 with real impressions are the fastest wins: they already rank on or near page two, so a targeted content or metadata fix can push them up without earning visibility from scratch. </Tip> <Screenshot src="/screenshots/cloud/gsc_search_performance.webp" alt="Google Insights Search Performance with clicks, impressions, and queries" caption="Search Console clicks, impressions, and position by query." width="3420" height="1892" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/best-seo-analytics-tools-and-metrics", title: "SEO analytics tools: measure and improve rankings" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/overview', '/docs/cloud/google-insights/traffic-users', '/docs/cloud/google-insights/content-performance']" /> --- # Technical Health URL: https://docs.digispot.ai/docs/cloud/google-insights/technical-health/ The Technical Health view covers crawl activity, security status, mobile usability, and Core Web Vitals from Google. The Technical Health view reads Google's own signals on how crawlable, secure, and fast the site is. It draws on the same data behind the crawl and Core Web Vitals reports in Search Console, plus a live PageSpeed reading. It's Google's opinion of the site's technical shape, which is the opinion that decides rankings. <Callout type="info"> Security status and crawl activity come from Search Console's **URL Inspection** data and need that permission on the connected property. Without it those sections show a locked state. The **PageSpeed** section uses a separate Google API and stays available regardless. </Callout> ## Google security status [#google-security-status] The first section states plainly whether Google has flagged the site. * **Overall health status** and **total issues** * **Manual actions** — penalties applied against the site * **Security issues** — malware, hacked content, or similar problems Anything here outranks the rest of the page. A manual action or security flag can suppress the whole site until it's cleared. ## PageSpeed and Core Web Vitals [#pagespeed-and-core-web-vitals] The middle section is the speed and experience reading. It's taken live from Google's PageSpeed data. * **Core Web Vitals** for both **mobile** and **desktop** — the field metrics for loading, interactivity, and layout stability * The performance scores Google assigns each profile ## Crawl activity [#crawl-activity] The last section monitors how Google is fetching and indexing the site. * **Crawl activity** over time — how often Googlebot visits * **Indexed URLs** and crawl volume * **Crawl errors** — server errors, not-found, robots-blocked, and the other failure types that keep pages out of the index <Tip> Field Core Web Vitals here reflect real visitors over the trailing window, so a fix won't show up immediately. Use the Performance audit for lab data that reacts to a change the moment it ships, and watch this view to confirm the gain lands for actual users. </Tip> <Screenshot src="/screenshots/cloud/gsc_technicalhealth.webp" alt="Google Insights Technical Health with crawl, security, and Core Web Vitals" caption="Crawl activity, security status, and Core Web Vitals from Google." width="3420" height="1888" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-to-submit-urls-to-google-for-indexing", title: "How to submit URLs to Google for indexing" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/overview', '/docs/cloud/audits/crawlability', '/docs/cloud/audits/performance']" /> --- # Traffic & Users URL: https://docs.digispot.ai/docs/cloud/google-insights/traffic-users/ The Traffic & Users view covers GA4 audience and engagement — sources, devices, bounce rate, and geography. The Traffic & Users view is the GA4 side of Google Insights. It covers who visits, where they come from, and how they engage once they arrive. Where Search Performance shows how the site earns visibility in Google, this view shows what happens after the click: audience size, channel mix, and device behavior. <Callout type="info"> This view is Google Analytics 4-scoped. Its widgets fill in only after GA4 is connected and has synced data for the project; until then they show an empty or connect state rather than an error. </Callout> ## User analytics overview [#user-analytics-overview] The first section sizes and segments the audience. * **Total users**, **new users**, and **returning users**, each with its trend * The balance of new versus returning as a read on whether the site is acquiring or retaining ## Traffic sources [#traffic-sources] The second section attributes visits to the channels that produced them. * **Traffic by source and channel** — organic, direct, referral, and the rest * Trends per source, so a shift in the mix is visible over time ## Device performance [#device-performance] The third section splits engagement by device, since mobile and desktop visitors rarely behave the same. * **Mobile, desktop, and tablet** sessions * **Bounce rate** and **average session duration** per device * The **mobile-versus-desktop gap** — where one device engages markedly worse than the other <Tip> A high mobile bounce rate against a healthy desktop rate usually points at a page-experience problem — layout, speed, or intrusive interstitials on small screens — rather than a content problem. Cross-check the affected pages in the Performance audit. </Tip> <Screenshot src="/screenshots/cloud/gsc_traffic_users.webp" alt="Google Insights Traffic and Users with GA4 sources and device split" caption="GA4 traffic sources, devices, and engagement." width="3420" height="1890" /> <RelatedDocs hrefs="['/docs/cloud/google-insights/search-performance', '/docs/cloud/google-insights/content-performance', '/docs/cloud/dashboard']" /> --- # Backlink research URL: https://docs.digispot.ai/docs/cloud/research/backlinks/ Profile the domains linking to a site with a health verdict, six headline metrics, and a sortable referring-domains table — generated as part of an audit run. Backlink research profiles the domains linking to a site so both authority and risk stay visible. Open **Backlinks Analysis** in the left sidebar. Unlike keyword and SERP research, it isn't a standalone lookup — the profile is generated when an audit runs with **Backlinks Analysis** enabled. <Callout type="info"> If the page is empty, turn on Backlinks Analysis in the audit configuration, run an audit, then pick that run from the selector at the top of the page. A `NO_DATA` result means the provider hasn't indexed the domain yet — common for new or small sites — not that the site has no links. </Callout> ## Profile health [#profile-health] The page opens with a health verdict for the whole profile — **Healthy**, **Review needed**, or **Critical** — computed from spam score, broken links, and referring- domain count. When something needs attention, it lists the specific issue: * **High spam score** — above 25% is flagged critical; 10–25% is a warning to review low-quality links * **Broken backlinks** — above 300 is critical; 50–300 suggests adding redirects to recover the lost link authority * **Thin link profile** — fewer than 20 referring domains prompts a push for more quality links ## Headline metrics [#headline-metrics] Six cards summarize the profile at a glance. * **Total backlinks** — every inbound link found * **Referring domains** — the unique domains linking in * **Domain rank** — the site's global ranking position * **Spam score** — the share of the profile that looks low-quality, as a percentage * **Referring pages** — the individual pages linking to the site * **Broken backlinks** — inbound links that no longer resolve ## Referring domains [#referring-domains] The referring-domains table is where the profile gets actionable. High-spam domains are hidden by default so a toxic tail doesn't distort the read. * **Domain** — the linking site, opening in a new tab * **Rank** — that domain's authority score * **Links** — how many backlinks it sends * **Spam** — its spam score, colored red above 40% and amber above 20% * **Type** and **placement** — the link's kind and where on the page it sits * **First seen** — when the backlink was discovered * **Status** — active or lost Sort by rank, link count, spam, or first-seen date, filter by link type, and search by domain name. The default spam filter hides domains scoring above 50 — uncheck **Hide high spam** to see them, and the table reports how many are hidden. <Screenshot src="/screenshots/cloud/cloud_backlinks.webp" alt="Cloud backlinks analysis with referring domains and authority signals" caption="The health verdict and six cards sit above a sortable, spam-filtered referring-domains table." width="3420" height="1892" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/backlink-analysis-a-step-by-step-guide-to-auditing-link-profiles", title: "How to find and analyze backlinks" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/audits/links', '/docs/cloud/research/keywords', '/docs/cloud/billing']" /> --- # Research URL: https://docs.digispot.ai/docs/cloud/research/ Keyword, SERP, and backlink research in the cloud — powered by Data credits, with a saved library for what you look up. The Cloud Platform includes research tools that pull live search data. These run on **Data credits**, a pool separate from AI credits. See [Plans & billing](/docs/cloud/billing/). <Callout type="info"> Every lookup spends Data credits. Items saved to your library stay available without re-spending, so save what you plan to revisit. </Callout> ## The three research tools [#the-three-research-tools] Research is split by what you start from — a term, a query, or a domain's link profile. * **[Keywords](/docs/cloud/research/keywords/)** — look up volume, difficulty, intent, and CPC for a term, expand it on a related-keyword graph, pull a competitor domain's rankings, and keep results in a reusable library * **[SERP](/docs/cloud/research/serp/)** — capture a live results page for a query, track how target keywords move over time, and list every query the domain ranks for * **[Backlinks](/docs/cloud/research/backlinks/)** — profile the domains linking to a site, with a health verdict and per-domain authority and spam signals, generated as part of an audit run <RelatedDocs hrefs="['/docs/cloud/google-insights', '/docs/cloud/content-opportunities', '/docs/cloud/billing']" /> --- # Keyword research URL: https://docs.digispot.ai/docs/cloud/research/keywords/ Look up search volume, difficulty, intent, and CPC for any term, expand into related keywords on a relationship graph, pull a competitor domain's rankings, and keep results in a reusable library. Keyword research pulls live search data for a term, expands it into related keywords, and keeps everything you unlock in a reusable library. It runs on **Data credits**, a pool separate from AI credits. See [Plans & billing](/docs/cloud/billing/). Open **Keywords** in the left sidebar. It expands into three tabs: **Research** for a single term, **Domain** for a competitor's rankings, and **Library** for everything you've unlocked. <Callout type="info"> A keyword lookup costs 1 Data credit. Turning on related keywords adds up to 10 more (one per related term returned). Revisiting anything in your Library is free. </Callout> ## Research — one keyword at a time [#research--one-keyword-at-a-time] On the **Research** tab, enter a term, set its **location** and **language**, and toggle **related keywords** on or off before you click search. The result opens with the term's core metrics and a 12-month volume trend. * **Search volume** — monthly searches, with month-over-month, quarter, and year trend deltas * **Keyword difficulty** — a 0–100 score, banded for quick reading * **CPC** and **top-of-page bids** — the low and high Google Ads bid range * **Search intent** — a primary label (informational, navigational, commercial, transactional) plus any secondary intents * **Competition** — level (low / medium / high) and the raw competition index * **SERP features** — which result types appear for the term (featured snippet, People Also Ask, video, local pack, AI Overview, and others) * **Ranking-page averages** — mean backlinks, referring domains, and domain rank across the current top 10 Difficulty is banded so a number reads at a glance: | Band | Score | | --------- | ------ | | Easy | 0–29 | | Possible | 30–49 | | Difficult | 50–69 | | Hard | 70–100 | ### Related-keyword graph [#related-keyword-graph] With related keywords enabled, the seed term anchors a force-directed graph of up to 10 connected keywords. Click any node to re-research it — each drill-down adds to a breadcrumb trail (up to five deep) so you can walk back without re-spending. Filter the graph by **intent**, **difficulty range**, and **CPC range**, and the related-keyword table flags **opportunities** where difficulty is 30 or below and volume is 500 or above. ## Domain — a competitor's keywords [#domain--a-competitors-keywords] On the **Domain** tab, enter a competitor's domain with a location and language to pull the keywords that domain already ranks for — the terms a site should target but may not yet. Results are paginated and carry the same per-keyword metrics as Research, plus word count and referring-domain and backlink counts per term. A domain pull costs 1 credit plus up to 11 for the keywords returned. ## Library — what you've unlocked [#library--what-youve-unlocked] The **Library** tab collects every keyword you look up, and its label shows the running count. Sort by volume, difficulty, CPC, or unlock date, and search by text. Reopening a saved keyword in Research restores it from cache at no cost. Keywords with no volume, difficulty, or CPC are flagged so a niche or mistyped term is obvious. <Screenshot src="/screenshots/cloud/cloud_keywords.webp" alt="Cloud keyword research view with keywords, metrics, and expansion options" caption="The Research tab pairs core metrics with the related-keyword graph for drill-down." width="3420" height="1892" /> ## Credits and plan limits [#credits-and-plan-limits] Related keywords, the domain pull, and batch lookups are gated by plan. | Action | Cost | Plan | | --------------------------- | ------------- | -------------- | | Single keyword lookup | 1 Data credit | Free and up | | + related keywords | up to 10 more | Starter and up | | Domain keyword pull | 1 + up to 11 | Starter and up | | Reopening a Library keyword | Free | Free and up | <FromTheBlog posts="[ { href: "https://digispot.ai/blog/understanding-keyword-search-volume", title: "Understanding keyword search volume" }, ]" /> <RelatedDocs hrefs="['/docs/cloud/research/serp', '/docs/cloud/content-opportunities', '/docs/cloud/billing']" /> --- # SERP research URL: https://docs.digispot.ai/docs/cloud/research/serp/ Capture a live Google results page for any query, track how the project's keywords rank over time, and see every query the domain ranks for — with device, language, and depth control. SERP research captures a live Google results page for a query and tracks how the project's own pages rank over time. It runs on **Data credits**, a pool separate from AI credits. See [Plans & billing](/docs/cloud/billing/). Open **SERP** from the left sidebar. The top-right toggle switches between two views: a one-off **Lookup**, and a **Rank Tracker** that follows the project's target keywords over time and lists every query the domain already ranks for. <Callout type="info"> A new lookup or a manual refresh costs 1 Data credit. Cached results, rank tracking summaries, timelines, and domain positions are free to view. </Callout> ## Lookup — a live results page [#lookup--a-live-results-page] On the **Lookup** view, type a query into the search bar, set the search context in the controls beside it, and click **Search**. * **Location** and **language** — where and in which language the search runs * **Device** — desktop or mobile * **Depth** — top 10, 20, 50, or 100 results The snapshot header reports the total result count, any **spell correction** Google applied, the **related searches** shown, and which **SERP features** are present. Each result card carries its own detail. * **Rank** — absolute position, plus the group rank where it differs * **Result type** — organic, video, featured snippet, knowledge panel, local pack, AI Overview, top stories, and others, each badged * **Title, URL, domain, and snippet** — with any extended or pre-snippet text * **Own-site highlight** — results on the project's domain are marked and tinted * **Rich elements** — star ratings with vote counts and expandable FAQ blocks where Google shows them Results extract from a full Google page, so organic listings, ads, local packs, and AI Overviews are all captured rather than organic-only. <Screenshot src="/screenshots/cloud/cloud_serp_lookup.webp" alt="Cloud SERP lookup showing search context, feature badges, and result cards for a query" caption="The header flags every feature on the page — AI Overview, People Also Ask, video — before the result cards begin." width="3420" height="1890" /> ## Rank Tracker — positions over time [#rank-tracker--positions-over-time] Click **Rank Tracker** in the top-right toggle. It records daily positions and splits into two tabs, **Tracked** and **All positions**. ### Tracked [#tracked] Open the **Tracked** tab. It follows the keywords set as project targets. A KPI bar summarizes the set — **tracked count**, **average rank**, **improved**, **declined**, and **featured** — above a distribution of how many keywords sit in the top 3, top 10, top 50, or aren't ranking. Select a keyword to open its **Position History**: a rank timeline over 7, 30, or 90 days, plus an on-demand view of the latest SERP for that term. Add a keyword to tracking straight from a Lookup with **Track keyword**. <Screenshot src="/screenshots/cloud/cloud_serp_tracker.webp" alt="Rank Tracker Tracked tab with keyword list, KPI summary, and a position-history timeline" caption="Position History plots one keyword's rank across every check, so a steady position reads as a flat line rather than a single number." width="3420" height="1892" /> ### All positions [#all-positions] Open the **All positions** tab. It lists every query where the project's domain appears — tracked and discovered. Filter by keyword text and device to see the ranking URL, position, location, and when each was last checked, and add any discovered query to tracking inline. <Screenshot src="/screenshots/cloud/cloud_serp_positions.webp" alt="Rank Tracker All positions tab listing ranking queries, positions, and ranking pages" caption="Discovered rankings appear alongside tracked ones, surfacing queries the domain ranks for without anyone adding them." width="3420" height="1890" /> ## What each view answers [#what-each-view-answers] | View | Question it answers | Cost | | ---------------------------- | -------------------------------------- | ----------------------- | | Lookup | Who ranks for this query right now? | 1 credit per new lookup | | Rank Tracker · Tracked | How are my target keywords moving? | Free to view | | Rank Tracker · All positions | Which queries does my domain rank for? | Free to view | <RelatedDocs hrefs="['/docs/cloud/research/keywords', '/docs/cloud/google-insights/search-performance', '/docs/cloud/billing']" /> --- # Content tab URL: https://docs.digispot.ai/docs/desktop/reports/content/ The Content tab measures quality, keywords, and authority across three sub-tabs, with intent and industry detection. The Content tab assesses how well a page's writing serves its purpose. It checks whether the page reads clearly, targets the right terms, and carries the trust signals Google and AI answer engines reward. A page identity card at the top shows the detected **intent**, **industry**, and **page type**, each with a confidence percentage. That frames the rest of the tab against what the page is actually trying to do. The detail is split across three sub-tabs. ## Content analysis [#content-analysis] The first sub-tab reports the fundamentals in a metric grid: **word count**, **reading time**, paragraph counts, **text-to-HTML ratio**, **readability grade** (with the Flesch reading-ease score), vocabulary diversity, passive voice, and maximum keyword density. * **Readability grade** — a lower grade reads more broadly; aim to match it to the audience rather than push it as low as possible. * **Text-to-HTML ratio** — a very low ratio can signal a thin or heavily templated page. * **Max keyword density** — the single most-repeated phrase's share of the text, the early-warning signal for keyword stuffing. <Screenshot src="/screenshots/spider/content_analysis.webp" alt="Spider Content tab Content analysis sub-tab with word count, readability, and content metrics" caption="Content analysis — the readability and structure fundamentals." width="3420" height="2072" /> ## Keywords & focus [#keywords--focus] The second sub-tab covers what the page targets: * **Related keywords & entities**, and **focus keywords** drawn from the title and headings * **Keyword density** — a table of one-, two-, and three-word phrases with each phrase's share of the analyzed text * **Keyword placement** — a matrix of each keyword against the title, meta, URL, and heading levels, flagging over- and under-optimization * A keyword-stuffing banner when density exceeds the safe threshold <Callout type="info"> Placement is judged separately from density. A keyword can appear at healthy density yet be missing from the title or H1. The placement matrix is where that gap shows. Closing it usually moves rankings more than adding repetitions. </Callout> <Screenshot src="/screenshots/spider/spider_keywordfocus.webp" alt="Spider Content tab Keywords and focus sub-tab with density table and placement matrix" caption="Keywords & focus — density by phrase length and a keyword-placement matrix." width="3420" height="2076" /> ## Authority & SERP [#authority--serp] The third sub-tab scores ranking potential. It covers an **intent** breakdown, a **content and keyword balance** rubric, **trust signals** (E-E-A-T: experience, expertise, authoritativeness, trust), and **featured-snippet opportunities**. Snippet opportunities are the lists, tables, and definitions the page is structured to win. They matter increasingly because the same structured passages that win a featured snippet are what AI answer engines quote. On paid tiers, the tab's **Content AI Audit** turns all of this into prioritized recommendations. <Screenshot src="/screenshots/spider/spider_authorityserp.webp" alt="Spider Content tab Authority and SERP sub-tab with E-E-A-T trust signals and snippet opportunities" caption="Authority & SERP — E-E-A-T trust signals and featured-snippet opportunities." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/how-to-analyze-competitor-seo", title: "Competitor SEO analysis: winning strategies" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/headings', '/docs/desktop/reports/links', '/docs/desktop/reports/overview']" /> --- # Headings tab URL: https://docs.digispot.ai/docs/desktop/reports/headings/ The Headings tab validates the H1–H6 outline, flags structural problems, and can fix the structure with AI. The Headings tab maps the page's H1–H6 outline and flags the structural problems that confuse both readers and search engines. A clean heading hierarchy tells Google what a page is about and how its sections nest. A missing or duplicated H1, or a skipped level, weakens that signal and hurts accessibility. Any heading-structure issues appear in a card at the top. The tab's score is the page's **headings score**. ## Count grid [#count-grid] A grid shows the count for each level, H1 through H6, plus a **Structure** cell. Each cell carries a one-word status: * **H1** — **Missing** (zero found), **Multiple** (more than one), or **Good** (exactly one). Google expects exactly one H1 per page. * **H2–H6** — **None**, **Too many** (more than 200 at a level), or **Good**. * **Structure** — the count of failed heading checks, shown as **Issues** or clean. An amber banner appears below the grid when the page does not have exactly one H1, or when the structure has hierarchy issues, spelling out the specific problem. ## Heading structure [#heading-structure] The full outline is listed in document order, indented by level, with each heading's tag, and its position and word count where available. The H1 carries a **primary keyword** chip: green when the extracted focus term is present in the H1, amber when it is missing. Use it to confirm the page's main heading targets its topic. The first 20 headings show by default, with a "Show all" control for longer pages. A **Copy** button exports the outline as indented text. <Callout type="info"> A page can have several H2s and lower levels. That is expected and healthy. The one-per-page rule applies only to the H1. The value of H2–H6 is a logical, unbroken nesting, not a specific count. </Callout> ## AI action [#ai-action] On paid tiers, the **Headings AI Audit** reviews the outline. An AI action can **fix the heading structure**, proposing a corrected hierarchy you can copy into the page. <Tip> Fix the H1 first: a missing or duplicated H1 is the highest-leverage heading problem, since it is the strongest structural signal of what the page is about. Correct skipped levels (an H4 directly under an H2) second. </Tip> <Screenshot src="/screenshots/spider/spider_headings.webp" alt="Spider Headings tab showing the H1-H6 count grid and heading outline" caption="The count grid flags a missing, multiple, or skipped heading level at a glance." width="3420" height="2070" /> <RelatedDocs hrefs="['/docs/desktop/reports/content', '/docs/desktop/reports/metadata', '/docs/desktop/reports/overview']" /> --- # Reports & dashboards URL: https://docs.digispot.ai/docs/desktop/reports/ Read your crawl — the project dashboard, the Visualizer, audit comparison, and the per-page report with a tab for every area of SEO. Once a crawl finishes, Spider gives you several ways to read the results. They range from a site-wide overview down to a single page, and across runs over time. ## Project dashboard [#project-dashboard] The project dashboard is the site-wide overview. It shows the latest run's issue breakdown by severity and category, device-by-device scores, site-health signals, and the trend across previous crawls. It's the fastest way to see what's burning and what to fix first. <Screenshot src="/screenshots/spider/reports_dashboards.webp" alt="Spider project dashboard showing issue breakdowns, device scores, and site-health signals" caption="The project dashboard — a site-wide view of the latest crawl." width="3420" height="2074" /> ## The Visualizer [#the-visualizer] The Visualizer maps your site as an interactive graph, color-coded by depth, status, or issues, and grouped into clusters you can drill into. It's the fastest way to spot orphan pages, over-deep sections, and broken-link clusters at a glance. See [The Visualizer](/docs/desktop/reports/visualizer/) for the full feature set. ## Comparing audits [#comparing-audits] Compare two crawls to see exactly what changed. It reports issues fixed versus newly introduced, and score and page-count deltas. Run it after shipping fixes to confirm they worked, or on a schedule to catch regressions. <Screenshot src="/screenshots/spider/spider_comparison.webp" alt="Spider audit comparison showing issues fixed versus introduced and score deltas between two crawls" caption="Audit comparison — what improved and what regressed between two crawls." width="3420" height="2070" /> ## The per-page report [#the-per-page-report] Open any crawled URL to see its full report. A sticky **SEO score** and issue count sit in the header. The detail is split into tabs, one per area of SEO. Every tab carries a one-click **AI Audit** on paid tiers. Page issues appear on the **Overview** tab rather than a tab of their own. <SectionCards hrefs="[ '/docs/desktop/reports/overview', '/docs/desktop/reports/metadata', '/docs/desktop/reports/headings', '/docs/desktop/reports/content', '/docs/desktop/reports/links', '/docs/desktop/reports/media', '/docs/desktop/reports/schema', '/docs/desktop/reports/social', '/docs/desktop/reports/performance', '/docs/desktop/reports/technical', '/docs/desktop/reports/local-seo', '/docs/desktop/reports/internationalization', ]" /> <Tip> Start with errors on your highest-traffic pages. Fixing one template usually clears the same issue across hundreds of URLs at once. </Tip> <RelatedDocs hrefs="['/docs/desktop/checks-and-scores', '/docs/desktop/google', '/docs/desktop/crawler']" /> --- # Internationalization tab URL: https://docs.digispot.ai/docs/desktop/reports/internationalization/ The Internationalization tab validates hreflang — language and region coverage, self-reference, x-default, and the variant list. The Internationalization tab validates a page's **hreflang** setup: the tags that tell Google which language and region version to serve to each searcher. Get it wrong and Google may show the English page to French users, split ranking signals across duplicate language variants, or ignore the annotations entirely. The tab renders only when internationalization is enabled for the project. On a monolingual site the checks stay off so they cannot false-positive. To turn them on, use Project Settings → Local SEO. ## Coverage [#coverage] A coverage strip summarizes the setup at a glance: the number of **languages** and **regions** declared, whether **x-default** is present, whether the page **self-references**, and the **validation** result — clean, or a count of errors. Any literal hreflang errors are listed explicitly. Three signals decide whether the setup is valid: * **Self-reference** — each page in a language set must include an hreflang tag pointing to itself. A set that omits the self-reference is invalid and Google discards it. * **x-default** — the fallback served when no declared language and region matches the user. Recommended for any multi-region site. * **Reciprocity** — every variant a page points to should point back. A one-directional annotation is ignored, so reciprocity errors are surfaced here. ## Regional language coverage [#regional-language-coverage] When the page targets regional variants, a **regional languages** summary lists the distinct language bases the crawl detected (for example, `en`, `es`, `de`), so you can confirm the intended locales are all represented. ## Hreflang variants [#hreflang-variants] The variants are shown as a table with columns for the language **code**, **region**, **URL**, and a note marking self, x-default, or alternate. For pages with many variants (more than twelve), the list groups into a per-language accordion instead, with x-default pinned to the top, so a large locale set stays readable. <Screenshot src="/screenshots/spider/international-seo.webp" alt="The Internationalization tab showing a coverage strip — 2 languages, 0 regions, x-default present, self-reference present, validation clean — above a Hreflang Variants table listing the en, ta, and x-default codes with their notes" caption="The coverage strip gives the verdict at a glance, and the variant table below lists every declared language and region with its role." width="2854" height="1118" /> <Callout type="info"> Hreflang is reciprocal by design. If page A lists page B as its French variant, page B must list page A in return, and both must self-reference. A single missing back-reference invalidates the pairing, which is why the tab reports reciprocity and self-reference as first-class checks rather than footnotes. </Callout> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/react-seo-optimization-guide", title: "React SEO: the complete guide (includes hreflang)" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/metadata', '/docs/desktop/reports/local-seo', '/docs/desktop/reports/overview']" /> --- # Links tab URL: https://docs.digispot.ai/docs/desktop/reports/links/ The Links tab reports link health, broken and unreachable links, weak anchors, and a filterable table of every link on the page. The Links tab inventories every link on the page and scores its link health. Internal links spread ranking equity and help crawlers discover pages. External links and anchor text shape how both Google and readers understand what a page points to. Broken links waste crawl budget and frustrate users. This tab is where they get caught before they compound across a site. ## Link metrics [#link-metrics] A row of tiles summarizes the page's links: * **Internal** and **External** counts, with nofollow noted * **Broken** links — flagged to fix immediately, since they dead-end users and crawlers * **Unreachable** — links to pages the crawl could not fetch (a timeout or bot wall, distinct from a confirmed 4xx) * **Weak anchors** — empty and generic anchor text such as "click here" or "read more", which carry no topical signal ## Link table [#link-table] The full list is filterable by **All / Internal / External / Other**, with columns for: * **URL** — the destination, marking insecure `http` links * **Anchor** — the visible text, flagging generic or empty anchors * **rel & status** — follow/nofollow and any error code returned On paid tiers, the **Links AI Audit** reviews the link profile and prioritizes what to fix. <Callout type="info"> An unreachable link is not necessarily broken. The crawl could not confirm its status — often a slow response or a bot wall on the target — so verify it in a browser before removing the link. </Callout> <Tip> Rewrite generic anchors before hunting for new links. Descriptive anchor text on the internal links you already have passes a clearer topical signal to the target page, at no extra crawl cost. </Tip> <Screenshot src="/screenshots/spider/spider_links.webp" alt="Spider Links tab with link-health metrics and a filterable link table" caption="Broken and unreachable links are called out before the full table." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/backlink-analysis-a-step-by-step-guide-to-auditing-link-profiles", title: "How to find and analyze backlinks" }, { href: "https://digispot.ai/blog/best-off-page-seo-strategies", title: "Off-page SEO strategies: build authority and links" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/content', '/docs/desktop/reports/media', '/docs/desktop/reports/overview']" /> --- # Local SEO tab URL: https://docs.digispot.ai/docs/desktop/reports/local-seo/ The Local SEO tab checks NAP consistency, LocalBusiness schema, map integration, and location signals — for pages that serve a physical area. The Local SEO tab audits the signals that affect local pack and map visibility, the results Google shows for "near me" and location-qualified searches. For a business that serves a physical area, these signals often matter more than traditional rankings. The tab renders only when local SEO is enabled for the project and the page carries local signals. Otherwise it shows a not-applicable state so it does not false-positive on a non-local page. ## Business identity (NAP) [#business-identity-nap] The identity card reports the **business name**, **address**, **phone**, **email**, and **geo coordinates** (with a Google Maps link), plus a structured breakdown of the address and whether **LocalBusiness schema** is active. NAP stands for Name, Address, Phone. This trio must match exactly across the site, the schema, and external directories for Google to trust the listing. <Screenshot src="/screenshots/spider/local-seo-1.webp" alt="The Local SEO tab's Business Identity (NAP) card showing business name, physical address, phone, email, and geo coordinates, plus a structured address breakdown, with a LocalBusiness schema active badge" caption="The identity card reads the NAP from the page and its schema together, so a mismatch between what a visitor sees and what the markup declares is easy to catch." width="2864" height="1514" /> ## Location signals [#location-signals] A signals card lists the **declared locations** on the page and the **places mentioned** in the content, so you can confirm the page actually names the area it means to rank for. ## Local SEO health [#local-seo-health] A pass/fail checklist covers: * **NAP consistency** — whether name, address, and phone agree across the page * **LocalBusiness schema** — present, and which recommended properties are missing * **Map integration** — an embedded map * **Google reviews** — review signals on the page * **Service area** and **store locator** coverage * **Single- vs multi-location** handling * Whether the location appears in key on-page elements (title, headings, content) The raw schema payload is available under a collapsible technical section. <Screenshot src="/screenshots/spider/local-seo-2.webp" alt="The Local SEO tab's lower half showing declared locations on the page, a Local SEO Health pass/fail checklist (NAP consistency, LocalBusiness schema, map integration, Google reviews, service area all passing, store locator failing), and the raw schema payload" caption="Each local signal is a plain pass or fail, and the raw schema payload sits below for confirming what the markup actually declares." width="2854" height="1740" /> On paid tiers, the **Local SEO AI Audit** reviews these signals and prioritizes fixes. <Callout type="info"> NAP consistency is the foundation. If the address or phone on the page disagrees with the LocalBusiness schema or the business's directory listings, Google discounts the whole set. Resolve any NAP mismatch before adding further local signals. </Callout> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/advanced-local-seo-strategies", title: "Local SEO strategies: dominate your geographic market" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/schema', '/docs/desktop/reports/internationalization', '/docs/desktop/checks-and-scores']" /> --- # Media tab URL: https://docs.digispot.ai/docs/desktop/reports/media/ The Media tab audits images and video — alt text, formats, dimensions, CDN delivery, and VideoObject schema. The Media tab covers both images and video on the page and flags the media that can be optimized for speed and search. Images are usually the single largest slice of page weight and a common cause of layout shift. Missing alt text costs both accessibility and image-search visibility. This tab connects directly to the Performance and Content findings. ## Images [#images] An **optimisation** list surfaces images that could be smaller, judged on format, dimensions, and bytes-per-pixel. An images card reports: * **Total**, **alt OK**, and **no alt** counts, with a three-state alt chip per image — **No alt** (a problem on meaningful images), **Decorative** (an intentional empty `alt`, which is correct), or **Alt** (present) * **Modern vs legacy** format — how many images use next-gen formats (WebP, AVIF) versus older JPEG/PNG * **No dimensions** — images without width and height, a Cumulative Layout Shift risk because the browser cannot reserve space before they load * **Responsive** (`srcset`) and **on CDN**, with the detected CDN provider * A paginated image list with thumbnails, path, format, and dimensions ## Videos [#videos] The videos card reports the **total** videos, **embedded players**, and whether **VideoObject schema** is present, along with detected platforms and poster coverage. It also gives guidance on schema, poster images, and captions. On paid tiers, the **Media AI Audit** reviews the media and prioritizes fixes. <Callout type="info"> A **Decorative** alt state is not a failure. An empty `alt=""` on a purely decorative image is the correct choice, because it tells screen readers to skip it. Only meaningful images flagged **No alt** need attention. </Callout> <Tip> Fixing images that report **no dimensions** and serving next-gen formats usually improves both the CLS and LCP metrics on the Performance tab. Treat this tab and Performance as one workflow. </Tip> <Screenshot src="/screenshots/spider/spider_media.webp" alt="Spider Media tab covering image alt text, formats, and video schema" caption="Images and video are scored together, with per-image alt and format status." width="3420" height="2072" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/image-compression-for-better-seo-speed", title: "Image compression for better SEO and speed" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/links', '/docs/desktop/reports/schema', '/docs/desktop/reports/performance']" /> --- # Metadata tab URL: https://docs.digispot.ai/docs/desktop/reports/metadata/ The Metadata tab audits the title, description, canonical, robots directives, hreflang, and the technical tags behind how a page is indexed. The Metadata tab covers the tags that decide how a page is indexed and displayed. That includes the title and description a searcher sees, plus the technical directives that control whether the page can appear at all. A single wrong tag here can suppress an otherwise strong page. It is usually the first tab to check when a page ranks below its content quality. The tab's score is the page's **indexability score**. Any issues in this category appear in a card above the field grid. ## Redirect chain [#redirect-chain] When the crawled URL redirects, a **redirect chain** card lists every hop in order, numbered top to bottom, with the status code of each and the final `200` destination. It is worth reading because each redirect adds latency. A chain can also leak link equity or, in the worst case, trap crawlers. The card flags three problems explicitly: * **Permanent vs temporary** — a chain built from `301`/`308` hops is marked permanent; a `302`/`307`/`303` hop marks it temporary. A temporary redirect where a permanent one was intended passes less link equity to the destination. * **HTTPS downgrade** — an `HTTPS↓` badge appears when any hop drops from `https://` to `http://`, an insecure and SEO-damaging step. * **Loop** — flagged when the chain returns to a URL it already visited. ## Field grid [#field-grid] Each tag is a row with a status dot and, where relevant, a length chip. Expand a row to see the raw value and a fix hint. Read it top to bottom. The first two rows carry the most weight because they are what a searcher actually sees. ### Title and meta description [#title-and-meta-description] Both are scored on length. The chip shows the **character count** alongside the **SERP pixel width** where available, since pixels are how Google actually decides truncation. Length is treated as an opportunity, not a hard error. Too short under-uses the SERP space and costs click-through. Too long risks truncation. | Tag | Optimal band | Status logic | Why it matters | | -------------------- | ------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Title** | 30–60 characters | Pass 30–63 (5% tolerance), warn outside, fail if missing | The strongest on-page signal and the clickable headline in results. | | **Meta description** | 120–160 characters | Pass 120–168 (5% tolerance), warn outside, fail if missing | Does not rank the page, but a sharp description lifts click-through; a weak one gets rewritten by Google. | ### URL and canonical [#url-and-canonical] * **URL** — shown with its character length; a **URL quality** row appears only when there is something to flag (tracking parameters, session IDs, or a fragment), with the parameter count. * **Canonical URL** — marked **Self** (the healthy default), **Different URL** (correct for a duplicate, a problem if unintentional), **External**, or **Missing**. A wrong canonical is one of the most common causes of a page quietly dropping out of the index. * **Pagination** — a `rel=prev`/`rel=next` row appears only on pages that are part of a paginated set, flagging a broken sequence or a loop. ### Language, robots, and access [#language-robots-and-access] * **Language** — the declared `lang` attribute against the language actually detected in the content, warning on a mismatch (for example, `lang="en"` on Japanese text). * **Character set** — flagged as a warning when missing rather than assumed to be UTF-8. * **Robots** — the meta directive (`index`/`noindex`, `follow`/`nofollow`) plus `noimageindex`, `noarchive`, and `nosnippet` where set. A chip surfaces the **X-Robots-Tag** HTTP header, which can override the meta tag and is invisible in view-source. * **Access** — how the crawler actually read the page (browser vs HTTP fetch, whether it had to escalate past a bot wall), shown only when that provenance exists. ### Hreflang and the rest [#hreflang-and-the-rest] * **Hreflang** — a one-line summary of variant and error counts that links to the Internationalization tab for the full per-variant table. Shows "Not enabled for this project" when internationalization is off. * **Meta keywords** and **Resource hints** (`preconnect`, `dns-prefetch`, `prefetch`, `modulepreload`) appear only when present. * **Built with** — the detected technology stack (frameworks, CMS, analytics, CDN), also available in full on the Technical tab. * **Mobile optimization** — the viewport meta, required for mobile-first indexing. * **Site icon (favicon)** — the detected favicon URL, since the favicon shows next to the result on mobile. <Callout type="info"> An X-Robots-Tag `noindex` set as an HTTP header blocks a page even when its HTML looks fine. It surfaces only in the Robots row's chip, not in view-source, so check it before assuming a page is indexable. </Callout> ## AI actions [#ai-actions] On paid tiers, the **Metadata AI Audit** pill in the header reviews the metadata and returns prioritized findings. At the bottom of the tab, once AI is unlocked, two write-actions — **rewrite title** and **rewrite meta description** — propose replacements you can apply. Both are seeded from the page's top content keywords. <Tip> Work this tab in order of leverage: clear any unintended `noindex` first, then fix the canonical, then the title, then the description. The first three decide whether the page ranks. The description decides whether people click. </Tip> <Screenshot src="/screenshots/spider/spider_metadata.webp" alt="Spider Metadata tab with the title, description, canonical, and robots field grid" caption="Each tag is a status row you can expand for the value and a fix hint." width="3420" height="2072" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/what-is-canonical-url", title: "Canonical URLs for SEO: complete implementation guide" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/headings', '/docs/desktop/reports/technical', '/docs/desktop/reports/internationalization']" /> --- # Overview tab URL: https://docs.digispot.ai/docs/desktop/reports/overview/ The Overview tab summarizes a single page — its SEO score, a Google search preview, category scores, what's working, and the full issue list. The Overview tab is the first thing you see when you open a crawled page. It rolls every other tab into a single verdict: the page's score, how it would look in search, its health by category, what already passes, and the full list of what to fix. It reads top-down. First comes the search preview and a rendering of how the page loads. The page summary follows, then Google's own performance data. Below that are the category scores, what is working, and the issues to act on. ## Google search preview [#google-search-preview] A **Google search preview** renders the page's title, description, favicon, and URL as Google would show them for the crawled device (desktop, mobile, or tablet). Where the page's schema supports them, it adds rich-result affordances: FAQ, breadcrumb, article, rating, and product. Article rich results only preview on editorial pages (an `og:type` of article or a blog-like URL), so a homepage is not wrongly advised to add Article markup. When a page could not be fetched, the preview is skipped rather than showing fabricated "missing title" guidance. ## Visual rendering [#visual-rendering] Beside the search preview, a **visual rendering** thumbnail shows the rendered page for the crawled device, with its Core Web Vitals grades. It puts how the page actually loads next to how it would appear in search. ## Page summary [#page-summary] The summary card leads with three hero tiles bound into one verdict band: * **SEO score** — 0–100 with a verdict of **Good** (≥ 80), **Needs work** (≥ 60), or **Poor** (below 60). A non-page such as a 404 shows its status rather than a misleading "0 · Poor". * **Issues** — the tracked count with Critical, High, Medium, and Low chips. * **Indexability** — the audit state (Indexed, Noindex, Soft-404, Canonicalised, Redirect chain, Near-duplicate, 4xx, 5xx, and more). Below the tiles, a metric grid groups the specifics: **Response** (status, document size, requests, stack), **Content** (title and meta length, words, images missing alt), and **Links & schema** (internal/external links, broken links, schema blocks, freshness). ## Google data [#google-data] When Search Console and GA4 are connected for the project, a **Google performance** card sits below the summary. It adds the page's real clicks, impressions, average position, sessions, and an indexing verdict. This is the one place per-URL Google data surfaces. It is Google's own verdict on the page, distinct from the crawl's audit score. ## Category scores [#category-scores] A **category scores** card lists clickable bars — Indexability, Content, Headings, Media, Links, Schema, Social, Local SEO, and Performance — each jumping to its tab. A category that does not apply to the page (for example, Local SEO on a non-local page) shows a neutral state rather than a red zero. That way it does not drag down the read. ## What's working and page issues [#whats-working-and-page-issues] **What's working** lists the checks the page passed. It is the only place passed checks surface, so the tab is not a wall of red. The **page issues** panel, expanded by default, lists every finding filterable by severity. Each issue states what it is, why it matters, and how to fix it. It also links to every other page in the crawl with the same issue, so a systemic problem can be fixed once at the template level. <Callout type="info"> Issues live only on the Overview tab. There is no separate Issues tab. Each per-category tab shows its own findings in a card, but the complete, filterable list for the page is here. </Callout> <Tip> Start from the severity chips. Clear Critical and High findings first, since those are the ones that block indexing or ranking. Then use the "same issue on N pages" links to batch the fix across the site. </Tip> <Screenshot src="/screenshots/spider/reports_dashboards.webp" alt="Spider project Overview showing the site score, page-level audit scores for desktop, mobile, and tablet, run-over-run changes, and an issues-by-severity breakdown" caption="The Overview rolls the latest run into one verdict, with site and page-level scores and issues broken out by severity." width="3420" height="2074" /> <RelatedDocs hrefs="['/docs/desktop/reports/metadata', '/docs/desktop/checks-and-scores', '/docs/desktop/reports/performance']" /> --- # Performance tab URL: https://docs.digispot.ai/docs/desktop/reports/performance/ The Performance tab reports Core Web Vitals, page weight, and the resources slowing a page down. The Performance tab reports how fast a page loads and what is holding it back. It shows Core Web Vitals plus a full breakdown of page weight and the specific resources that cost load time. Speed is both a ranking signal and a conversion factor. This tab pairs the graded metrics with the named offenders behind them, so the fix is concrete rather than a number to chase. <Callout type="info"> These metrics come from the crawl's own browser render, not real-user data. INP cannot be measured in a crawl because it needs a real user interaction to exist. The tab never claims an INP pass, and for INP it points to field data in Search Console. When a page could not be browser-rendered (for example, blocked by a bot wall), an HTTP-fallback banner explains that Core Web Vitals, page weight, and the screenshot are unavailable. The HTML-level audit is unaffected. </Callout> ## Score and Core Web Vitals [#score-and-core-web-vitals] A **performance score** ring sits beside the Core Web Vitals bars — **LCP**, **INP**, **CLS**, **FCP**, **TTFB**, **TBT**, and **Speed Index**. Each is graded against Google's current thresholds from the measured value. A verdict banner above summarizes the result. It names which of LCP, INP, and CLS actually passed and calls out any it could not measure rather than counting them as passes. Each metric is rated **Good**, **OK** (needs improvement), or **Poor** at these boundaries: | Metric | Good | Needs improvement | Poor | What it measures | | -------- | -------- | ----------------- | --------- | --------------------------------------------------------- | | **LCP** | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s | Time to render the largest element — perceived load speed | | **INP** | ≤ 200 ms | 200–500 ms | > 500 ms | Responsiveness to interaction (field data only) | | **CLS** | ≤ 0.1 | 0.1–0.25 | > 0.25 | Visual stability — how much layout shifts | | **FCP** | ≤ 1.8 s | 1.8–3.0 s | > 3.0 s | Time to first visible content | | **TTFB** | ≤ 800 ms | 800–1800 ms | > 1800 ms | Server response time | | **TBT** | ≤ 200 ms | 200–600 ms | > 600 ms | Main-thread blocking during load (lab proxy for INP) | LCP, INP, and CLS are the three Google ranks on. The rest are diagnostic. Because INP needs a real interaction, it shows in the bars but is sourced from field data, not the crawl. ## Page weight [#page-weight] A **page weight** breakdown shows a stacked proportion bar and per-type rows — **HTML**, **CSS**, **JavaScript**, **Images**, **Fonts**, and **Other**. Each row shows its share and size, plus the total transferred bytes and request count. This is the real page weight, not the HTML document size shown in the page header, so it reflects what actually costs load time. When some responses could not be measured, the total is marked as a lower bound. ## Resource insights and offenders [#resource-insights-and-offenders] **Resource insights** summarize the delivery signals behind the score, each color-coded good, warning, or bad: * **Render-blocking** — the count of blocking scripts and stylesheets (a warning above zero, bad above four) * **CDN** — whether the document and its assets are served from a CDN, with the detected provider and asset coverage percentage * **HTTP version** — flagged when still on HTTP/1.1 * **Cache hit-rate** — a warning below 60% * **Uncompressed text** — the file count and wasted bytes when compression is missing **Resource offenders** name the specific files to fix: the **heaviest resources**, **oversized images**, and **slowest requests**. Each is a short list of URLs with their size or timing. On paid tiers, the **Performance AI Audit** turns the score, weight, and offenders into a prioritized list of the highest-impact fixes. <Tip> Chase the offenders before the score. A single oversized hero image or a render-blocking script usually explains a poor LCP. Fixing it moves the metric far more than incremental tuning. </Tip> <Screenshot src="/screenshots/spider/spider_preformance.webp" alt="Spider Performance tab with Core Web Vitals, page weight, and resource offenders" caption="Page weight and the heaviest resources sit next to the Core Web Vitals." width="3420" height="2070" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/core-web-vitals-seo-guide", title: "Core Web Vitals SEO: improve LCP, CLS, and INP" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/media', '/docs/desktop/reports/technical', '/docs/desktop/checks-and-scores']" /> --- # Schema tab URL: https://docs.digispot.ai/docs/desktop/reports/schema/ The Schema tab detects structured data, validates it, checks rich-result eligibility, and visualizes the entity graph. The Schema tab finds the structured data on a page, validates it against Google's requirements, and shows how the entities connect. Structured data is what earns rich results such as star ratings, FAQ drop-downs, breadcrumbs, and product pricing. It is also increasingly how AI answer engines identify and quote a page's facts. A block that is present but invalid earns nothing. Validation matters as much as coverage. Header chips show which key types (Article, Product, Breadcrumb, Organization) are present or missing. The tab has three inner views. ## Overview [#overview] A type-distribution donut shows the mix of schema types on the page, alongside a **rich-result eligibility** list. Each type is marked **Eligible** or **Ineligible**. An ineligible type lists the specific blockers holding it back, usually a required property that is missing or malformed. This is the fastest path from "I have schema" to "my schema actually qualifies for a rich result". ## Entities [#entities] A per-entity grid marks each block **Valid**, **Has issues**, or **Warning**, and expands to the full properties table or the raw JSON-LD. Use it to find the one malformed entity behind an ineligible type. ## Graph [#graph] An entity graph draws the nodes and the relationships between them (for example, an Organization linked to its Product and its reviews), expandable to full screen. A well-connected graph helps search engines resolve a page into a coherent set of entities rather than isolated blocks. <Screenshot src="/screenshots/spider/schema_graph.webp" alt="The Schema tab's Graph view showing the entity graph — 45 entities and 39 relationships as connected nodes for types like MedicalOrganization, PostalAddress, GeoCoordinates, VideoObject, and FAQPage, with nodes carrying issues marked in red" caption="The graph draws every entity and how it links to the others, so an isolated or orphaned block stands out from the connected set." width="3420" height="2076" /> **Copy all JSON** exports the page's structured data in one click. On paid tiers, the **Schema AI Audit** and an AI action to **validate & fix schema** turn the findings into corrected markup. <Callout type="info"> Eligibility is not a guarantee of a rich result, since Google decides per query. But ineligibility is a guarantee of none. Clearing the listed blockers is the prerequisite, so treat the Ineligible list as the work queue. </Callout> <Screenshot src="/screenshots/spider/spider_schema.webp" alt="Spider Schema tab with entity list, validation, and rich-result eligibility" caption="Rich-result eligibility shows which types are blocked and why." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/advanced-schema-markup-seo-guide", title: "Advanced schema markup for SEO: unlock rich snippets" }, { href: "https://digispot.ai/blog/how-to-validate-and-test-schema-markup", title: "How to validate and test schema markup" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/media', '/docs/desktop/reports/social', '/docs/desktop/reports/local-seo']" /> --- # Site health URL: https://docs.digispot.ai/docs/desktop/reports/site/ The Site health view covers the site-wide checks that run once per crawl — robots.txt, sitemaps, SSL, and llms.txt — and feed the Site Architecture score. Site health covers the checks that apply to the whole site rather than a single page. These are the foundations that decide how every URL is discovered, trusted, and served. A problem here rarely shows on one page in isolation. A blocking `robots.txt` rule or an expired certificate suppresses the entire crawl at once, which is why these checks run once per crawl and are scored on their own. <Callout type="info"> Open Site health from the project **Overview**, via **View site checks** on the Site-level card. These checks are shared across every device in a crawl and roll up into the **Site Architecture** score, separate from the per-page scores. See [Checks & scores](/docs/desktop/checks-and-scores/). </Callout> ## Site Architecture score [#site-architecture-score] A single **Site Architecture** score summarizes the site-wide foundations. It is a composite of the four checks below, so a weak `llms.txt` or a robots.txt block pulls it down without touching any individual page's score. The view opens on this score, then breaks into a tab per foundation. ## Robots.txt [#robotstxt] The **Robots.txt** tab opens with quick answers: whether the file exists, whether **Googlebot** and **AI crawlers** are allowed, whether a **sitemap** is referenced, and the rule count broken into agent groups, disallow, and allow directives. A **crawl blocking impact** panel reports how many of the URLs this audit crawled the file actually blocks. A **per-device fetch** panel shows what each device's user agent retrieved. This is where an accidental site-wide block shows up, such as a `Disallow: /` left over from staging that keeps the whole site out of the index. <Screenshot src="/screenshots/spider/spider_robots.webp" alt="The Site health Robots.txt tab with quick-answer cards for file existence, Googlebot access, AI-crawler access, sitemap reference, and rule count, above a crawl-blocking-impact panel showing 0% of crawled URLs blocked and a per-device fetch panel" caption="Quick answers confirm the file exists and what it allows; the crawl-blocking-impact panel reports how many crawled URLs the file blocked." width="3420" height="2072" /> ## Sitemap [#sitemap] The **Sitemap** tab covers the XML sitemaps the site publishes. Quick answers report whether a sitemap exists, its **total URLs**, whether robots.txt references it, and its **freshness**. A **crawl coverage** panel compares the sitemap against the crawl: URLs in both, **orphans** (crawled but not listed), and URLs listed but not reached. Per-sitemap metrics follow — URL count, video URLs, compression, average priority, and size — along with a **URL composition** breakdown by top directory and declared change frequency. A sitemap that lists URLs no page links to, or that omits pages that matter, is a discovery problem the tab makes visible before it costs indexing. <Screenshot src="/screenshots/spider/spider_sitemap_1.webp" alt="The Site health Sitemap tab with quick-answer cards for existence, total URLs, robots reference, and freshness, above an audit issue flagging URLs found by crawling that are missing from sitemap.xml" caption="The top of the tab: existence, total URLs, robots reference, and freshness, with any audit issue below — here, pages reached by crawling that the sitemap omits." width="3420" height="1758" /> <Screenshot src="/screenshots/spider/spider_sitemap_2.webp" alt="The Sitemap tab's lower panels: crawl coverage counts for in-sitemap-and-crawled, orphans, and in-sitemap-only URLs, the discovered sitemap's metrics, and a URL composition breakdown by directory and change frequency" caption="Crawl coverage separates listed-and-crawled URLs from orphans and uncrawled ones, then breaks the sitemap down by directory and change frequency." width="3420" height="2074" /> ## SSL [#ssl] The **SSL** tab covers the site's transport security. It leads with an **SSL security score** out of 100, then quick answers: whether the site uses **HTTPS**, **days until expiry**, the **TLS version**, and whether **HSTS** is set. The full **certificate** follows — issuer, subject, validity window, chain length and validity, key size, and cipher. These are read once for the site rather than per page. <Screenshot src="/screenshots/spider/spider_security.webp" alt="The Site health SSL tab showing an SSL security score of 80/100, quick-answer cards for HTTPS, days until expiry, TLS version, and an unset HSTS header, above the certificate details — issuer, subject, validity dates, chain length, key size, and cipher" caption="The SSL security score sits above the quick answers and the full certificate; here HTTPS and TLS 1.3 pass, while HSTS is flagged as not set." width="3420" height="2070" /> ## LLMs.txt [#llmstxt] The **LLMs.txt** tab checks the emerging files that guide AI crawlers to the content worth citing: **llms.txt**, its **llms-full.txt** full-content variant, and **ai.txt** crawler directives. Quick answers report which are present and a **completeness** score out of 100, measured against the expected spec shape — an H1 title, a summary blockquote, then link sections. A **spec structure** panel breaks that score down check by check (title, summary, link sections, well-formed links), and **findings** name the specific fix, such as adding a one-line summary blockquote under the title. As ChatGPT, Perplexity, and Gemini send real traffic and citations, a missing or malformed `llms.txt` is a growing gap. <Screenshot src="/screenshots/spider/spider_llms_1.webp" alt="The Site health LLMs.txt tab with quick-answer cards for llms.txt, llms-full.txt, and ai.txt presence and a completeness score, above a spec-structure panel checking the title, summary, link sections, and well-formed links" caption="Quick answers cover llms.txt, llms-full.txt, and ai.txt; the completeness score is graded against the spec shape shown in the structure panel below." width="3420" height="1798" /> <Screenshot src="/screenshots/spider/spider_llms_2.webp" alt="The LLMs.txt tab's file metrics for the served llms.txt — URL, size, lines, link sections, completeness, and llms-full.txt variant — with a findings note to add a one-line summary blockquote under the title" caption="File metrics for the served file, with findings that name the exact fix — here, a missing summary blockquote under the title." width="3228" height="1146" /> <Callout type="info"> Security findings gate more than the padlock icon. An expired certificate or a downgrade off HTTPS undermines trust across every page the audit scored. Treat it as a site-wide blocker, not a cosmetic warning. </Callout> <RelatedDocs hrefs="['/docs/desktop/reports/technical', '/docs/desktop/checks-and-scores', '/docs/desktop/crawler']" /> --- # Social tab URL: https://docs.digispot.ai/docs/desktop/reports/social/ The Social tab validates Open Graph, Twitter/X, and LinkedIn tags and previews how the page looks when shared. The Social tab checks the tags that control how a page looks when shared and previews the share cards before anyone posts. These tags do not affect rankings. But a missing or broken image, title, or description turns a shared link into a bare URL. That directly costs the click-through and referral traffic a social post is meant to earn. ## Status and preview [#status-and-preview] Status dots show whether **Open Graph**, **Twitter card**, and **LinkedIn** are ready. A preview renders the Facebook, Twitter, and LinkedIn share-card mockups from the page's actual tags, so a wrong image or a truncated title is visible before it ships, not after. ## Tag fields [#tag-fields] Two field grids list every tag and flag what is missing: * **Open Graph** — title, description, image (with dimensions and alt), type, locale, site name, and URL * **Twitter / X** — card type, title, description, image and alt, site, and creator A **favicons & app icons** panel checks the favicon, Apple touch icon, and PWA icons. On paid tiers, the **Social AI Audit** reviews the tags and prioritizes fixes. <Callout type="info"> Most platforms fall back to Open Graph tags when their own are absent, so a complete Open Graph set is the priority. The Twitter and LinkedIn cards inherit from it. Fill Open Graph first, then add Twitter-specific tags only where you want a different card. </Callout> <Tip> The image is what a share stands or falls on. Confirm `og:image` is present, at a landscape ratio, and large enough (Facebook and LinkedIn expect roughly 1200×630) using the live preview before treating the tab as clean. </Tip> <Screenshot src="/screenshots/spider/spider_social.webp" alt="Spider Social tab with Open Graph and Twitter validation and share previews" caption="The share previews render from the page's actual tags." width="3420" height="2072" /> <RelatedDocs hrefs="['/docs/desktop/reports/schema', '/docs/desktop/reports/metadata', '/docs/desktop/reports/media']" /> --- # Technical tab URL: https://docs.digispot.ai/docs/desktop/reports/technical/ The Technical tab checks HTTPS, robots, canonical, security headers, cloaking, and the detected technology stack. The Technical tab covers the server- and markup-level signals that affect how a page is crawled, secured, and trusted. These checks decide whether a page can be reached and rendered at all, and whether what a bot sees matches what a browser sees. A content-level audit cannot surface these problems. ## Technical signals [#technical-signals] A field grid reports each signal with a status: * **HTTPS**, **Robots — index**, **Robots — follow**, and **Canonical URL** — the core crawl and index directives * **Hreflang**, **Mobile viewport**, and **Character encoding** * **HSTS** — whether a `Strict-Transport-Security` header is present * **Security headers** — how many of the recommended headers are set, and which are missing * **AI crawler visibility** — a cloaking and render-parity check (see below) ### AI crawler visibility [#ai-crawler-visibility] This check compares what the page serves to a bot over a raw HTTP fetch against what it renders in a browser. It reports a **divergence score** from 0 to 100 where **0 is healthy** (the two match). A high score means significant content appears only after JavaScript runs. That content may never be seen by LLM crawlers such as GPTBot, Claude, and PerplexityBot, or by Googlebot's first render wave. An expandable **static-vs-browser evidence table** breaks the gap down by SEO-weighted signal: words, headings, schema, links, and images. <Callout type="info"> A large static-vs-browser gap is usually a render problem, not deliberate cloaking. It is key content that only exists after JS execution. Either way the effect is the same: crawlers that read raw HTML miss it. Serving that content in the initial HTML (SSR or pre-rendering) is the fix. </Callout> ## Technology stack [#technology-stack] A **technology stack** card lists the detected frameworks, CMS, plugins, analytics, CDN, and libraries, grouped by category with a confidence score. It is the same detection surfaced as "Built with" on the Metadata tab. Here it is shown in full. On paid tiers, the **Technical AI Audit** reviews these signals and prioritizes fixes. <Screenshot src="/screenshots/spider/spider_technical.webp" alt="Spider Technical tab with HTTPS, security headers, cloaking check, and tech stack" caption="The AI-crawler visibility check compares what a bot and a browser each see." width="3420" height="2074" /> <FromTheBlog posts="[ { href: "https://digispot.ai/blog/technical-seo-checklist-for-2025", title: "The ultimate technical SEO checklist" }, { href: "https://digispot.ai/blog/javascript-seo", title: "JavaScript SEO: complete guide for modern web apps" }, ]" /> <RelatedDocs hrefs="['/docs/desktop/reports/metadata', '/docs/desktop/reports/performance', '/docs/desktop/crawler']" /> --- # The Visualizer URL: https://docs.digispot.ai/docs/desktop/reports/visualizer/ The Visualizer maps a crawled site as an interactive graph — color-coded by depth, status, or issues, grouped into clusters, with per-node drill-in and CSV export. The Visualizer maps your site as an interactive, force-directed graph. Every URL the crawl discovered is a node, and internal links are the edges between them. It surfaces structure a table can't: how deep pages sit from the homepage, which act as hubs, and which are orphaned. <Callout type="info"> Open the Visualizer from a crawl — the **Sitemap** tab's Site Structure panel has a **Visualize** action, and it opens as its own view for the run. It can be shared as a link. See [Site health](/docs/desktop/reports/site/). </Callout> ## Color by [#color-by] **Color by** re-shades the graph to answer a specific question: * **Depth** — each ring out from the homepage gets its own hue * **HTTP status** — surface non-200 pages inside the structure * **Top issues** — highlight the sections carrying the most findings * **Inbound / outbound links** — separate hubs (many inbound links) from orphans (zero internal links) The same page looks different under each mode. Reading depth finds pages buried too far from the homepage; reading inbound links finds the orphans no internal link points to. ## Group by clusters [#group-by-clusters] **Group by** collapses the graph into named **territory clusters** by section, so a large site reads as a handful of areas rather than thousands of dots. Each cluster is clickable. * **Drill in** to expand a cluster and see the pages inside it * **Export CSV** to download a cluster's URLs with their `url`, `depth`, `section`, and `sitemap` columns Clustering is what keeps the graph legible on a site with thousands of pages, where an ungrouped node cloud would be unreadable. ## Filters and labels [#filters-and-labels] Narrow the map to focus on one part of the structure: * **Depth** — show a single depth ring, or all depths at once * **Sitemap file** — filter to the URLs in one sitemap * **Label density** — set how many page names print on the map, since every node is hoverable regardless of whether its label shows ## Inspecting a node [#inspecting-a-node] **Double-click a node** to drill in and inspect a single page: * Its **inbound** and **outbound** internal links * For a weakly linked page, suggestions for **where to add a link** to pull it out of the shallows <Tip> Color by inbound links, then look for nodes with no edges into them — those are the orphans. A page with zero internal links is one the crawler only found through the sitemap, and one Google may struggle to discover or rank. </Tip> <Screenshot src="/screenshots/spider/spider-visualizer.webp" alt="Spider Visualizer showing the site as an interactive graph of linked pages, color-coded and clustered by section" caption="The Visualizer maps the crawl as an interactive graph — recolor, cluster, and drill into any node." width="3420" height="2074" /> <RelatedDocs hrefs="['/docs/desktop/reports/site', '/docs/desktop/reports/links', '/docs/desktop/reports']" /> --- # Create URL: https://docs.digispot.ai/docs/cloud/content-studio/create/ The Create screen generates a new AI-written article, grounded in your project data. The Create screen is where a new article begins. A brief goes in and a full draft comes out, grounded in the active project's own context rather than written blind. The header shows how many articles the current AI-credit balance can still afford, so the cost of a generation is visible before it runs. <Callout type="info"> Content Studio is gated on the **Free** plan. It requires **Starter** or above. Each generation is an affordability check against the **AI credit** pool. If the balance can't cover an article, Create shows an upgrade or top-up prompt instead of the form. The Library stays viewable even when credits are exhausted. </Callout> ## The brief [#the-brief] The form collects the inputs the model uses to shape the draft. Most have sensible defaults, so a topic alone is enough to start. | Field | What it controls | | ------------------------------------- | -------------------------------------------------------------------------- | | **Topic** | The subject of the article — the one required field. | | **Keywords** | Terms to target, comma-separated, woven into the draft. | | **Page type** | Blog, service, home, category, or landing — sets the structure and intent. | | **Tone** | Informative, conversational, professional, persuasive, or entertaining. | | **Target audience** | General, beginners, intermediate, experts, or business. | | **Word count** | A slider from 300 to 2,500 words. | | **Include FAQ** | Appends an FAQ section, on by default. | | **Meta description** and **CTA text** | Optional snippet and call-to-action copy. | | **Competitor URLs** | Reference pages the model reads to match or beat. | ## Grounding and model tier [#grounding-and-model-tier] Two controls decide how the draft is produced. * **Personalization** — **fully branded** ties the piece to the project's real products, audience, and audit context. **Semi-generic** keeps it looser and more broadly reusable. * **Model tier** — **Basic** for standard drafts. **Advanced** for higher-quality output at a higher credit cost. ## From draft to editor [#from-draft-to-editor] Generation runs through visible phases and can be stopped mid-run. When it finishes, the article moves into the [editor](/docs/cloud/content-studio/edit/) for section-level refinement, internal linking, and review. Longer or advanced-tier pieces first run through a plan-approval step — see [Plans](/docs/cloud/content-studio/plans/). <Tip> Starting from a gap in [Content opportunities](/docs/cloud/content-opportunities/) pre-fills the topic, keywords, audience, and suggested length from that gap's analysis. The result is a faster, better-targeted brief than writing one from scratch. </Tip> <RelatedDocs hrefs="['/docs/cloud/content-studio/edit', '/docs/cloud/content-studio/plans', '/docs/cloud/content-opportunities']" /> --- # Edit URL: https://docs.digispot.ai/docs/cloud/content-studio/edit/ The Edit screen refines a draft — section by section — with internal-link suggestions and research insights. The Edit screen is where a draft becomes publish-ready. The article opens as individually addressable sections rather than one block, so structure, wording, and internal links can be worked on part by part. The header keeps a running **section count** and **total word count** as the piece changes. ## Section manager [#section-manager] The article is broken into ordered sections, each with its own title, type, and word count, and each editable on its own. * **Rewrite** a single section without touching the rest * **Reorder** sections by drag; the change saves and the numbering renumbers 1..n * **Add** a new section, which lands at the end with the next index * **Delete** a section, after which the remaining ones renumber automatically Working at the section level keeps a targeted regeneration cheap and contained, rather than re-running the whole article for one weak paragraph. ## Internal links and research [#internal-links-and-research] Two aids sit alongside the draft. * **Internal link suggestions** — relevant pages on the same site to link to. The new piece connects into the existing structure instead of orphaning. * **Research insights** — supporting data surfaced against the topic. It strengthens claims as sections are edited. ## Review before publish [#review-before-publish] Longer and advanced-tier articles pass through a **plan-approval** step before the full draft is generated, so a reviewer can sign off on the outline first. The states an article moves through, and how to act on each, are covered in [Plans](/docs/cloud/content-studio/plans/). <Tip> Save section reorders before regenerating. Order is persisted server-side, and a regeneration reads the saved order. Reordering after a regenerate without saving first can leave the two out of sync. </Tip> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/plans', '/docs/cloud/content-studio/library']" /> --- # Content Studio URL: https://docs.digispot.ai/docs/cloud/content-studio/ Content Studio is the AI content suite — create and edit articles, generate infographics, and manage everything through plans and a library. Content Studio is the platform's AI content suite. It produces publish-ready articles and infographics, grounded in your audit and project data. <Callout type="info"> Content Studio is not available on the free plan, and its actions spend AI credits. See [Plans & billing](/docs/cloud/billing/). </Callout> <Screenshot src="/screenshots/cloud/content_studio.webp" alt="Cloud Content Studio for creating and editing AI-written articles" caption="Content Studio — create and edit AI-written articles." width="3420" height="1890" /> ## The workflow [#the-workflow] <SectionCards hrefs="[ '/docs/cloud/content-studio/create', '/docs/cloud/content-studio/edit', '/docs/cloud/content-studio/infographics', '/docs/cloud/content-studio/library', '/docs/cloud/content-studio/plans', ]" /> ## Ask Digispot [#ask-digispot] **Ask Digispot** — the AI SEO Analyst — is the assistant that answers questions grounded in your actual audit data. It is reachable from anywhere in the platform. Ask it what to fix first, which pages are losing traffic, or what changed since the last run. It responds from your project's data rather than generic advice. Conversations are saved. Each message spends an AI credit. <RelatedDocs hrefs="['/docs/cloud/content-opportunities', '/docs/cloud/research', '/docs/cloud/billing']" /> --- # Infographics URL: https://docs.digispot.ai/docs/cloud/content-studio/infographics/ The Infographics studio generates branded infographics with control over palette, icons, typography, and dimensions. The Infographics studio turns an existing article into a branded visual. Pick a source article, then control palette, type, icons, and dimensions so the output matches the site it will sit on. <Callout type="info"> Like the rest of Content Studio, infographics require an active paid plan and aren't available on **Free**. An infographic is built from a saved article, so generate the article first, then select it here. </Callout> ## Source article [#source-article] Generation starts from an **article selector** listing the project's saved pieces. The chosen article's content is parsed into the infographic's structure, so the visual reflects the article rather than a blank template. ## Palette, type, and icons [#palette-type-and-icons] Three controls set the look, each with curated presets. * **Color palette** — named presets such as *Executive Navy*, *Minimal Scandinavian*, and *High Contrast Pro*. They are grouped from corporate to creative, to keep the graphic on-brand. * **Typography** — curated font families organized into categories (sans-serif, serif, display), each with a readability note * **Icons** — an icon selector for the visual accents on each data point ## Dimensions [#dimensions] The output aspect ratio is chosen from presets, each mapping to a fixed pixel size: | Preset | Aspect ratio | Size | | ------------------------------ | ------------ | ----------- | | **Blog Infographic** (default) | 4:3 | 1200 × 900 | | **Long-form** | 2:5 | 1000 × 2500 | | **Square** | 1:1 | 900 × 900 | | **Blog Cover / Hero** | 16:9 | 1600 × 900 | <Tip> Match the dimension to where the graphic will live: **Long-form** for an in-body explainer readers scroll, **Square** for social, and **Blog Cover / Hero** for the header image. The 4:3 default suits a standard mid-article infographic. </Tip> <Screenshot src="/screenshots/cloud/cloud_infographics.webp" alt="Cloud Content Studio infographic generation with palette, icons, and typography controls" caption="Generate infographics with control over palette, icons, and typography." width="3420" height="1894" /> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/library', '/docs/cloud/content-studio']" /> --- # Library URL: https://docs.digispot.ai/docs/cloud/content-studio/library/ The Library holds every piece of AI-generated content, so you can find, revisit, and manage what you've produced. The Library is where every article generated for a project lives, so nothing produced is lost between sessions. It's scoped to the **active project** — switch projects and the list swaps to that project's content. ## Browsing the library [#browsing-the-library] Each entry lists the article with its **type** (blog, service, and the rest), when it was created and by whom, and how many **infographics** are attached to it. A **search** box filters the list by keyword, and results page in batches. ## Acting on an article [#acting-on-an-article] From a library entry the article can be: * **Opened** in the [editor](/docs/cloud/content-studio/edit/) to continue refining sections * **Used as a source** in the [Infographics](/docs/cloud/content-studio/infographics/) studio to build a visual from it * Reviewed for its meta description, research insights, and attached infographics <Callout type="info"> The Library stays viewable even when the **AI credit** balance is exhausted. Running out of credits stops new generation, not access to what's already produced. It does require an active paid plan. Content Studio is unavailable on **Free**. </Callout> <Screenshot src="/screenshots/cloud/content_library.webp" alt="Cloud Content Studio Library listing generated articles" caption="Every generated article, scoped to the active project." width="3414" height="1762" /> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/plans', '/docs/cloud/content-studio']" /> --- # Plans URL: https://docs.digispot.ai/docs/cloud/content-studio/plans/ Content plans organize article work through a review workflow — from draft to approved to completed. A content plan is the outline an article is approved against before the full draft is written. Rather than generating a long piece blind, the studio produces a plan, holds it for review, and only writes the article once the plan is signed off. A team drafts, approves, and completes content in a controlled flow instead of a loose pile of drafts. The Plans screen lists every saved plan for the active project and lets you resume one that's still in progress. ## Statuses [#statuses] Each plan carries a status that drives what you can do with it. | Status | Meaning | Next action | | -------------------- | ----------------------------------------------------- | ---------------------------------------- | | **Draft** | The plan exists but hasn't been submitted for review. | Continue building it. | | **Pending approval** | Submitted and awaiting sign-off. | Continue — review and approve or reject. | | **Approved** | Signed off; ready to generate the article. | Continue to generation. | | **Rejected** | Turned down in review. | Revise or discard. | | **Completed** | The article has been generated from the plan. | Open the article in the Library. | | **Expired** | Aged out before completion. | Start a new plan. | Plans in **pending approval** or **approved** show a **Continue** action to pick up generation where it left off. A **completed** plan links through to its generated article. <Callout type="info"> Plans belong to Content Studio and require an active paid plan. Approving and completing a plan spends **AI credits** on the article it generates. The plan and review steps organize the work, but the draft itself is the credited action. </Callout> <Screenshot src="/screenshots/cloud/content_plans.webp" alt="Cloud Content Studio Plans with plan statuses" caption="Content plans and their approval statuses." width="3420" height="1640" /> <RelatedDocs hrefs="['/docs/cloud/content-studio/create', '/docs/cloud/content-studio/edit', '/docs/cloud/content-studio/library']" />