A page of alternatives is easy to fake. Pick a famous product, list anything from the same category, and the URL looks useful. On RadarMakers the directory does the opposite. A tool page is added only when at least five live products do the same job as one well known tool. A shared category or a shared tag is not enough.
This post uses the directory as it was served on 28 October 2026. The hub returned HTTP 200. Its visible sentence was: "No alternatives page is published yet, because no well known tool has five live matches in the catalog." Requests for /alternatives/notion returned 404. The same is true for any other tool slug. There is a route, and there is no published tool page.
What the hub actually says
The title is "Alternatives directory". The description says a page is added when at least five live products do the same job as one well known tool.
The introduction says the maker tagline and the pricing label come from the listing. It also says each published page has its own introduction, a comparison table, and answers to common questions. The order on a page follows community votes, then overall score, then the earlier launch.
Three questions are on the hub:
- When is an alternatives page published? When five or more live products do the same job as one well known tool. A shorter list stays off the directory.
- Does the table review the well known tool? No. The table shows RadarMakers products only. It uses the maker tagline and pricing label. It does not score the named tool and it does not add features the listing does not state.
- How can a product appear on a list? Submit it for free with a confirmed account and wait for review. The reviewer checks that the website matches the listing. The product joins a page only when its job matches that tool and at least five live products qualify.
Those sentences are the page. They are not a claim that five substitutes exist for any named product today.
Why five, and why the job matters
The constant in frontend/src/lib/saas-alternatives.ts is MIN_SAAS_ALTERNATIVES = 5. A target is a hand-written record: a slug, a name, an introduction, questions, and a list of product slugs. The publisher keeps a target only when at least five of those slugs are live. If the list is empty, the hub renders the empty sentence and the tool route calls notFound.
The hand-written list is the point. Two products in "AI Tools" can both be live and still do different jobs. Putting them on a "ChatGPT alternatives" page because they share a category would invent a comparison the listings do not support. The code comment says not to add a tool that has four matches.
On 28 October 2026 the target list was empty. That is why the sitemap on that day listed https://radarmakers.com/alternatives and no tool URLs under it. The hub entry changed two days later, as described further down.
What a tool page would show
The unpublished template still describes the table. The headings are Product, Tagline, and Pricing label. Each product name links to /product/<slug>. The pricing cell uses the maker label already stored on the product: free, freemium, paid, or open source. There is no extra price, no feature grid, and no winner.
The page would also repeat its own questions as FAQ structured data. None of that HTML is on the public site until a target qualifies.
Images that are live, and images that wait
The hub Open Graph image is /og/alternatives.png, 1200 by 630. Its alt text is "Discover alternatives | RadarMakers". The Twitter card is a separate file, /og/alternatives-x.png, 1200 by 675, with the alt text "Discover alternatives on RadarMakers. Tools from indie makers." Both returned HTTP 200 as image/png on 28 October 2026. The small header illustration is /illustrations/saas-alternatives/alternatives-header.svg.
Five taller cards exist for Notion, Trello, Canva, Zapier, and Calendly. They are 1200 by 675 and they are reachable as image files. They are not attached to a tool page, because those pages return 404. A template card that still says "Tool Name" is not published.
A recheck on 31 October 2026 gave the same picture. All seven image files, the two hub images and the five named cards, answered HTTP 200 as PNG files at the stated sizes. All five named tool routes still answered 404.
Source: HTTPS requests to radarmakers.com, checked October 31, 2026 at 04:55 UTC. Chart: RadarMakers.
The tool route, when a page exists, uses the generic Open Graph image. It uses a named Twitter card only for a slug that has one of those five files. Every other slug uses the generic Twitter card.
Links from the catalog
A product page can link to a tool page with the sentence "See this product on the {name} alternatives page". A category page can list the same tool pages when one of its products is on that list, and the product card in that category can show the same link. On 28 October 2026 those links had nothing to point at, because no tool page was published. The hub itself is linked from the footer and from /tools.
Validate every candidate before counting it
The threshold is necessary, but it does not establish that five products solve the same problem. Start with a plain language job statement. A shared category label is not enough. A tool that includes a notes feature is not automatically a replacement for a knowledge base. A design product with export is not automatically an image editor.
For every candidate, open the public product site and its directory listing. Confirm that it is live and that the available description supports the proposed comparison. Record the date and evidence. Exclude a product when the listing does not support the claimed use. Do not fill a missing detail with a guess. The five distinct live product IDs must be counted after status and duplicate checks.
This method also makes future maintenance possible. Products can change purpose, become unavailable, or leave the directory. Revisit each candidate set after material listing changes. If fewer than five still qualify, the page should stop presenting itself as an eligible comparison under the policy. A saved spreadsheet or a short review record is enough to make the decision reproducible.
Attribute the fields the table actually shows
The template uses product name, maker supplied tagline, and pricing label. Explain that narrow scope. The page does not independently review the named commercial tool and does not score a winner. A tagline is short maker supplied copy, not a verified feature specification. A label such as free, freemium, paid, or open source is not a price schedule.
If you add a new field, define its source and update method. A feature grid can appear authoritative while its claims become stale. A smaller table with current attributable facts may be more useful than a broad matrix built from uncertain details. Link readers to the product page for current terms. Do not infer an amount, usage cap, trial, or entitlement from a pricing label.
A method note should say what makes a product eligible, when records were checked, which fields come from the listing, and how a maker can suggest a correction. If the list is curated, explain the rule without implying independent testing. Disclose a connection when it could affect how the page should be interpreted.
State the inspection date and correction route. When a maker asks why a product appears, the team can point to the same job definition and evidence standard. Keep private correspondence private. Disclose an editorial or commercial connection when it affects how a reader should interpret the comparison.
Keep an empty hub honest and useful
An empty hub can explain the inclusion rule and link to broader discovery. It should not imply that comparison pages exist when they do not. Make the empty state useful by explaining what a future page would contain and where a reader can browse now. Avoid promising a specific date unless the team has made that commitment.
An empty state can still produce broken internal links if a category card or product page points to an unqualified target. Test links from the hub, product detail, category page, and sitemap. A route that returns an error for an unknown or unqualified target may be correct, but it should not be linked as if it were ready.
The recorded snapshot showed five named image cards prepared for Notion, Trello, Canva, Zapier, and Calendly, while no target comparison page was published. Those assets are not proof of completed editorial review. Keep design files, route records, and published content as separate states. A card can exist before the page qualifies, and that distinction should be clear to anyone reading the evidence.
Match structured data to visible content
Structured data describes the page; it does not repair vague copy or guarantee a result in search. Use a type only when its definition fits. Questions and answers in markup should be visible to a reader. Product names, canonical URLs, and table values should agree across visible text and metadata.
Recheck the output after the candidate set changes. A cached page can retain a former comparison after the live list no longer qualifies. Inspect a fresh build and the served response. Confirm status code, robots metadata, canonical, and sitemap membership together. Do not leave a self canonical on a removed route or point every potential page to the hub without a reason.
Review the route as a visitor and a crawler
Start at the hub and follow every link. Open each product and target route. Verify response codes, title, description, canonical, robots directives, and visible content. Check the sitemap for the hub and eligible targets. Test an unknown slug and a target that previously qualified but no longer does. Update links after removing a route.
The initial HTML should contain the information a crawler needs without depending on a client side fetch. Check the social card and its alt text against the page that actually loads. A live response check verifies behavior at the time of inspection. It does not establish whether a search engine indexed the page or how it ranks.
Use a simple editorial worksheet: target name, shared job, candidate products, evidence, live status, distinct count, review date, and decision. Then review whether the title implies endorsement, whether the introduction explains limits, whether fields are attributed, and whether the empty state offers a working next step. This small record makes the page easier to maintain than a claim that it is curated.
- [ ] Define the shared user job before collecting candidates.
- [ ] Confirm each candidate is live, distinct, and supported by evidence.
- [ ] Attribute maker supplied copy and pricing labels.
- [ ] Keep the empty hub accurate and useful.
- [ ] Verify route status, canonical, robots, internal links, and sitemap.
- [ ] Ensure structured data matches visible page content.
- [ ] Record evidence dates and recheck after catalog changes.
Avoid implying endorsement or a complete review
A page titled as an alternative list can sound like a verdict. Explain that the page is a directory of products whose public descriptions matched a defined job. Do not say that one is better, safer, faster, or cheaper unless the team has evidence and a published method for that claim. Keep editorial copy distinct from maker supplied text.
If community signals affect ordering, label them carefully. Votes indicate recorded interest, not a universal preference. Comments contain individual reports, not a representative survey. A rating captures member responses, not an independent test. Explain the sort rule where a reader encounters it, and avoid converting a position in the list into a quality award.
Give each product a route to its source page. Readers can inspect current terms and capabilities there. If a field is missing, state that it is not provided rather than filling the gap. If a product site is unavailable, pause the inclusion review and do not treat its stale listing as current evidence.
Treat the snapshot as a dated observation
The date beside a live check is part of the evidence. The hub response, target route responses, and card files are observations from October 28, 2026. They do not say what the routes return today. When this article is reused, repeat the checks and update the date before describing current behavior.
Keep raw response notes or a small reproducible script where the team can find them. Store the requested URL, final URL after redirects, status code, content type, and retrieval date. Avoid collecting unrelated response data. A short audit trail helps distinguish a route that was never published from one that became unavailable later.
Do not treat the existence of an image as proof that a route is complete. A share card can be prepared in advance, but its title, image, and description need to match a public page before release. Check the initial HTML and metadata on the actual URL. If a page is not eligible, avoid linking its card as if the comparison were live.
The October 28 response count covers one inspected hub and five inspected tool routes. It is a snapshot for those addresses, not an error rate for the site or a statement about later responses.
Keep the publication rule understandable
A threshold is easiest to maintain when it is described in the same language as the user job. Explain that the route requires five live products that do the same kind of work, not merely five products with a shared tag. Put the rule near the empty state and in the internal review checklist. This makes a rejection easier to explain and helps another editor apply the same standard later.
The implementation should fail closed for a target that has not been deliberately configured. A popular product name in a URL is not enough reason to generate a page. Keep the set of approved targets explicit, and make sure the rendering route checks both membership in that set and current product eligibility. An unknown slug should not inherit a generic page with a misleading heading.
When the data source is unavailable, avoid treating the failure as a successful empty result. The page builder should preserve the distinction between no qualifying set and an unsuccessful lookup. Decide whether to show a temporary response, serve a recent cached page, or omit the route from the sitemap, then test that policy. The response should not claim that no alternatives exist if the underlying lookup failed.
What changed between the two checks
The October 28 snapshot had one awkward detail. The hub said that no alternatives page was published, yet it was a normal index eligible URL listed in the sitemap. That is an empty listing page offered to search engines, which is the same thin content problem that category pages solve with a threshold.
A change deployed on October 30 closed that gap. The hub metadata now asks for the published target list first. When the list loads and is empty, the page emits noindex, follow. When the lookup fails, the page keeps its default metadata, so an API error does not quietly mark the hub noindex. The hub also stopped emitting an item list with zero entries in its structured data. The sitemap now adds the hub only when the first tool page is published.
// frontend/src/app/alternatives/page.tsx, excerpt
const pages = await getPublishedSaasAlternatives().catch(() => null);
return pages && pages.length === 0 ? { ...baseMetadata, robots: { index: false, follow: true } } : baseMetadata;
On October 31 the served hub carried <meta name="robots" content="noindex, follow"/>, and the sitemap had no URL under /alternatives. The visible sentence and the three questions were unchanged. Visitors still get the same page, with the same explanation of the rule. The only difference is that the site no longer asks search engines to index a directory with nothing in it.
Source: RadarMakers route checks on October 28 and October 31, 2026, and sitemap.xml on both dates. Chart: RadarMakers.
The target list in the code was still empty on October 31, so the five match rule had nothing to evaluate. That is the expected state for a rule that refuses to publish on a category match alone. The empty list is not a bug to fix by adding weaker targets. It is a record that no hand checked set has reached five live products yet.
Two habits come out of this change. First, an empty state needs its own metadata decision, the same as a thin category. Second, the failure case needs a separate decision, written next to the code, so that a timeout does not flip a page into noindex or into the sitemap by accident.
What this does not prove
An empty directory is not a review of Notion, Trello, Canva, Zapier, Calendly, or any other product. It does not say that RadarMakers has no products in those jobs. It says no hand-checked set of five live products was published for one well known tool. Search engines were told about the hub URL through IndexNow on 28 October 2026. That notice does not create tool pages, and it does not say the hub is indexed.
Sources
- RadarMakers alternatives implementation, frontend/src/lib/saas-alternatives.ts, route and template behavior recorded in this article.
- RadarMakers live response inspection recorded October 28, 2026. The hub returned HTTP 200 and the five named target routes returned HTTP 404.
- RadarMakers live recheck on October 31, 2026: hub response and robots meta tag, five named tool routes, seven image files, and sitemap.xml.
- RadarMakers alternatives hub metadata change deployed October 30, 2026, frontend/src/app/alternatives/page.tsx.
Top comments (0)