Request a feature

Tell us the problem, not the solution. Every tool here started as a job someone was doing by hand.

Two kinds of request

• A change to a tool that exists — a missing export format, a column you need, a mode that would save you a step. These are usually quick, and small ones often ship the same week.
• A tool that does not exist yet — a whole job you keep doing manually. These take longer and not all of them get built, but this is where most of the site came from.

What makes a request likely to get built

The best requests describe the job, not a feature spec. Something like "every month I copy 200 URLs into Search Console one at a time to check indexing" tells us far more than "add a bulk mode". Useful things to include:

• The task itself, in your own words, and roughly how often you do it.
• How you do it today — the spreadsheet, the script, the six-tab routine, the paid tool you are working around.
• Where it hurts: is it slow, error-prone, expensive, or just mind-numbing?
• What "done" looks like — the output you actually need. A CSV? A single regex? A list you can paste somewhere else?
• Examples. Sample URLs, a screenshot, a slice of the spreadsheet. The messy version is genuinely fine and usually more useful than a tidy description.

A request is more likely to get built when it is a job many people repeat, when the result can be defined precisely, and when it does not require a paid data source to be useful. If it does need a paid API, it can still work — the tool will simply ask you for your own key.

What happens next

• You get a reply, normally within two working days, even when the answer is no.
• If it is a fit, we will usually come back with a few questions — edge cases are where these tools live or die.
• When it ships, it goes live on SEO Tools, free for everyone, and you get a message telling you it is there.

Found a bug instead?

Bugs get priority over features. The Contact page lists what to include so it can be fixed in one round trip.

Last updated: 28 July 2026