After the scan
This page goes through the findings category by category and tells you plainly which ones you can fix yourself. Some take ten minutes with whoever already looks after your site, and cost nothing.
Same categories as the ones in your results
If your site still opens over plain http, or the certificate is close to expiry, browsers show a not secure warning before a customer sees anything you sell. On the day it actually expires, the whole site stops opening.
You can fix this. Almost every host has a switch for HTTPS and automatic renewal in its control panel. If you cannot find it, ask their support where it is.
These tell the browser what it is allowed to load. Without them, a stray script that gets in through a comment box or an ad runs with full access, including reading what customers type into your forms.
Fixable by whoever maintains the site. It is a few lines of configuration. The hard one is Content-Security-Policy, because set it too tight and parts of your site break silently. Run it in report-only mode first.
Someone loads your page inside a frame on their site and puts invisible buttons over it. Your customer thinks they are clicking your button but they are clicking theirs. It is used to get people to confirm orders or grant access without realising.
You can fix this. One configuration line saying nobody may frame your pages, unless you deliberately allow a partner to embed something.
Your server announces which software and version it runs. Anyone following vulnerability news knows immediately which known holes you have not patched, without having to try anything.
You can fix this by turning the announcement off in your server config. But hiding the label is not the same as closing the hole. The real fix is updating the software.
Loosely configured cookies can be stolen and replayed, which means someone gets into your customer's account without ever knowing their password. If that account holds personal data, that is a reportable incident under Thai PDPA.
Needs someone hands on. The change is in the code where cookies are set, and login has to be retested afterwards. It is not a setting in a hosting panel.
The page is https but still pulls images or scripts over plain http. Anyone on the same network as your customer, a cafe wifi for instance, can swap those files for their own, and newer browsers block them until the page looks broken.
You can fix this. Change those file addresses from http to https. The results list how many places were found.
Every second of load time is customers closing the tab before they see anything, and it is one of the numbers Google ranks on. A slow site loses both the people who arrived and the people who never found it.
Partly. Compressing images and turning on caching you can do. But if the server is slow on the very first byte, the problem is usually the hosting plan or the database, and that needs someone to look at the real thing.
Without the mobile setting, your page gets shrunk down to unreadable on the device most of your customers use. Without a title or description, your search result shows up as a blank line nobody clicks.
You can fix this. A few lines in the page, plus robots.txt and sitemap.xml, which most site platforms can generate for you.
Not because the tool is weak, but because it deliberately does not touch your system
There is no need to jump to the most expensive option
If everything you got back is marked as something you can fix, do that. It is faster and you do not have to wait for anyone. Re-run the check as many times as you like, it stays free.
Run the check again →If you are not sure which findings are urgent, or where to start, email me the results. I will read them and tell you what to do first. No charge and no follow-up chasing.
phisit@zyntronlabs.comReply within one business dayIf you want to know what an outside scan cannot see, that starts with signed authorisation. Then I test from the inside and send a report that says how to fix each finding.
See packages and prices →