When I built ramrom.io, a free video downloader that runs on plain PHP hosting, I spent most of my time on the tool itself: the resolve endpoint, the download proxy, the rate limits. The structured data on each page was an afterthought — until I realised search engines were treating my tool pages like ordinary blog posts. That is when I added WebApplication schema.
What it actually is
WebApplication is a Schema.org type that tells a search engine: this page is not just an article about a tool, it is the tool. You add it as a block of JSON-LD inside a <script type="application/ld+json"> tag in the page head. Google reads it, and it can change how your page is understood and shown.
Here is close to what I ship on the homepage:
{ "@context": "https://schema.org", "@type": "WebApplication", "name": "RamRom", "url": "https://ramrom.io/", "applicationCategory": "MultimediaApplication", "operatingSystem": "Any", "browserRequirements": "Requires JavaScript. Requires HTML5.", "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" } } Every field there is a fact about the site, not a claim. The tool really is free, it really runs in any browser, and it really needs JavaScript.
The temptation to fake it
The WebApplication type has optional fields that are tempting to fill in: aggregateRating, review, featureList full of superlatives. I left them all out. I have no user ratings to report, so inventing a 4.9-star score would be lying to Google and to anyone who reads the source. Structured data is a place where honesty is also the practical choice — made-up ratings are one of the fastest ways to earn a manual action, and they do nothing for a tool whose whole point is that it works when you paste a link.
The same rule applies to featureList. I could list every platform the downloader supports, but platforms change and the list would go stale. The schema describes what the tool is, and the page copy describes what it does today.
Why static JSON-LD, not generated
The site is plain PHP with no build step and no framework, so the schema is a static block pasted into the shared head include. Every page gets the same block, with the url and name adjusted where a page is really a different tool — the TikTok downloader page, for example, names itself as that tool rather than the whole site.
Keeping it static has one real advantage: I can read it. There is no template logic to debug, no variable that silently renders empty. When I changed the homepage copy, the schema did not need to change, because it never described the copy. It describes the application.
How I check it
Before any page goes live, I paste its URL into Google's Rich Results Test. It either parses the JSON-LD or it does not — there is no grey area, which I like. A missing comma or a stray quote fails loudly, and fixing it takes a minute. I also check the tool itself still works in the browser, because schema is decoration: if the downloader breaks, no JSON-LD saves it.
One more check: view the page source and confirm the script block is actually there. On a site assembled from includes, it is easy to edit the head template on one copy and upload a different one. I have done exactly that, and the Rich Results Test caught it.
Is it worth it?
I cannot prove the schema alone moved any ranking — nobody can isolate one change that cleanly. What I can say is that it costs nothing, it takes ten minutes to add, and it makes the site's nature legible to machines in the same plain way the homepage makes it legible to people: a free web tool, no sign-up, paste a link, download the file. For a one-person side project, that kind of cheap clarity is worth having.
If you run a small tool site, add the block, keep every field true, and leave out anything you cannot back up. The schema will not make a bad tool good — but it will make a good tool easier to understand.
