The SEO Playbook for Launch Sites and Tool Directories

This is the manual half. The other half is the story of how I ended up with these rules on Shipstry, including the migration that turned 2,882 known URLs into 949 redirects and duplicates: A Third of Shipstry's URLs Are SEO Debt. Everything below assumes you already accept the problem and want to know what to build next.

Two numbers set every threshold in this piece. The average maker on Shipstry writes 707 characters of notes, and the best-voted product in the registry has 7 votes. Plan for a long tail with a thin head, not for encyclopedia entries.

The seven page families

Each family answers a different question and needs different content to answer it. Treat them as one template and you get 820 pages that differ only in the name at the top.

Product detail pages

This is the only family I would hand-write, and only for a subset.

A complete page looks like this:

1. Header: logo, name, a one-line tagline, the primary action.
2. Facts rail: maker, category, tags, ship week, any award. All linked, all generated from data.
3. Preview image: one 16:9 shot. 767 of 820 products have one, and the other 53 are the pages that look unfinished.
4. Body: the maker's own notes, sanitized and rendered once at write time.
5. Alternatives: up to six products sharing a category or tags, closest first, with a sentence explaining the order.
6. Same-week peers: what shipped alongside it, plus a link to the week archive.
7. Structured data: Product, Breadcrumb, and the organization schema once per page.

The interesting decision is the body, and the distribution is a paragraph and a half:

So I tier the work: real editorial for the products that earned attention, the facts rail plus the maker's own words for everyone else. On Shipstry that means the 103 products with a weekly or monthly award, plus paid launches where the maker is already motivated to write more. Everyone else gets a complete, generated page, which is a promise I can keep with a real submission queue.

One URL rule belongs here, because it decides how much maintenance you sign up for: put the slug and a stable id in the product path (/products/{slug}/{id}). Slugs carry the query match, ids keep the page unambiguous when two products share a name or someone edits a slug.

Category archives

Category pages are the easiest thing in a directory to generate and the hardest to make worth indexing.

Categories on Shipstry began as the Explore list with one filter applied. A filtered list with a keyword in the URL will not outrank the index page it copies.

What makes it a real page is the copy under the list: what the category covers, how to pick inside it, which topics belong to it, and a short FAQ. That is authored work, seventeen times, and it is what separates an archive from a filter.

Three rules I would keep:

Keep the list first and the copy after it. The list answers the query; the copy explains and disambiguates. A screen of introduction above the results serves neither.

Give addresses only to real destinations. On Shipstry, /explore with any combination of category, sort and query parameters canonicalizes back to /explore. Category archives are the one place a filter becomes a URL, and only because each one has its own copy. Let ?category=ai-ml&sort=new mint an indexable URL and you will spend a year cleaning up.

Link down, not sideways. Category pages should point at the topic archives inside them. A block of 17 links to sibling categories competes with the list it sits above and teaches crawlers to ignore the block.

Topic archives

Tags are where a directory picks up its long tail. "AI video generator" is a category, "lip sync" is a topic, and both get searched.

I do not build a topic page until the tag has three approved products. Below that it is a one-card page repeating the product it lists. On Shipstry 66 tags exist and 58 clear that bar, and all 58 carry their own intro and FAQ.

The trap is that nothing keeps the two sides in sync. Tags live in the database, copy lives in a TypeScript file, and a tag that crosses the threshold goes live looking finished, with a list and no explanation. Nothing in the interface tells you it is half-built. Add the check that fails when an indexable tag has no copy: twenty lines that read product counts and compare them against the copy keys.

The same discipline applies on product pages, where a tag renders as a link only when its archive is indexable and as plain text otherwise. Internal links into noindex archives are one of the most common self-inflicted problems in directory SEO, and the fix is one conditional.

Time archives

If your product has a calendar, build this family first. Categories can be copied in an afternoon. "What shipped in the second week of March, and how it compared to the week before" cannot.

Each archive on Shipstry carries the product count, the vote total, the category breakdown with counts, the number of first-time makers, a week-over-week comparison of products, categories and votes, links to the previous and next week, and links to that month's awards.

Two indexation decisions sit inside it. The open week stays reachable but unindexed: while the week runs, votes, order and even the product set still move, so the page is noindex until the week closes and then flips. Because the URL does not change during the flip, that transition is safe. Change the URL at close and you generate a redirect per week, forever.

Sparse weeks stay out as well. The gate is a closed week with at least ten approved products, and today every closed week clears it, so it protects a future week rather than a present one.

Award pages

Winners look like repeated content, so they get skipped. They are the most shareable pages you will generate, and they cost one query if you already count votes.

A weekly winner page is the only page on the site that can say "this was the best thing that shipped that week". The winning maker shares it, which is a link you cannot buy, and it adds a second internal path to products that would otherwise only be reachable from their category.

Compute awards from votes, ordered by count with a deterministic tie-break. Give an award an editorial reason and every award page on the site becomes a paid placement in disguise.

Maker profiles and search

A profile with one product and no bio is the product page with worse information. Gate it: indexable when the maker has a written bio or at least two approved products. Everything else stays reachable and noindex.

Search is noindex, nofollow, permanently. Infinite parameter combinations, results that differ per visitor, and nothing a crawler needs that the archives do not already offer.

Internal linking you can generate

The best linking work in a directory is structural, so it exists on every page without anyone remembering to add it.

What runs on Shipstry, all of it generated:

• product → its category, every tag whose archive is indexable, its week archive, its alternatives, its same-week peers
• week archive → the categories it touches, that month's awards, the previous and next week
• topic → related topics, ranked by shared products
• category → the topics inside it

The result is that no product page is an orphan, no week archive is a dead end, and the crawl path through 37 weeks is a chain rather than a list.

One constraint I would not trade away: links come from data, never from prose. I argued that one out in the other post, and here it is just a rule you have to live with.

There is an operational cost attached to it. Sanitizing and rendering the maker's notes to HTML once, at write time, keeps product pages cheap, but it also means you cannot inject links into 800 descriptions later without a backfill. Decide the prose-link policy before you have rows.

One module decides what gets indexed

Every family above has a threshold. Put them in one place and have both the sitemap and each page's robots tag import it. Two places that decide independently will eventually disagree, and the coverage report they leave you with is one you cannot explain.

Two sitemap notes from experience. priority and changefreq are ignored by Google and I emit them anyway because they cost nothing. lastmod is the only field that carries information, and it should come from real row timestamps, meaning the newest updated_at behind each family, not a guessed date.

Rendering and the machine-readable layer

Prerender a page and the Worker never runs, which quietly rules out markdown negotiation, canonical redirects and the edge cache. The machine-readable layer sits on the same decision. /llms.txt and /llms-full.txt describe the site for agents, server-rendered pages answer Accept: text/markdown, and a read-only MCP server exposes the registry data. Whether it produces citations is still an open question for me, but it forced the rendering decision into the open, which was worth doing for caching and canonicals regardless.

Images

Directories are image-heavy and their images are bad: 16×16 favicons, two-line wordmarks on white, .ico files, dead links from three years ago.

What I do about it:

• resize anything hosted in R2 or public/ through Cloudflare Images; external URLs are left alone, and .ico is unsupported, so those bypass resizing
• set explicit width and height on every card and hero image, because missing dimensions are the cheapest layout shift you will ever fix
• use a seeded placeholder component, so a dead logo becomes a neutral tile instead of a broken image icon

767 of 820 products have a preview image, which leaves 53 on the fallback path. That is a permanent condition, not an edge case.

Build order

If I were starting a launch site or a tool directory from zero:

1. Product detail page with a facts rail and generated linking. One complete page before any archive exists.
2. One category archive with authored copy, to prove the pattern on the family that receives the most internal links.
3. The indexation module: one list of thresholds, imported by the sitemap and by every page head.
4. Topic archives, gated at three products, only with copy, plus the check that flags tags missing copy.
5. Time archives, if you have a calendar. Build the stats, the category split and the adjacent-week links together, because a list of the week's products repeats the product pages and earns nothing on its own.
6. Award pages, computed from votes.
7. The machine-readable layer, last, once the rendering decisions are settled.

Everything after that is depth, and depth does not template. The average maker writes 707 characters, anything more requires a human, and the only question worth arguing about is which hundred pages deserve one.

How you know it is working

Four signals, none of them ranking positions:

• the Search Console coverage report reads as a short list you can explain one by one
• every indexable page contains at least one paragraph that exists nowhere else
• pick a random product and there is a path to it in two hops
• the sitemap and the indexable set are the same set

When those hold, structure is done and the remaining work is content. When one of them fails, another page family will not fix it.