A Practical SEO Checklist for Tool Pages

Tool pages are a specific SEO problem. They are often short, they overlap with each other (“PNG to JPG” sits right next to “PNG to WebP”), and the interesting part — the tool — produces almost no text for a search engine to read. Everything below is a fix for one of those three facts, in the order worth doing them.

One page, one intent

Before titles and schema, settle what the page is for. A page that tries to serve “compress an image” and “convert an image” and “resize an image” will rank for none of them as well as three pages that each serve one.

Two tests that catch most of the problem:

• Could you hand this page to someone with one sentence? If the sentence needs an “and”, the page is probably two pages.
• Does the page have a competitor on your own site? Two pages targeting the same phrase split their own signals. Merge or differentiate — but do not leave both as they are.

On this site that rule shows up as conversion-specific paths: the converter lives at /tools/image-converter/png-to-jpg, not on one page with a format dropdown in the title. The dropdown is still there — the URL and the intent are just narrower than the tool.

The head: title, description, canonical

On a Next.js or App Router site each of these belongs in the route's own metadata export — a shared layout that sets one title for everything is the single most common way tool pages end up invisible. A per-page canonical is also what keeps query-string variants and trailing-slash duplicates from splitting your signals.

The body: answer the question on the page

A tool page does not need to be 2,000 words. It needs the answers that make a visit successful, in the order someone would ask them:

1. What does this do? One sentence, above the fold.
2. What are the limits? File size, number of files, what happens to the data. State them; people search for them.
3. How do I use it? The steps, short, in the order they happen.
4. What should I know before I trust the result? The real caveats of the transformation.
5. What next? The related tool or the guide that continues the job.

Point four is the one people skip, and it is the one that earns links and return visits: a page that says “lossy mode with quality below 70 becomes visible on text” is more useful than one that says “best quality” five times.

Internal links, the lever most sites leave alone

Search engines discover pages by following links, and they judge a page partly by what links to it. On a tool site the internal link graph is usually the weakest asset on the whole property: every tool is linked from the navigation, and nothing links between tools.

Four links worth adding to every tool page, in order of value:

• The next step in the same job. Optimizer → Resizer → Converter. Each one answers the question the previous one just created.
• The guide, from the tool. A conversion page should link to the article about that conversion — that is how a reader becomes a returning reader.
• The tool, from the guide. And back. Articles are where a search engine finds the vocabulary; tools are where the visitor stays.
• The sibling page in the same family. If you have png-to-jpg, the jpg-to-webp page should be one click away, and both should be listed in a hub page.

Structured data that earns something

Schema is not a ranking factor; it is a way to be understood and, sometimes, to be presented differently. Three types are worth the markup on a tool site:

• SoftwareApplication with applicationCategory, operatingSystem, offers at price 0 and a featureList. It describes what the tool is, in a vocabulary the crawler already knows.
• FAQPage on pages with genuine questions and answers. Only mark up what is visibly on the page — duplicated invisible Q&A is exactly what the guidelines warn about.
• BreadcrumbList so the path (Tools → Image → Converter) is explicit rather than guessed.

Validate with the Rich Results Test after every change. A malformed block is worse than no block, because it tells the crawler something untrue.

Speed is part of the page, not a separate project

A tool page is judged by the same Core Web Vitals as anything else, and tool pages tend to carry extra weight: screenshots, before/after examples, diagrams, sometimes a video. The fixes are the usual ones, which is why they are easy to put off:

• Resize every illustration to the size it renders at, then compress it.
• Set width and height so the layout does not shift as images arrive.
• Do not lazy-load the largest image in the first screen; that is usually the LCP element.
• Keep the interactive tool off the critical path — a heavy workspace should load when it is used, not before the heading is readable.

Image Optimizer and Image Resizer are the two tools that do this work for the screenshots you are about to add. Why image optimization is critical for fast SEO growth covers the measurement side.

Sitemaps, canonicals and what gets indexed

• Generate the sitemap from the routes, not by hand. A hand-written sitemap goes stale the day the next page ships.
• Include every indexable page, exclude the rest. Account pages, saved vaults and result URLs should not be in it.
• Check what actually got indexed a fortnight after launch, not the day after. New tool pages often need one internal link from an established page before they are crawled.
• Watch for near-duplicates. Ten conversion pages with identical copy and one changed word will compete with each other; give each one its own real content.

The checklist

1. One intent per page, stated in a single sentence.
2. Title names the task; brand comes second.
3. A meta description written for a person, unique to the page.
4. One H1, matching the intent, with real subheadings below it.
5. Limits, steps and caveats on the page — the things people search for.
6. Two to four internal links to the next step, the guide and the family.
7. Canonical on the page, pointing at the one URL you want indexed.
8. SoftwareApplication, FAQPage and BreadcrumbList markup, validated.
9. Every image resized, compressed and given width and height.
10. Interactive workspace out of the critical rendering path.
11. Sitemap generated from routes, with private pages excluded.
12. A fortnightly index check, not a launch-day guess.