Operate every StrictSEO tool with confidence.

Choose the right StrictSEO tool

The tools overlap deliberately. Metadata, headings, links, images, JSON-LD, answer structure, trust signals, social fields, and observable implementation checks should use the same language no matter which interface you open. The difference is how the page is captured and what additional evidence the interface can collect.

Start with the extension when the user journey matters and you want feedback as you navigate. Move to the full analyzer when one page needs careful inspection, inventory work, or a formal export. Move to StrictSEO Browser when the question cannot be answered by a rendered snapshot alone. The local crawler can observe HTTP responses, redirects, robots rules, sitemaps, depth, inlinks, and broken internal destinations. Local projects preserve compact crawl baselines and action notes. Search Console supplies first-party traffic evidence. Lighthouse and axe-core add attributed third-party evidence.

Understand the evidence model before interpreting findings

StrictSEO reports Fix, Review, and Passed instead of a composite score. Fix means the current deterministic rule found observable evidence that normally requires correction. Review means page purpose, human judgment, or an external source is needed. Passed means the snapshot satisfied that one rule. It does not certify the page, promise indexing, or forecast traffic.

Priority is a suggested order, not an impact prediction. A high-priority canonical or indexing conflict usually deserves attention before a low-priority refinement. Scale and page importance still matter. A medium defect produced by a shared template across hundreds of pages may be more important than one high-priority finding on an unpublished draft. Add business and search evidence explicitly rather than pretending the page HTML contains it.

Every useful finding should be read as a six-part statement: the stable check identity, status, priority, observed evidence, affected location, and next action. The issue-library link explains the reasoning and verification method. Reading only the title strips away the evidence that distinguishes a confirmed problem from a contextual prompt.

Ten-minute first run after you receive the build

The access-request and private reply happen before this procedure and have no promised turnaround time. Once you have verified and extracted the supplied release, your first goal is not to remove every warning. Complete one page review that produces one reproducible action and one saved report. This teaches the operating model without turning the tool into a score-chasing exercise.

Chrome extension operating manual

Install the unpacked beta

Open the free private software access form and provide the required site, product, environment, and intended-use details. Once the request is complete, save the supplied versioned package and matching SHA-256 checksum from the email reply. Confirm the full digest and test the package before extracting it. Chrome cannot load the package file itself. The extracted extension folder directly contains manifest.json, background and side-panel files, the shared analyzer, onboarding, options, security notes, and icons.

Open chrome://extensions in the address bar, turn on Developer mode, select Load unpacked, and choose the extracted extension root. Chrome should list StrictSEO Page Analyzer version 0.8.0 and open onboarding. Move the extracted folder to a stable location before loading it; Chrome references that folder during reload. If Chrome says the manifest is missing, you selected the wrong folder level or an incomplete extraction.

Open the puzzle-piece Extensions menu and pin StrictSEO. The temporary NEW badge reminds you that the extension is installed but no live review has started. Do not enable incognito access. The manifest intentionally disables incognito operation for this beta.

Choose the report target

Production mode opens detailed reports on https://strictseo.com and is correct for normal use. Local mode opens only http://localhost:3114 and exists for contributors testing website changes. It requires the StrictSEO development site to be running on that port. Open Extension options from the extension Details page to switch. Arbitrary report hosts are not accepted.

The target choice does not change which page the extension can read. It controls only the approved destination used when you request a detailed analyzer handoff. The extension holds one undelivered snapshot behind a one-time token, rejects it after two minutes, and deletes it after the trusted analyzer receives it.

Start, continue, and stop live review

Open a normal web page and click StrictSEO. That user gesture grants temporary active-tab access for the selected tab. The side panel captures the rendered page and shows live suggestions. Continue navigating on the same origin and the panel refreshes after page loads. The extension can retain up to fifty unique URL reports during the Chrome session, replacing the report for a URL when it is reviewed again.

Crossing to another origin pauses review. This is intentional: the extension does not request permanent all-sites access. Click StrictSEO again on the new site only if you want to inspect it. Stopping review, closing the reviewed tab, losing same-origin permission, or ending the browser session clears the current live snapshot and badge. Older session pages can remain selectable, but they are historical evidence and should not be presented as the live page.

Read and filter the side panel

The current page header identifies the report. Counts summarize Fix, Review, and Passed checks without creating a grade. The triage sentence names high-priority work. Filters narrow by status, priority, category, and search text. Search covers finding titles, evidence, recommendations, selectors, and location context. Filters affect the view, not the underlying report, so reset them before deciding that a finding is absent.

Page evidence includes descriptive counts such as visible words, headings, links, images, schemas, DOM nodes, resource counts, transfer size, and locally exposed timings. These values describe that browser load. They are not search volume, keyword-density targets, backlink data, rankings, or field Core Web Vitals.

Locate the exact cause

Expand Where this was found on a finding tied to rendered elements. StrictSEO can show the evidence scope, total affected count, a bounded sample, structural selector, visible text, inventory position, measurement context, and sanitized DOM excerpt. A bounded sample keeps the report usable; the total may be larger than the examples shown.

Choose Show on page only when the matching URL is currently live. StrictSEO scrolls to the captured selector and outlines the element briefly. If the DOM changed after capture, reload or rescan instead of assuming the issue was fixed. Relationship checks can show both elements involved. A heading-level jump, for example, needs the previous heading and the affected heading so the developer can repair semantic structure rather than guessing which H3 or H4 caused the message.

Build a representative site session

Browse intentionally: homepage, hub or category, editorial page, product or service page, conversion page, and a known edge-case template. Site patterns compares only these reviewed pages. It can identify recurring findings, duplicate titles, descriptions, and H1s, canonical collisions, indexability and language coverage, and pages without an incoming link captured in the session.

Session evidence is not a complete crawl. A page described as lacking a captured incoming link may have links from pages you never visited. Use the local crawler before calling it orphaned. The value of the session is speed: it can reveal that one issue repeats across a representative user journey while you browse normally.

Rescan, select history, and export

Use Rescan after a CMS preview changes, a client-side transition updates the DOM without a normal load, or a developer applies a local fix. Wait for the intended page state. The saved-page selector lets you inspect historical reports, but highlighting requires the matching current page. Clear removes the temporary session, so export first.

JSON preserves nested evidence and is best for archives or automation. CSV flattens findings for spreadsheets and assignment. Markdown creates the most readable implementation brief. Every export keeps public fix-guide URLs so the recipient can understand the repair and verification. Treat exports as page-content derivatives because they may contain bounded visible snippets and DOM evidence.

On-Page SEO & AEO Analyzer operating manual

Choose extension, pasted HTML, or file input

Use the extension handoff when the rendered browser state matters. JavaScript output, consent state, CMS preview content, and the visible DOM can differ from server HTML. Use pasted HTML for a controlled template or source review. Use file upload for a saved document supplied by a developer. Pasted and uploaded scripts are parsed as inert markup and are not executed.

Enter the intended source URL when analyzing HTML. It supplies origin, protocol, canonical, internal-link, and relative-path context; StrictSEO does not fetch the URL. Remove credentials and sensitive parameters. If no source URL is supplied, some URL-dependent checks must remain unavailable or contextual rather than being fabricated.

Prepare a comparable page state

Write one sentence describing the page’s job before running the report. Record URL, locale, viewport, consent state, authentication state, experiment, and input method when those conditions affect content. Wait for rendered content to settle before extension handoff. A before report taken after consent on desktop is not directly comparable with an after report taken before consent on mobile if the DOM differs.

After analysis, confirm page identity and evidence counts. Unexpected zeros often mean the HTML is only a JavaScript shell, the wrong file was chosen, or capture happened before content rendered. Correct the input and rerun instead of logging production defects from an incomplete snapshot.

Use the report regions in order

Start here identifies the most urgent confirmed issues. The findings list provides observed evidence, next action, exact location, and educational link. The indexability summary gathers captured canonical and directive clues. Search and social previews package supplied metadata for editorial diagnosis; they do not reproduce or predict live external results. The heading outline reveals hierarchy. Page evidence provides descriptive counts and local implementation observations.

The link explorer searches anchors and destinations and filters internal, external, nofollow, and anchor-quality evidence. Image evidence shows captured sources, alternatives, dimensions, loading behavior, and potential delivery concerns. The structured-data inspector displays JSON-LD as escaped text, reports parse errors, and recursively identifies types in @graph. Parsing is not proof of truthful markup or rich-result eligibility; compare every important property with visible content.

Interpret content and AEO checks responsibly

StrictSEO treats AEO as part of useful search and content design. It reviews question-and-answer pairing only when the page presents visible question headings. A concise answer can improve scanning and extraction, but not every page should become an FAQ. Product, tool, gallery, and transactional pages may satisfy intent through controls, examples, or comparisons.

Definitions, authorship, dates, sources, examples, tables, and reader aids can strengthen clarity and trust when relevant. Their absence is not automatically a defect on every page. The analyzer can observe whether these signals exist; it cannot verify expertise, factual accuracy, or whether a citation supports a claim. Prominent terms, repeated phrases, paragraph length, and title/H1 coverage are descriptive clues—not keyword-density targets.

Build an action plan and export it

Select current findings for the temporary action plan. Group by root cause. Three social fields missing from one template usually form one task. Repeated image dimensions can belong to one component. Keep editorial intent decisions separate from deterministic implementation work. Every ticket should include URL or template scope, check ID, observed evidence, selector or excerpt, intended behavior, owner, and verification.

The analyzer checklist exists only in browser state. Copy or export before leaving. Copy priority summary is suitable for a quick ticket. JSON preserves the complete structured report. Check-level CSV supports triage. Link-inventory CSV preserves every captured link. Print creates a readable meeting document or PDF. Name exports with site, page, state, and date, and review them for sensitive snippets before sharing.

StrictSEO Browser operating manual

Choose desktop app or source-run package

StrictSEO Browser is a local product, not another public website. It starts a dashboard on loopback and launches a dedicated temporary Chrome profile for normal browsing. Remote websites remain in stock Chrome; the desktop shell displays only the local dashboard. Both the app and source-run package use the same shared page engine as the extension.

The macOS Apple Silicon app package removes the Node and terminal requirement, but the current build is unsigned and intended for local evaluation until Developer ID signing and notarization are configured. StrictSEO.com publishes no build files. Approved early-access requests can receive a private source-package link; that package requires Node.js 22 or newer plus Chrome or Chromium. The unsigned desktop bundle remains outside the normal Git release archive because it exceeds GitHub’s standard per-file limit.

For the source package, request private StrictSEO Browser access. Once the required request information is complete, verify the versioned archive and checksum from the reply, extract it, and open a terminal in the StrictSEO-Browser-VERSION folder. Run npm install --prefix local-browser, then npm --prefix local-browser start. Keep the terminal open. The dashboard normally uses 127.0.0.1:3115; Chrome debugging uses a dynamically allocated loopback port.

Understand the two-window workflow

The dedicated Chrome window is where you browse. The local app dashboard is where you read reports, navigate, crawl, run Lighthouse, and export. Entering a bare domain in the dashboard address field visibly adds HTTPS. Back, Forward, and Reload control the active dedicated browser target. If all controlled browsing tabs are closed, entering a new address recreates one.

Page analysis updates after a rendered HTTP or HTTPS page finishes loading and keeps up to one hundred unique URL reports for the session. The Page issues, Page evidence, and Site patterns views behave like the extension but have more room and a local highlight action. Confirm the selected page URL before highlighting; the browser refuses to highlight a historical report on a different live page.

Operate Page issues and Page evidence

Page issues is the prioritized report. Use status, area, priority, and search controls to narrow it. Open the exact location for selectors, snippets, measurements, and DOM excerpts. Show on page brings the dedicated Chrome tab forward, scrolls to the selector, and outlines it temporarily. If the element changed, reload or rescan by navigating the page again.

Page evidence shows what the browser observed: evaluated checks, visible words, headings, links, images, schema, DOM size, resource and transfer clues, and category summaries. These are local measurements. Do not label them field performance or search-platform data. Site patterns compares only pages reviewed through browsing and can identify recurring issues and duplicate page signals without running a hidden crawl.

Create a local fix plan from exact evidence

Use Add to local fix plan on an actionable Page issues card when the finding needs implementation work. StrictSEO creates or selects the local project for that page’s origin and saves the page identity, compact finding record, fix-guide link, status, and any note you enter. The project does not need to exist before page review: browsing and diagnosis remain immediate, while persistence starts only when you save a crawl or action.

Open Progress & verify to work the plan. Use Planned while the item is assigned or in progress. Add an implementation note that names the real source changed—for example, the title template, React component, CMS field, redirect rule, or content section. Mark Fixed only after the change is available on the page you can load. Then open the same URL in the dedicated Chrome window, wait for the new rendered report, and choose Verify. StrictSEO requires a newer capture that evaluated the same check; an absent or unevaluated check is not silently called resolved.

A verified technical fix and an improved search outcome are different states. DOM, metadata, directive, and content findings verify against a newer rendered scan. Search-performance actions wait for a later Search Console period. Preserve this distinction in status meetings and exports: “implemented and verified” describes the page; “measured later movement” describes correlated traffic evidence.

Run and save a bounded site crawl

Open Site crawl, enter the starting URL, choose 25 to 500 pages, and select a maximum depth from 3 to 20. Start & save crawl is an explicit action: it runs the crawl and retains a compact baseline for that origin on this device. The crawler stays on the starting origin, respects applicable robots.txt rules, reads XML sitemaps and sitemap indexes, follows at most ten redirects, limits each document to five megabytes, and times individual requests out after fifteen seconds. It parses HTML without executing scripts in Node.

Watch Pages crawled, Successful, Redirected, Errors, Robots blocked, and Sitemap URLs. Crawl issue groups combine server evidence and the shared page checks. Affected-URL controls open a page in the dedicated browser. The URL inventory shows status, root depth or sitemap-only discovery, observed inlinks, response time, and discovery source. Stop ends the crawl at its current bounded state.

Interpret depth carefully. Root-reachable pages are prioritized before sitemap-only URLs. A sitemap-only label means the crawler discovered the URL from a sitemap but did not observe a root navigation path within this bounded crawl. It is an orphan candidate, not proof of orphan status. A low inlink count is similarly scoped to the crawl. Use the evidence to inspect navigation and context manually.

Download crawl JSON before another crawl replaces the active complete report or the session ends. The complete page findings remain in local process memory and are returned through the explicit download endpoint. The saved project keeps a smaller, sanitized record: URL and crawl summaries, discovery and link counts, and actionable check summaries. It excludes raw HTML, rendered DOM excerpts, cookies, complete page captures, axe output, and Lighthouse reports. StrictSEO retains at most twelve saved crawl snapshots per origin.

Compare crawls and inspect internal-link architecture

After the second saved crawl, open Progress & verify and compare the two newest snapshots. New means a check appears in the newer snapshot but not the older one. Resolved means the newer crawl rechecked the same URL and no longer retained that actionable check. Continuing means it remains. Not rechecked means the older URL was absent from the newer bounded crawl; StrictSEO deliberately does not call that resolved. Compare page limits, depth, start URL, robots behavior, and crawl completion before treating count differences as product changes.

Open Architecture after a saved crawl. Link hubs are pages with the most observed direct internal links inside the crawl. Weak connections have one or fewer observed inlinks. Sitemap only means no route from the start page was observed within the crawl. Deep paths are three or more clicks from the start page. These groups are diagnostic candidates, not PageRank, authority, or complete-site metrics. Inspect whether each page deserves stronger contextual linking before changing navigation merely to improve a count.

Connect or import Google Search Console evidence

Open Traffic opportunities. The optional direct connection requests Google’s read-only Search Console scope. A distributor-configured build can supply its OAuth client automatically. In a private local build, create a Google Cloud OAuth client of type Desktop app, download the JSON file, select it in the connection control, and choose Connect Google Search Console. Do not use a Web application client file. StrictSEO uses PKCE, state validation, a random loopback callback, and a bounded authorization window; Google’s approval page opens outside the local dashboard.

After approval, choose a verified Search Console property that matches the active project origin. Enter a project URL if no crawl or browsed page has established the origin. The default sync selects a final 28-day period ending three days before today and automatically requests the immediately preceding equal-length baseline. You may choose a 2-to-90-day current period. StrictSEO requests page-and-query rows, filters a domain property back to the project origin, and retains at most 25,000 usable rows per period and twelve period imports per project.

If you do not want to connect Google, export a Search Console Performance table and use the CSV fallback. The CSV needs Clicks and Impressions. Include Page and Query when possible. If the export contains queries but no Page column, enter the one page URL those queries belong to. Provide accurate period dates and a clear label so comparisons remain interpretable. Rows from another origin are ignored, oversized imports are bounded, and private or sensitive fields do not belong in the file.

Search Console is incomplete by design: anonymized and lower-volume queries can be omitted, aggregation and property filters matter, and row limits can make imported totals differ from the Performance chart. StrictSEO therefore explains the observed clicks, impressions, CTR, average position, comparison, and threshold behind each suggestion. It does not invent search volume, keyword difficulty, traffic value, backlink authority, or ranking probability.

Save a traffic opportunity and measure a later period

Review the opportunity’s page, query where available, observed metrics, recommendation, priority, and measurement guide. Save an accepted opportunity to the local fix plan; StrictSEO preserves its metric baseline. Record the actual implementation in the note and mark the action Fixed on the day it becomes available. Do not mark work fixed merely because a ticket was opened.

Sync or import a later period whose start date is after the implementation date. An overlapping period remains useful context but is not a clean post-change window. When a valid later row exists, the outcome panel compares clicks, impressions, CTR, and average position; daily rates are normalized when period lengths differ. A missing row is not automatically a loss, because Search Console can suppress or omit rows. Interpret direction alongside release history, demand, seasonality, index coverage, competitor movement, and other changes.

Use the phrase correlated outcome evidence in the handoff. StrictSEO can show that the measured page or page-query combination moved after the release; it cannot prove that one action caused every delta. Keep the action when the result is inconclusive, add the context in the note, and collect another comparable period rather than rewriting history.

Run Lighthouse correctly

Open Lighthouse, enter a page URL or use the reviewed-page default, choose Mobile or Desktop, and select Run Lighthouse. Bare domains normalize to HTTPS. StrictSEO launches a separate temporary headless Chrome process with Lighthouse 12.6.1 and simulated lab throttling. Wait for completion before starting another run.

The dashboard shows Performance, Accessibility, SEO, and Best Practices scores, plus First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index where Lighthouse returns them. Failed and partial scored audits appear as a prioritized diagnostic list. Download complete JSON for technical analysis and HTML for the full human-readable Lighthouse report.

Lighthouse scores vary with machine load, network conditions, page state, third-party services, and run-to-run noise. Repeat important tests in controlled conditions. A Lighthouse LCP is lab evidence, not the field LCP experienced by real visitors. Use field Core Web Vitals for real-user measurement and Lighthouse to diagnose reproducible bottlenecks.

Read axe-core and other open-source checks

axe-core runs automatically against the selected rendered page after the core StrictSEO findings are published. Open Open-source checks to see the axe version, violation groups, impact, affected-node count, example selectors, description, and link to the upstream rule documentation. If the page changes before axe finishes, StrictSEO discards the superseded result rather than attaching it to the wrong capture.

An empty automated violation list is not an accessibility certification. Automated tools can detect only part of WCAG conformance and cannot judge every label, reading order, instruction, cognitive burden, animation, or task flow. Test keyboard use, focus, zoom, screen readers, color, error recovery, and representative user tasks manually.

The open-source view also attributes Mozilla Readability for crawled main-content extraction, robots-parser for applicable robots rules, and fast-xml-parser for sitemap discovery. StrictSEO preserves their result names and licenses instead of presenting them as proprietary metrics. Readability output is an extraction clue, not a content-quality score.

Export and end the local session

Session JSON includes reviewed pages, site patterns, current crawl and Lighthouse summaries, plus the active local project, opportunities, fix actions, and available outcomes. CSV flattens page findings, search opportunities, and fix-plan actions into assignable rows. Markdown creates a readable browsed-site brief with search and fix-plan sections when available. Dedicated crawl JSON and Lighthouse JSON/HTML preserve more complete tool-specific reports. Exports never include Google refresh credentials.

Use Clear in Site patterns only to clear the temporary reviewed-page session. Use Clear local project in Progress & verify to erase the selected origin’s saved crawls, imported Search Console rows, actions, notes, comparisons, and outcomes. Use Disconnect Google to request token revocation and remove the separate local refresh credential. These controls have different scopes; export approved evidence before clearing persistent project data.

Press Control-C in the source-run terminal or quit the desktop app when finished. The runtime stops its loopback server, controlled browser connections, and temporary processes, then removes the temporary Chrome profile. Saved local projects and the optional Google connection survive an ordinary restart until explicitly cleared or disconnected. Downloaded reports remain in the destination you selected. StrictSEO does not upload them or delete them after you save them.

Four complete operating workflows

Workflow 1: inspect and repair one page

1. Write the page purpose and intended user task.
2. Open the rendered page and activate the extension.
3. Confirm identity and resolve high-priority access, canonical, directive, title, and H1 evidence first.
4. Open the full analyzer for previews, outline, inventories, content evidence, and JSON-LD.
5. Turn accepted findings into tasks with URL, check ID, evidence, owner, intended behavior, and rerun.
6. After implementation, analyze a comparable state and inspect the same check IDs.
7. Measure later search and business outcomes separately.

Workflow 2: diagnose a repeated template problem

1. Browse representative pages with the extension and confirm the finding repeats.
2. Inspect exact selectors and excerpts to identify the shared component or generator.
3. Run a bounded crawl to understand affected URLs, discovery paths, statuses, and template scale.
4. Create one root-cause task plus representative URL samples rather than one ticket per warning.
5. Test the component in different page purposes, locales, and responsive states.
6. Rerun the crawl and sample rendered pages after deployment.

Workflow 3: move from a Search Console opportunity to measured evidence

1. Open Traffic opportunities and connect Search Console read-only or import a bounded CSV for the correct origin and period.
2. Inspect the suggestion’s page, query, metrics, property-specific comparison, recommendation, and known data limits.
3. Confirm the opportunity with page intent, rendered evidence, crawl context, live search research, and business relevance.
4. Add the accepted item to the local fix plan, preserve its baseline, assign an owner, and record the actual implementation.
5. Mark it Fixed only when released, then wait for a cleanly later comparable Search Console period.
6. Review clicks, impressions, CTR, and average-position movement as correlated evidence; document seasonality, demand, indexing, and other releases.
7. Keep, iterate, or reverse the change based on the complete evidence—not one metric or a promised ranking gain.

Workflow 4: investigate a slow or inaccessible page

1. Capture StrictSEO page evidence and automatic axe results in the intended rendered state.
2. Run Lighthouse Mobile in a controlled environment and download the HTML and JSON reports.
3. Map failed audits to real resources, components, interactions, and affected axe selectors.
4. Fix a coherent bottleneck group, such as oversized hero delivery or blocking third-party code.
5. Repeat Lighthouse under comparable conditions and perform manual accessibility tasks.
6. Use field performance and real-user evidence before claiming the visitor experience improved.

Verify, document, and hand off the repair

Save the before URL, input method, page state, report date, finding ID, observed evidence, selector, excerpt, and intended behavior. After the change, run the same mechanism in a comparable state. A finding is technically verified only when the newer report evaluates the same check and the page shows the intended behavior. Absence from an incomplete snapshot is not a pass.

For metadata, inspect the new value and confirm server evidence where relevant. For elements, verify visible semantics and not merely disappearance of an old selector. For links, follow the destination and use a crawl when site discovery matters. For JSON-LD, confirm parsing and truthfulness, then use official validators where eligibility matters. For performance, repeat controlled lab runs and inspect field data. For accessibility, combine axe with manual testing.

Separate the implementation report from outcome measurement. A passed title or answer check proves the supplied page changed, not that Google selected it or traffic improved. Record the release date and compare appropriate later data without claiming one edit caused every movement. Demand, competition, indexing, seasonality, links, and unrelated releases can all change the result.

StrictSEO Browser supports that separation directly. Page findings verify only against a newer rendered capture that evaluated the same check. Search opportunities preserve the pre-change metric baseline and wait for a cleanly later Search Console import. When period lengths differ, compare rates as well as totals. When the matching row is missing, preserve uncertainty rather than converting missing data into a zero or a loss.

Privacy, permissions, and report retention

The extension uses active-tab, scripting, side-panel, temporary storage, and a fixed analyzer host permission. It does not request all-sites access. Captured URLs are bounded and credentials, fragments, sensitive query values, email and telephone destinations, and unsupported payloads are removed or redacted. The live session can still contain visible text, headings, link labels, and DOM excerpts from the page.

The analyzer processes extension snapshots, pasted HTML, and uploaded HTML in the browser. The audited site has no page-snapshot upload API. StrictSEO Browser runs locally and binds its dashboard and debugging interfaces to 127.0.0.1. The crawler fetches the public HTTP or HTTPS URLs you instruct it to crawl from your computer. Lighthouse and axe run locally through their packaged components.

StrictSEO Browser saves local project files in the operating system’s application-data area with a private user directory. Each origin can retain up to twelve compact crawl snapshots, twelve Search Console imports of up to 25,000 usable rows each, two hundred fix actions, and notes you enter. Project records exclude raw HTML, DOM excerpts, cookies, credentials, complete snapshots, axe output, and Lighthouse reports. Use Clear local project to remove the active origin’s persistent record.

The optional Search Console connection requests only webmasters.readonly. The refresh credential is stored separately from projects with owner-only file permissions and is not included in dashboard event state, page captures, exports, or StrictSEO.com requests. Disconnect Google requests revocation and deletes the local credential even if Google cannot be reached. A CSV import avoids OAuth but places the exported rows in the same bounded local project record.

Downloaded reports are persistent files under your control. Review them before placing them in email, shared drives, project trackers, or support messages. Avoid activating StrictSEO on pages where even local processing of visible content would violate policy. Reproduce a bug on a safe public test case whenever possible. Closing the extension clears its temporary session; quitting StrictSEO Browser clears temporary page, axe, crawl-detail, Lighthouse, and Chrome-profile state, but deliberately retained projects and downloaded reports remain until you remove them.

Troubleshooting by symptom

Operating completion checklist

Use this checklist to confirm that a StrictSEO review is reproducible and educational. It is not a score.

1. The page purpose, intended reader, and user task are written down.
2. The selected tool matches the evidence required for the decision.
3. The report title, URL, locale, input method, and page state are confirmed.
4. Status and priority are interpreted separately from business impact and affected scale.
5. High-priority access, identity, canonical, directive, and security evidence is reviewed first.
6. Every accepted action includes observed evidence and a precise next step.
7. Rendered findings retain selector, snippet, position, measurement, or DOM excerpt where available.
8. Relationship findings retain both the previous and affected element evidence.
9. Review prompts have a documented human decision rather than being treated as automatic failures.
10. Passed checks are described as narrow regression evidence rather than page certification.
11. Site patterns are labeled as browsed-session evidence, not a complete crawl.
12. Crawl conclusions state origin, page limit, depth, robots behavior, and discovery boundaries.
13. Sitemap-only and low-inlink pages are described as bounded candidates, not proven orphans.
14. Saved-crawl comparisons distinguish resolved on rechecked URLs from URLs that were not rechecked.
15. Architecture groups are labeled bounded link observations, not authority, PageRank, or complete-site metrics.
16. Search Console evidence records the property, origin, period, row limits, quality notes, and comparison method.
17. Every accepted traffic opportunity retains its observed metrics, intended action, release date, and outcome window.
18. Lighthouse is labeled lab evidence and axe is labeled automated accessibility evidence.
19. Structured data is compared with visible content and not presented as a display guarantee.
20. The owner, scope, intended behavior, and verification method are defined for each task.
21. A newer comparable report evaluates the same check before technical completion is claimed.
22. Later search, field, and business outcomes are measured separately from implementation verification.
23. Exports are reviewed for visible text and DOM evidence before sharing.
24. Temporary sessions are cleared or closed and downloaded files follow the organization’s retention policy.

StrictSEO operating glossary

Operating manual questions