# Website security scan in under a minute. Website security scan for small business websites. Check HTTPS, security headers, email records and trackers, then download a PDF with the fixes. ## What does a website security scan check? The scan runs 28 checks on your homepage. It covers HTTPS and redirects, browser security headers, cookies, email and DNS records, third-party scripts, trackers and outdated libraries. Each result says what to fix, what to look at and what we could not check. ### HTTPS connection Does the website respond securely and ask browsers to keep using encrypted connections? ### Browser protection Can the site block unwanted scripts, stop other sites framing it and stop browsers guessing file types? ### Cookies, trackers and software We check cookie settings, trackers that load before visitors agree to them, outdated JavaScript libraries and software versions the site gives away. ## Get more from your website security scan ### What a website security scan tells you A website security scan shows the settings your homepage sends to every visitor. We check HTTPS, browser security headers, cookies, email records, trackers and the software the site gives away. Use your website security scan to prepare questions for your developer and to keep a dated record before you change anything. ### Read your website security scan results Your website security scan sorts results into urgent host checks, settings to fix and choices that depend on how your site works. A missing optional header is not a sign of an attack. The site score in a website security scan runs from 0 to 100 and counts passed checks. The colours tell you what to look at first. ### Before and after a website security scan Run a website security scan before you change hosting or security settings, so you have something to compare against. Check payment pages, logins and embedded services before tightening any rules. Afterwards, run a fresh website security scan, compare it with the old report and test the site in a real browser. Keep software updates and account security in your regular maintenance. ### Share a website security scan with your developer A website security scan is easier to act on when the person doing the work can see it. Download the PDF or send the report link to your developer. Each website security scan shows when it was run. The owner of the website can also publish the report after proving they control the site. ## Questions about your website security ### Does a website security scan prove my site is secure? No. It checks a set of public settings. It cannot find every vulnerability, malware, coding flaw or hacked account. A full security audit goes much further. ### Will a website security scan affect my website? Barely. The scan looks up your DNS records, requests the homepage over HTTPS and plain HTTP, follows up to five redirects, reads security.txt and loads the homepage once in a cloud browser. It does not visit other pages, submit forms, log in or try attacks. If your site blocks the scan, you get an incomplete result. ### Why is a website security scan limited to two checks a day? The limit keeps the tool free and avoids sending needless traffic to websites. ### What do the website security scan colours mean? Red means ask your host to check something urgently, such as an old PHP version with a known critical flaw. Orange means a setting needs fixing. Blue means it is worth a closer look. Green means the check passed. Grey means we could not check it. None of these colours means your site has been hacked. ### Can a website security scan detect PHP2Shell? It can flag a PHP version older than the fixed releases. Version headers can be wrong, hidden or changed, and some hosts patch older versions. Ask your host to confirm the installed PHP version and patches. We never send attack requests. A missing PHP header does not mean PHP is absent or patched. ### Why does a website security scan flag software headers? Version details make it easier to find sites running vulnerable software. Remove them where you can. Hiding them does not fix anything, so keep the software itself up to date. ### What should I do after a website security scan? Start with the red items, then go through the orange ones with your developer or host. Test header changes before going live, because strict rules can break payments, forms and embedded content. Download the PDF to share the results. Mecanik Dev can help pick the right fixes and do the work. ### Are my website security scan results public? No. Scans are private. Only the owner of a website can publish its report, after proving they control the site with a DNS record or a file. You can still share a private link or the PDF. No account or email is needed. ## The checks included in your report ### Encrypted connection HTTPS encrypts data between the site and its visitors. This shows the scanner connected securely. It does not test the rest of the site. ### Redirect plain HTTP to HTTPS Visitors who type the address without https:// should go straight to the secure site. HSTS then keeps their browser on HTTPS. ### Keep visitors on HTTPS Set Strict-Transport-Security with a max-age of at least six months. Check your subdomains before adding includeSubDomains or preload. ### Control what can run Content-Security-Policy controls which scripts and content the page may load. The right rules depend on the site, and a missing policy is not a vulnerability in itself. If the page sets the policy in its HTML, the browser check reads it. Report-only policies do not block anything. ### Protect against deceptive framing Use CSP frame-ancestors or X-Frame-Options, and allow only the sites that really need to embed yours. ### Stop browsers guessing file types Set X-Content-Type-Options to nosniff so browsers treat each file as the type the server says it is. ### Limit information shared with other sites An explicit Referrer-Policy makes the behaviour clear. Modern browsers already limit this by default, so a missing header does not mean data is leaking. ### Restrict sensitive browser features Permissions-Policy can switch off the camera, microphone and location for your site. The right settings depend on what the site does. ### X-Powered-By disclosure Remove runtime details where you can. It makes the site harder to fingerprint, but you still need to keep the software updated. ### Server version disclosure Ask your host to hide version numbers and keep the server updated. A server name without a version is fine. ### PHP patch review PHP2Shell is the name for two critical flaws in PHP itself. The header only reports a version, which may be wrong or leave out fixes your host has applied. Ask your host to confirm the installed version against current PHP advisories. Hiding the header does not fix anything. ### HTTPS-only cookies Secure means the cookie is only sent over HTTPS. We only see cookies set by the homepage response. Cookies set after login or by scripts are not covered, and cookie values never appear in your report. ### Session cookie script protection HttpOnly stops scripts on the page from reading the cookie. We guess which cookies are session cookies from their names, so ask your developer to confirm. ### Cross-site cookie rules SameSite controls when cookies are sent with requests from other sites. None can be right for some integrations, and browsers apply a default when it is missing. ### Cross-origin access CORS is often needed for APIs and shared files. A wildcard on its own does not expose private data. This homepage check cannot tell if an API trusts any origin. ### Browser window isolation COOP keeps the page apart from windows opened by other sites. Payment and login pop-ups may need a looser setting. Leaving it out does not make the site exploitable by itself. ### Resource embedding rules Cross-Origin-Resource-Policy controls which sites may embed your files. Public images and shared files may need to stay open. Most pages do not need it. ### Email sender policy (SPF) SPF helps mail servers reject fake emails sent in your domain's name. If the domain never sends email, publish v=spf1 -all. We check the main domain. ### Email spoofing policy (DMARC) DMARC tells mail servers what to do with emails that fail SPF and DKIM. Start in monitoring mode, read the reports, then move to quarantine or reject. ### Certificate authority rules (CAA) CAA records list the certificate authorities allowed to issue certificates for the domain. They lower the risk of a certificate being issued by mistake. Include every provider you use. ### Signed DNS (DNSSEC) DNSSEC lets resolvers spot fake DNS answers. Turn it on at your DNS provider and registrar together, because a broken setup can take the domain offline. ### Security contact (security.txt) Publish /.well-known/security.txt with a Contact and an Expires date, so people who find a problem know how to reach you. ### Insecure page resources Insecure files can be changed on the way to the visitor, and browsers may block them and break the page. Switch these addresses to HTTPS. We only checked the homepage. ### Third-party services Every outside script or service can see your visitors and change the page. Keep the list short, remove what you no longer use and check what each provider receives. Using outside services is not a vulnerability by itself. ### Tracking before consent Privacy laws such as GDPR and PECR usually require consent before non-essential tracking. The scanner loads the page once from our servers and accepts nothing. Consent tools can act differently by country, so check your own setup as well. ### Outdated JavaScript libraries We recognise jQuery, jQuery UI, Bootstrap, AngularJS, Lodash and Moment.js when they show their version. Update the affected library, or the theme or plugin that includes it, then test the site. ### Script integrity checks Subresource Integrity lets browsers reject a changed copy of a script file. It works for versioned files from a CDN. It does not suit scripts that change on purpose, such as tag managers. ### Website platform version A generator tag with a version number makes the site easier to target with automated attacks. Remove it where you can and keep the platform, themes and plugins updated. Hiding the version does not fix anything. ## Privacy notice To stop abuse and to answer complaints or legal requests, Mecanik Dev Ltd keeps a record of every scan. It holds the website, the time, the notice version, your IP address, your browser and device details, and your approximate location based on your IP address. We keep these records for 30 days and then delete them. We do not use them for marketing and only share them when the law requires it. Our hosting and security provider processes your IP address to run the service and the anti-bot check, and keeps its own logs. Agreeing to a scan is not agreeing to marketing. Your browser creates the PDF itself. For controller contact details, data rights and information about service providers, see our main privacy policy. If you publish a report, we store the domain, the scan time and the findings for up to 90 days. The public directory shows the latest report for each website. Private scans are never stored there. Earlier public reports stay up until they expire or are removed. Public reports never include visitor IP addresses, browser details, authorisation records or cookie values. Your theme preference is saved in this browser. The current report is kept in this tab's session storage so switching languages does not require another scan. Clear browser storage to remove these saved preferences and results.