# SiteScan.top — full text > Website diagnostics: SiteScan.top crawls a site the way a real user would and reports > broken links, dead forms, console errors, accessibility, performance, SEO and > security-header problems. - Canonical host: https://sitescan.top - Languages: en, ru, pl, de (default: en; this file is en) - Short form: https://sitescan.top/llms.txt - Generated: 2026-10-20 This is every public page and every article of SiteScan.top as one Markdown document, generated at build time from the same route table, translation table and article sources the site itself renders. Each entry carries the URL it was taken from. The Russian, Polish and German sites say the same things at the same paths under `/ru`, `/pl` and `/de`. Scan reports are not here: there is one per scanned domain at `/scan//`, they are generated from a crawl rather than written, and they are listed in https://sitescan.top/sitemap-scans.xml. ## Pages ### Your site, checked and protected. - Page: Home - URL: https://sitescan.top/ - Description: Free website diagnostics: crawl any site for broken links, dead forms, console errors, accessibility, performance, SEO and security headers in under a minute. SiteScan.top verifies security headers, TLS and mixed content on every page — you see what already holds, and the exact spot where it does not. Free scan — no sign-up required - **Find bugs before your users do.** — SiteScan.top crawls your entire site like a real user — finding broken links, dead forms, and hidden errors before your visitors hit them. - **Be the page AI recommends.** — SiteScan.top audits titles, metadata, structured data and crawlability — the signals Google and AI assistants use to decide whether your pages are worth showing. - [Product](https://sitescan.top/product/) - [Pricing](https://sitescan.top/pricing/) - [Recent scans](https://sitescan.top/scans/) #### Three steps. Under 60 seconds. ##### Paste your URL Any website works - Public or staging URLs - No code changes needed - Works with any framework ##### AI does the work Fully automated - Crawls all pages - Tests every form - Checks accessibility & SEO ##### Get your report Actionable insights - Prioritized issues - Fix suggestions - Export to PDF #### Everything you need to ship with confidence Comprehensive testing across every dimension of web quality. - **Sub-60 second audits** — Full site scans complete in under a minute. AI-powered discovery finds every page that matters. - **Broken link detection** — Find every dead link, 404, and redirect chain across your entire site. - **Security headers** — Check CSP, HSTS, and security best practices across every response. - **AI-powered form testing** — AI intelligently fills and submits forms. Catches broken validation, submission errors, and UX issues. - **Performance insights** — Core Web Vitals, LCP, FID, CLS — all measured automatically. - **Accessibility audit** — WCAG 2.1 compliance checks with actionable fix suggestions. - **Console error capture** — JavaScript errors, failed requests, and runtime issues detected. - **SEO & AI visibility** — Meta tags, Open Graph, structured data and sitemaps — the signals search engines and AI assistants read. - **Privacy & consent** — Third-party trackers, the cookie banner, and the legal pages your site links to. #### Why teams choose SiteScan.top One scan covers everything below — no setup, no checklist to keep in your head. - AI-powered form testing - Broken link detection - Console error capture - Multi-page crawling - Accessibility audit - Performance metrics - SEO analysis - Automated retesting #### Trusted by teams worldwide - **Sarah Chen — Engineering Lead, ShopifyPlus Store** — SiteScan.top found a broken checkout form that was losing us $50k/month. The AI form testing is incredible. - **Marcus Webb — CTO, Fintech Startup** — We used to spend 2 days on manual QA before each release. Now it takes 2 minutes with SiteScan.top. - **Priya Sharma — VP Product, Enterprise SaaS** — The accessibility audit alone saved us from a lawsuit. SiteScan.top pays for itself many times over. - **James Liu — Founder, Dev Agency** — Finally, a QA tool that tests like a real user. The AI form testing catches things we'd never find manually. - **Elena Rodriguez — Staff Engineer, Tech Corp** — We integrated SiteScan.top into our CI/CD pipeline. Every deploy now gets automatically tested. - **David Park — Marketing Director, Digital Agency** — The broken link detection found 47 dead links we didn't know existed. Embarrassing but fixed now. - **Tomás Ferreira — Head of Web, Travel Marketplace** — A single scan turned up 213 dead links across our old city guides. We fixed them in one sprint and the organic traffic came back. - **Anna Kowalczyk — SEO Lead, Retail Group** — Every title and meta description across 900 pages, checked in one pass. Our SEO backlog stopped being guesswork. - **Rahul Mehta — Security Engineer, Payments** — It flagged a missing CSP on our payment pages before our pentest did. That alone paid for the year. - **Sofie Lindqvist — Privacy Officer, Media House** — The privacy report listed every third-party tracker firing before consent. Legal finally has a document they trust. - **Diego Alvarez — Frontend Lead, News Portal** — LCP went from 4.1s to 1.6s after we worked through the performance findings page by page. - **Yuki Tanaka — QA Engineer, Gaming Studio** — Console errors we could never reproduce locally showed up with the exact page and the exact request that failed. - **Grace Okonkwo — Product Designer, Banking App** — It caught tap targets smaller than a fingertip across half our mobile flows. Design QA now starts with this report. - **Martin Novak — Web Producer, Publishing House** — Six hundred images without alt text, sorted by page. We cleared them in two weeks instead of arguing about where to start. - **Elif Demir — Technical SEO, Marketplace** — After the domain move it mapped every redirect chain. We collapsed three-hop chains down to one. - **Lukas Berger — DevOps Engineer, SaaS** — We scan staging on every merge. Broken forms do not reach production anymore. - **Camille Rousseau — Account Director, Web Agency** — The PDF report goes to the client with every handover. It looks like we spent three days auditing. - **Priya Nair — Ecommerce Manager, Fashion Retail** — It found a checkout that failed only with a discount code applied. Support tickets dropped the same week. - **Jonas Weber — Tech Lead, Enterprise CMS** — After the migration we had 1,100 pages to verify. The crawl did it in an hour and listed exactly what broke. - **Marta Silva — Content Manager, Nonprofit** — Editors break links constantly. Now I get a weekly list instead of hearing about it from a donor. - **Nils Andersen — International SEO, Travel** — Our hreflang tags pointed at pages that had been deleted. Nobody noticed for a year; the scan found it in a minute. - **Sarah Whitfield — Head of Delivery, Consultancy** — Client-ready PDFs mean I stop rewriting findings into slides. That is a day back on every project. - **Ahmed Hassan — Site Reliability Engineer, Logistics** — We rescan after every deploy. Twice it caught a broken form within minutes of release. - **Julia Kaminski — Engineering Manager, HealthTech** — New engineers read the report on day one and grasp the state of the front end faster than from any doc we wrote. - **Marco Bianchi — Growth Lead, B2B SaaS** — Half our campaign landing pages had a form that silently failed on mobile. We were paying for that traffic. - **Hanna Virtanen — Legal Counsel, Insurance** — The consent findings and the linked legal pages are exactly what our regulator asks to see. - **Peter Malinowski — Platform Engineer, Telecom** — Compression was off across an entire subdomain. Nobody had looked at those headers since 2019. - **Rosa Delgado — SEO Consultant, Freelance** — Structured data errors listed per template rather than per page. I fix one component and 400 pages go green. - **Chris Bennett — Head of Content, Fintech** — We want AI assistants to quote us. The report tells us which pages they can actually read. - **Ingrid Haugen — Web Manager, University** — Our sitemap still listed course pages from 2021. Search engines were crawling ghosts. - **Kenji Watanabe — Frontend Architect, Electronics** — Duplicate ids across our component library, found by crawling the live site rather than reading the code. - **Laura Meyer — Founder, Small Agency** — A few tokens per check cost less than an hour of my time, and the report reads better than the ones I used to write by hand. - **David Osei — Digital Lead, Charity** — We have no QA team. This is our QA team. - **Emma Lindgren — Documentation Lead, Dev Tools** — Six hundred docs pages, forty broken anchors. Readers had been hitting them for months. - **Paulo Castro — IT Director, School Network** — Accessibility compliance is a legal requirement for us. The WCAG findings map straight onto our audit checklist. - **Nadia Sokolova — Head of Engineering, Marketplace** — Two thousand seller pages crawled overnight, console errors grouped by template. That is a week of manual work. #### Ship with confidence. Run your first audit in under 60 seconds. No signup, no credit card, no code changes. - [View pricing](https://sitescan.top/pricing/) ### The diagnostic engine for web quality. - Page: Product - URL: https://sitescan.top/product/ - Description: How SiteScan.top reads a site: it renders every page, follows each link, checks forms, headers and metadata, then scores speed, SEO and security. SiteScan.top renders your site like a real user, then dissects it across every dimension of web quality — surfacing every broken link, dead form, and hidden error with surgical precision. #### Where errors live, visualized. As you read the report, anatomy rules connect each finding to the exact element on your page — so you see not just what's wrong, but where. - **Render like a user** — A real headless browser loads every page, executes JavaScript, and waits for network idle — exactly as your visitors experience it. - **Act like a user** — AI agents fill forms, click buttons, and navigate flows to catch broken validation and submission errors no static scan can find. - **Report like an engineer** — Prioritized issues with reproduction steps, fix suggestions, and one-click PDF export for stakeholders. #### Analyzers - Meta tags, Open Graph, structured data, sitemaps. - WCAG 2.1 compliance with actionable fix suggestions. - Core Web Vitals — LCP, FID, CLS measured automatically. - CSP, HSTS, and security header best practices. - Trackers, consent layer and the legal pages the site links. - Markup validity: parse errors, doctype, duplicate ids, obsolete tags. - AI-powered form testing — validation, submission, UX. - Every dead link, 404, and redirect chain detected. - JavaScript errors, failed requests, runtime issues. - Server response, redirects, compression, caching. - Viewport, pixel widths that overflow a phone, home-screen icons. - Broken files, legacy formats, missing dimensions, pictures inlined into the HTML. #### Scan your site now Free audit — no signup required. Results in under 60 seconds. - [Or explore pricing](https://sitescan.top/pricing/) - [Recent scans](https://sitescan.top/scans/) ### Pay as you go - Page: Pricing - URL: https://sitescan.top/pricing/ - Description: One token pays for one page checked. Packs from 500 tokens for $9; a scan from the home page is free and a new account gets 100 tokens. Tokens never expire. Buy tokens once, use them whenever. One token pays for one page checked. No subscription. #### Choose your pack The same packs as in your account. Bigger packs, better rates. Tokens never expire. - 500 tokens — $9.00 ($18.00 per 1,000 tokens) - 2,000 tokens — $29.00 ($14.50 per 1,000 tokens) - 10,000 tokens — $99.00 ($9.90 per 1,000 tokens) - 50,000 tokens — $399.00 ($7.98 per 1,000 tokens) #### What a token pays for One token is one page the scanner actually read — the same rate for a check from the panel, a scheduled check and a scan through the API. - **A scan from the home page** — free · up to 5 pages · no account - **A check from the account panel** — 1 token per page read - **Scheduled monitoring of a site** — 1 token per page, every run - **A scan through the API** — 1 token per page read - **Reading reports, history and API results** — free - **A check that ends without a report** — free - **A new account** — +100 tokens Example: watching a 10-page site weekly costs about 40 tokens a month — the 2,000-token pack lasts around four years. #### Frequently asked questions - **How do tokens work?** — Tokens are the balance in your account. Every check spends one token per page the scanner actually read, and only when the check finishes. Buy them in packs and they wait on the balance until you use them. - **How many pages does one check read?** — You choose it per site in the account panel — 5, 20, 100, 1000 or all the links — up to the scanner's limit per check, which the panel shows. A check never reads more pages than the balance pays for. - **Is there anything free?** — Yes. A scan from the home page is free, needs no account and reads up to 5 pages. A new account also starts with 100 tokens. - **Do tokens expire?** — No, tokens never expire. Buy them once and use them whenever you need a check. - **Can I get a refund?** — We offer refunds within 7 days of purchase if you haven't used any of the tokens. Contact support for assistance. ### Web diagnostics and optimisation - Page: Blog - URL: https://sitescan.top/blog/ - Description: Practical guides on Core Web Vitals, broken links, console errors, form testing, accessibility, security headers and image optimisation. Practical breakdowns: how to find broken links, dead forms and console errors — and how to speed a site up without breaking it. 40 articles - [RSS feed](https://sitescan.top/blog/feed.xml) #### Featured - [Website check online: what one minute of scanning reveals](https://sitescan.top/blog/website-check-online/): An online website check in about a minute: which areas it covers, what the report looks like, how to read the first screen and when the check is worth running. - [Website analysis online: how to read the report and what to fix](https://sitescan.top/blog/website-analysis-online/): Website analysis online starts after the scan: how to read scores, severities and categories, set priorities and turn a report into a fix list you will finish. - [Website audit online: a step-by-step plan from scan to re-check](https://sitescan.top/blog/website-audit-online/): A website audit online is a process, not a score: set the scope, capture a baseline, triage findings, turn them into tickets and prove the fixes with a rescan. - [SEO website analysis: titles, canonicals, hreflang and indexing](https://sitescan.top/blog/seo-website-analysis/): An SEO website analysis of the on-page and indexing signals: titles and descriptions, headings, canonical, hreflang, structured data, robots.txt and sitemap. - [Free SEO audit: what it shows, what it misses, how to use it](https://sitescan.top/blog/free-seo-audit/): What a free SEO audit can and cannot tell you, where free ends and paid begins, and how to get the most out of a free website scan in one evening. - [Website error check: links, 404s, 5xx, JS errors and forms](https://sitescan.top/blog/website-error-check/): A practical website error check: how to find broken links, real and soft 404s, 5xx responses, JavaScript errors, dead forms, mixed content and broken images. - [Technical website audit: TLS, redirects, headers, DNS and mail](https://sitescan.top/blog/technical-website-audit/): A technical website audit checks the foundation: certificate, redirects, robots.txt and sitemap, security headers, caching, DNS, mail and exposed files. - [SEO check in 15 minutes: a step-by-step checklist](https://sitescan.top/blog/seo-check/): An SEO check you can finish in 15 minutes: indexing, robots.txt, canonicals, titles and descriptions, sitemap, speed, structured data and broken links. - [Free website analysis: what you can check for free, and the limits](https://sitescan.top/blog/free-website-analysis/): Free website analysis covers more than you think: DevTools, webmaster panels, PageSpeed, the terminal and scanners. Where the limits are and when to pay. - [Online website scanning: how a scanner reads your site](https://sitescan.top/blog/website-scanning/): What happens during online website scanning: how pages are picked and rendered, what robots.txt means, and why a report can differ from your browser. - [Website diagnostics: from symptom to cause](https://sitescan.top/blog/website-diagnostics/): Website diagnostics the way a doctor works: start from the symptom — slow pages, lost traffic, mail in spam, outages, browser warnings — and find the cause. - [Automated website checks: catch regressions before users do](https://sitescan.top/blog/automated-website-check/): How to set up an automated website check: schedules, comparing scans, alerts that are worth reading, and the expiry dates that need watching most. - [Comprehensive website audit: every dimension, one work plan](https://sitescan.top/blog/comprehensive-website-audit/): A comprehensive website audit puts SEO, speed, security, accessibility, mobile, privacy and email in one picture. Here is how to plan the work it produces. - [AI website check: using an LLM with real scan results](https://sitescan.top/blog/ai-website-check/): An AI website check works when the model gets real scanner data. How to have AI explain a report, write the fix brief and not fall for hallucinations. - [AI website audit: a checklist for AI search and assistants](https://sitescan.top/blog/ai-website-audit/): An AI website audit in six steps: crawler access in robots.txt, content without JavaScript, llms.txt, structured data, clear answers and measurement. - [Third-party scripts: the weight you did not write](https://sitescan.top/blog/third-party-scripts/): Analytics, tag managers, chat widgets and pixels each look harmless on their own. Together they decide how fast your page is — here is how to take stock and cut them back. - [Web fonts without the wait: font-display, subsets and preload](https://sitescan.top/blog/web-fonts/): Invisible text, jumping layouts and an extra origin for every visitor — how to load custom fonts so that text appears immediately and stays put. - [RSS and Atom feeds: the old format that still moves your content](https://sitescan.top/blog/rss-atom-feeds/): Why a feed still matters in 2026, RSS 2.0 versus Atom, how to make it discoverable, and the small mistakes that make readers show a year-old post as new. - [SPF, DKIM and DMARC: your domain sends mail whether you do or not](https://sitescan.top/blog/email-authentication/): Why every website domain needs email authentication records, how SPF, DKIM and DMARC fit together, and how to roll out a reject policy without losing your own mail. - [Canonical URLs: one page, one address](https://sitescan.top/blog/canonical-urls/): Why the same page lives at a dozen addresses, what rel=canonical can and cannot do about it, and the canonical mistakes that quietly undo your own SEO. - [Soft 404: the missing page that answers 200 OK](https://sitescan.top/blog/soft-404/): Why a not-found page that returns 200 fills the index with garbage, blinds your monitoring, and how to make the server tell the truth about missing addresses. - [Mixed content: the http:// leftovers inside your https:// page](https://sitescan.top/blog/mixed-content/): Why one forgotten http:// image or script undoes the security of an HTTPS page, what browsers block or quietly upgrade, and how to clean it up for good. - [Two dates that take the whole site down: certificate and domain expiry](https://sitescan.top/blog/expiry-dates/): Why auto-renewal still fails, what changes as certificate lifetimes shrink to 47 days, how a domain actually lapses, and the checks that catch both in time. - [Being quotable: how AI assistants read your site](https://sitescan.top/blog/ai-visibility/): Answer engines cite pages they can parse, attribute and trust. What that means in practice, and which of your pages currently fail it. - [Invalid HTML: which errors browsers forgive and which cost you](https://sitescan.top/blog/html-validity/): Duplicate ids, unclosed tags, nested forms. The markup mistakes that survive because the browser repairs them, and the ones that quietly break behaviour. - [robots.txt and sitemap.xml: two files that decide what gets indexed](https://sitescan.top/blog/sitemap-robots/): The difference between blocking a crawl and blocking an index, why a stale sitemap wastes crawl budget, and the one-line mistake that hides a whole section. - [Mobile usability: the defects a desktop review never sees](https://sitescan.top/blog/mobile-usability/): Viewport, tap targets, horizontal scroll and the keyboard that covers the button. The checks that decide whether a phone visitor can finish. - [hreflang: the tag that breaks quietly and stays broken](https://sitescan.top/blog/hreflang/): Why language annotations must be reciprocal, the three errors that make them useless, and how to verify a multilingual site without opening every page. - [Caching and compression: the free speed nobody claims](https://sitescan.top/blog/http-caching/): Cache-Control that actually caches, why a hashed filename changes everything, and the compression setting still missing on half the sites we scan. - [Cookie banners that do nothing: trackers firing before consent](https://sitescan.top/blog/cookie-consent/): The banner is the visible part. What matters is which requests leave the browser before anybody clicks Accept — and how to see them. - [Structured data: markup errors live in templates, not pages](https://sitescan.top/blog/structured-data/): Why one broken component costs four hundred pages their rich results, and how to validate schema.org across a whole site in one pass. - [Redirect chains: the tax you pay on every old link](https://sitescan.top/blog/redirect-chains/): Where three-hop redirects come from, what they cost in latency and crawl budget, and how to flatten them without breaking the old URLs. - [Titles and descriptions: the tags that decide the click](https://sitescan.top/blog/meta-tags/): What a search engine actually shows, why it rewrites your title, and how to audit metadata across a whole site instead of page by page. - [Core Web Vitals: LCP, INP and CLS without the myths](https://sitescan.top/blog/core-web-vitals/): What Google's three metrics actually measure, why lab numbers disagree with field data, and which fixes move the needle. - [Broken-link audits: finding every 404 before your users do](https://sitescan.top/blog/broken-links/): Why a sitemap-based check misses half the problems, why a soft 404 is worse than a real one, and how to run a recurring audit. - [Console errors: which ones cost sales and which are noise](https://sitescan.top/blog/console-errors/): JavaScript errors sorted by user impact, the source-map trap, and how to separate your own code from third-party widgets. - [Dead forms: why enquiries never arrive, and how to catch it](https://sitescan.top/blog/form-testing/): Seven places a form submission breaks, a checklist for contact and checkout forms, and what belongs in a test submission. - [WCAG accessibility: what automation finds and what it misses](https://sitescan.top/blog/accessibility/): Automated tests cover about a third of the WCAG criteria. What they catch, what they miss, and how to check the rest by hand in half an hour. - [HTTP security headers: the minimum worth setting today](https://sitescan.top/blog/security-headers/): CSP, HSTS, X-Content-Type-Options and the rest: what actually protects you, what is obsolete, and in which order to roll them out without an outage. - [Images: cutting half the page weight in one sprint](https://sitescan.top/blog/image-optimization/): Formats, dimensions, lazy loading and priorities. A practical order of work that halves page weight without losing quality. ### All scans - Page: Recent scans - URL: https://sitescan.top/scans/ - Description: Every site SiteScan.top has scanned, newest first, with its score, page count and issue count. Open any report to see the findings on each page. Every site SiteScan.top has scanned, newest first. Open any report to see the pages, the issues and the data found on them. - [Run a scan](https://sitescan.top/) - [Product](https://sitescan.top/product/) ### How can we help? - Page: Help centre - URL: https://sitescan.top/help/ - Description: Answers about what SiteScan.top checks, how long a scan takes, how tokens and reports work, which browser it renders with, and how your data is handled. Find answers to common questions about SiteScan.top. #### How SiteScan.top works A scan starts with nothing but an address. SiteScan.top requests the page, reads the HTML the server returns, follows the internal links it finds and repeats that until the page budget is used up. There is nothing to install, no tag to add to your site and no account to create — a surface scan is free and anonymous. Every page that comes back goes through the same set of analysers: response status and timing, title and description, canonical and hreflang, heading structure, images and their alt text, forms and their fields, internal and external links, security headers, structured data, and the validity of the markup itself. What comes back is one report: an overall score, a score per category, every issue with the pages it was found on, the quick wins ordered by how much they pay back per minute of work, and the tests worth running next. The report keeps a stable address, so you can send it to a colleague or open it again after a fix and compare. #### What SiteScan checks Every row of the site-level report has its own page: what the check looks at, why it matters and how to fix what it finds. ##### TLS certificate - [TLS certificate expiry](https://sitescan.top/help/tls-expiry/) - [Outdated TLS versions (TLS 1.0/1.1)](https://sitescan.top/help/tls-versions/) - [TLS certificate chain](https://sitescan.top/help/tls-chain/) - [TLS certificate issuer](https://sitescan.top/help/tls-issuer/) - [Certificate signature algorithm](https://sitescan.top/help/tls-signature/) ##### Domain registration - [Domain registration expiry](https://sitescan.top/help/domain-expiry/) - [Registered domain name](https://sitescan.top/help/domain-name/) - [Domain registrar](https://sitescan.top/help/registrar/) - [Domain registration date](https://sitescan.top/help/domain-created/) - [Domain last updated date](https://sitescan.top/help/domain-updated/) - [Domain status codes (EPP)](https://sitescan.top/help/domain-status/) - [Domain transfer lock](https://sitescan.top/help/domain-lock/) - [Registrar abuse contact](https://sitescan.top/help/abuse-contact/) - [RDAP and WHOIS data source](https://sitescan.top/help/registration-source/) ##### Indexing - [robots.txt file](https://sitescan.top/help/robots/) - [CSS and JS blocked in robots.txt](https://sitescan.top/help/robots-assets/) - [XML sitemap](https://sitescan.top/help/sitemap/) - [Sitemap index file](https://sitescan.top/help/sitemap-index/) - [Off-domain URLs in the sitemap](https://sitescan.top/help/sitemap-foreign/) - [Sitemap lastmod dates](https://sitescan.top/help/sitemap-lastmod/) - [Broken URLs in the sitemap](https://sitescan.top/help/sitemap-urls-probed/) - [RSS and Atom feed](https://sitescan.top/help/feed/) ##### Addresses & redirects - [HTTP to HTTPS redirect](https://sitescan.top/help/https-redirect/) - [www and non-www redirect](https://sitescan.top/help/www-variant/) - [Redirect chain length](https://sitescan.top/help/redirect-hops/) - [404 error handling and soft 404](https://sitescan.top/help/not-found/) ##### Security headers - [HTTP security headers and grade](https://sitescan.top/help/headers/) - [Strict-Transport-Security (HSTS) header](https://sitescan.top/help/strict-transport-security/) - [Content-Security-Policy (CSP) header](https://sitescan.top/help/content-security-policy/) - [X-Content-Type-Options: nosniff](https://sitescan.top/help/x-content-type-options/) - [X-Frame-Options and clickjacking](https://sitescan.top/help/x-frame-options/) - [Referrer-Policy header](https://sitescan.top/help/referrer-policy/) - [Permissions-Policy header](https://sitescan.top/help/permissions-policy/) - [HSTS preload list](https://sitescan.top/help/hsts-preload/) - [CORS and cross-origin reads](https://sitescan.top/help/cors/) - [HTTP TRACE method](https://sitescan.top/help/trace/) ##### Delivery & reputation - [Cache-Control header for HTML](https://sitescan.top/help/cache-control/) - [ETag and Last-Modified revalidation](https://sitescan.top/help/validators/) - [HTTP/3 and QUIC support](https://sitescan.top/help/http3/) - [Server version disclosure in headers](https://sitescan.top/help/banner/) - [DNS blocklist (DNSBL) check](https://sitescan.top/help/reputation/) ##### Internal links - [Broken internal links](https://sitescan.top/help/links/) - [Broken images](https://sitescan.top/help/images/) - [Missing favicon](https://sitescan.top/help/icon/) ##### Exposure - [Exposed sensitive files (.env, .git, backups)](https://sitescan.top/help/exposed-files/) - [Directory listing enabled](https://sitescan.top/help/directory-listing/) - [Public JavaScript source maps](https://sitescan.top/help/source-maps/) - [Exposed WordPress endpoints](https://sitescan.top/help/wordpress-endpoints/) ##### Well-known files - [security.txt file](https://sitescan.top/help/security-txt/) - [llms.txt for AI assistants](https://sitescan.top/help/llms-txt/) - [llms-full.txt file](https://sitescan.top/help/llms-full-txt/) - [ads.txt authorized sellers file](https://sitescan.top/help/ads-txt/) - [humans.txt file](https://sitescan.top/help/humans-txt/) - [Well-known change-password URL](https://sitescan.top/help/change-password/) ##### DNS & email - [MX records (mail servers)](https://sitescan.top/help/mail/) - [SPF record](https://sitescan.top/help/spf/) - [DMARC record and policy](https://sitescan.top/help/dmarc/) - [DNSSEC signing](https://sitescan.top/help/dnssec/) - [CAA record](https://sitescan.top/help/caa/) - [Nameserver redundancy](https://sitescan.top/help/nameservers/) - [IPv6 support (AAAA record)](https://sitescan.top/help/ipv6/) - [MTA-STS policy](https://sitescan.top/help/mta-sts/) - [TLS-RPT reporting record](https://sitescan.top/help/tls-rpt/) - [BIMI record (brand logo in email)](https://sitescan.top/help/bimi/) - [Wildcard DNS record](https://sitescan.top/help/wildcard-dns/) - [Dangling CNAME and subdomain takeover](https://sitescan.top/help/cname/) ##### Privacy & consent - [Analytics and tracking scripts](https://sitescan.top/help/trackers/) - [Cookie consent banner](https://sitescan.top/help/consent/) - [Privacy policy link](https://sitescan.top/help/legal-privacy/) - [Terms of service link](https://sitescan.top/help/legal-terms/) - [Imprint (Impressum)](https://sitescan.top/help/legal-imprint/) - [Accessibility statement](https://sitescan.top/help/legal-accessibility/) ##### Core Web Vitals - [Lighthouse performance score](https://sitescan.top/help/performance-score/) - [Largest Contentful Paint (LCP)](https://sitescan.top/help/lcp/) - [Cumulative Layout Shift (CLS)](https://sitescan.top/help/cls/) - [Interaction to Next Paint (INP)](https://sitescan.top/help/inp/) - [CrUX field data vs lab data](https://sitescan.top/help/data-source/) ##### Technology - [Web server detection](https://sitescan.top/help/web-server/) - [CMS detection](https://sitescan.top/help/cms/) - [HTTP and TLS protocol versions](https://sitescan.top/help/protocol/) - [Website technology stack](https://sitescan.top/help/tech/) #### A scan, step by step ##### 1. You paste an address Type a domain, with or without https://, and start the scan. The address has to be publicly reachable: a site behind a login, a VPN or a private IP range cannot be crawled from the outside. ##### 2. The crawler walks the site The home page is opened in a real browser first (so a bot-check page can finish), then up to five pages in the same session — ten at most. Extra URLs come from links on the home page and the sitemap. ##### 3. Every page is analysed Each page is scored on accessibility, performance, SEO, security, forms, links, infrastructure and HTML validity. A category with nothing measurable on it is reported as not measured rather than filled in with a guess. ##### 4. The report is written and stored Findings are grouped by issue rather than by page, so a missing alt attribute on nine images is one item with nine locations. The finished report is stored and shows up in the public list of recent scans. #### How to read the scores Scores are diagnostics, not grades. They exist to tell you where to look first, and they compare a site with what the checks expect — never with another site. - **The overall score** — Each measured category starts at 100 and loses points for every issue found, weighted by severity and spread over the pages crawled. The overall score is the average of the measured categories, so one badly broken area cannot hide behind eight healthy ones. 90 and above is excellent, 70 to 89 is good, below 70 needs work. - **Category scores** — Nine categories are reported: accessibility, performance, SEO, security, forms, links, console, infrastructure and HTML. Open any of them to see the issues behind the number and the exact pages they were measured on. - **Severity** — Issues are critical, high, medium or low. Critical and high mean something is already broken for visitors: a dead link, a form with no action, a page answering with an error. Medium and low are usually missing metadata or markup that will cost you later rather than today. - **Quick wins** — Quick wins rank the findings by payoff per minute of work, so the top of that list is where an hour of your time buys the largest change in the score. Each one names the pages to change and what improves once you have. #### Frequently asked questions - **What does SiteScan.top scan for?** — SiteScan.top performs comprehensive testing including broken link detection, JavaScript console error analysis, form testing, accessibility audits (WCAG), performance metrics (Core Web Vitals), SEO analysis, and security header checks. - **How many pages does one scan cover?** — A free scan reads five pages by default and ten at most: the address you entered plus the internal links found on it. The budget is per scan rather than per day, and larger crawls belong to the paid audits. - **How long does an audit take?** — Surface audits typically complete in 1-3 minutes. Deep audits with full form testing and comprehensive analysis may take 5-10 minutes depending on site size. - **Why does my scan say it is waiting?** — Five sites are crawled at the same time; when every slot is busy, new scans queue instead of being refused. The page shows your position and starts on its own as soon as a slot frees up — there is nothing to click. - **Why did I get a report I did not just run?** — A report is reused for fifteen minutes, so a shared link, a reload and a second visitor do not crawl the same site three times over. Use the rescan button to force a fresh crawl once you have changed something. - **What is the difference between Surface and Deep audits?** — Surface audits scan all pages for broken links and console errors. Deep audits add AI-powered form testing, full accessibility scans, SEO analysis, and detailed reproduction steps for each issue. - **How exactly is the score calculated?** — Every measured category starts at 100 and loses points per issue, weighted by severity and averaged over the pages crawled. The overall figure is the mean of the measured categories, so it moves when a whole area improves rather than when one page does. - **Why is the console score empty?** — Console errors are captured when Playwright opens the page. A scan that finishes reports them in the Console category. - **Is my website data secure?** — Yes. We only access publicly available pages on your site. We do not store credentials, and audit data is encrypted at rest. You can delete your audit history at any time. - **What do you store about a site I scanned?** — The report itself: the pages crawled, the values measured on them and the issues raised. Reports appear in the public list of recent scans, so do not scan an address you would rather not see listed — and write to support if one needs removing. - **Can I audit password-protected pages?** — Currently, SiteScan.top only audits publicly accessible pages. Support for authenticated page testing is on our roadmap for enterprise plans. - **Can I scan a staging site or localhost?** — Only addresses that resolve publicly can be scanned: localhost, private ranges and anything behind a VPN are refused. A staging site on a public domain works fine, and pages behind basic auth are reported as unauthorised rather than crawled. - **How do tokens work?** — A scan from the home page is free and reads up to 5 pages. Checks from the account — by hand, on a schedule or through the API — cost one token per page read. A new account gets 100 tokens; packs start at 500 tokens for $9. Tokens do not expire. - **What browsers does SiteScan.top test with?** — SiteScan.top uses headless Chromium for testing, which represents the majority of modern browser usage. Results are applicable to Chrome, Edge, and most Chromium-based browsers. - **In which languages is a report available?** — The interface and every report are available in English, Russian, Polish and German. A site is crawled once and the findings are written out in the language you are reading, so one report can be shared across a team that does not share a language. - **Can I export my audit results?** — Yes. Deep audit reports can be exported as PDF documents. The report includes all issues, severity ratings, and reproduction steps. - **Is there an API?** — The report page is served by a JSON endpoint, and a documented, versioned public API is on the roadmap. Until it ships, write to support if you need programmatic access and we will tell you what is stable enough to build on. - **A finding does not look right. What now?** — Every issue carries the measured values it was raised from, so you can check it against the page yourself. If the numbers are right but the conclusion is wrong for your case, send us the report link and we will look at the rule behind it. - **How often should I scan?** — Before a release and right after it is the pair that catches the most: the first shows what you are shipping on top of, the second whether the deploy broke something. Beyond that, once a month is enough for a site that changes slowly. - **How do I get the notices in Telegram?** — Open the Notifications tab in your account, switch Telegram on and press Connect Telegram: our bot @notify_flowbot opens, you press Start, and the chat is connected — there is nothing to copy. By hand works too: message the bot yourself, send /id, and paste the number it answers with into the Chat id field. The bot only writes to a chat that started it, so blocking it stops the notices at once. #### What a scan does not do Automated testing finds what can be measured from the outside. It will not tell you whether your copy makes sense, whether a checkout charges the right amount, or whether someone using a screen reader can finish a task — a large share of accessibility barriers still needs a person to confirm. The crawl also sees only what a visitor sees: pages behind a login, addresses that nothing links to, and content injected long after load can be missing from the report. Read a clean report as “nothing measurable is broken”, not as a certificate. #### Still have questions? Send us a message and we'll respond within 24 hours. - [Contact support](https://sitescan.top/contact/) ### Get in touch - Page: Contact - URL: https://sitescan.top/contact/ - Description: Questions about a report, an invoice or a feature? Send a message and the SiteScan.top team answers within one working day. Questions, feedback, or enterprise inquiries — send us a message and we'll respond within 24 hours. #### Contact - **Email** — support@sitescan.top - **Response time** — Within 24 hours, Mon–Fri - **Location** — Remote-first · Worldwide - [Help center](https://sitescan.top/help/) - [Status](https://sitescan.top/status/) ### SiteScan.top API - Page: API documentation - URL: https://sitescan.top/api-docs/ - Description: Start website scans and read SEO, performance and security reports from your own code. Keys from the account panel, paid per page in tokens. Start scans and read reports from your own code: a CI check before a release, a dashboard across client sites, an alert when a score drops. The API runs the same scanner as the site and is paid from the same token balance. Base URL: https://sitescan.top/api/v1 #### Quick start - Sign in, open the account panel and go to the API tab. Create a key and copy it — it is shown once. - Start a scan with POST /scans and the domain. The answer is 202 with the scan's id. - Poll GET /scans/{id} every few seconds until status is done or failed. Add ?report=1 to get the full report with the last answer. #### Authentication Every request except /ping carries a key, in either header: Authorization: Bearer or X-API-Key: . Keys start with ssk_. Only a hash of the key is stored, so a lost key cannot be shown again — revoke it and create a new one. An account can hold 5 keys. The key is the credential: keep it on a server or in CI secrets, never in a public web page. #### Tokens and pricing A scan costs one token per page the crawl actually read — the same price as a check from the account panel. The tokens are taken when the scan finishes. A scan that fails, times out or is blocked by the site costs nothing. Reading reports, the scan list and the account costs nothing. A scan needs at least one token, and never reads more pages than the balance pays for. Tokens are bought on the Pricing page. #### Limits 60 requests a minute per key. Every answer carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset; a 429 also carries Retry-After. 3 scans running at once per account. A second scan of a domain that is already being scanned answers with the running one instead of starting another. pages is 1 to max_pages (GET /account says how many this server allows), 5 when it is left out. #### Endpoints ##### GET /ping Whether the API is up. Answers 503 when the account store is unavailable. Needs no key — this is what the status page calls. ``` curl https://sitescan.top/api/v1/ping ``` ##### GET /account The account behind the key: balance in tokens, and the limits that apply to it. ``` curl https://sitescan.top/api/v1/account \ -H "Authorization: Bearer $SITESCAN_KEY" ``` ##### POST /scans Start a scan. Answers 202 while the crawl runs, or 200 when it finished within the request. ``` curl -X POST https://sitescan.top/api/v1/scans \ -H "Authorization: Bearer $SITESCAN_KEY" \ -H "Content-Type: application/json" \ -d '{"domain": "example.com", "pages": 5}' ``` ##### GET /scans/{id} One scan. 202 while it runs (with progress), 200 once it is done or failed. The poll is also what moves a stalled crawl along. ``` curl "https://sitescan.top/api/v1/scans/scn_4f1c9a2b7d3e8f60?report=1" \ -H "Authorization: Bearer $SITESCAN_KEY" ``` ##### GET /scans The 50 latest scans this account started through the API, newest first. ``` curl https://sitescan.top/api/v1/scans \ -H "Authorization: Bearer $SITESCAN_KEY" ``` ##### GET /reports/{domain} The latest stored report for a domain, whoever started it. Free. ``` curl https://sitescan.top/api/v1/reports/example.com \ -H "Authorization: Bearer $SITESCAN_KEY" ``` #### Scan status - **running** — The crawl is in the queue or under way. progress.stage is queued, crawl, audit or score. - **done** — The report is stored. score, pages_read and tokens_charged are filled in. - **failed** — No report — error says why (for example timeout or blocked). Nothing was charged. #### Errors Errors share one shape: {"error": {"code": "…", "message": "…"}}. Branch on code; the message is for people. - **key_required (HTTP 401)** — No key in the request. - **key_invalid (HTTP 401)** — The key is wrong or has been revoked. - **insufficient_tokens (HTTP 402)** — The balance is empty — top up in the account panel. - **unknown_scan (HTTP 404)** — No scan with this id on this account. - **unknown_report (HTTP 404)** — No stored report for this domain yet. - **unknown_endpoint (HTTP 404)** — No such endpoint. - **method_not_allowed (HTTP 405)** — The endpoint exists, but not with this method. - **invalid_domain (HTTP 422)** — domain is not a domain name. - **invalid_pages (HTTP 422)** — pages is out of range. - **rate_limited (HTTP 429)** — Too many requests this minute — wait for Retry-After. - **too_many_scans (HTTP 429)** — Three scans are already running on this account. - **store_unavailable (HTTP 503)** — A problem on our side; try again later. #### Examples ##### curl + jq ``` export SITESCAN_KEY="ssk_…" ID=$(curl -s -X POST https://sitescan.top/api/v1/scans \ -H "Authorization: Bearer $SITESCAN_KEY" \ -H "Content-Type: application/json" \ -d '{"domain": "example.com"}' | jq -r .scan.id) while :; do SCAN=$(curl -s https://sitescan.top/api/v1/scans/$ID -H "Authorization: Bearer $SITESCAN_KEY") STATUS=$(echo "$SCAN" | jq -r .scan.status) [ "$STATUS" != "running" ] && break sleep 5 done echo "$SCAN" | jq .scan ``` ##### JavaScript ``` const KEY = process.env.SITESCAN_KEY; const api = (path, init = {}) => fetch("https://sitescan.top/api/v1" + path, { ...init, headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json" }, }).then((r) => r.json()); let { scan } = await api("/scans", { method: "POST", body: JSON.stringify({ domain: "example.com", pages: 5 }) }); while (scan.status === "running") { await new Promise((done) => setTimeout(done, 5000)); ({ scan } = await api(`/scans/${scan.id}`)); } console.log(scan.status, scan.score, scan.report_url); ``` ##### Python ``` import os, time, requests API = "https://sitescan.top/api/v1" HEADERS = {"Authorization": f"Bearer {os.environ['SITESCAN_KEY']}"} scan = requests.post(f"{API}/scans", json={"domain": "example.com", "pages": 5}, headers=HEADERS).json()["scan"] while scan["status"] == "running": time.sleep(5) scan = requests.get(f"{API}/scans/{scan['id']}", headers=HEADERS).json()["scan"] print(scan["status"], scan["score"], scan["report_url"]) ``` ### System status - Page: Status - URL: https://sitescan.top/status/ - Description: Live availability of the SiteScan.top crawler, form testing, report rendering, PDF export, dashboard and API, plus the recent incident history. Real-time and historical uptime across all SiteScan.top services. All systems operational #### Services - **Scan engine** — Operational · 99.99% uptime - **AI form testing** — Operational · 99.98% uptime - **Report generation** — Operational · 100.00% uptime - **PDF export** — Operational · 99.95% uptime - **Dashboard** — Operational · 99.99% uptime #### Incident history - **2026-08-28 — API rate limiting degraded** — Monitoring: We are investigating elevated API latency for a subset of requests. Mitigation is in place and we are monitoring recovery. - **2026-08-15 — Scheduled maintenance completed** — Resolved: Scan engine infrastructure upgrade completed. All services operating normally. - **2026-07-30 — Report generation delay** — Resolved: A temporary queue backlog caused delayed PDF reports. The backlog has cleared and generation times are back to normal. ### Every page on SiteScan.top - Page: Sitemap - URL: https://sitescan.top/sitemap/ - Description: The complete index of SiteScan.top: all pages and articles in English, Russian, Polish and German, plus the machine-readable sitemap.xml and llms.txt. A complete index of the site, in every language it is published in. 14 pages and 40 articles, published in 4 languages — 216 addresses in total. - [sitemap.xml](https://sitescan.top/sitemap.xml) - [robots.txt](https://sitescan.top/robots.txt) - [llms.txt](https://sitescan.top/llms.txt) - [llms-full.txt](https://sitescan.top/llms-full.txt) The full directory is at https://sitescan.top/sitemap/ and in sitemap.xml. ### Legal overview - Page: Legal overview - URL: https://sitescan.top/legal/ - Description: One page pointing at the three documents that govern SiteScan.top: the privacy policy, the terms of service and the diagnostic disclaimer. SiteScan.top is a diagnostic tool, not a party to your website's operations. These documents explain what we collect, how the service may be used, and the limits of our analysis. We keep our legal documents short, plain, and structured so you can understand them quickly. Each document below opens in a reader-friendly view with an executive summary at the top. Last updated: October 19, 2026 #### Legal - **Privacy policy** — How we collect, use, and protect your data. - **Terms of service** — The rules and expectations for using SiteScan.top. - **Disclaimer** — Limitations of our diagnostic reports and recommendations. - [Privacy policy](https://sitescan.top/privacy-policy/) - [Terms of service](https://sitescan.top/terms-of-service/) - [Disclaimer](https://sitescan.top/disclaimer/) #### Questions? If anything in these documents is unclear, or you need a signed agreement for enterprise procurement, contact us at support@sitescan.top ### Privacy policy - Page: Privacy policy - URL: https://sitescan.top/privacy-policy/ - Description: What SiteScan.top collects when you scan a site, how long reports are kept, who processes them, and how to have your data removed. We only access publicly available pages on your site, store audit results encrypted at rest, and never sell your data. You can delete your audit history at any time. Last updated: October 19, 2026 #### Executive summary ##### 1. Information we collect When you run an audit, SiteScan.top accesses only the publicly available pages of the target website — the same pages any visitor can reach. We do not require or store credentials for the scanned site. To provide the service, we collect: the URL you submit, the pages and resources our crawler fetches, the diagnostic results generated, and basic account information (email address) if you create an account. ##### 2. How we use information Audit data is used to generate your reports and to improve the accuracy of our analyzers. Aggregated, non-identifying statistics (such as the number of sites scanned) may be displayed publicly in our community feed. We do not use the content of your scanned pages to train external models, and we do not sell or rent your data to third parties. ##### 3. Data storage and security Audit results are encrypted at rest. Access to production data is restricted to authorized personnel and is logged. We retain audit results for the lifetime of your account unless you delete them. You can delete individual audits or your entire audit history at any time from your dashboard. Deletion is permanent and cannot be undone. ##### 4. Third-party services We rely on infrastructure providers for compute, storage, and email delivery. These providers process data on our behalf under written agreements and are bound to confidentiality obligations. ##### 5. Cookies and consent The site sets nothing beyond what it needs to work until you have answered the consent banner. Strictly necessary storage covers your sign-in session, your language and the record of that answer itself; it stays on your device and is never shared. Analytics — Google Analytics and Yandex.Metrika — is loaded only after you accept it, and the cookies it sets are removed again if you refuse or withdraw. You can change your answer at any time through “Cookie settings” in the footer. ##### 6. Your rights You may request access to, correction of, or deletion of your personal data. Where applicable under GDPR, CCPA, or similar laws, you also have the right to data portability and to object to certain processing. To exercise any right, email support@sitescan.top and include the email address associated with your account. ##### 7. Changes to this policy We will update this policy as our service evolves. Material changes will be announced in advance. The "Last updated" date above reflects the most recent revision. #### Legal - [Terms of service](https://sitescan.top/terms-of-service/) - [Disclaimer](https://sitescan.top/disclaimer/) ### Terms of service - Page: Terms of service - URL: https://sitescan.top/terms-of-service/ - Description: The rules for using SiteScan.top: acceptable use of the scanner, how tokens and reports work, availability, termination and governing law. By using SiteScan.top you agree to scan only sites you own or have permission to test, to use tokens and API keys in good faith, and to accept that reports are informational — not legal or compliance guarantees. Last updated: October 19, 2026 #### Executive summary ##### 1. Acceptance of terms By running a scan, creating an account, purchasing tokens or calling the API, you agree to these terms. If you are using SiteScan.top on behalf of an organization, you represent that you have authority to bind that organization. ##### 2. Acceptable use You may only scan websites that you own, operate, or have explicit permission to test. You may not use SiteScan.top to attack, overload, or disrupt any service, or to access areas of a site not intended for public access. Automated, high-volume scanning intended to degrade the service for others is prohibited. We may suspend accounts that abuse the service. ##### 3. Tokens and billing Tokens are purchased in packs and kept on the account balance. A check from the account — by hand, on a schedule or through the API — spends one token per page the scanner actually read, taken when the check finishes; a check that ends without a report spends nothing. A scan from the home page is free. Tokens do not expire. Refunds are available within 7 days of purchase if none of the pack's tokens have been used. Prices, packs and the token cost of a check may change. Changes do not affect tokens already purchased. API keys are personal to the account: you are responsible for the tokens spent with them and for revoking a key that has leaked. ##### 4. Reports and intellectual property You own the audit reports generated for your scanned sites and may use them internally or share them as you see fit. SiteScan.top retains ownership of the underlying analyzer logic, algorithms, and service software. ##### 5. Service availability We strive for high availability but do not guarantee uninterrupted service. Maintenance windows and incidents are published on our status page. We are not liable for indirect or consequential damages arising from service interruptions. ##### 6. Termination You may close your account at any time. We may suspend or terminate access for violations of these terms. Upon termination, unused tokens remain available for a grace period of 30 days before the account is fully removed. ##### 7. Governing law These terms are governed by the laws of the jurisdiction in which SiteScan.top operates, without regard to conflict-of-law principles. Disputes will be resolved in the courts of that jurisdiction. #### Legal - [Privacy policy](https://sitescan.top/privacy-policy/) - [Disclaimer](https://sitescan.top/disclaimer/) ### Disclaimer - Page: Disclaimer - URL: https://sitescan.top/disclaimer/ - Description: SiteScan.top reports are diagnostic, not a certification: what the findings mean, the limits of automated testing, and where responsibility lies. SiteScan.top reports are informational diagnostics, not legal, accessibility, or security certifications. Always validate critical findings with a qualified professional before acting. Last updated: October 19, 2026 #### Executive summary ##### 1. Informational nature of reports The reports generated by SiteScan.top are provided for informational and diagnostic purposes only. They reflect the state of the scanned website at the moment the audit ran and may not represent the current state of the site. ##### 2. No legal or compliance certification An accessibility score, security check, or SEO analysis from SiteScan.top does not constitute legal compliance, certification, or a guarantee of conformance with WCAG, GDPR, CCPA, or any other standard or regulation. For formal compliance assessments, consult a qualified legal professional or an accredited auditor. ##### 3. No warranty of accuracy While we work to make our analyzers accurate and up to date, we cannot guarantee that every finding is correct or complete. Some issues may be false positives, and some real issues may not be detected. You are responsible for verifying findings before acting on them. ##### 4. Limitation of liability To the maximum extent permitted by law, SiteScan.top is not liable for any damages — direct, indirect, incidental, or consequential — arising from the use of, or reliance on, our reports or service. ##### 5. Third-party content Scan results may reference third-party scripts, resources, or services embedded in the scanned site. SiteScan.top does not control and is not responsible for the behavior or content of those third parties. ##### 6. Changes to this disclaimer We may revise this disclaimer as our service and analyzers evolve. The "Last updated" date above reflects the most recent revision. #### Legal - [Privacy policy](https://sitescan.top/privacy-policy/) - [Terms of service](https://sitescan.top/terms-of-service/) ## Articles ### Website check online: what one minute of scanning reveals - URL: https://sitescan.top/blog/website-check-online/ - Category: Infrastructure - Published: 15 October 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 7 min > An online website check in about a minute: which areas it covers, what the report looks like, how to read the first screen and when the check is worth running. An online website check is the cheapest way to find out what state a site is in right now: no server access, no tracking snippet to install, no contractor to brief. You type an address and about a minute later you see what a visitor, a search crawler and a browser see — which pages answer with an error, when the certificate runs out, what is missing from the headers and the meta tags. Here is what that minute actually covers, what the result looks like, and when it is worth running. #### What happens while you wait The scanner starts from the address you entered. The home page is opened in a real browser, so JavaScript gets to run and a bot-check page in front of the site gets to finish. Then the crawler follows internal links and the sitemap and reads a few more pages. A free SiteScan check reads five pages by default and ten at most — enough to cover the templates (home, category, product, article, contact), and a mistake in a template repeats on every page built from it. Alongside the pages run the checks that belong to the domain rather than to any single page: certificate, domain registration, DNS, robots.txt, sitemap.xml, redirects and response headers. The [help centre](/help/) describes the crawl in detail. #### What gets checked List the areas and you have most of what tends to break on a live site: - **Links and server responses.** Broken internal links, pages answering 4xx or 5xx, redirect chains, and soft 404s — a missing address that answers 200 OK. See the article on [broken links](/blog/broken-links/). - **SEO groundwork.** Title, description, H1, canonical, hreflang, structured data, robots.txt and the sitemap. `noindex` gets its own treatment: deliberate on the cart and the account pages, a mistake on a product page. - **Speed.** HTML and image weight, compression, static-file caching, HTTP/2, slow server responses — plus Core Web Vitals for the home page from PageSpeed Insights, where [LCP](/help/lcp/) under 2.5 s, CLS under 0.1 and INP under 200 ms count as good. - **Security.** TLS certificate expiry and chain, the http-to-https redirect, HSTS, CSP and the other headers, and files that should never be public: `.env`, `.git`, database dumps. - **Console and markup.** JavaScript errors logged while the browser had the page open, and HTML validity errors. - **Accessibility and mobile.** Alt text, form labels, tap target sizes, and whether the menu works from a keyboard on a phone-sized screen. - **Mail and privacy.** MX, SPF, DMARC, trackers, the cookie consent layer and links to the privacy policy. The full list of analysers is on the [product page](/product/). #### What the result looks like The report opens with an overall score from 0 to 100 and a score per category: 90 and up is excellent, 70–89 good, below 70 needs work. The overall figure is the average of the measured categories, so one failing area cannot hide behind eight healthy ones. Underneath sits a short block for the site owner — the three most dangerous problems, how many pages each touches and what fixing it gives you. Then come the quick wins, every finding with its severity (critical, high, medium, low), the site-level checks, and a table of pages with everything the crawler read on them. The same problem on nine pages is one item with nine addresses, not nine rows. How to read all this and decide what to fix first is the subject of [website analysis online](/blog/website-analysis-online/). The report has a permanent address, so you can send it to a colleague, print it or save it as a PDF. Finished reports also appear in the public list of [recent scans](/scans/). #### When to run it A single check is a snapshot, and snapshots are most useful at particular moments: 1. **Before and after a release.** The first shows what you are shipping on top of; the second whether the deploy broke anything. 2. **After a migration.** New hosting, a new CMS, a new domain or the move to HTTPS — the classic sources of lost redirects and a forgotten `Disallow: /`. 3. **When something feels off.** Traffic dropped, mail lands in spam, the browser complains about the certificate — a one-minute check narrows the list of suspects. 4. **Once a month as hygiene**, for a site that changes slowly. Certificates and domains expire quietly; see [expiry dates](/blog/expiry-dates/). #### What an online check will not do An automated scanner sees what can be measured from the outside. It will not tell you whether your copy persuades or whether someone with a screen reader can finish an order — a good share of accessibility barriers still needs a person. Pages behind a login and addresses nothing links to stay out of the report. A clean report means "nothing measurable is broken", not "the site is perfect". If you need a repeatable process with a plan, tickets and re-checks, that is a [website audit](/blog/website-audit-online/), not a one-off measurement. #### How to check a site with SiteScan 1. Open the [home page](/) and paste the address, with or without `https://`. 2. Wait about a minute. If every slot is busy, the scan starts on its own from the queue. 3. Read the owner summary and the quick wins first, then open the categories with the lowest scores. 4. Fix, deploy and press **Rescan**: a saved report is reused for fifteen minutes, and the button forces a fresh crawl. No sign-up is needed for the free check. For more pages per scan or the deeper audit types, see [pricing](/pricing/). ### Website analysis online: how to read the report and what to fix - URL: https://sitescan.top/blog/website-analysis-online/ - Category: SEO - Published: 14 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 6 min > Website analysis online starts after the scan: how to read scores, severities and categories, set priorities and turn a report into a fix list you will finish. Website analysis online does not start when you press the scan button. It starts when the report is already open and you are looking at forty findings, a dozen categories and an overall score of 68. The scanner has collected the facts; turning them into a decision — what to fix today, what next month, what to leave alone — is still your job. (What goes into the report in the first place is covered in [website check online](/blog/website-check-online/).) Here is how to read scores, severities and categories, and how to turn a report into a fix list in half an hour. #### A score is a diagnosis, not a grade Every measured category starts at 100 and loses points for each issue found, weighted by severity and by how many of the crawled pages it appears on. The overall score is the average of the measured categories. Three practical consequences follow: - **Compare the site with itself, not with a competitor.** The score measures how well a site meets what the checks expect. Your 82 against their 85 says nothing about who ranks better. - **"Not measured" is not zero.** If the pages have no forms, the Forms category gets no invented score and does not pull the average either way. - **The bands are coarse, and that is fine.** 90+ excellent, 70–89 good, under 70 needs work. If the report shows a change since the previous scan, read that first: the trend matters more than the absolute number. The method is described in the [help centre](/help/). #### Severity: broken now versus broken later Every finding carries one of four levels: - **Critical and high** — something already fails for visitors: a dead link, a form with no `action`, a page answering 500, a certificate about to expire. These are this week's tasks. - **Medium** — missing metadata and markup that will cost you later: no canonical, duplicate titles, no [Content-Security-Policy](/help/content-security-policy/). - **Low** — notes and observations. Some are deliberate choices (no IPv6, no DNSSEC), and closing them just to see a green tick is optional. Read severity together with reach. "Pages: 9 of 10" on a medium template issue often matters more than a high issue on one forgotten page. And "whole site" marks a domain-level setting — fixed once in the server or DNS configuration, not page by page. #### Categories tell you who gets the ticket Categories are not just a breakdown of the score; they route the work: - **SEO, HTML, links** — the content or SEO person plus the CMS templates. See [meta tags](/blog/meta-tags/) and [canonical URLs](/blog/canonical-urls/). - **Performance and images** — front end plus server or CDN settings: compression, caching, WebP and AVIF. - **Security and infrastructure** — the sysadmin or DevOps: headers, TLS, redirects, DNS. Anything marked "whole site" goes here. - **Console, forms, mobile, accessibility** — the front-end developer. JavaScript errors often break forms and analytics at once; see [console errors](/blog/console-errors/). The SEO diagnostics block deliberately separates findings that look alike but mean different things: `noindex` on the cart or the search page is marked intentional and not counted as an error, while `noindex` on a product page is flagged as a mistake. #### Setting priorities A simple scheme that works almost every time: 1. **Everything critical and high** — immediately, whatever the effort. Visitors are already running into it. 2. **Medium issues with wide reach** — next. One template edit closes the finding on every page. 3. **Quick wins** — in parallel. This separate list is ranked by payoff per minute of work; each item carries a time estimate and the pages to change. An hour on the top of it usually moves the score more than a day elsewhere. 4. **The rest** — into the backlog with a review date. Also check whether a finding is wrong for your case. Every issue carries the measured values it was raised from: if the numbers are right but the conclusion does not apply to your site, record an exception instead of changing anything. #### Common mistakes when reading a report - **Chasing 100.** The last few points usually cost more than they return. The target is zero critical and high findings and a steady trend. - **Fixing page by page.** The report groups findings by problem, not by address — fix them the same way: template, config, plugin. - **Ignoring the site checks.** Domain expiry, SPF and [DMARC](/help/dmarc/), the redirect to HTTPS are invisible on the pages and break everything at once. #### Analysing a site with SiteScan 1. Run a check from the [home page](/) — free, no sign-up. 2. Read "In short, for the site owner": the three most dangerous problems, their reach and a ready fix for your platform. 3. Open Quick Wins and the lowest-scoring category. 4. Press **Copy fix brief**: the critical, high and medium findings are copied as a Markdown task list sorted by severity and reach, with an acceptance criterion — a task is done when a fresh scan no longer reports it. 5. After the fixes, rescan. "What changed since the last scan" shows what is new, what is fixed and what is still there. When analysis turns into regular work with a plan and tickets, read about the [website audit online](/blog/website-audit-online/). ### Website audit online: a step-by-step plan from scan to re-check - URL: https://sitescan.top/blog/website-audit-online/ - Category: Infrastructure - Published: 14 October 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 6 min > A website audit online is a process, not a score: set the scope, capture a baseline, triage findings, turn them into tickets and prove the fixes with a rescan. A website audit online often gets confused with a check: run the scanner, get a score, call it an audit. In practice a check is a measurement and an audit is a process. It has a goal, a scope, tasks with owners, and a second measurement that proves the tasks are done. Without those last steps the report stays a nice PDF in somebody's inbox. Below is a plan that turns an online scan into an audit with an outcome. #### Audit versus one-off check A [website check online](/blog/website-check-online/) answers "what is wrong right now?". An audit answers three questions: what is wrong, which of it we fix and in what order, and how we will know it is fixed. So the outputs differ: a check produces a report; an audit produces closed tasks and a second report in which they no longer appear. That is why an audit is always at least two scans — before and after. #### Step 1. Set the goal and the scope Before running anything, answer three questions in writing: 1. **Why.** A release, accepting a site from a contractor, a traffic drop, a security requirement, a move to a new domain. 2. **What is in.** Which domains and subdomains, which language versions, which templates are critical — product page, checkout, article. 3. **Who decides.** Who signs off and who fixes: developer, sysadmin, content editor, agency. The goal decides which categories you read first. Before a migration that is redirects, [robots.txt](/help/robots/) and canonicals; when mail lands in spam, SPF and DMARC; when conversion drops, forms, console errors and speed. #### Step 2. Capture the baseline Run a scan and keep the report link — that is your starting point. Note the overall score, the category scores, the number of critical and high findings, and the date. If the site has several languages or key sections, scan them separately: the free check reads up to ten pages, and they should be the pages you care about. Do not skip what only shows at domain level: certificate and [domain registration](/help/domain-expiry/) expiry, the http-to-https redirect, security headers, mail records. Manual audits miss these most often, because a browser never shows them. #### Step 3. Triage the findings This is where the report becomes a decision. Reading scores, severities and reach is covered in [website analysis online](/blog/website-analysis-online/). In short: - critical and high go into work without debate; - medium go in if they affect a template or the whole site; - low are the owner's call — some are deliberate choices; - disputed ones are checked against the measured values and recorded as an exception with a reason. The output is a list in which every line has a decision: fix, won't fix because…, or verify by hand. #### Step 4. Turn findings into tickets A good audit ticket has four fields: what is wrong, where (addresses or "whole site"), how to fix it, and how to accept it. In SiteScan you do not write that by hand: **Copy fix brief** assembles the critical, high and medium findings into a Markdown list sorted by severity and reach, with page addresses and an acceptance criterion. Paste it into a tracker, an email or a chat — or hand it to a developer's AI assistant as the task description. Group tickets by owner, not by page: one edit to a CMS template or an nginx config closes a finding across the site. For the technical layer — TLS, headers, caching, DNS — use the checklist in [technical website audit](/blog/technical-website-audit/). #### Step 5. Re-check and record the result An audit ticket is closed when a fresh scan no longer reports it — not before. After the deploy, press **Rescan** (a saved report is reused for fifteen minutes; the button forces a new crawl). "What changed since the last scan" sorts findings into three groups: - **New** — appeared after your changes; these are regressions to look at right away; - **Fixed** — there last time, gone now; - **Still there** — found both times. The acceptance rule: everything planned is under Fixed, and no new critical or high finding has appeared in exchange. #### Step 6. Make it recurring A site changes with every release, certificates and domains expire on schedule, plugins update themselves. **Watch this site** in the report header adds the domain to your account's scheduled checks — from hourly to monthly — and notifications by email, Telegram or SMS can tell you about critical and high findings, a score drop, or a check that could not run. More in [automated website check](/blog/automated-website-check/). #### Starting an audit with SiteScan 1. Write down the goal and scope — five lines in any document. 2. Run the baseline scan from the [home page](/) and keep the report link. 3. Triage, copy the fix brief and split the tasks by owner. 4. After the fixes, rescan and compare before and after. 5. For larger sites and deeper audit types, see [pricing](/pricing/) — credits do not expire. If the audit has to cover everything at once — SEO, speed, security, accessibility, mail and legal pages — see [comprehensive website audit](/blog/comprehensive-website-audit/). ### SEO website analysis: titles, canonicals, hreflang and indexing - URL: https://sitescan.top/blog/seo-website-analysis/ - Category: SEO - Published: 13 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 6 min > An SEO website analysis of the on-page and indexing signals: titles and descriptions, headings, canonical, hreflang, structured data, robots.txt and sitemap. Most SEO advice is about content and links. But before a search engine can weigh either, it has to fetch the page, understand what it is about and decide which address to index. An **SEO website analysis** of that layer — on-page markup and indexing signals — is the cheapest part of SEO to get right, and the part where one wrong line can cancel months of work. #### What a crawler actually reads A search robot does not see your design. It sees a status code, a `` full of metadata, a heading outline and a set of links. In practice the signals that decide indexing fit on one screen: - the HTTP status and any redirects on the way to the page; - `` and `<meta name="description">`; - the H1 and the heading hierarchy below it; - `<link rel="canonical">` and `<meta name="robots">`; - `hreflang` alternates for other languages; - structured data and Open Graph; - the site-wide files: `robots.txt` and `sitemap.xml`. A useful analysis checks each of these on every page and, more importantly, checks that they agree with each other. #### Titles, descriptions and headings The title is still the strongest on-page signal and the headline of your search snippet. Keep it unique per page, put the main phrase near the start and stay within roughly 50–60 characters so it is not cut off. The description does not affect ranking directly, but it is what people read before clicking: 120–160 characters that answer "why this page". Typical mistakes are boring and widespread: the same title on every product page, a description copied from the home page, an empty H1 or three H1s produced by a theme. Duplicates are the worst of them — when ten pages share one title, the search engine has to guess which one matters. More on the details in [the meta tags guide](/blog/meta-tags/). #### Canonical: which copy to index Almost every site serves the same content at several addresses: with and without a trailing slash, with `?utm_source=`, sorted and filtered. The canonical tag names the version you want indexed. It only works if it points to a page that answers **200**, on the same host, over HTTPS, and is not itself redirected or noindexed. A canonical that points into another language or to a redirect is worse than none. The full set of rules is in [our article on canonical URLs](/blog/canonical-urls/). #### hreflang and language versions Multilingual sites add another layer: every language version should list all its alternates, including itself, and every link must be reciprocal. One-way hreflang, a code like `en-UK` instead of `en-GB`, or an alternate that leads to a redirect — and search engines quietly ignore the whole cluster. Add `x-default` for visitors whose language you do not cover. See [the hreflang breakdown](/blog/hreflang/) for working examples. #### Structured data and Open Graph Schema.org markup in JSON-LD does not move rankings by itself, but it makes the page eligible for rich results and helps both search engines and AI assistants understand what the page is: an article, a product, an organisation. Open Graph controls how the link looks when shared. Both must match the visible content — a product price in markup that differs from the page is a classic way to lose rich results. Details are in [the structured data guide](/blog/structured-data/). #### robots.txt, sitemap and noindex These three decide what gets crawled and indexed at all. A `Disallow: /` left over from staging hides the whole site; see [the robots.txt reference](/help/robots/). The sitemap should list only canonical addresses that answer 200 — [here is what the scan checks in it](/help/sitemap/). And `noindex` needs a sanity check: on a cart or account page it is deliberate, on a category or article page it is an expensive mistake. [Sitemap and robots.txt together](/blog/sitemap-robots/) explains how the pieces interact. #### Running an SEO website analysis with SiteScan 1. Enter your domain on [the home page](/) — no sign-up needed. A free scan reads up to ten pages: the home page and the internal links found on it. 2. Open the **SEO diagnostics** block. It keeps apart findings that look alike but mean different things: intentional noindex (cart, search, account) versus mistaken noindex on content pages, missing canonicals, wrong ones and canonicals absent from the sitemap. For multilingual sites it lists hreflang without a link back, missing `x-default`, mismatched codes and duplicate titles, descriptions and H1s. 3. Check the **Pages** table: title, description, canonical, meta robots, hreflang, Open Graph and headings for each crawled page. 4. Look at **Site checks → Indexing** for robots.txt and the sitemap. 5. Fix, then press **Rescan** and compare. If you need a quick routine rather than a deep dive, use [the 15-minute SEO check](/blog/seo-check/); the server side of indexing — redirects, TLS, headers — is covered in [the technical website audit](/blog/technical-website-audit/). ### Free SEO audit: what it shows, what it misses, how to use it - URL: https://sitescan.top/blog/free-seo-audit/ - Category: SEO - Published: 13 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 5 min > What a free SEO audit can and cannot tell you, where free ends and paid begins, and how to get the most out of a free website scan in one evening. "Free SEO audit" is one of the most overused phrases in marketing. Sometimes it means a useful automated report; often it is a lead form that ends in a sales call. Both have their place, but you should know what you are getting. This article is about the honest version: what a **free SEO audit** of a website can realistically find, what it never will, and how to squeeze the most out of one. #### What a free audit is good at An automated scan is excellent at anything that can be measured from the outside and expressed as a rule. On a typical site that already covers a large share of the technical SEO problems that actually cost traffic: - missing, empty or duplicated titles, descriptions and H1s; - canonicals that point to redirects, errors, other hosts or other languages; - `noindex` on pages that should rank; - a `robots.txt` that blocks too much, a sitemap that is missing, broken or full of redirects; - a non-existent address that answers 200 instead of 404 — a [soft 404](/blog/soft-404/); - broken internal links, redirect chains, plain-HTTP access without a redirect to HTTPS. None of these needs a consultant to discover. They need someone to look, and a machine looks faster. #### What it cannot tell you A free report is not an SEO strategy. It will not: - research keywords or tell you which queries are worth targeting; - judge whether your copy answers the searcher's question better than competitors; - analyse backlinks, positions or traffic — that data lives in Google Search Console, Yandex Webmaster and paid link tools; - see pages behind a login or pages nothing links to; - decide trade-offs, such as whether thin filter pages should be merged or closed. Read a clean report as "nothing measurable is broken", not as proof that the site will rank. #### Free versus paid: where the line really is The line is rarely about which checks run; it is about **scale and depth**. A free scan on SiteScan reads a handful of pages — five by default, ten at most — starting from the address you enter. That is enough to catch template-level problems, because a bug in the product template repeats on every product. Larger crawls, AI form testing and PDF export belong to the paid audit types, which run on credits that do not expire; the [pricing page](/pricing/) lists what each type includes. Paying makes sense when the site has thousands of pages with different templates, or when you need a document for a client. #### How to get the most from a free scan **Scan by template, not by site.** The crawl starts from the address you type, so run separate scans for the home page, a category, a product page and a blog article. Four free scans cover four templates. **Start from the top of the report.** The owner summary shows the three most dangerous problems; Quick Wins rank fixes by payoff per minute of work. Our guide on [interpreting the results](/blog/website-analysis-online/) explains scores and severities. **Check the evidence.** Each finding carries the values it was raised from — the actual title, the canonical target, the status code. Verify a couple by hand before filing tickets. **Hand it over.** The **Copy fix brief** button turns critical, high and medium findings into a task list for a developer, with an acceptance criterion: the next scan no longer reports them. **Rescan after the fix.** A report is reused for fifteen minutes; after deploying, press **Rescan** to force a fresh crawl. One caveat: reports appear in the public list of [recent scans](/scans/), so do not scan an address you would rather not see listed. #### Your free SEO audit in five steps 1. Enter the domain on [the home page](/) — no sign-up. 2. Open the SEO diagnostics and the indexing checks; the factors themselves are explained in [our SEO website analysis guide](/blog/seo-website-analysis/). 3. Repeat for each key template. 4. Copy the fix brief, fix, rescan. 5. If you outgrow ten pages, read about [what else you can analyse for free](/blog/free-website-analysis/) or turn the one-off check into a proper [website audit process](/blog/website-audit-online/). Questions about any finding are answered in the [help centre](/help/). ### Website error check: links, 404s, 5xx, JS errors and forms - URL: https://sitescan.top/blog/website-error-check/ - Category: Links - Published: 12 October 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 6 min > A practical website error check: how to find broken links, real and soft 404s, 5xx responses, JavaScript errors, dead forms, mixed content and broken images. Visitors rarely report errors. They hit a dead link, a form that silently does nothing or a page that renders half a layout — and leave. Search engines are less polite: they record the error and crawl you less. A regular **website error check** is how you find these before either group does. This article is a field guide to the seven kinds of errors that show up most often, where each hides and how to confirm it. #### 1. Broken links A link that leads to a 404 or 410 is the most common error on any site older than a year. Pages get renamed, products get removed, a menu item keeps pointing to last season's sale. Internal broken links are fully under your control and hurt twice: a dead end for the visitor and a wasted fetch for the crawler. External ones rot on their own schedule. The fix is to change the link, not to redirect forever: point the anchor at the final address. Our [broken links guide](/blog/broken-links/) covers the edge cases, and [this reference page](/help/links/) explains how the scanner follows internal links to see where they land. #### 2. 404 pages and soft 404s A real 404 is fine — it is the honest answer for a missing page. The error is when a missing page answers **200 OK** with "Not found" in the text. That is a [soft 404](/blog/soft-404/): monitors think the page is healthy, search engines index garbage. Test it in one line: curl -s -o /dev/null -w "%{http_code}\n" https://example.com/no-such-page-7c1/ Anything except 404 or 410 needs fixing. The scan runs exactly this test — see [how 404 handling is checked](/help/not-found/). #### 3. Server errors (5xx) A 500, 502 or 503 means the server failed, not the visitor. Sporadic 5xx are the hardest to catch: the page works when you open it and fails under load, on a cold cache or for a particular query string. Look for them in server logs and in any crawl that fetches many pages in a row. A page answering with an error is one of the few findings that is always critical: it is broken for everyone right now. #### 4. JavaScript console errors A thrown exception can stop the rest of a script from running: the menu does not open, the cart does not update, the analytics tag never fires. Visually the page may look perfect. Open DevTools → Console and reload; red lines are errors, uncaught exceptions are the worst. Common culprits are a third-party script that failed to load, a missing element the code expects and a 404 on a JS chunk after a deploy. The [console errors article](/blog/console-errors/) explains how to triage them. #### 5. Forms that do not work A contact or checkout form is where errors cost money directly. Typical failures: the form has no `action` or posts to a removed endpoint, validation rejects valid input (a phone number with a plus sign, a Polish letter in a name), the submit button does nothing because of a JS error, or the "thank you" page is a 404. Submit every form yourself after each release; [the form testing guide](/blog/form-testing/) lists what to try. #### 6. Mixed content and broken images On an HTTPS page, any resource loaded over `http://` is mixed content. Browsers block active mixed content (scripts, iframes) outright and flag passive content, so a single old image URL can cost you the padlock. Details are in [the mixed content article](/blog/mixed-content/). Broken images are the visual twin of broken links: an image URL that answers 404 shows an empty frame and a missing `alt` shows nothing at all. #### Checking a site for errors with SiteScan 1. Enter the address on [the home page](/). A free scan opens up to ten pages in a real browser, so it sees what a visitor sees, including JavaScript. 2. In the report, look at the **HTTP status** of each page in the Pages table and at **Site checks → Internal links**: every internal link found on the crawled pages is fetched, and the dead ones are listed with the page they were found on. 3. Check **404 handling** for soft 404s, the **Browser console** block for errors and exceptions logged on each page, and the images check for files that do not load. 4. Fix, then press **Rescan**. Signed in, the **Watch this site** button puts the domain on a schedule, and the next report shows what is new, what is fixed and what is still there. For problems that start with a symptom rather than an error code — "the site got slow", "emails go to spam" — continue with [website diagnostics](/blog/website-diagnostics/). ### Technical website audit: TLS, redirects, headers, DNS and mail - URL: https://sitescan.top/blog/technical-website-audit/ - Category: Infrastructure - Published: 11 October 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 6 min > A technical website audit checks the foundation: certificate, redirects, robots.txt and sitemap, security headers, caching, DNS, mail and exposed files. Design can be argued about and copy can be rewritten, but the technical layer either works or it does not. An expired certificate, a chain of four redirects, an `.env` file left in the web root or a missing DMARC record never show up in a mock-up or a sprint review — until the day the site stops opening, invoices land in spam and half the pages drop out of the index. A technical website audit is a check of exactly that foundation: everything that happens between the browser, the server and DNS before the first pixel is drawn. #### How it differs from an SEO or UX audit An SEO audit asks whether a search engine understands the page; a UX review asks whether a person can use it. A technical website audit asks whether either of them receives the right response at all: over HTTPS, with the right status code, without detours, with headers that shut down common attacks, from a domain that is not about to lapse. Most items are binary and can be checked from the outside without server access, which makes them easy to automate. The general method — scan, tickets, re-check — is covered in our guide to the [website audit online](/blog/website-audit-online/); this article walks through the technical layer block by block. #### 1. HTTPS and the certificate - **Expiry.** Alert at 30, 14 and 7 days. Auto-renewal fails more often than people think: DNS moved, port 80 closed, nginx never reloaded. The full story is in [two dates that take the whole site down](/blog/expiry-dates/); what the report shows is explained under [certificate expiry](/help/tls-expiry/). - **Protocol versions.** TLS 1.0 and 1.1 are withdrawn; the server should speak TLS 1.2 and 1.3. - **The full chain.** Without the intermediate certificate desktop Chrome often copes, while Android, `curl` and payment webhooks fail. From a terminal: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate -issuer #### 2. Addresses and redirects A site should have exactly one canonical origin. `http://` answers **301** to `https://` (see [HTTP to HTTPS redirect](/help/https-redirect/)), and the www or bare variant answers 301 to the main one. Every extra hop is another round trip before the first byte, so count the redirects to the entry page: zero or one is fine, three is a ticket. Check the opposite case too: an address that does not exist must return **404**, not 200 with "page not found" text. curl -sI http://example.com/ | head -3 curl -s -o /dev/null -w "%{http_code}" https://example.com/no-such-page-123 #### 3. robots.txt and sitemap.xml These are technical files even though they decide SEO outcomes. The classic outage is a `Disallow: /` carried over from staging with a release. Make sure [robots.txt](/help/robots/) does not block the home page, CSS or JavaScript and that it names the sitemap. The [sitemap.xml](/help/sitemap/) itself should be valid XML, list only canonical URLs that answer 200, and contain no addresses from staging or another domain. #### 4. Security headers and leaks The baseline is `Strict-Transport-Security`, `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, frame protection and `Referrer-Policy`; why each matters and how to roll out CSP without breaking the site is in our piece on [security headers](/blog/security-headers/). Equally important is what should not be on the server at all: - **files a deploy left behind** — `.env`, `.git/`, database dumps; bots look for them within hours ([exposed files](/help/exposed-files/)); - **directory listings** and published **source maps**; - **version banners** such as `Server: nginx/1.18.0` or `X-Powered-By: PHP/7.4`; - a **TRACE** method the server echoes back. #### 5. Delivery: compression, caching, protocol HTML and static files should go out compressed (gzip, ideally Brotli) over HTTP/2 or HTTP/3. Fingerprinted assets get `Cache-Control: public, max-age=31536000, immutable`; the HTML gets a short lifetime or `no-cache` plus an `ETag` so revisits cost a 304. A sensible server target is a first byte under 800 ms. #### 6. DNS, domain and mail At least two nameservers, transfer lock on, domain auto-renew on. For mail: a single SPF record within the ten-lookup limit, DKIM, and DMARC starting at `p=none` with a reporting address before moving to `quarantine`. CAA, DNSSEC and MTA-STS are optional but worthwhile. dig +short TXT example.com dig +short TXT _dmarc.example.com #### Running a technical audit with SiteScan 1. Start a [free scan](/) from the home page: enter the domain and the report arrives in a minute or two. 2. Open the blocks "TLS certificate", "Domain registration", "Addresses & redirects", "Indexing", "Security headers" and "DNS & email". Every row has a "what is this?" button that leads to the help reference. 3. Click "Copy fix brief": the critical, high and medium findings go to the clipboard as a developer task list, with affected addresses and acceptance criteria. 4. After the fixes, scan again. "What changed since the last scan" lists what was fixed, what is new and what is still there. 5. Do not keep expiry dates in your head: "Watch this site" puts the domain on scheduled checks, with notices by email, Telegram or SMS. ### SEO check in 15 minutes: a step-by-step checklist - URL: https://sitescan.top/blog/seo-check/ - Category: SEO - Published: 11 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 5 min > An SEO check you can finish in 15 minutes: indexing, robots.txt, canonicals, titles and descriptions, sitemap, speed, structured data and broken links. A full SEO audit takes days, yet most disasters are visible in a quarter of an hour. A section blocked from indexing, a canonical pointing at staging, the same title on a hundred pages, a sitemap full of 404s — none of these need deep expertise, only someone who looks in time. Below is an SEO check split by the minute: a timer, a scanner report, a browser and one terminal. The goal is not a perfect site but a short list of what to fix first. #### Minutes 0–2: start the scan Let the machine work while you read on. Enter the domain in the [free scan](/) form on the home page: the crawler walks the pages, checks the service files and asks Google PageSpeed for the home page's speed data. Meanwhile, open the site in a private window — everything you check by eye should match what the crawler sees. #### Minutes 2–4: is indexing open? The most expensive mistake is a site that asks search engines to leave. 1. Open `/robots.txt`. Is there a `Disallow: /` for `User-agent: *` or for Googlebot specifically? Does it name the sitemap? The help page on [robots.txt](/help/robots/) lists what else to look for. 2. Look at the "SEO diagnostics" block of the report. It separates **intentional noindex** (cart, account, search — fine) from **mistaken noindex**: a product, category or article hidden from search. The second kind is ticket number one. 3. Search for `site:example.com`. The count is rough, but if you expect a thousand pages and see twelve, the problem is not your content. #### Minutes 4–6: one address per page Open the source of a few key pages (`Ctrl+U`) and find `rel="canonical"`. Typical misses: it points to the http version, another host, a redirect or another language. The report groups these as "No canonical" and "Wrong canonical"; why it matters is covered in our guide to [canonical URLs](/blog/canonical-urls/). While you are there, confirm that `http://` and `www` reach the main address in a single 301. #### Minutes 6–8: titles, descriptions, H1 Scroll through the pages table in the report — it shows the title, description, headings and canonical of every page. Look for: - **duplicate titles and descriptions** — "Catalogue | Shop" on every category; - titles longer than 60–65 characters that get cut in results; - empty or missing descriptions, which leave the snippet to chance; - two H1s on a page, or none. How to write meta tags people actually click is in our piece on [titles and descriptions](/blog/meta-tags/). #### Minutes 8–10: the sitemap Open `/sitemap.xml`. A good [sitemap](/help/sitemap/) is valid XML with only canonical URLs that answer 200 — no staging, no sorting parameters. The report also flags canonical addresses missing from the sitemap: a page asks to be indexed at an address the sitemap never mentions. #### Minutes 10–12: speed and mobile Check the PageSpeed Insights block: mobile and desktop results and Core Web Vitals. Google's thresholds are [LCP](/help/lcp/) ≤ 2.5 s, CLS ≤ 0.1 and INP ≤ 200 ms. If real-user data (CrUX) is there, trust it over the lab run, which only simulates. Then look at the mobile layout: viewport, horizontal scrolling, tap targets — see [mobile usability](/blog/mobile-usability/). #### Minutes 12–14: markup and languages Paste a product or article URL into the Schema.org validator or Google's Rich Results Test: are `Product`, `Article`, `BreadcrumbList` and `Organization` present and error-free? More in our article on [structured data](/blog/structured-data/). On a multilingual site the report adds a "Language versions" block: hreflang reciprocity, x-default, language codes and canonicals that agree. #### Minute 14–15: broken links and the task list Last look: internal links, how many were checked and how many are broken. Every link to a 404 wastes link equity and leads crawlers into a dead end; how to find and fix them is in our guide to [broken links](/blog/broken-links/). Now write down the findings in order of impact: indexing, then canonicals and duplicates, sitemap, speed, markup. #### What next A 15-minute SEO check catches the emergencies; it does not replace working through the ranking factors. Once the fire is out, move on to a systematic [SEO website analysis](/blog/seo-website-analysis/). And instead of retyping the checklist, use "Copy fix brief" in the SiteScan report to hand the critical, high and medium findings to a developer — then rescan after the fixes to see what really went away. ### Free website analysis: what you can check for free, and the limits - URL: https://sitescan.top/blog/free-website-analysis/ - Category: SEO - Published: 10 October 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 5 min > Free website analysis covers more than you think: DevTools, webmaster panels, PageSpeed, the terminal and scanners. Where the limits are and when to pay. "Free" usually sounds like "superficial", yet a surprising amount of website analysis costs nothing at all. Browsers ship professional tools, search engines publish data about your own site, and a terminal answers in seconds what a consultant would bill an hour for. The catch is not the quality of free tools — it is that each one sees a different slice, and none of them watches the site for you. Here is what a free website analysis can cover, with which kinds of tools, and where paying starts to make sense. #### 1. The browser: DevTools and Lighthouse Every Chromium browser and Firefox has developer tools built in. In ten minutes on one page you can see: - **Console** — JavaScript errors and failed requests; why they matter is explained in our article on [console errors](/blog/console-errors/); - **Network** — status codes, redirects, response sizes, whether files are compressed and cached; - **Lighthouse** — a lab run of performance, accessibility, SEO and best practices. The limit: it is one page, on your machine, on your network. Ten templates mean ten manual runs. #### 2. Search engine panels Google Search Console and Yandex Webmaster are free and irreplaceable: only they show which pages are actually indexed, which queries bring impressions, and what the crawler stumbled over. The limits: you must prove you own the site, data arrives with a delay of days, and it describes the past — a broken `robots.txt` shows up there after the traffic has already dropped. #### 3. Speed: PageSpeed Insights and CrUX PageSpeed Insights combines a Lighthouse lab run with field data from the Chrome UX Report — what real visitors experienced over 28 days. The thresholds are LCP ≤ 2.5 s, CLS ≤ 0.1 and INP ≤ 200 ms (background in our guide to [Core Web Vitals](/blog/core-web-vitals/)). The limits: field data exists only for sites with enough traffic, and the tool analyses one URL at a time. #### 4. The command line Three commands cover a large share of the technical layer: curl -sI https://example.com/ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate dig +short TXT _dmarc.example.com Headers and redirects, the certificate's expiry date and mail authentication — in seconds. The limit: you need to know what to ask and how to read the answer. #### 5. Online scanners A scanner bundles the above: it walks several pages, reads service files, checks headers, DNS, certificate and links, and puts everything in one report with severities. That is the fastest way to get the whole picture — and SiteScan's [free scan](/) needs no sign-up. What it covers is listed on the [product page](/product/); browsing [recent public reports](/scans/) shows what a real result looks like before you run your own. If a row in the report is unclear, the [help centre](/help/) explains every check, for example how the [performance score](/help/performance-score/) is calculated. #### Where free ends Free analysis is a snapshot, and snapshots have predictable gaps: - **Coverage.** A free scan reads a limited number of pages. On a shop with 5,000 products, problems in a rare template may simply not be in the sample. - **Time.** A one-off check says nothing about tomorrow. A certificate that expires in 12 days looks fine today. - **Depth.** Testing forms by actually filling them in, or a full check of every link, takes more work than a quick pass. - **Access.** Anything behind a login, and sites behind aggressive bot protection, are out of reach for any external scanner. For SEO specifically, we cover the same boundary in [free SEO audit](/blog/free-seo-audit/). #### When it makes sense to pay Pay when the cost of a missed problem is higher than the cost of the check: a large catalogue, an agency reporting to clients, a site where forms are the business, or a team that needs to know about regressions before customers do. SiteScan sells credits rather than subscriptions; the audit types on the [pricing page](/pricing/) differ by the number of pages and add AI form testing, a full link check and PDF export. Regular checks with notifications are covered in [automated website checks](/blog/automated-website-check/). #### A free plan that works 1. Run a free scan and fix everything marked critical or high. 2. Connect Search Console and Yandex Webmaster — they cost nothing and show what no scanner can. 3. Check speed in PageSpeed Insights for your three most important templates. 4. Repeat the scan after each release and compare: the report shows what was fixed and what is new. ### Online website scanning: how a scanner reads your site - URL: https://sitescan.top/blog/website-scanning/ - Category: Infrastructure - Published: 9 October 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 6 min > What happens during online website scanning: how pages are picked and rendered, what robots.txt means, and why a report can differ from your browser. You paste an address, wait a minute and get a report. Between those two moments a scanner makes dozens of HTTP requests, opens a headless browser, reads several files nobody ever looks at and decides which of your pages are worth reading at all. Knowing how online website scanning works inside is not trivia: it explains most of the "but on my machine it looks fine" moments and tells you how far a report can be trusted. #### Step one: the entry page and the browser Every scan starts from a single address. The scanner requests it, follows the redirects to the final URL and records each hop — this is where a chain like `http → https → www → /en/` first shows up (see [redirect hops](/help/redirect-hops/)). The home page is then opened in a real headless Chromium. That matters for two reasons. First, modern sites build part of their content with JavaScript, and only a browser sees the result. Second, many hosts sit behind a CDN or a WAF that shows a "checking your browser" page to anything that does not run scripts. A browser lets that challenge finish. The same session also records console errors and failed requests, which a plain HTTP client never sees. #### Step two: choosing which pages to read A scanner is not a search engine. It does not try to read the whole site; it reads a sample. Candidates come from the links on the entry page and from the sitemap, and before anything is picked the list is cleaned up: - addresses are normalised, so `/page`, `/page/` and `/page?utm_source=x` are one page, not three; only query parameters that can name a page of their own (for example `page`, `category`, `product`) are kept; - URL traps are skipped: endless calendars, paths that repeat the same segment, absurdly long or deep addresses, redirect loops; - files that are not pages — images, PDFs, archives — are left out. From the cleaned pool a handful of pages is picked. The free scan reads a few pages, which is enough to catch problems that live in templates: if the product template lacks a canonical, every product page lacks it. A repeat check of a watched site reads the same pages again, so two reports are comparable. #### Step three: being a polite robot A scan should never look like an attack. SiteScan sends one recognisable User-Agent, so a site can allow or refuse it on purpose, keeps a pause between requests to the same host, retries after **429** and transient **5xx** while honouring `Retry-After`, and works within a fixed time budget. If a site answers too slowly, the scan stops at the limit and the report says which pages and checks were not reached, instead of silently pretending they were fine. When a protection layer answers instead of the site, the page is marked as **blocked**, not as an error of yours. The report's crawl section shows the User-Agent, the pace, retries and every 403 split into "WAF" and "the site itself". #### What robots.txt means for a scan `robots.txt` is addressed to search crawlers that index the web on their own schedule. An on-demand scan that you start for your own site is a different kind of visit, and for the scanner robots.txt is above all an object of inspection. The report reads it and tells you whether it [blocks crawlers](/help/robots/), whether it hides CSS and JavaScript from them, whether it names a [sitemap](/help/sitemap/) and whether that sitemap is valid. A single stray `Disallow: /` left over from staging is one of the most expensive mistakes a site can make, and it is exactly what a scan is good at catching; more in [sitemap and robots.txt](/blog/sitemap-robots/). #### Why the report may differ from your browser **Location and IP.** The scanner connects from a data centre. Geo-redirects, regional CDNs and anti-bot rules may treat it differently from your home connection. **No cookies, no login.** You see the site as a returning, logged-in visitor who accepted the cookie banner. The scanner is a first-time anonymous visitor every time. **Caches.** Your browser and your CDN may still hold yesterday's version. On the other side, a report is reused for fifteen minutes so that a shared link does not trigger a new crawl; press **Rescan** after a deploy. **Lab versus field.** Speed metrics come from Google PageSpeed Insights for the home page: a lab run on an emulated device and, if the site has enough traffic, real-user data from the Chrome UX Report. A lab LCP of 3.1 s and a field LCP of 2.2 s are both true; read [where the data comes from](/help/data-source/) and the thresholds in [Core Web Vitals](/blog/core-web-vitals/). **Content after load.** Anything injected long after the page settles, or only after a click, may be missing. #### How to get the most out of a scan 1. Start from the address real visitors use, ideally the final one after redirects. 2. Check the crawl section first: if pages were blocked, fix access before reading scores. 3. Treat findings on one template as findings on all pages of that template. 4. After a fix, rescan and compare — do not rely on the old report. To try it, [run a free scan](/) of your site; [the product page](/product/) lists what each analyser checks, and [an online website check](/blog/website-check-online/) explains what the result looks like. ### Website diagnostics: from symptom to cause - URL: https://sitescan.top/blog/website-diagnostics/ - Category: Infrastructure - Published: 8 October 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 6 min > Website diagnostics the way a doctor works: start from the symptom — slow pages, lost traffic, mail in spam, outages, browser warnings — and find the cause. Nobody runs website diagnostics for fun. It starts with a complaint: "the site is slow", "traffic halved", "clients say our invoices land in spam", "Chrome shows a warning". A complaint is a symptom, and the same symptom can have five unrelated causes. Good diagnostics goes from the symptom to a short list of suspects, checks each one with a measurement, and only then changes something. Below are the five complaints we hear most often, with the usual causes and how to confirm them. #### "The site is slow" First ask: slow for whom and at which moment? Three different problems hide behind this phrase. - **The server is slow to answer.** Time to first byte above 800 ms means the HTML is generated slowly: no page cache, heavy database queries, an overloaded host. Every page is slow, including tiny ones. - **The page is heavy.** The first byte arrives fast, but the main image is 2 MB, fonts and scripts block rendering, and the [largest contentful paint](/help/lcp/) crosses 2.5 s. Typical for marketing pages. - **Repeat visits are slow too.** Static files are sent without `Cache-Control`, so the browser downloads the same CSS and JS on every page. See [HTTP caching](/blog/http-caching/). Also check compression (HTML and scripts without gzip or Brotli) and HTTP/2. A redirect chain on every internal link adds a round trip each time. #### "Traffic dropped" Separate a sudden drop from a slow decline. A sudden drop after a release almost always has a technical cause: - `robots.txt` from staging with `Disallow: /` went live — check what [robots.txt](/help/robots/) actually says; - a `noindex` landed on templates that should be indexed — product, category or article pages; - canonical tags point to another host, to plain HTTP or to the home page; read about [canonical URLs](/blog/canonical-urls/); - old URLs return 404 after a migration instead of a 301 to the new address; - the site started answering 5xx to crawlers under load. A slow decline over months is usually not technical: competitors, content, search algorithm changes. Diagnostics from outside will not explain that — but it rules out the technical causes in minutes. #### "Our emails go to spam" Mail from your domain is judged by DNS records that have nothing to do with the website itself, which is why they are forgotten. 1. **SPF** lists the servers allowed to send for the domain. A missing one, or a second `v=spf1` record, breaks it. 2. **DKIM** signs messages; it is configured at the mail provider. 3. **DMARC** tells receivers what to do with mail that fails the checks. Without it, large providers increasingly treat mail as suspicious. 4. **Reputation.** If the domain or its IP is on a DNS blocklist, even perfect records will not help. The report shows [DNS blocklist](/help/reputation/) results. Details and examples of records are in [email authentication](/blog/email-authentication/). #### "The site is down" Before blaming the hosting, rule out the things that expire: - **The TLS certificate.** Automatic renewal breaks quietly — a changed DNS, a firewall rule, a full disk. One day browsers show a full-page error. - **The domain.** An expired card or an old email at the registrar, and the domain stops resolving. - **DNS.** Moved nameservers, a deleted record, a typo in an A record. All three are visible from the outside days or weeks in advance; see [expiry dates](/blog/expiry-dates/). If none applies and the server answers 5xx or times out, the cause is on the server: logs, resources, the latest deploy. #### "The browser shows a warning" - **"Not secure" in the address bar** — the page or a form is loaded over HTTP, or an HTTPS page pulls scripts and images over HTTP. That is [mixed content](/blog/mixed-content/). - **A full-page certificate error** — expired certificate, wrong host name, or a missing intermediate certificate. The last one is treacherous: desktop Chrome often fixes it by itself, while Android and API clients fail. Check the [certificate chain](/help/tls-chain/). - **A "deceptive site" warning** — the domain is on a safe-browsing list, usually after a hack. That is a security incident, not a configuration problem. #### How to run diagnostics with SiteScan A scan from the outside covers most suspects at once: response time and page weight, compression and caching, robots.txt, noindex and canonicals, broken links, certificate and domain dates, SPF, DMARC and blocklists. What it cannot see is your server logs and search console data, so combine both. [Run a scan](/) of the affected site, open the category that matches the symptom and look at the critical and high findings first. After the fix, rescan to confirm the cause is gone rather than assuming it. ### Automated website checks: catch regressions before users do - URL: https://sitescan.top/blog/automated-website-check/ - Category: Infrastructure - Published: 7 October 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 6 min > How to set up an automated website check: schedules, comparing scans, alerts that are worth reading, and the expiry dates that need watching most. A one-off scan answers "how is the site today?". Sites, however, break between scans: a plugin update removes a security header, a new landing page ships without a canonical, the certificate renewal quietly fails. An automated website check turns a snapshot into a time series and answers a more useful question: what changed, and is it worse? #### What actually breaks between releases It is rarely the code you were working on. Regressions come from the edges: - **Configuration drift.** A CDN or hosting panel change resets `Cache-Control`, compression or HSTS. - **CMS updates and plugins.** A theme update adds a render-blocking script; an SEO plugin update toggles `noindex` on archives. - **Content.** An editor uploads a 4 MB hero image, links to a page that was deleted last week, pastes an `http://` embed. - **Things that expire.** Certificates, domains, payment cards at the registrar. - **Third parties.** A chat widget or analytics tag starts throwing console errors. None of these show up in your test suite, and none of them announce themselves. That is the case for checking from the outside, on a schedule. #### How often to check Match the frequency to how fast the site changes and how expensive an outage is: - **Before and after every release** — the pair that catches the most. The first scan shows the baseline, the second whether the deploy broke something. - **Daily** for shops and sites with frequent content changes. - **Weekly or monthly** for a corporate site that changes slowly. - **Hourly or every six hours** only where minutes of downtime cost money — and only for a few pages. More often is not automatically better: every check costs a crawl, and a report nobody reads is noise. #### Compare, do not just repeat The value of automation is in the difference between two reports. A repeat check of a watched site reads the same pages as the previous one, so the comparison is fair. The report then sorts findings into three groups: - **New** — not there last time. This is your regression list. - **Fixed** — found last time, gone now. Proof that a ticket was really closed. - **Still there** — found both times. Your backlog. A finding counts once however many pages raise it, and the number of affected pages is shown as "before → now", so a problem that spreads from 2 to 40 pages is visible even if it is not new. Alongside, the trend shows how the [overall score](/help/performance-score/) moved since the previous scan. Read the trend over weeks, not one run: one score drop of 2 points is noise, a steady slide is a signal. #### Alerts worth reading An alert that fires every day is muted within a week. Configure notifications by event, not by run: 1. **Critical issues** — a dead page, an expired certificate, a blocked crawl. Always on. 2. **High-severity issues** — missing security headers, redirect chains, forms without labels. 3. **Score dropped** — compared with the previous check. 4. **The check could not run** — the site did not answer or refused the scanner. Often the earliest sign of an outage. Send them where the team actually looks: email for a weekly digest, a Telegram chat for the critical ones. #### Expiry dates: the cheapest wins of monitoring Most dramatic outages are not bugs but dates. Watch three of them: - **The TLS certificate.** A 90-day certificate renewed automatically should always have more than 30 days left; if it drops below that, renewal is failing. See [certificate expiry](/help/tls-expiry/). - **The domain registration.** Auto-renew fails on an expired card; check the [domain expiry](/help/domain-expiry/) date and the email at the registrar. - **Mail and DNS records** that a migration may have dropped. Why these dates are dangerous and how to keep them safe is covered in [expiry dates](/blog/expiry-dates/). #### Where automation ends An automated check measures; it does not decide. It will not tell you that a new page is badly written or that a price is wrong. Treat its output as an input to the [audit process](/blog/website-audit-online/): new findings go into tickets, fixed ones are closed after a rescan confirms them. For the kinds of errors that most often appear as regressions, see [checking a site for errors](/blog/website-error-check/). #### Setting it up with SiteScan 1. [Run a scan](/) of the site and look at the report once by hand. 2. Press **Watch this site**, pick an interval — from hourly to monthly — and how many links each check reads. 3. In the account, open **Notifications**, choose the events and a channel: email or Telegram. 4. Checks are paid from a token balance, one token per page read; see [pricing](/pricing/). From then on, every report opens with what changed since the last scan. ### Comprehensive website audit: every dimension, one work plan - URL: https://sitescan.top/blog/comprehensive-website-audit/ - Category: SEO - Published: 6 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 6 min > A comprehensive website audit puts SEO, speed, security, accessibility, mobile, privacy and email in one picture. Here is how to plan the work it produces. Most sites get checked in slices. Marketing looks at SEO, a developer looks at speed, and once a year someone remembers the certificate. Each check is honest, but the result is a mosaic, and the most expensive problems live exactly where the slices meet: a redirect that hurts both indexing and load time, an analytics script that slows the page down and also fires before cookie consent. A comprehensive website audit exists to see every layer at once and decide what to fix first — instead of fixing whatever happened to catch someone's eye. #### Seven dimensions, checked together A proper comprehensive audit does not cover "everything". It covers a defined set of dimensions: - **SEO and indexing.** Title and description, headings, canonical, hreflang, structured data, robots.txt and the sitemap. - **Speed.** Core Web Vitals, with Google's "good" thresholds: LCP ≤ 2.5 s, CLS ≤ 0.1, INP ≤ 200 ms. - **Security.** HTTPS and the certificate, HSTS, Content-Security-Policy and the other headers, service files left exposed. - **Accessibility.** WCAG 2.1: labelled fields, contrast, visible focus, keyboard operation. - **Mobile.** The viewport, elements wider than the screen, menus and dialogs on a phone. - **Privacy and legal pages.** Trackers, the consent banner, links to the privacy policy and terms. - **Email and domain.** SPF, DKIM, DMARC, and the expiry dates of the domain and the certificate. Each of these has its own article on our blog, from [Core Web Vitals](/blog/core-web-vitals/) to [email authentication](/blog/email-authentication/). The point of a comprehensive approach is to put them on one scale of priority. #### Why checking in slices fails Three common situations where a partial audit misses the real problem: 1. **Third-party scripts.** The SEO specialist does not see them, the developer considers them "someone else's", and legal does not know the chat widget sets cookies. One script ends up hurting INP, breaking the CSP and violating GDPR at the same time. 2. **Moving to HTTPS or a new domain.** Redirect chains cost speed and crawl budget, mixed content costs security, and a forgotten SPF record on the new domain sends contact-form mail to spam. 3. **A redesign.** The new layout passes visual sign-off but quietly loses form labels — and the product markup along with them. When different people look at different dimensions at different times, nobody notices that it is one cause. #### Turning the audit into a work plan The output of a comprehensive audit easily becomes a list of a hundred items that nobody finishes. A simple order helps. **First, whatever breaks the whole site.** An expiring certificate, a domain without auto-renewal, a robots.txt that blocks indexing, 5xx errors on key pages. These are domain-level problems: one change, effect everywhere. **Then critical and high findings, weighted by the number of pages.** A bug in the product template that shows up on 400 pages beats a perfect fix to a single article. **Then the quick wins.** Security headers, width and height on images, caching for static files: half an hour of work, visible results. **Only then the long projects.** Rewriting the front end for INP or rebuilding navigation for accessibility are sprint-sized tasks, not evening ones. Give every task an owner: server and DNS to the admin, templates to the front-end developer, copy and meta tags to content, the consent banner and policies to whoever owns the legal side. #### How many pages to check You do not need every URL. Most sites have only a handful of templates, so the sample has to include the home page, category pages, product or service pages, articles, forms and the cart. If the site has 20 page types and the audit read 10 addresses, some templates were never seen — that is a reason to run a deeper audit type, not to draw conclusions from half a picture. #### The re-check is part of the audit An audit without a second run is an opinion, not a result. After the fixes are deployed, scan the site again and compare: what was fixed, what is still there, and what is new. The last group matters most — tightening the CSP easily breaks a payment widget, and font optimisation can break the mobile layout. The process side is covered in our piece on the [website audit as a process](/blog/website-audit-online/), the server side in the [technical audit](/blog/technical-website-audit/) guide. #### Running a comprehensive audit with SiteScan 1. Start a [free scan](/). The scanner loads pages in a real headless browser and returns an overall score out of 100 plus category scores: SEO, performance, security, accessibility, mobile, privacy, forms, links, console, HTML validity, images and infrastructure. 2. Read "In short, for the site owner" first: the three most dangerous problems and how many pages each one touches. 3. Go through the site-level checks — certificate, domain registration, mail, headers. Every row links to an explanation, for example on [DMARC](/help/dmarc/) or [certificate expiry](/help/tls-expiry/). 4. Click "Copy fix brief" to turn the critical, high and medium findings into a task list for your developer. 5. After the fixes, scan again: the report shows what changed since the previous scan. What each analyzer covers is described on the [product page](/product/); deeper audits for larger sites are on the [pricing page](/pricing/). ### AI website check: using an LLM with real scan results - URL: https://sitescan.top/blog/ai-website-check/ - Category: SEO - Published: 5 October 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 6 min > An AI website check works when the model gets real scanner data. How to have AI explain a report, write the fix brief and not fall for hallucinations. "Check my site for errors" is one of the most common things people type into a chat assistant, and one of the least useful. A language model cannot measure your LCP, see your response headers or click your checkout button. Pasted a URL, it either fetches one raw HTML file or simply guesses from what it knows about sites like yours. An AI website check becomes genuinely useful only when the work is split properly: a scanner measures, the model explains and drafts the fix, and a second scan verifies. #### What a model cannot see on its own Even with browsing switched on, a chat assistant typically gets one HTML response, without rendering, without the console, without the timing of a real page load. It does not know: - what the server sends in its headers and redirects; - which JavaScript errors appear after the page has loaded; - how long the largest element takes to paint, or how much the layout shifts; - whether the form actually submits, or what the certificate expiry date is. Without data, the model fills the gap with plausible text. "Your site may have slow-loading images" is true of almost any site — and tells you nothing. #### Split the work: the scanner measures, AI explains The sensible pipeline has three steps. First a tool collects facts: status codes, headers, Core Web Vitals, console errors, HTML validation messages. Then a model works on those facts: it explains a finding in plain language, groups related ones, and drafts a patch for your stack. Finally the same tool checks the result. The model never becomes the source of truth about your site — the measurement does. #### Prompts that work with a report Give the model the finding, not the whole site. Good requests look like this: - "Here is a finding from my site audit. Explain in two paragraphs what it means for visitors and for search, without jargon." - "These are the HTTP response headers of my home page. Write an nginx config block that adds the missing security headers. Do not add HSTS preload." - "This JavaScript error appears on 14 pages. Here is the stack trace and the file. Suggest the most likely cause and a minimal fix." The narrower the input, the less room for invention. For console errors in particular, read our guide to [console errors](/blog/console-errors/) first — half the messages there come from third-party scripts you cannot change. #### A fix brief for an AI coding assistant Coding assistants in the editor work best from a structured task: what is wrong, where, how severe, how to tell it is done. That is exactly the shape of a good audit brief. Paste it with a short instruction — "Fix these one at a time, starting from the top; show me the diff for each and explain anything that touches server configuration." — and review every change like a colleague's pull request. #### Where AI gets it wrong most often - **Content-Security-Policy.** Models happily write a strict policy that blocks your analytics, payment widget and inline scripts. Roll it out as Report-Only first; see [CSP](/help/content-security-policy/). - **HSTS preload.** Suggested casually, it is hard to undo. Read [HSTS preload](/help/hsts-preload/) before accepting it. - **robots.txt and canonical.** One wrong line removes whole sections from search. Never accept these without understanding every directive. - **Outdated advice.** FID instead of INP, deprecated headers like X-XSS-Protection, meta keywords "for SEO". And never paste secrets, tokens or customer data into a prompt — a report and a config fragment are enough. #### Trust, but re-scan Code that looks right is not the same as a fixed site. The only acceptance criterion that matters: a fresh scan no longer reports the problem, and nothing new appeared in exchange. Our article on [reading audit results](/blog/website-analysis-online/) explains how to compare two runs; if you want to know how ready your site is for AI search itself, that is a different topic — see the [AI website audit](/blog/ai-website-audit/). #### How to do it with SiteScan 1. Run a [free scan](/). Pages are loaded in a real headless browser; forms are exercised by AI agents, as described in our piece on [form testing](/blog/form-testing/). 2. Use the [help centre](/help/) for the meaning of each row before asking a model — it gives the context the model lacks. 3. Click "Copy fix brief". You get plain Markdown: critical, high and medium findings, sorted by severity and reach, with check ids, affected pages and acceptance criteria. It pastes cleanly into a task tracker or an AI assistant. 4. After deploying, scan again and look at "What changed since the last scan": new, fixed, still there. ### AI website audit: a checklist for AI search and assistants - URL: https://sitescan.top/blog/ai-website-audit/ - Category: SEO - Published: 4 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 5 min > An AI website audit in six steps: crawler access in robots.txt, content without JavaScript, llms.txt, structured data, clear answers and measurement. Answer engines and chat assistants now send real visitors — and, more often, answer without sending anyone. Whether your site is the source they quote depends on things you can check. Our article on [how AI assistants read a site](/blog/ai-visibility/) explains the principles; this one is the working checklist. An AI website audit takes an afternoon, and you can repeat it every quarter. #### Step 0. Decide what you want Before touching robots.txt, separate two questions. Do you allow your content to be used for **training** models? And do you want to appear in **AI search answers** with a link back? They are controlled by different crawlers, and many sites want "no" to the first and "yes" to the second. Write the decision down; the rest of the audit checks whether the site actually implements it. #### Step 1. Access: robots.txt, firewall, status codes The main user-agent tokens, as published by their operators: - OpenAI: **GPTBot** (training), **OAI-SearchBot** (ChatGPT search), **ChatGPT-User** (fetches on a user's request). - Anthropic: **ClaudeBot**, **Claude-SearchBot**, **Claude-User**. - Perplexity: **PerplexityBot**, **Perplexity-User**. - Google: **Google-Extended** is a robots.txt token, not a crawler — it governs use in Gemini models; AI Overviews follow ordinary Googlebot rules. - Others: **Applebot-Extended**, **CCBot** (Common Crawl, a frequent training source). A typical "no training, yes search" policy: User-agent: GPTBot Disallow: / User-agent: OAI-SearchBot Allow: / Then check that reality matches the file. A CDN "bot fight" mode or WAF often returns 403 or a challenge page to these agents regardless of robots.txt. Test with curl -I -A "OAI-SearchBot" https://example.com/ and look at the status. See also the [robots.txt reference](/help/robots/). #### Step 2. Content without JavaScript Most AI crawlers do not execute JavaScript. Open a key page with scripts disabled, or look at the raw HTML: are the headline, the main text, prices and dates there? If the page is an empty shell filled in by the client, the assistant sees nothing. Server-side rendering or prerendering fixes this. #### Step 3. llms.txt and llms-full.txt [llms.txt](/help/llms-txt/) is a short Markdown map of the site at the root: who you are, the key sections, links to the pages that matter. [llms-full.txt](/help/llms-full-txt/) is the long form, typically for documentation. It is a convention, not a standard, and no assistant is obliged to read it — but it costs an hour and removes guesswork. #### Step 4. Structured data and attribution - **Organization** markup with name, logo and sameAs on the home page; **Article** with author and dateModified on articles; **Product** with price and availability in the shop. Details in our guide to [structured data](/blog/structured-data/). - One address per piece of content: a correct [canonical](/blog/canonical-urls/), so the citation points to the right URL. - A visible author, publication date and the company name the same way everywhere. #### Step 5. Clarity of content Assistants quote fragments. A page is quotable when the answer comes first and the explanation second; when headings are questions or plain statements, not slogans; when numbers, terms and conditions are written out in text rather than hidden in images or accordions. Read your top ten pages and ask: can one paragraph be lifted out and still be correct? #### Step 6. Measure and repeat Look in server logs for the user agents from step 1 and their status codes — 403s and 5xx are your first fixes. In analytics, segment referrals from AI services. Repeat the audit after every major release: a new firewall rule or a client-side rewrite can undo everything silently. #### Running an AI website audit with SiteScan 1. Start a [free scan](/). The report shows whether robots.txt blocks crawlers and whether llms.txt and llms-full.txt are present. 2. For each page, the report lists the structured data found, the canonical, title and description — enough to cover steps 3 and 4. 3. AEO analysis is part of the deeper audit types; see [pricing](/pricing/). 4. To turn findings into tasks and have an assistant explain them, follow our guide to an [AI website check](/blog/ai-website-check/). ### Third-party scripts: the weight you did not write - URL: https://sitescan.top/blog/third-party-scripts/ - Category: Performance - Published: 3 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 7 min > Analytics, tag managers, chat widgets and pixels each look harmless on their own. Together they decide how fast your page is — here is how to take stock and cut them back. Open the network panel on almost any commercial site and count the domains. Your own origin, a CDN, then a long tail: analytics, a tag manager, two ad pixels, a chat widget, an A/B testing tool, a font service, a map, a video embed. None of that code was written by your team, none of it is reviewed in your pull requests, and all of it runs with the same rights as your own JavaScript. Each tag was added for a good reason by someone who needed it. The problem is that nobody owns the sum. #### What every new origin costs **Connection setup.** A new domain means a DNS lookup, a TCP handshake and a TLS negotiation before the first byte of the script arrives. On a mobile connection that is easily several hundred milliseconds per origin, and a script that loads more scripts from yet another domain pays it again. **Main-thread time.** Third-party JavaScript has to be downloaded, parsed and executed on the same thread that handles clicks and taps. A chat widget that boots a whole UI framework or an A/B tool that rewrites the DOM competes directly with your page's interactions, and it shows up as poor **INP** (Interaction to Next Paint). **Render blocking.** A plain `<script src>` in the `<head>` without `async` or `defer` stops the parser until it has been fetched and run. Some A/B testing snippets do this deliberately, and hide the page until they finish, to avoid flicker. **Single point of failure.** If a vendor's server is slow or down, a blocking script makes your page slow or blank with it. Your uptime now depends on theirs, and your monitoring will not tell you why. **Privacy and consent.** A pixel that fires before the visitor has answered the cookie banner sends their data to a third party without consent. Loading the script at all is often enough to transfer the IP address and a referrer. **Security.** Every external script is part of your supply chain. If the vendor or the CDN is compromised, the attacker's code runs on your checkout page. A strict Content Security Policy becomes much harder to write when the allowlist grows with every tag. #### Take inventory Start with facts rather than memory: - In Chrome DevTools, open **Network**, reload, and group or sort by domain. Note every origin that is not yours and what it loads. - Open the **Coverage** panel to see how much of each script actually executes on a typical page. - Look inside the tag manager: list every tag, its trigger and the date it was last changed. For each tag, ask three questions. **Who owns it?** If nobody can name a person or a team, that is a candidate for removal. **Is it still used?** Pixels for campaigns that ended last year and trials of tools that were never bought are common finds. **Does it need to load on every page, immediately?** Usually the answer is no. A SiteScan report helps with the first step: it counts the third-party origins your pages load resources from and flags it when there are too many ("Cut the number of third-party origins the pages load from"). It also lists the technologies and widgets it detects on the site, which is a quick way to spot a forgotten tool. #### Techniques that work **Remove.** The fastest script is the one that is not there. Deleting two dead tags beats optimising five live ones. **Defer what stays.** Analytics and most pixels can use `async` or `defer`, or be fired from the tag manager after the page has loaded. Nothing that does not draw the first screen should block it. **Load on interaction.** A chat widget or a YouTube embed does not need to boot before anyone wants it. Show a lightweight facade — a static button or a thumbnail image — and load the real thing on click: <button class="chat-facade" type="button">Chat with us</button> <script> document.querySelector(".chat-facade").addEventListener("click", () => { const s = document.createElement("script"); s.src = "https://widget.example-chat.com/loader.js"; document.head.append(s); }, { once: true }); </script> **Self-host where the licence allows.** Fonts and small libraries served from your own origin skip the extra connection and stay under your caching rules. **Preconnect sparingly.** `<link rel="preconnect">` helps for the one or two third-party origins that are on the critical path. Adding it for ten origins just spends early bandwidth and sockets on things that are not urgent. **Keep the tag manager clean.** Restrict who can publish, require a description and an owner for each tag, and review the container regularly. A tag manager makes adding scripts easy; it should not make it invisible. **Pin static files with Subresource Integrity.** For a versioned library on a public CDN, an `integrity` attribute makes the browser refuse a file that has been altered: <script src="https://cdn.example.com/lib@2.4.1/lib.min.js" integrity="sha384-..." crossorigin="anonymous"></script> SRI does not work for scripts the vendor changes in place, which is exactly why those deserve the most scrutiny. **Set a budget.** Agree on a limit — number of third-party origins, kilobytes of third-party JavaScript — and check it before each new tag goes live. A budget turns "just one more pixel" into a decision. #### Check-list 1. Every third-party origin is listed with an owner and a purpose. 2. Unused tags and expired campaign pixels are removed. 3. No third-party script blocks rendering of the first screen. 4. Chat widgets and video embeds load on interaction behind a facade. 5. Nothing that tracks visitors loads before consent. 6. Preconnect is used only for the one or two critical origins. 7. Static CDN files carry an `integrity` attribute. 8. A third-party budget exists and new tags are checked against it. ### Web fonts without the wait: font-display, subsets and preload - URL: https://sitescan.top/blog/web-fonts/ - Category: Performance - Published: 2 October 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 7 min > Invisible text, jumping layouts and an extra origin for every visitor — how to load custom fonts so that text appears immediately and stays put. A custom font is usually the largest piece of the design that blocks text. Until it arrives, the browser has to decide what to do with every heading and paragraph on the page: hide them or show them in something else. Both options have a cost, and the defaults rarely pick the cheaper one for you. #### FOIT, FOUT and what font-display controls **FOIT** — flash of invisible text — is the browser keeping text hidden while the font downloads. On a slow connection the page has a layout, images and buttons, and no words. **FOUT** — flash of unstyled text — is the opposite: text is drawn immediately in a fallback font and swapped when the web font arrives. The `font-display` descriptor in `@font-face` chooses between them. It defines a short *block period* (text invisible) and a *swap period* (fallback visible, web font may still replace it): - **`auto`** (the default) and **`block`** — in practice a block period of up to about three seconds. This is the FOIT you want to avoid. - **`swap`** — a near-zero block period and an unlimited swap period. Text appears at once in the fallback, and the web font replaces it whenever it lands. The safe default for body text and headings. - **`fallback`** — a block period of around 100 ms and a swap period of about three seconds. If the font is late, the page keeps the fallback for this visit. A good compromise when a late swap would be more disruptive than a different typeface. - **`optional`** — a block period of around 100 ms and no swap period. The browser uses the web font only if it is available almost immediately, usually from cache; otherwise the fallback stays. No layout shift from fonts at all, at the price of first-time visitors on slow networks never seeing your typeface. `swap` trades visual stability for visible text; `optional` trades the brand font for stability. For most sites, `swap` on text fonts and `optional` on decorative ones is a reasonable starting point. #### Ship fewer, smaller files **WOFF2 only.** Every browser in current use supports it, and its Brotli-based compression beats WOFF and TTF clearly. Listing `.woff`, `.ttf` and `.eot` fallbacks in `src` adds nothing but maintenance. **Subset.** A full font with Latin, Cyrillic, Greek and Vietnamese glyphs can be several times larger than what one page needs. Split it into subsets and let `unicode-range` tell the browser which file to fetch — it downloads a subset only if the page actually contains characters from that range: @font-face { font-family: "Inter"; src: url("/fonts/inter-latin.woff2") format("woff2"); font-weight: 400 700; font-display: swap; unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+2000-206F, U+20AC, U+2122; } @font-face { font-family: "Inter"; src: url("/fonts/inter-cyrillic.woff2") format("woff2"); font-weight: 400 700; font-display: swap; unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116; } An English page then never downloads the Cyrillic file, and a Russian page gets both, since it still uses Latin digits and punctuation. **Limit weights and styles.** Regular, bold and italic in two families is already six files. Ask whether the design really needs a 300 and a 600. **Variable fonts** help when it does: one file covers the whole weight axis (`font-weight: 100 900`). A variable file is usually larger than a single static weight, so it pays off from about three weights upward, not for one. #### Self-host instead of a third-party font CDN Loading from Google Fonts means a stylesheet from `fonts.googleapis.com` and then the font files from `fonts.gstatic.com` — two extra origins, each with its own DNS lookup, TCP and TLS handshake, discovered only after your HTML and CSS are parsed. The old argument that a visitor already has the font cached from another site no longer holds: all major browsers now partition the HTTP cache by top-level site, so a font cached on one site is downloaded again on yours. Self-hosting puts the files on the origin the browser is already connected to, gives you control over subsets and cache headers, and removes a third-party request from every page view. The fonts' licence normally allows it; check before you copy. #### Preload the one or two that matter The browser learns about a font only after it has the CSS and finds text that uses it. A preload starts the download earlier: <link rel="preload" href="/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin> The `crossorigin` attribute is required even for same-origin fonts: fonts are fetched in CORS mode, and a preload without it does not match the real request, so the file is downloaded twice. Preload only the font used above the fold — typically the main text face in one subset. Preloading every weight competes with CSS and the hero image for bandwidth and makes the page slower, not faster. #### Make the fallback the same size With `swap`, the moment the web font replaces the fallback, lines rewrap and blocks change height. That is layout shift, and it counts toward CLS. Font metric overrides let you shape a local font to match the web font's proportions: @font-face { font-family: "Inter Fallback"; src: local("Arial"); size-adjust: 107%; ascent-override: 90%; descent-override: 22%; line-gap-override: 0%; } body { font-family: "Inter", "Inter Fallback", sans-serif; } The numbers above are illustrative; calculate them for your font with a tool such as Capsize or Fontaine, or let your framework generate them. Done well, the swap becomes almost invisible. #### Cache them for a year Font files are ideal for long caching. Put a version or hash in the filename and serve: Cache-Control: public, max-age=31536000, immutable If fonts are on a separate CDN host, that host must also send `Access-Control-Allow-Origin`, or the browser will refuse to use them. A SiteScan report checks one part of this: it flags web fonts declared without `font-display` and suggests setting `font-display: swap`. #### Check-list 1. Every `@font-face` has an explicit `font-display`. 2. Fonts are served as WOFF2 only. 3. Files are split into subsets with `unicode-range`. 4. Only the weights the design uses are loaded; variable fonts where there are many. 5. Fonts are self-hosted on your own origin. 6. One or two critical fonts are preloaded with `crossorigin`. 7. The fallback font has metric overrides to limit layout shift. 8. Font files have versioned names and a one-year immutable cache. ### RSS and Atom feeds: the old format that still moves your content - URL: https://sitescan.top/blog/rss-atom-feeds/ - Category: SEO - Published: 1 October 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 5 min > Why a feed still matters in 2026, RSS 2.0 versus Atom, how to make it discoverable, and the small mistakes that make readers show a year-old post as new. A feed looks like a relic. Nobody types a feed URL into a browser any more, and most site owners last thought about theirs when the CMS generated it by default. Yet a feed is still the cheapest machine-readable answer to "what is new on this site", and a surprising number of things keep asking. #### Who actually reads it - Feed readers — Feedly, Inoreader, NetNewsWire, Miniflux — used by exactly the technical audience that writes about you and links to you. - Aggregators that republish headlines from dozens of sources. - Automation: IFTTT and Zapier recipes, newsletters assembled from the latest posts, Slack and Telegram bots that announce each entry in a channel. - Syndication the way podcasts work: one URL, many subscribers, each polling on its own schedule. - Search engines and AI tools looking for fresh content. A feed is a compact list of recent URLs with dates, far cheaper to fetch than a crawl. With WebSub the feed can even push: you ping a hub when you publish, and subscribers get the update in seconds instead of on their next poll. #### RSS 2.0 or Atom 1.0 RSS 2.0 is more widespread, and every consumer understands it. Atom 1.0 is the stricter, better-specified one: `id` and `updated` are mandatory on every entry, content declares its type (`text`, `html`, `xhtml`) instead of leaving the client to guess, and `xml:base` gives relative references a defined meaning. Either is fine. Pick one and do it properly — a correct RSS feed beats a half-valid Atom one. #### Make it discoverable A feed that nothing points to does not exist. Declare it in the `<head>` of every page, not only the blog index: <link rel="alternate" type="application/atom+xml" title="SiteScan blog" href="/blog/feed.xml"> Readers and browser extensions look for exactly this tag. Serve the file itself with the matching type — `application/atom+xml` or `application/rss+xml`, not `text/html`. #### What goes inside **Absolute URLs everywhere.** The feed is read outside your site, so `/blog/post` resolves to nothing. That includes links and images inside the content. **Stable entry ids.** The id is how a reader knows it has already seen an entry. Change it — new domain, new URL scheme, http to https — and every subscriber sees your whole archive as new again. Atom tag URIs exist for this: <id>tag:sitescan.top,2026:blog/rss-atom-feeds</id> **Honest dates.** `updated` changes when the content changes, not on every build. **Full content or excerpt.** Full content is friendlier to readers; an excerpt brings people to the page. Both are legitimate — just make the excerpt meaningful rather than the first 200 characters cut mid-word. **The latest N entries.** Twenty to fifty is plenty. The feed is a window on recent changes, not an archive, and a 5 MB file gets polled by every subscriber, every hour. **One feed per language.** A multilingual site should not mix languages in one stream. Give each language its own feed and declare the right one on that language's pages. #### Common mistakes - The feed exists, but no page links to it. - Relative URLs in links and content. - Broken XML because of one unescaped `&` in a title. A parser rejects the whole document, not just that entry. - Dates in the wrong format: RSS wants RFC 822 (`Wed, 01 Oct 2026 09:00:00 GMT`), Atom wants RFC 3339 (`2026-10-01T09:00:00Z`). - The feed URL returns 404 after a CMS migration, and every subscriber silently loses you. - The feed sits behind a bot-protection challenge, so readers receive an HTML page instead of XML. #### How this blog does it A SiteScan report shows whether a page declares a feed, in the "RSS / Atom feed" row. It is optional and shown as a fact, not a penalty: plenty of sites have no reason to publish one. This blog now does — an Atom feed per language at `/blog/feed.xml`, `/ru/blog/feed.xml`, `/pl/blog/feed.xml` and `/de/blog/feed.xml`, each declared in the head of the pages in that language. #### Check-list 1. Pick RSS 2.0 or Atom 1.0 and validate the output. 2. Declare it with `<link rel="alternate">` on every page. 3. Serve it with the correct Content-Type and no challenge in front. 4. Use absolute URLs and ids that never change. 5. Use the date format your feed format requires. 6. Keep the latest 20–50 entries, one feed per language. 7. After any migration, fetch the old feed URL and make sure it still answers 200 or redirects. ### SPF, DKIM and DMARC: your domain sends mail whether you do or not - URL: https://sitescan.top/blog/email-authentication/ - Category: Infrastructure - Published: 30 September 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 6 min > Why every website domain needs email authentication records, how SPF, DKIM and DMARC fit together, and how to roll out a reject policy without losing your own mail. "We don't send email" is one of the most common answers when a scan flags a missing SPF or DMARC record. It is also beside the point. Anyone on the internet can put your domain in the From line of a message. The only thing that decides whether Gmail or Outlook believes it is a handful of TXT records in your DNS — and if they are missing, nobody is speaking for your domain. #### Why a website owner should care **Spoofing and phishing.** Without a DMARC policy, receiving servers have no instruction from you about what to do with mail that claims to be from your domain and fails checks. Fake invoices and "password reset" messages from `support@yourdomain` are cheap to send and damage trust in the real site. **Your own notifications.** Contact forms, order confirmations, password resets — even a "static" site usually sends something. A form handler that calls PHP `mail()` from the web server, with the visitor's address in From, fails every check and lands in spam or nowhere at all. **Mailbox provider requirements.** Since February 2024 Gmail and Yahoo require all senders to have SPF or DKIM, and bulk senders to have both, plus a DMARC record (`p=none` is the minimum) and a From domain aligned with one of them. Other providers have been moving the same way. Mail that does not meet the rules is increasingly rejected, not just filtered. #### SPF: who may send SPF is a TXT record on the domain itself listing the servers allowed to send for it: example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" Rules that trip people up: - **One record only.** Two TXT records starting with `v=spf1` is not "both apply" — it is a permanent error, and receivers treat SPF as broken. Merge them into one. - **Ten DNS lookups.** `include`, `a`, `mx`, `exists`, `redirect` and `ptr` each cost a lookup, and nested includes count too. Past ten, evaluation fails. Remove services you no longer use before adding new ones. - **The ending matters.** `-all` says everything else fails; `~all` is a soft fail, a reasonable setting while you are still inventorying senders; `+all` authorises the entire internet and is worse than having no record. SPF checks the envelope sender (the bounce address), not the From header the user sees. That is why it is not enough on its own. #### DKIM: a signature on every message DKIM signs outgoing mail with a private key; the public key is published in DNS under a **selector**: s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..." Each sending service — your mailbox provider, the newsletter tool, the transactional mail API — gives you its own selector and key, or a CNAME pointing to one it manages. Use 2048-bit RSA keys where the provider allows, and remove selectors for services you have dropped. Unlike SPF, a DKIM signature survives forwarding, which makes it the more reliable of the two. #### DMARC: the policy that ties them together DMARC lives at `_dmarc` and tells receivers what to do when a message fails, and where to send reports: _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" A message passes DMARC when SPF or DKIM passes **and** the domain it passed for is aligned with the domain in From. SPF passing for your email provider's bounce domain does not count; a DKIM signature with `d=example.com` does. Roll it out in stages: 1. **`p=none`** with `rua` reports. Nothing is blocked; you get daily aggregate XML reports showing every server sending as your domain. Use a report parser or service rather than reading XML by hand. 2. Fix every legitimate sender that fails: add it to SPF, set up DKIM, make sure From uses your domain. 3. **`p=quarantine`**, optionally with `pct=` to apply it to a share of failing mail first. 4. **`p=reject`**. Spoofed mail is refused at the door. `p=none` is a monitoring mode, not protection. Staying there for years means you collected the data and never acted on it. #### Domains that send no mail Parked domains, redirect-only domains and old brand names are favourite spoofing targets because nobody watches them. Close them completely: example.net. TXT "v=spf1 -all" _dmarc.example.net. TXT "v=DMARC1; p=reject" A null MX record (`example.net. MX 0 .`) additionally tells other servers the domain does not accept mail. #### How to check dig +short TXT example.com dig +short TXT _dmarc.example.com dig +short TXT s1._domainkey.example.com The first should return exactly one `v=spf1` string. For DKIM you need the selector: open a message you sent, look at the `DKIM-Signature` header and take the value of `s=`. The `Authentication-Results` header of a received message shows SPF, DKIM and DMARC verdicts in one place. A SiteScan report checks the DNS side for you: it flags a missing SPF record, multiple SPF records, an overly permissive `+all`, a missing DMARC record and a DMARC policy left at `p=none`. It does not check DKIM — selectors cannot be discovered from DNS without knowing their names — so verify that with a real message. #### Check-list 1. Exactly one SPF record, under ten lookups, ending in `~all` or `-all`. 2. DKIM is set up for every service that sends as your domain. 3. Site notifications go through an authenticated provider, From your domain, with the visitor in Reply-To. 4. DMARC exists with `rua` reports and is moving from `p=none` towards `p=reject`. 5. Domains that send no mail have `v=spf1 -all` and `p=reject`. ### Canonical URLs: one page, one address - URL: https://sitescan.top/blog/canonical-urls/ - Category: SEO - Published: 29 September 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 6 min > Why the same page lives at a dozen addresses, what rel=canonical can and cannot do about it, and the canonical mistakes that quietly undo your own SEO. To you, a page is a piece of content. To a search engine, a page is a URL. If the same content answers at ten URLs, the crawler sees ten pages, has to work out that they are copies, and then has to guess which one you meant. Canonicalisation is the job of making that guess unnecessary. #### How one page gets many addresses Nobody publishes duplicates deliberately. The server just accepts more variants than you think: - **Host.** `www.example.com` and `example.com` both answer. - **Protocol.** `http://` still serves the site instead of redirecting to `https://`. - **Trailing slash.** `/pricing` and `/pricing/` return the same document. - **Case.** `/Blog/Post` and `/blog/post` both work on a case-insensitive server. - **Index files.** `/docs/` and `/docs/index.html` are the same file. - **Query parameters.** `?utm_source=newsletter`, `?sort=price`, `?sessionid=…` — every combination is a new URL with identical or near-identical content. - **Pagination.** `/blog?page=2` is a real, different page — but it is often wrongly treated as a duplicate of page one. Multiply these together and a site with a hundred pages can expose thousands of addresses. Links, shares and crawl attention get split between them. #### One host, enforced with a 301 The cheapest duplicates to remove are the ones at the host and protocol level, and the right tool is a permanent redirect, not a tag. Pick one form — say `https://example.com` — and send every other combination there in a single hop: server { listen 80; listen 443 ssl; server_name www.example.com; return 301 https://example.com$request_uri; } Two details matter. The redirect must be a **301** (or 308), not a 302: a temporary redirect tells search engines the old address is still the real one. And it should be one hop: `http://www` going to `https://www` and then to `https://` works, but wastes a round trip on every first visit. Do the same for trailing slashes: choose one style and redirect the other. #### rel=canonical is a hint For duplicates you cannot redirect — tracking parameters, sorting, print versions — you declare the preferred address in the page head: <link rel="canonical" href="https://example.com/pricing/"> This is a **hint, not a directive**. Google weighs it together with redirects, internal links, the sitemap and hreflang, and may pick a different canonical if those signals disagree. Your job is to make every signal point at the same URL. Good practice: - **Self-referencing canonicals.** Every indexable page names itself. That protects it from parameter variants you never anticipated. - **Absolute URLs.** A relative `href="/pricing/"` is valid, but it resolves against whatever host and protocol the copy was served from, which is exactly the duplicate you were trying to fix. - **Pagination canonicalises to itself.** Page 2 names page 2, not page 1; otherwise everything linked only from page 2 becomes harder to discover. **Non-HTML files use a header.** A PDF has no head, so send it in the response instead: Link: <https://example.com/guide.pdf>; rel="canonical" #### Mistakes that do real damage **Canonical to the home page everywhere.** A template sets the same canonical on every page. You have just told the search engine that your whole site is a duplicate of `/`. **Canonical to a page that is not there.** The target redirects, returns 404, or carries `noindex`. The signals contradict each other, and the search engine usually ignores the hint. **Conflicts with hreflang and the sitemap.** The sitemap lists `/pricing`, the canonical says `/pricing/`, hreflang points to a third variant. Each of these should list exactly the canonical URL. **JavaScript changes it.** The server HTML says one thing, a client-side router or SEO plugin rewrites the tag after load. Crawlers may see either version. Render the correct canonical on the server and leave it alone. **Several canonical tags.** Two plugins each add one. With conflicting values, the hint is usually ignored altogether. #### How to check Fetch the raw HTML and look at what the server actually sends, not what DevTools shows after scripts have run: curl -s https://example.com/pricing/ | grep -i 'rel="canonical"' curl -sI http://www.example.com/ | grep -iE '^(HTTP|location)' The second command should show a single 301 to your chosen host. A SiteScan report covers part of this automatically: it flags pages with no canonical link, pages whose canonical names a different address, sites where both the www and non-www hosts answer 200 instead of one redirecting permanently, and host redirects that use a temporary 302. #### Check-list 1. One host and one protocol; every other combination returns a single 301. 2. One trailing-slash style, the other redirected. 3. Every indexable page has an absolute, self-referencing canonical. 4. Canonical targets return 200, are indexable and do not redirect. 5. Sitemap, hreflang and internal links use exactly the canonical URLs. 6. Paginated pages canonicalise to themselves. 7. PDFs and other files send a Link header where needed. 8. The canonical in server HTML matches the one after JavaScript runs. ### Soft 404: the missing page that answers 200 OK - URL: https://sitescan.top/blog/soft-404/ - Category: SEO - Published: 27 September 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 6 min > Why a not-found page that returns 200 fills the index with garbage, blinds your monitoring, and how to make the server tell the truth about missing addresses. A 404 is not a failure. It is the server answering an honest question honestly: there is nothing at this address. A soft 404 is the same answer with the wrong status code — the page says "not found", the HTTP response says **200 OK**. Humans read the page; crawlers, monitors and caches read the status. Everyone except the human gets lied to. #### Where they come from Almost nobody writes a soft 404 on purpose. They fall out of reasonable-looking defaults: - **SPA fallback.** The classic nginx config for a single-page app is `try_files $uri /index.html;`. Every address that is not a file gets the app shell with 200, and the router renders "Page not found" in JavaScript after the status has already been sent. - **Empty listings.** CMS search, tag and category pages with zero results still render a full template — header, filters, "nothing found" — with 200. Each combination of parameters becomes a separate indexable page. - **Redirect everything home.** A catch-all rule that sends every unknown URL to `/` with a 301 or 302. Search engines treat a redirect to an unrelated page as a soft 404, and users lose the address they were trying to reach. - **Out-of-stock products.** The product is gone, the template stays: no price, no description, no photos, one line of "currently unavailable", and a 200. - **WAF and bot challenges.** A firewall or CDN challenge page served with 200 instead of 403 or 429. To a crawler, your entire catalogue becomes copies of one "checking your browser" page. #### Why it hurts **Garbage in the index.** Typos, old campaign URLs and scanner probes all become "pages". Google eventually spots many of them and lists them in the Search Console **Soft 404** report — but only after crawling them, and not all of them. **Crawl budget.** Every fake page is a fetch the crawler did not spend on real content. On a large site with parameterised listings this is not a rounding error. **Duplicates of the home page.** Blanket redirects and SPA shells make thousands of URLs resolve to the same content, which muddies canonical selection for the page you actually care about. **Blind monitoring.** Uptime checks, link checkers and synthetic tests look at the status code. If dead links answer 200, every broken-link audit reports a clean site. **Polluted analytics.** Hits on nonexistent pages are counted as normal page views, with normal bounce and time-on-page. The "not found" traffic never shows up as an error. #### How to test Request an address that cannot exist and look only at the status: curl -s -o /dev/null -w "%{http_code}\n" https://example.com/this-page-does-not-exist-8f3a/ Anything other than 404 or 410 is a problem. Repeat for each template that has its own routing: `/blog/nonexistent`, `/product/nonexistent`, `/search?q=zzzzqx`, a missing locale prefix. A SiteScan report does this for you: it checks what the server answers for an address that does not exist and flags a 200. #### The fixes **Return a real 404.** For a static or prerendered site, let nginx serve a prebuilt page with the right status: error_page 404 /404.html; location / { try_files $uri $uri/ =404; } For an SPA with server rendering, the server has to know the route table: if no route matches, or the route matches but the record does not exist, respond with 404 before streaming the HTML. If the server truly cannot know — a pure client-side app behind a dumb host — add `<meta name="robots" content="noindex">` to the client-rendered not-found view. That is a last resort: it keeps the page out of the index, but monitors and link checkers still see 200. **Use 410 for content removed for good.** A discontinued product or a deleted article is "gone", not "not found". 410 tells crawlers to stop asking sooner. **Redirect only to a genuine equivalent.** A 301 is correct when the content moved — the renamed article, the replacement model. A blanket redirect to the home page is not a fix; it is a soft 404 with an extra hop. **Make the 404 page useful, not successful.** Search, links to the main sections, for us the scan input — all of it fits on an error page. The page can be as helpful as you like; the status code still has to be 404. #### Check-list 1. A random URL on every routing template returns 404. 2. Empty search and listing pages are noindex or 404. 3. Removed content returns 410 or a 301 to a real equivalent. 4. No catch-all redirect to the home page. 5. Bot challenges return 403 or 429, not 200. 6. The 404 page helps the visitor and still answers 404. ### Mixed content: the http:// leftovers inside your https:// page - URL: https://sitescan.top/blog/mixed-content/ - Category: Security - Published: 25 September 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 7 min > Why one forgotten http:// image or script undoes the security of an HTTPS page, what browsers block or quietly upgrade, and how to clean it up for good. Moving a site to HTTPS takes an afternoon: get a certificate, redirect port 80, done. Then the padlock refuses to show up on half the pages, a slider stops working, or a font silently falls back to Arial. The page itself arrives over https://, but something inside it still asks for http://. That is mixed content. #### Why one http:// request matters HTTPS protects the whole page only if every byte of it comes over an encrypted connection. A single script loaded over plain HTTP can be read and replaced by anyone on the path — public Wi-Fi, a compromised router, an injecting ISP. A replaced script runs with full access to the page: it can read form fields, rewrite links and steal session data. The encryption of the HTML document no longer means anything. Browsers split mixed content into two groups by how much damage it can do. - **Active (blockable) content**: scripts, stylesheets, iframes, fonts, `fetch` and XHR requests, workers. Anything that can change the page or read from it. Modern browsers block it outright — the request is never sent, and the console logs an error. - **Passive (upgradable) content**: images, audio and video. The worst an attacker can do is swap a picture. Current Chrome and Firefox no longer load these over HTTP at all: they rewrite the URL to https:// automatically, and if the resource is not available over HTTPS, it simply fails to load. Older browsers and some embedded web views still display passive mixed content as is, and mark the page as not fully secure — that is where the missing or crossed-out padlock comes from. Forms are a separate case. A `<form action="http://...">` on an HTTPS page sends the user's input unencrypted. Browsers warn before submitting such a form, and the warning looks alarming enough that many people abandon it. #### Where it comes from Almost every mixed-content issue is a leftover from the time before the migration. - **Hardcoded URLs in the CMS database.** Editors inserted images while the site was on HTTP, so post bodies, widgets and settings still contain `http://example.com/uploads/...`. Changing the site address in the admin panel does not touch content already saved. - **Old embeds.** Video players, maps, counters and chat widgets pasted years ago with an http:// URL. Some of those providers now serve HTTPS; some no longer exist. - **CSS.** `background-image: url(http://...)` in a stylesheet or an inline `style` attribute, and `@font-face` pointing to an HTTP font host. - **Responsive images.** The `src` was fixed, but `srcset` still lists http:// candidates, and the browser may pick one of those on a high-density screen. - **Templates and JavaScript.** A theme that builds absolute URLs from a hardcoded scheme, or a script that injects `http://` resources at runtime. #### How to find it **DevTools.** Open the page, open the console, reload. Every mixed-content request is reported with the exact URL and whether it was blocked or upgraded. In the Network panel of Chrome the filter `mixed-content:all` narrows the list to these requests. This works for one page at a time. **Static HTML.** A quick first pass over the markup: curl -s https://example.com/ | grep -Eo '(src|href|srcset|action)="http://[^"]+"' It will not see URLs in CSS files or those added by JavaScript, but it catches most of the CMS leftovers. **CSP reports.** To find mixed content across the whole site with real traffic, send a report-only policy that allows only HTTPS sources: Content-Security-Policy-Report-Only: default-src https: data: blob: 'unsafe-inline' 'unsafe-eval'; report-uri /csp-report Nothing gets blocked; every http:// load produces a report with the page and the URL. Note that `upgrade-insecure-requests` has no effect in a report-only policy, and the old `block-all-mixed-content` directive is deprecated — modern browsers already block active content by default. A SiteScan report also checks this: it flags any scanned page that loads assets over http:// under "Serve every asset over https://". #### How to fix it **Use https:// or relative URLs.** For your own assets, a path like `/uploads/photo.jpg` is the most robust option: it follows the scheme and the domain of the page. For third-party resources, switch to https:// and check that the provider actually serves it. If they do not, replace or self-host the resource. **Search and replace in the database — carefully.** Back up first. In WordPress, use WP-CLI rather than raw SQL, because it handles serialized PHP data correctly: wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run Run it without `--dry-run` once the counts look right. A plain SQL `REPLACE` changes string lengths inside serialized values and can corrupt widget and plugin settings. **Add upgrade-insecure-requests as a safety net.** With this header the browser rewrites every http:// subresource on the page to https:// before requesting it: Content-Security-Policy: upgrade-insecure-requests It is a safety net, not a fix: if a host has no HTTPS, the request just fails, and the http:// URLs remain in your content and in your feeds. **Turn on HSTS once the site is clean.** `Strict-Transport-Security: max-age=31536000; includeSubDomains` tells the browser to never contact your domain over HTTP again. Start with a short max-age and raise it once you are sure every subdomain works over HTTPS. #### Check-list 1. The console shows no mixed-content warnings on the main templates. 2. No http:// URLs in `src`, `href`, `srcset`, `action` or CSS `url()`. 3. Old URLs in the database are replaced with a serialization-safe tool. 4. Third-party embeds load over HTTPS or are removed. 5. `upgrade-insecure-requests` is set as a safety net. 6. HSTS is enabled after everything above is clean. ### Two dates that take the whole site down: certificate and domain expiry - URL: https://sitescan.top/blog/expiry-dates/ - Category: Infrastructure - Published: 23 September 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 5 min > Why auto-renewal still fails, what changes as certificate lifetimes shrink to 47 days, how a domain actually lapses, and the checks that catch both in time. Most outages are partial: one page is slow, one form is broken. Two events are total. When the TLS certificate expires, every browser shows a full-screen warning. When the domain registration lapses, the name stops resolving at all. Both are scheduled months in advance, and both still catch teams by surprise. #### "But we have auto-renewal" ACME clients such as certbot renew Let's Encrypt certificates on their own, which is exactly why nobody watches them. The failures we see are rarely in the client itself: - **DNS changed.** The domain moved to a new host or CDN, and the HTTP-01 challenge now lands on a server that knows nothing about it. - **A firewall blocks port 80.** Someone closed plain HTTP "for security"; the HTTP-01 challenge needs it. - **A redirect on `/.well-known/acme-challenge/`.** A catch-all rule sends it to the homepage or a login page, and validation fails. - **The cron job died with the old server.** The site was migrated, the renewal timer was not. - **Renewed on disk, never loaded.** certbot wrote a new file, but nginx was not reloaded and keeps serving the old certificate from memory. - **Another copy elsewhere.** A CDN or load balancer terminates TLS with its own certificate, uploaded by hand two years ago. #### Lifetimes are shrinking CA/Browser Forum ballot SC-081 cuts the maximum certificate lifetime in steps: 200 days from March 2026, 100 days from March 2027, 47 days from March 2029. Renewing by hand once a year is already over; by 2029 it would mean a manual change every month or so. Automation is no longer optional, which makes monitoring that automation the actual job. #### A valid date is not enough Two problems pass a date check and still break clients. A **missing intermediate certificate**: desktop browsers often fetch it themselves, while Android, curl and API clients fail. And a **weak signature**: anything signed with SHA-1 is rejected outright; look for `sha256WithRSAEncryption` or an ECDSA equivalent. #### How a domain actually lapses Domains rarely expire through neglect alone. Typically the card on file at the registrar has expired, and the renewal notices go to the mailbox of an employee who left in 2021. What follows depends on the TLD and registrar, but the usual sequence is: the expiry date passes; the registrar may set **clientHold**, which pulls the domain out of DNS; an auto-renew grace period runs, often up to 45 days, when renewal is still cheap; then **redemption**, around 30 days, when it costs a restoration fee; then **pendingDelete**, about five days, when nothing can be done. After that the name is released, and drop-catching services register valuable names within seconds. Two more things belong in the same review. **Transfer lock** (`clientTransferProhibited`) should be on, so the domain cannot be moved away quietly. And **nameservers** should be at least two, ideally on separate networks or providers. #### Check it yourself What the server actually presents: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \ | openssl x509 -noout -enddate -issuer The `-servername` flag matters: without SNI you may get the default certificate instead of the one for your host. For the domain, RDAP is the structured successor to WHOIS: curl -s https://rdap.org/domain/example.com Look at the `expiration` event, the registrar and the `status` list. #### Monitoring that works - **Alert at 30, 14 and 7 days.** One notice is easy to miss; three escalating ones are not. - **Check from the outside.** Test what a browser receives, not the file on disk. That catches the missed reload, the CDN copy and the broken chain. - **Check every hostname.** `www`, `api`, `mail` and the apex often carry different certificates from different places. A SiteScan report shows days left on the certificate, its issuer and signature algorithm, days left on the domain, the registrar, registry status codes and whether transfer lock is on. Watching a site re-checks them on schedule, so the reminder arrives while it is still routine. #### Check-list 1. The certificate on every hostname has more than 30 days left. 2. The full chain is served; the signature is SHA-256 or better. 3. Renewal is automated, and the reload after it is too. 4. The ACME challenge path is reachable over port 80 without redirects. 5. The registrar has a valid card and a shared, current email address. 6. Domain auto-renew and transfer lock are on. 7. There are at least two nameservers. 8. Alerts fire at 30, 14 and 7 days. ### Being quotable: how AI assistants read your site - URL: https://sitescan.top/blog/ai-visibility/ - Category: SEO - Published: 9 September 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 4 min > Answer engines cite pages they can parse, attribute and trust. What that means in practice, and which of your pages currently fail it. A growing share of visits now begins with an assistant summarising the web rather than a list of links. The mechanics are less mysterious than the discourse suggests: an assistant fetches pages, extracts what it can parse, and cites the sources it can attribute. Every one of those verbs is a technical requirement you can check. #### Can it fetch the page? Most assistants crawl without executing JavaScript, or execute it with a short budget. A page that renders its content client-side may be, to that crawler, an empty shell with a loading spinner. Server-render or prerender the text you want quoted — this is the same requirement search engines had, applied more strictly. Then check what your robots.txt says. Assistant crawlers use their own user agents, and a blanket `Disallow` written for scrapers years ago may now be excluding you from answers. That is a policy decision worth making deliberately rather than inheriting. #### Can it parse the meaning? Extraction favours documents with visible structure: - **One h1, then h2 and h3 in order.** Skipped levels and headings chosen for their font size make the outline unreadable. - **The answer near the question.** A heading phrased as a question with the answer in the first paragraph below it is the most citable shape there is. - **Facts in text, not in images.** A price, a spec table or a deadline rendered as a picture is invisible to extraction. So is text inside a video. - **Structured data that matches the page.** Product, Article, FAQPage and Organization markup remove ambiguity about what a number means. #### Can it attribute you? Assistants cite sources they can name. That means an explicit author, a publication and modification date, a stable canonical URL, and an Organization block that says who you are. Pages with no author and no date are the first to be summarised without credit — the content is used, the link is not shown. #### Does it trust the page? Trust here is mundane: does the page contradict itself, is the date plausible, does the linked policy exist, do the internal links resolve. A page full of broken links and a copyright notice from 2019 reads as abandoned to a model for the same reason it does to a person. #### What to check on your own site Take your twenty most valuable pages and ask, for each: is the main text in the served HTML, without JS? is there one h1 and a sensible heading order? does a question in a heading have its answer in the next paragraph? are the key facts text rather than image? is there an author, a date and a self-referencing canonical? is structured data present and consistent with the visible content? Most sites fail three or four of these on most pages, and every one of them is a small, mechanical fix. None of it is a new discipline — it is the same crawlability, structure and honesty that search rewarded, now with a stricter reader that will happily answer from somebody else's page if yours is hard to read. ### Invalid HTML: which errors browsers forgive and which cost you - URL: https://sitescan.top/blog/html-validity/ - Category: HTML - Published: 8 September 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 3 min > Duplicate ids, unclosed tags, nested forms. The markup mistakes that survive because the browser repairs them, and the ones that quietly break behaviour. Browsers are forgiving by design: the HTML parser has a documented recovery procedure for almost any malformed input. That forgiveness is why invalid markup survives for years — and why some of it does real damage while nobody notices. #### The errors that actually break things **Duplicate ids.** `document.getElementById` returns the first match, and only the first. A label points at the wrong field; a script wires a handler to an element nobody clicks. This is the single most common finding on component-based sites, because an id hard-coded inside a component becomes a duplicate the moment the component renders twice. **Nested forms.** HTML does not allow them and the parser silently drops the inner one. The submit button inside it then does nothing, and the code looks correct in the editor. **Labels with no target.** `for="email"` with no `id="email"` breaks the click-the-label behaviour and removes the accessible name — one mistake that costs both usability and accessibility. **Interactive elements nested inside each other.** A button inside a link, or a link inside a button, produces inconsistent behaviour between browsers and unpredictable keyboard focus. **Duplicate attributes.** `<input value="a" value="b">` — the second is discarded, usually the one someone added later to fix a bug. #### The errors that are mostly cosmetic An unclosed `<li>`, a stray `&` that should have been `&`, an obsolete `<center>`, a missing `type` on a script tag. The parser handles all of them and the rendered page is identical. They are worth fixing when they are cheap, but they do not deserve a sprint. The one caveat: unclosed tags in **table** and **list** structures can change the shape of the DOM tree rather than just the markup, which does move content on the page. Treat those as real. #### Why linting the source is not enough Templates are assembled at runtime. A component that is valid on its own becomes invalid in a page where it appears twice, or inside a wrapper that already opened a form. Your linter reads files; the browser sees the assembled document. The only reliable check is on the rendered HTML of real pages: for each crawled page: parse the served HTML ids seen more than once? forms nested inside forms? label[for] without a matching id? interactive elements inside interactive elements? Run it across the whole site and group by template — like most markup problems, one bad component explains a hundred bad pages. #### What it costs when you skip it Nothing dramatic, which is exactly the trouble. A form that cannot submit on one template. A screen reader announcing the wrong field. A click handler bound to an invisible duplicate. Each looks like an isolated bug, gets a ticket, gets a workaround — and the actual cause, three lines of markup, stays in place, ready to produce the next isolated bug. ### robots.txt and sitemap.xml: two files that decide what gets indexed - URL: https://sitescan.top/blog/sitemap-robots/ - Category: SEO - Published: 6 September 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 4 min > The difference between blocking a crawl and blocking an index, why a stale sitemap wastes crawl budget, and the one-line mistake that hides a whole section. These two files are the shortest configuration on your site and the easiest place to do lasting damage. A single line in robots.txt can remove a section from search, and it will not look like anything is wrong — the pages still load, the links still work, and traffic simply stops. #### robots.txt does not do what most people think It controls **crawling**, not **indexing**. A blocked URL can still appear in results — without a description, because the crawler was never allowed to read it. If your goal is "this page must not appear in search", robots.txt is the wrong tool: use `<meta name="robots" content="noindex">` and make sure the page is crawlable, because a crawler that cannot fetch the page will never see the noindex. That combination is the classic mistake: Disallow: /private/ # in robots.txt <meta name="robots" content="noindex"> # on the page The two cancel out. The engine cannot fetch the page, so it never learns it should drop it. #### What belongs in robots.txt Search endpoints, faceted filter URLs, endless calendars, cart and account paths — anything that generates infinite variations and no value. Keep it short and specific. Two rules to keep in mind: the most specific matching rule wins, and blocking `/assets/` or `/static/` can stop the crawler rendering your pages at all, which affects how they are evaluated. Also point to your sitemap from it: Sitemap: https://site.com/sitemap.xml #### What belongs in the sitemap Only URLs you actually want indexed: status 200, canonical to themselves, not blocked in robots.txt, not `noindex`. Every URL that fails one of those tests is a wasted hint, and a sitemap full of wasted hints gets trusted less. `lastmod` is worth setting honestly — meaning it changes when the content changes, not on every build. A sitemap where every page claims to have been modified today teaches the crawler to ignore the field. `priority` and `changefreq`, by contrast, are largely ignored by the major engines; do not spend time tuning them. Over 50,000 URLs or 50 MB, split into several files behind a sitemap index. Generate it from the same source that generates your routes, so a deleted page disappears from both at once. #### The failures worth checking for - URLs in the sitemap that redirect, 404, or are blocked in robots.txt. - Pages that exist and are linked from navigation but appear in no sitemap. - A `Disallow: /` left over from a staging environment and deployed to production. This one costs a site its entire search presence, and it happens more often than anyone admits. - A sitemap that has not changed since the last CMS migration. #### Verify from outside The check that matters is not "does the file look right" but "does what it says match the site". Crawl the site, take the link graph, take the sitemap, and compare the two sets: pages in the crawl but not the sitemap, URLs in the sitemap that the crawl cannot reach or that answer with anything but 200. The disagreements between those two lists are, reliably, the most valuable SEO findings a site has. ### Mobile usability: the defects a desktop review never sees - URL: https://sitescan.top/blog/mobile-usability/ - Category: Mobile - Published: 4 September 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 4 min > Viewport, tap targets, horizontal scroll and the keyboard that covers the button. The checks that decide whether a phone visitor can finish. Most teams review their site on a laptop and ship. Most of their traffic is on a phone. The gap between those two sentences is where a specific family of defects lives — none of them visible at 1440 pixels wide, all of them capable of ending a purchase. #### Start with the viewport One missing line makes a phone render the page at desktop width and shrink it: <meta name="viewport" content="width=device-width, initial-scale=1"> Two variations of it are worse than the omission. `maximum-scale=1` and `user-scalable=no` block pinch-zoom, which is a hard accessibility failure for anyone with low vision, and browsers increasingly ignore them anyway. Nothing about your layout is worth taking zoom away from a reader. #### Tap targets A fingertip is about nine millimetres. Interface guidelines settle on roughly 44 by 44 CSS pixels as a minimum, with a few pixels of separation. Below that, taps land next to their target and the visitor blames the site rather than their thumb. Where it goes wrong is predictable: icon-only buttons scaled down for mobile, links in a dense footer, checkbox labels that are not clickable, and pagination controls sized for a mouse. The pattern to look for is a small control **next to another small control** — a mis-tap on an isolated button costs a moment, a mis-tap in a row of five costs a wrong action. #### Horizontal scroll If any element is wider than the viewport, the whole page slides sideways and text runs off the edge. The usual culprits are a fixed-width table, an image without `max-width: 100%`, a code block, or a container with a `min-width` copied from the desktop design. The test is one line in the console: document.documentElement.scrollWidth > window.innerWidth Run it at 360 pixels on every template, not just the home page. #### The keyboard problem On a phone, the on-screen keyboard covers the bottom third of the screen. A submit button fixed to the bottom of a form ends up underneath it. So does the error message that explains why the form did not submit. This is the single most common reason a mobile form "does nothing" — the feedback exists, off-screen. Check with the keyboard open, not with the field merely focused in a desktop emulator. #### Text and inputs Font sizes below 16 pixels in an input make iOS zoom the page on focus, and the layout never quite recovers. Body text under 14 pixels is a readability problem in daylight. And every input deserves the right `inputmode` and `autocomplete` — a numeric keypad for a phone number is a two-attribute change that measurably lifts completion. #### Test at real widths Emulation in DevTools catches layout; it does not catch the keyboard, the browser chrome that eats a hundred pixels, or a tap that lands two millimetres off. Run the important flows on an actual device once a release, and automate the mechanical part — viewport meta, target sizes, overflow, input attributes — on every page, on every deploy. ### hreflang: the tag that breaks quietly and stays broken - URL: https://sitescan.top/blog/hreflang/ - Category: SEO - Published: 2 September 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 3 min > Why language annotations must be reciprocal, the three errors that make them useless, and how to verify a multilingual site without opening every page. A multilingual site has a specific failure mode: everything looks right in every language, and the wrong version ranks in every country. The cause is almost always hreflang — a tag nobody sees, nobody tests, and everybody copies from a template. #### What it is for hreflang does not decide which page ranks. It tells a search engine that several pages are the same content in different languages, so the engine can swap in the version that matches the user. Get it right and your German visitor lands on the German page instead of the English one. Get it wrong and the engine falls back to guessing. The shape is unremarkable: <link rel="alternate" hreflang="en" href="https://site.com/page/"> <link rel="alternate" hreflang="de" href="https://site.com/de/page/"> <link rel="alternate" hreflang="x-default" href="https://site.com/page/"> #### The rule that catches everyone **Annotations must be reciprocal.** If the English page lists the German one, the German page must list the English one back — and both must list themselves. A one-way annotation is ignored entirely, which is why a site can be full of correct-looking tags that do nothing. This is also why hreflang breaks during ordinary work. Someone adds a fourth language and updates three templates instead of four. Someone deletes a page and its former siblings keep pointing at it. Nothing errors, nothing looks different, and the annotation set silently stops being valid. #### Three errors, in order of frequency **Pointing at redirects or 404s.** The target must be the final URL, with a 200. A link to an address that redirects wastes the annotation. **Wrong codes.** The language is ISO 639-1, the optional region is ISO 3166-1 Alpha-2, and the order is language-then-region: `en-GB`, not `gb-en`. `en-UK` is not a country code. A bare `de` covers every German speaker; use `de-AT` only when the content genuinely differs. **Missing x-default.** Without it the engine has no instruction for visitors who match none of your languages. The x-default should point at your language selector or your most general version. #### Verifying without opening every page The check is mechanical, which means it should never be manual: for each page: collect its alternates for each alternate: does it return 200? does it point back at this page? is the code well-formed? is there exactly one x-default in the set? Run it on a crawl of the whole site. On a site with four languages and a thousand pages that is four thousand relationships — a list no human maintains by hand, and precisely the kind of thing that stays broken for a year because nobody has a reason to look. #### One more consistency check The `lang` attribute on `<html>` should agree with the hreflang for that page, and the canonical of each language version should point at itself, not at the English original. Those two mistakes together produce the classic symptom: the English page ranking in every market, and the translated pages appearing nowhere at all. ### Caching and compression: the free speed nobody claims - URL: https://sitescan.top/blog/http-caching/ - Category: Infrastructure - Published: 30 August 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 3 min > Cache-Control that actually caches, why a hashed filename changes everything, and the compression setting still missing on half the sites we scan. Most performance work is expensive: rewriting components, deferring scripts, arguing about a framework. Two settings are not. They live in a config file, they take an afternoon, and they are still wrong on a large share of production sites. #### Compression first Text compresses by seventy to eighty percent. HTML, CSS, JavaScript, JSON, SVG — all text. If the response has no `Content-Encoding`, you are shipping four times the bytes for nothing. Brotli beats gzip by roughly fifteen percent on the same content and is supported everywhere that matters; keep gzip as the fallback. Two mistakes are common: compressing images (JPEG and PNG are already compressed — you spend CPU to save nothing) and forgetting that the setting applies per MIME type, so a subdomain serving JSON from a different config quietly ships it raw. #### Cache-Control, honestly The header answers two questions: may this be stored, and for how long. The useful patterns are few. **Hashed assets** — `/app.4f2a91.js`: Cache-Control: public, max-age=31536000, immutable A year, and never revalidated. Safe precisely because the filename changes when the content does. This is the single biggest win available, and it only works if your build actually hashes filenames. **HTML**: Cache-Control: no-cache Counter-intuitively this does not mean "do not cache". It means "store it, but revalidate before use". The browser sends an `If-None-Match` and usually gets a 304 with no body — fast, and never stale. **Personalised responses**: Cache-Control: private, no-store For anything a shared cache must never keep: account pages, carts, anything behind a login. #### The mistakes that cost the most **Short max-age on hashed files.** `max-age=600` on a filename that includes a content hash throws away the entire benefit. **Long max-age on unhashed files.** `/logo.png` cached for a year means the redesign does not reach anyone who visited before it. **Missing ETag or Last-Modified on HTML.** Without a validator the browser cannot ask "has this changed"; it re-downloads the whole document. **Vary set wrong.** `Vary: User-Agent` fragments a CDN cache into thousands of near-identical entries and is almost never what you meant. #### Prove it rather than assume it Configuration is one thing; what actually reaches the browser is another, because a CDN, a proxy or a hosting panel may rewrite headers on the way out. The check is per-response, across the whole site: for each response: content-encoding present on text/*? cache-control matches the asset class? etag or last-modified on documents? Run it after each deploy. This class of regression is silent — nothing breaks, the site just gets slower and the bill for bandwidth goes up — which is exactly why it survives for years when nobody looks. ### Cookie banners that do nothing: trackers firing before consent - URL: https://sitescan.top/blog/cookie-consent/ - Category: Privacy - Published: 28 August 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 3 min > The banner is the visible part. What matters is which requests leave the browser before anybody clicks Accept — and how to see them. Almost every site has a consent banner. A surprising number of them are decorative: the scripts they are supposed to gate have already loaded by the time the banner renders. The banner asks permission for something that has happened. #### What regulators actually look at Not the banner design. The question is narrow and technical: **between page load and the click on Accept, did anything leave the browser that identifies the visitor?** That includes analytics beacons, advertising pixels, session recorders, embedded video players, chat widgets, font services that log IPs, and any cookie set with an identifier in it. Two things follow. Refusal must be as easy as acceptance — a "Reject all" button on the first screen, not three clicks into a settings modal. And a pre-ticked box is not consent anywhere in the EU, which has been settled law since Planet49. #### Where the leaks come from **Tag managers.** The container itself is usually harmless; the tags inside fire on page view unless every single one is bound to a consent trigger. One forgotten tag is one violation. **Third-party embeds.** A YouTube iframe or a map sets cookies the moment it renders. The fix is a click-to-load placeholder, not a note in the privacy policy. **Self-hosted assumptions.** A font or a script loaded from a CDN sends the visitor's IP to that CDN. That is a transfer, whether or not you think of the CDN as a tracker. **The banner script itself.** Several consent platforms set an identifier before any choice is made — ironically, the tool bought for compliance. #### How to see the truth Reading the code will not tell you; the network will. Load the page in a clean profile, do not click anything, and record every request: requests before consent .filter(r => r.setsCookie || r.thirdParty) .groupBy(r => r.domain) Anything in that list that is not strictly necessary for the page to function is a finding. Repeat with "Reject all" clicked — a depressing number of sites fire the same requests either way — and again after Accept, to confirm the tags that should fire actually do. #### The pages people forget The consent state has to hold across the whole site, not just the home page. Campaign landing pages built outside the CMS, old microsites on a subdomain, the checkout, and anything served by a different stack are where the exceptions live. A per-page crawl catches them; a manual check of the home page never will. #### Keep the legal pages honest The privacy policy should list the same processors your network log shows. When the two disagree, it is almost always the policy that is out of date — a vendor was swapped a year ago and nobody told legal. Checking that the linked policy, the cookie list and the actual requests agree takes one crawl and settles the question that a regulator will otherwise ask you to answer under time pressure. ### Structured data: markup errors live in templates, not pages - URL: https://sitescan.top/blog/structured-data/ - Category: SEO - Published: 26 August 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 3 min > Why one broken component costs four hundred pages their rich results, and how to validate schema.org across a whole site in one pass. Structured data is the one part of SEO where a machine tells you plainly whether you got it right. Either the page qualifies for a rich result or it does not, and the reason is always specific: a missing property, a wrong type, a price without a currency. #### What it buys you Rich results are not a ranking boost. They are screen real estate: a review row, a price, a stock status, an FAQ accordion, a recipe time. On a crowded results page that is the difference between one line and four. The types that repay the effort on most sites: - **Product** — price, availability, and reviews if you actually have them. - **BreadcrumbList** — replaces the raw URL in the snippet with a readable path. - **Article** — headline, date, author; the entry ticket to news surfaces. - **Organization** — logo, social profiles, contact points; feeds knowledge panels. - **FAQPage** — only where a real question and answer exist on the page. #### The errors that recur **Markup describing something the page does not show.** A price in JSON-LD that the visitor never sees is the fastest way to lose the rich result entirely. **Wrong nesting.** `offers` outside `Product`, `author` as a string instead of a `Person`. Valid JSON, invalid schema. **Dates in the wrong format.** `datePublished` must be ISO 8601. "12 March 2026" is not. **Copy-pasted IDs.** Every product carrying `@id: "product-1"` because the template hard-codes it. #### One fix, four hundred pages Here is the part teams miss: structured data is emitted by a template, so an error is never on one page — it is on every page that renders that component. That cuts both ways. A report that lists two thousand invalid pages is really listing three broken components, and fixing three components turns two thousand pages green in one deploy. So group findings by template before you plan the work: findings .groupBy(f => f.template ?? inferTemplate(f.url)) .sortBy(group => -group.pages) Fix the group with the most pages first. The list collapses fast. #### Validate in the pipeline, not by hand Testing tools check one URL at a time, which is fine for a spot check and useless as a guarantee. What you want on every release is a crawl that parses every `application/ld+json` block, validates it against the type, and fails the build on new errors. That way markup breaks in review, not in the search results a week later. #### A note on AI answers Assistants that summarise pages lean on the same explicit markup, for the same reason search engines do: it removes guesswork about what a number on the page means. Clean structured data is no longer only about the blue links — it is about being quotable. ### Redirect chains: the tax you pay on every old link - URL: https://sitescan.top/blog/redirect-chains/ - Category: Links - Published: 24 August 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 3 min > Where three-hop redirects come from, what they cost in latency and crawl budget, and how to flatten them without breaking the old URLs. A redirect is a promise that an old address still works. A chain of redirects is that promise kept three times over, each hop costing a round trip. Nobody plans them: they accumulate, one migration at a time. #### How a chain is born Year one: `/products/shoes` moves to `/catalog/shoes`. Year two: HTTP goes to HTTPS. Year three: the site standardises on trailing slashes. Year four: the catalogue moves under a locale prefix. Now the original link in someone's newsletter does this: http://site.com/products/shoes → https://site.com/products/shoes (301) → https://site.com/catalog/shoes (301) → https://site.com/catalog/shoes/ (301) → https://site.com/en/catalog/shoes/ (301) Four requests before a byte of content. On a mobile connection that is most of a second, paid by exactly the visitors who trusted an old link. #### What it actually costs **Latency.** Each hop is a full round trip: DNS is cached, the connection may be reused, but the request and response are not free. Three hops on a 3G connection is comfortably over a second. **Crawl budget.** Search engines follow a limited number of hops — commonly around five — and they spend a fetch on each one. On a large site the crawler burns its budget on redirects instead of new pages. **Signal decay.** Modern engines pass ranking signals through redirects, but every extra hop is another chance for one link in the chain to be misconfigured, and a chain that ends in a 404 passes nothing at all. **Analytics.** Referrer and UTM parameters survive most redirects and get dropped by some. Chains are where campaign attribution quietly disappears. #### Flattening without breaking anything The rule is simple: **every old URL redirects to the final destination in one hop.** Not to the next step in history — to where the content lives today. 1. Crawl the site and record every redirect with its full chain. 2. For each starting URL, resolve the terminal target. 3. Rewrite the rules so the start points straight at the terminus. 4. Keep the old rules. Deleting them turns links into 404s; the point is to shorten chains, not remove redirects. Watch for two traps. A **loop** — A to B to A — serves nothing at all and usually comes from two rules that each think they are canonical. And a **redirect to a 404**, which is worse than a plain 404, because the crawler has to spend two requests to learn the same bad news. #### Keeping it flat Chains reappear after every migration, so measure them the way you measure anything else that regresses: crawl on a schedule, alert when the maximum chain length grows, and treat "more than one hop" as a defect rather than a fact of life. Internal links deserve stricter treatment. An external link you cannot fix; your own navigation pointing at an address that redirects is simply a stale href — update it and the hop disappears entirely. ### Titles and descriptions: the tags that decide the click - URL: https://sitescan.top/blog/meta-tags/ - Category: SEO - Published: 22 August 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 3 min > What a search engine actually shows, why it rewrites your title, and how to audit metadata across a whole site instead of page by page. A title tag is not a header. It is an advertisement that competes with nine others on the same screen, and it is the only part of your page most people ever read. On a site of any size the metadata quietly rots: templates duplicate, pages get copied, a migration wipes half the descriptions. #### What actually gets shown Search engines rewrite titles on roughly a third of queries. They do it when the title is stuffed with keywords, when it repeats the brand twice, or when it says nothing about the query. The way to keep your own wording is to make it the best available option: specific, front-loaded, one idea. - **50–60 characters.** Longer is not penalised, it is truncated. - **The distinguishing word first.** "Winter tyres 205/55 R16" beats "Online store — buy tyres". - **Brand at the end, once.** A separator and the site name is enough. Descriptions are not a ranking factor and never have been. They are a click factor: the snippet is what the reader compares against the other results. Write the sentence that answers the query, not a summary of the page. #### The four failures worth hunting **Duplicates.** Two hundred product pages sharing one title is the most common finding on an e-commerce site, and it is always a template that forgot a variable. **Empty descriptions.** The engine then quotes whatever text it finds first — often a cookie notice or a navigation label. **Titles from the CMS.** `Home | Home | My Site` survives for years because nobody looks at the tab. **Open Graph missing.** Shared links then show a grey box, and the click-through on social drops for a reason nobody attributes to markup. #### Auditing at site scale Checking metadata by hand works for a landing page and fails at a hundred. The pattern that scales: for each crawled page: title.length, description.length hash(title) → count duplicates og:title, og:image present? canonical == self? That is a crawl, not a spreadsheet. Run it after every release and the class of problem disappears — a template regression is caught while it is still one page, not two thousand. #### Canonical, briefly Half of "duplicate title" findings are actually one page reachable at four URLs: with and without a trailing slash, with and without `?utm_source`. Fix the canonical and the duplicates resolve themselves. #### The check that pays for itself Sort your pages by traffic, take the top fifty, and read their snippets as a stranger would. If a snippet does not say what the page gives you, no ranking improvement will save it — the click goes to whoever wrote a clearer sentence. ### Core Web Vitals: LCP, INP and CLS without the myths - URL: https://sitescan.top/blog/core-web-vitals/ - Category: Performance - Published: 18 August 2026 - Updated: 26 August 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 3 min > What Google's three metrics actually measure, why lab numbers disagree with field data, and which fixes move the needle. Core Web Vitals are three numbers Google collects from real users. They get confused with "the Lighthouse score", but they are not the same thing: Lighthouse is a lab run under sterile conditions, the Vitals come from the field — from people on slow 4G with three-year-old phones. #### LCP — when the user sees the main thing Largest Contentful Paint records the moment the largest element in the viewport renders: usually a banner, an article cover or the H1. The threshold is **2.5 seconds** at the 75th percentile. Typical causes of a slow LCP, in order of frequency: 1. The hero image loads late. `fetchpriority="high"` on the LCP image and a `preload` for the heading font both help. 2. Slow server response. Above 600 ms TTFB, optimising the frontend is pointless — fix caching and the database first. 3. Render-blocking CSS. A single `@import` inside an external file costs a full network round trip. 4. Client-side rendering. If the LCP element only appears after hydration, JS download and parse time are added on top. #### INP — the price of interactivity Interaction to Next Paint replaced FID in 2024 and is considerably stricter. It takes not the first interaction but effectively the worst one in the session: from the click to the next paint. The threshold is **200 ms**. The main culprit is long tasks on the main thread. A handler that synchronously recalculates the cart, filters a 5,000-item list or calls `getBoundingClientRect` in a loop can hold the thread for 400 ms. Three remedies: split the work with `scheduler.yield()`, take analytics and third-party scripts off the critical path, and move heavy computation into a Web Worker. #### CLS — a layout that does not jump Cumulative Layout Shift sums up unplanned content movement. The threshold is **0.1**. The causes are almost always the same: - images and iframes without `width`/`height` or `aspect-ratio`; - banners and cookie bars injected into the flow after load; - web fonts without `font-display: optional` or without matched fallback metrics. #### Lab versus field A lab run is deterministic and excellent for catching regressions in CI. Field data (CrUX, your own RUM) shows reality, but with a 28-day lag. The workable arrangement is to measure both and investigate only the lab regressions the field confirms. #### The order of work that pays off Measure the distribution first, not the average: p75 and p95 per page type. Then find the single template with the worst numbers — usually a product page or search — and fix it completely. Small corrections smeared across the whole site almost never move p75. And check the result on a real device, not on your laptop: for INP the gap between a MacBook and a budget Android reaches a factor of five. ### Broken-link audits: finding every 404 before your users do - URL: https://sitescan.top/blog/broken-links/ - Category: Links - Published: 5 August 2026 - Author: Дмитрий Орлов, QA lead - Reading time: 3 min > Why a sitemap-based check misses half the problems, why a soft 404 is worse than a real one, and how to run a recurring audit. A broken link rarely arrives alone. It is usually a symptom: a renamed section, a redesign, a decommissioned subdomain — and dozens of dead addresses spread across the site that nobody knows about until a customer writes in. #### Why sitemap.xml alone is not enough A sitemap-based check only finds the pages you declared yourself. It knows nothing about: - links in article bodies to external resources that have since closed; - buttons whose `href` is assembled in JavaScript; - page resources — images, fonts, scripts — returning 404; - links in the footer and menu pointing at pages excluded from the sitemap. A complete audit is a graph crawl: take a start URL, extract every `<a href>`, `<img src>`, `<link>` and `<script src>`, recurse within the domain, and record the status code for every address. #### Soft 404 — the nastiest case The server answers **200 OK** while the page says "Product not found". For a user it is a dead end; for a search engine it is a valid page, dutifully indexed. You detect it through indirect signals: suspiciously little content, boilerplate phrasing, a missing H1, a redirect to the homepage that loses the path. #### What to do with each class of error - **404** — the page does not exist. Redirect (301) to the closest relevant address, or serve a genuinely useful error page. - **410** — deliberately removed. Leave it and strip the inbound links. - **500** — an application error. File a bug, not a redirect. - **403** — locked by permissions. Check whether it was meant to be public. - **Timeout** — a slow external resource. Take it off the critical path or cache it. Redirect chains are their own category. Three consecutive 301s work, but they cost up to half a second on a slow network and dilute link equity. Collapse chains to a single hop. #### Regularity beats completeness A one-off audit of 10,000 pages produces a handsome report that is stale within a month. More practical: 1. A full crawl once a week, on a schedule. 2. A quick crawl of the key templates after every release. 3. An automated check of external links once a month — they die more often than internal ones. 4. A CI gate: the release fails if new internal 404s appear. #### How not to breed redirects When you move a section, prepare the old-to-new address map **before** the deploy, not after. One 301 layer in nginx or an edge function is cheaper than ten rules accumulated over the years. And delete old rules once traffic through them drops to zero — otherwise in two years nobody will dare touch that file. ### Console errors: which ones cost sales and which are noise - URL: https://sitescan.top/blog/console-errors/ - Category: JavaScript - Published: 22 July 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 3 min > JavaScript errors sorted by user impact, the source-map trap, and how to separate your own code from third-party widgets. Open DevTools on any commercial site and you will find between three and thirty red lines. Some are harmless; some quietly eat conversion every day. The difference is not in the error text but in what happens to the user afterwards. #### Three levels of impact **Blocking.** The exception is thrown before handlers are attached — the "Buy" button simply does not respond. The classic is `Cannot read properties of undefined` during module initialisation. The user sees a page that looks functional and does nothing. **Partial.** One widget breaks: a map, a slider, a shipping calculator. The rest of the page is alive, but the flow never completes. **Noise.** An analytics error, a request blocked by an extension, `ResizeObserver loop limit exceeded`. No effect on behaviour, but they mask the real problems in the log stream. #### What almost always deserves a fix - `Uncaught (in promise) TypeError` — an unhandled reject, usually with an incomplete network request behind it. - `Failed to fetch` on your own domain — that is CORS or a backend that fell over, not "a browser glitch". - `Hydration failed` in React/Vue — server and client markup diverged; missing handlers follow. - Errors inside `submit` handlers — a direct route to an unsent form. #### The source-map trap Without source maps the stack reads `main.4f2a.js:1:88213`, and the investigation ends there. The correct setup: generate source maps per release, upload them to your monitoring system, and **do not ship them next to the bundle** — otherwise your source becomes public. In most bundlers that is the `hidden-source-map` option. #### Separate somebody else's code Chat, advertising and A/B testing scripts produce half the errors and almost none you can fix. Filter by origin: window.addEventListener("error", (e) => { const own = e.filename?.startsWith(location.origin); report(e, { severity: own ? "error" : "third-party" }); }); That keeps your own errors from drowning in other people's. Set a budget separately: if a third-party widget contributes more than N errors a day, it gets removed or replaced. #### Check before production Runtime errors are caught by neither linter nor type system: they arise on real data. A cheap way to get ahead of them is to run the key pages through a headless browser on every release and fail the build when new console errors appear. Five minutes of CI against a week of a silently broken checkout. And keep history: the same error returning after every deploy is not a "flaky bug", it is an unresolved race during loading. ### Dead forms: why enquiries never arrive, and how to catch it - URL: https://sitescan.top/blog/form-testing/ - Category: Forms - Published: 9 July 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 3 min > Seven places a form submission breaks, a checklist for contact and checkout forms, and what belongs in a test submission. The form is the most expensive part of a website: enquiries, sign-ups and orders all arrive through it. It is also the most fragile: it depends on the frontend, the backend, email, spam protection and the CRM all at once. Any link breaks and the user sees "Thank you!" while you see nothing. #### Where the chain snaps 1. **Validation.** The email regex rejects an address with a plus sign or a `.digital` domain. The user cannot tell what is wrong and leaves. 2. **The button.** The handler never attached because of a JS error higher up the page — the form does not submit at all. 3. **The request.** CORS, an expired CSRF token, a 500 from the backend. The frontend reports success because it never checks the status code. 4. **Spam protection.** The captcha fails to load in some regions; the honeypot catches genuine users with autofill. 5. **Email.** SPF/DKIM are missing — the message lands in spam or bounces. 6. **The CRM.** The webhook broke a month ago, there are no retries, and enquiries vanish silently. 7. **Analytics.** The conversion event never fires, so nobody notices the drop. #### The checklist - Submit with **empty** fields: a clear message appears and focus moves to the first invalid field. - Submit with **valid** data: both the email **and** the CRM record arrive. Check both channels, not one. - Edge cases: an address with a plus sign, a non-ASCII domain, a phone number with spaces and brackets, a one-letter name. - Double-click the button: two enquiries must not be created. - Submit **without JavaScript**, or with a script error: is there any degradation? - Mobile: does the keyboard cover the button, are `inputmode` and `autocomplete` correct? - Accessibility: every field has a `<label>`, errors are linked via `aria-describedby`, and the error state is not conveyed by colour alone. #### Test submissions that do not get in the way Mark synthetic submissions so they can be filtered in the CRM and excluded from analytics: a dedicated address space such as `qa+2026-08@`, a technical field `source: monitoring`, a fixed string in the comment. Otherwise in six months sales will be cold-calling robots. #### Monitoring instead of a one-off check A manual check finds problems at the moment of checking. Real breakage happens between checks — after a plugin update, a token rotation or a change of mail provider. What works: fill in the key forms automatically once a day, verify the status code, the email delivery and the CRM record, and alert on any mismatch. Watch the **number of enquiries per day** separately: a sudden drop to zero is the most reliable sign that a form has died, even when it technically answers 200. ### WCAG accessibility: what automation finds and what it misses - URL: https://sitescan.top/blog/accessibility/ - Category: Accessibility - Published: 24 June 2026 - Author: Ольга Мирошник, Product analyst - Reading time: 3 min > Automated tests cover about a third of the WCAG criteria. What they catch, what they miss, and how to check the rest by hand in half an hour. Automated accessibility checks are a good first-pass filter and a poor guarantee. Estimates put their coverage at **25–40%** of the WCAG 2.2 criteria. The rest needs a person, because a machine does not understand meaning. #### What automation finds reliably - Images without `alt`. - Insufficient contrast between text and background (level AA — 4.5:1 for body text, 3:1 for large text). - Form fields without an associated `<label>`. - Gaps in the heading hierarchy: an H2 straight after an H4. - Duplicate `id` values and invalid ARIA roles. - A missing `lang` on the document. These are cheap fixes and they belong in CI: wire axe-core into the e2e run and fail the build on critical violations. #### What the machine will miss **Meaningful alt text.** `alt="image"` passes the check and carries nothing. For decorative graphics the right answer is an empty `alt=""`, not a missing attribute. **Focus order.** Tabbing must follow the visual order. A modal has to trap focus and return it to the triggering button on close. Neither rule is checkable statically. **Link meaning out of context.** Twenty "Learn more" links on a page are valid HTML and useless navigation for a screen reader. **Dynamic updates.** A form error appears or the cart counter changes — that needs `aria-live`, otherwise the change goes unannounced. **Keyboard traps.** A custom select or carousel you cannot tab out of. #### A thirty-minute manual pass 1. Put the mouse away. Walk the key flow with the keyboard only: Tab, Shift+Tab, Enter, Esc, arrows. 2. Make sure focus is **always visible**. `outline: none` without a replacement is the single most common failure. 3. Zoom to 200%. Nothing should be clipped or pushed off screen. 4. Turn on a screen reader (VoiceOver, NVDA) and listen to the first minute of the homepage. 5. Check the page in high-contrast mode and with images disabled. #### Why this is not only about disabled users Correct headings help search engines, `label` enlarges tap targets on mobile, and a visible focus ring saves time for anyone filling in a form from the keyboard. Accessibility almost always coincides with ordinary interface quality — its failures are simply more visible and more painful. And fix the target level: **WCAG 2.2 AA** is the practical reference point most regulatory requirements point to, European ones included. ### HTTP security headers: the minimum worth setting today - URL: https://sitescan.top/blog/security-headers/ - Category: Security - Published: 10 June 2026 - Author: Марк Лебедев, Frontend engineer - Reading time: 3 min > CSP, HSTS, X-Content-Type-Options and the rest: what actually protects you, what is obsolete, and in which order to roll them out without an outage. Security headers are one of the rare cases where a few lines of configuration close whole classes of attack. And one of the rare cases where a careless rollout breaks the site in seconds. So the order matters as much as the content. #### Start with the safe ones These three can be enabled with almost no risk: **`X-Content-Type-Options: nosniff`** — stops the browser guessing content types. It closes the scenario where a user-uploaded "text" file is executed as a script. **`Referrer-Policy: strict-origin-when-cross-origin`** — stops leaking the full page path into somebody else's analytics. It is the browser default today, but stating it explicitly is more reliable. **`Strict-Transport-Security: max-age=31536000; includeSubDomains`** — HSTS forces HTTPS. Careful: enable it **only** once the whole site and every subdomain already run on HTTPS. There is no fast rollback — browsers remember the header for the entire max-age. Start at `max-age=300`, confirm nothing broke, then raise it. #### CSP — the most useful and the most dangerous Content-Security-Policy declares where scripts, styles and images may be loaded from. It blocks most XSS, and it takes the site down if the policy was written on a hunch. The right path has three steps: 1. Turn on observation mode: `Content-Security-Policy-Report-Only` with a reporting endpoint. Nothing is blocked, but you see what **would** be. 2. Collect reports for a couple of weeks and add everything legitimate to the policy — widgets, fonts, analytics. 3. Switch to the enforcing header. A minimal sensible policy for a site without inline scripts: Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com; font-src https://fonts.gstatic.com; img-src 'self' data:; frame-ancestors 'none'; base-uri 'self' The `frame-ancestors 'none'` directive supersedes the obsolete `X-Frame-Options` and closes clickjacking. #### What is no longer needed `X-XSS-Protection` is obsolete: modern browsers ignore it, and in older ones it was itself a vulnerability. `Feature-Policy` has been renamed `Permissions-Policy`. #### How to verify Headers are set at several layers — CDN, reverse proxy, application — and are easily lost or duplicated when infrastructure changes. Check the **actual response**, not the configuration, across several URL types: the homepage, a route from the SPA router, a static file, an API endpoint. The differences between them are the most common audit finding. And watch for regressions: a header accidentally dropped during a move to a new CDN gives no signal until it is too late. ### Images: cutting half the page weight in one sprint - URL: https://sitescan.top/blog/image-optimization/ - Category: Performance - Published: 27 May 2026 - Author: Анна Ковалёва, Performance engineer - Reading time: 3 min > Formats, dimensions, lazy loading and priorities. A practical order of work that halves page weight without losing quality. On a typical site images account for 50–70% of page weight. And they are almost always served at a resolution nobody will see, in a format from a decade ago, and without declared dimensions. It is the most predictable source of speed there is. #### Step 1: stop shipping pixels nobody sees A 2400 px wide image in a 600 px container is sixteen times the data required — area grows quadratically. The fix is `srcset` built around your real layout breakpoints: <img src="/img/hero-800.jpg" srcset="/img/hero-400.jpg 400w, /img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w" sizes="(max-width: 768px) 100vw, 800px" width="800" height="450" alt="…"> `width` and `height` are mandatory: without them the browser does not know the aspect ratio and the layout jumps — a direct contribution to CLS. #### Step 2: change the format AVIF averages 40–50% lighter than JPEG at the same quality, WebP 25–30%. Every current browser supports both. A `<picture>` block gives you a fallback: <picture> <source type="image/avif" srcset="/img/hero.avif"> <source type="image/webp" srcset="/img/hero.webp"> <img src="/img/hero.jpg" width="800" height="450" alt="…"> </picture> For interface screenshots and charts with flat fills, PNG is not rarely lighter than AVIF — measure rather than follow the rule blindly. #### Step 3: set priorities Lazy loading is not free. `loading="lazy"` on a first-screen image **slows** LCP down, because it defers the single most important request. The rule is simple: - images above the fold — `fetchpriority="high"`, no `lazy`; - everything else — `loading="lazy"` and `decoding="async"`. #### Step 4: delete what nobody needs The most effective optimisation is not optimising but removing. The decorative background nobody sees on mobile; the eight-banner carousel whose third slide reaches 4% of users; icons shipped as PNG that should be SVG. #### What to measure Look at two numbers rather than a "score": **image weight per page** and **time to LCP on a mobile network**. If weight halved and LCP did not move, the bottleneck is not the images but the request queue or the server response, and optimising graphics further is pointless. Set a budget — say, no more than 400 KB of images on a listing page. A budget enforced in CI works better than any agreement. ## Machine-readable - [llms.txt](https://sitescan.top/llms.txt): the short map this file is the long form of - [sitemap.xml](https://sitescan.top/sitemap.xml): an index over the two below - [sitemap-pages.xml](https://sitescan.top/sitemap-pages.xml): the pages and the blog - [sitemap-scans.xml](https://sitescan.top/sitemap-scans.xml): one entry per stored report - [robots.txt](https://sitescan.top/robots.txt) - [Atom feed](https://sitescan.top/blog/feed.xml): new articles, in full (also under /ru, /pl and /de) - [SiteScan.top](https://sitescan.top/): the site itself