Reviews
Part of Before you trust technical SEO reviews, check the method
How to run a technical SEO product comparison buyers can defend
A method for comparing technical SEO products on evidence: define needs, verify claims, score usability, and keep an audit trail with a due diligence checklist.
What to take away
A technical SEO product comparison is a scored evaluation of tools against your own requirements, with the evidence kept.
- Define the tasks your team performs before you look at any product.
- Weight each requirement so the rubric decides, not the demo.
- Verify vendor claims against primary sources and date each check.
- Keep pricing and contract terms inside the comparison.
Start from tasks, not feature lists
A comparison works only when requirements come before products. List the jobs your team does weekly: crawling, log analysis, index monitoring, reporting. Weight each job by hours spent.
Write the weights down before any demo. This stops a polished interface from changing what you value halfway through. A weighted list also shows where two products overlap, which is usually where money is wasted.
Verify claims against primary sources
Vendors describe their own products, so check what can be verified independently. Search engine documentation sets out how crawling and indexing behave, and your tests should measure claims against it.
Verify vendor claims
- Check claim against primary source
- Confirm WCAG version and criteria
- Test contrast and keyboard navigation
- Record date each claim checked
Accessibility coverage is a useful test case. If a tool audits pages against WCAG, record whether it checks WCAG 2.2 Level AA and which success criteria it covers, such as 1.4.3 Contrast (Minimum), 2.1.1 Keyboard and 2.4.11 Focus Not Obscured (Minimum). A tool that flags contrast but misses keyboard navigation is not equivalent.
Record the date you checked each claim, because product pages change quietly.
Shortlist tools by the job they do
Examples to consider include Screaming Frog SEO Spider and Sitebulb for crawling; Lumar, Botify, Oncrawl and JetOctopus for enterprise crawling and log analysis; and Ahrefs and Semrush for broader SEO platforms that include site auditing and rank reporting.
Treat these as candidates, not endorsements. Check each product’s current documentation and test the tasks your team actually performs before scoring it.
Check the supplier, not just the software
A product is only as reliable as the company behind it. Ask the supplier how it handles security, data protection, support and changes to the service, and request evidence that your organisation can review.
Check the company’s details on the Companies House register, including its registered name and status, and compare them with the proposed contract. Where relevant to your procurement, ask for an ISO/IEC 27001 certificate or SOC 2 report, and check the ICO’s data protection fee register if the supplier is required to pay the fee.
Set a scoring rubric and keep it
Set the rubric before product demonstrations, then use the same criteria and evidence standard for every product.
How to weight and score each product
Use a short list of criteria: task fit, data accuracy, accessibility coverage, integration effort, and total cost across the contract term. Score each from one to five, then multiply by the weight you set earlier. For an illustrative weighting, assign task fit five, data accuracy four, accessibility coverage three, integration effort two and total cost one; change the weights to reflect your team’s priorities.
Two reviewers should score independently. Where scores differ by more than one point, discuss the evidence instead of averaging.
How to document the decision
Keep one file holding the rubric, raw scores, source links and dates. Note who scored what. If the decision is questioned later, the file answers most of it without a meeting.
Keep product documentation, test results, security responses and dated quotations in the same evidence file as the rubric.
Build the due diligence checklist
- Requirements signed off before demos begin.
- Weightings agreed and dated.
- Each claim traced to a primary source.
- Accessibility coverage checked against WCAG 2.2 Level AA and the success criteria claimed.
- Company registration and ownership checked on the Companies House register.
- Security evidence, such as an ISO/IEC 27001 certificate or SOC 2 report, reviewed where relevant.
- ICO data protection fee registration checked where applicable.
- Total cost modelled across the contract term.
- Independent scores from at least two reviewers.
The checklist sits with the rubric and forms the audit trail.
Where comparisons usually go wrong
Weak comparisons fail in predictable places. One is comparing list prices without modelling the quoted licence, seat counts, overage fees, contract and renewal terms, setup charges or migration effort. Use the same team size and contract period for each product, and include all these components in the total cost model. Another is letting a single enthusiastic reviewer set every score.
A third is ignoring how a tool fits existing workflows. A product that duplicates reporting you already trust adds cost without adding evidence.
If you are comparing agencies rather than software, the evidence standards differ. The guide to technical SEO agency reviews and data sources covers what to ask for and how to check it.
Common questions
Use these questions to check the size of the shortlist, how to treat price, and when to revisit the rubric.
How many products should a comparison cover?
Three to five is usually enough to test the market without scoring fatigue. More than that and reviewers start scoring carelessly.
Should price decide the outcome?
No. Price is one weighted criterion. A cheaper tool that fails task fit costs more in manual work across a year.
How often should the rubric be revisited?
Review it when your task mix changes, such as after a replatform. Otherwise an annual check is reasonable.
What if two products score equally?
Return to the weightings. The criteria that matter most to your team break the tie, and you should record why.
