hey postcard Review: thin reach (60.4/100) — SiteList

hey postcard is a five-page, single-page app-download landing site for an iOS consumer product.

Field	Value
Domain	heypostcard.com
Category	Slow/asynchronous personal messaging
Pricing	Unknown; no price or monetization disclosure in the crawl
Crawl	5 pages crawled on 2026-08-12
Overall score	60.4/100

hey postcard scores 60.4/100. Its strongest asset is a clear, distinctive product mechanic: messages arrive the next morning, between 8 and 10 AM, rather than appearing instantly. The crawl baseline is documented: all 5 crawled URLs returned 200, used self-canonical URLs, appeared in the sitemap, and had raw HTML identical to rendered HTML.

The limiting factor is strategic coverage. The crawl found zero informational pages and zero comparison pages; keyword-gap analysis placed the site on roughly 3 of an estimated 26 category topics. The homepage title, H1, and 67-word body do not share one category target, while /postbox repeats the homepage H1 and has in_degree 0. Measurement is incomplete: all 8 PageSpeed runs returned empty, Search Console is unconnected, and Wayback has no snapshot.

Top themes:

• Give the homepage one clear category target and delivery promise.
• Resolve the duplicate, orphaned /postbox page.
• Build a small discovery surface around how it works, Android availability, and alternatives.

hey postcard explains its core mechanic in seconds, but it does not clearly name its audience or show the product. The hero says "not everything should be a quick message, wait for the morning." and promises delivery between 8 and 10 AM at a random time; jargon density is 0.0 per 1,000 words. The title, meta description, visible hero, and social phrasing tell four different stories, while the only adjacent proof is a Product Hunt mention. Align the title, meta, and OG copy around the delivery mechanic, then show real postcard mockups and a morning notification.

The site makes the product understandable but leaves the download decision's most important questions unanswered. Visible copy explains that visitors can send digital postcards delivered the next morning, yet "close friends" appears only in the meta description and the page never states the price or whether a recipient needs the app. The two-sided product therefore asks a visitor to imagine the recipient path. Add a short how-it-works block that resolves recipient access, cost, and the 8–10 AM local-time rule, and put the audience in visible copy.

A simulated cognitive walkthrough passes the first-impression and App Store handoff tasks, but every how-do-I task fails at support. The homepage H1, positioning line, and delivery sentence explain what the product does without a click; the App Store link and QR code make the desktop-to-phone handoff clear. The support link is also easy to find, but /support supplies only contact@heypostcard.com and a 2–3 business-day response promise, with 0 forms, 0 buttons, and no search. Replace the dead-end with task-based answers before relying on email.

hey postcard has a structurally clean accessibility baseline, but the supplied audit reports one Level A issue plus contrast problems. Every page carries lang="en", exactly one H1, and no skipped heading levels; alt attributes are present on all sampled images. The Level A issue is aria-hidden="true" elements containing focusable descendants, while the audit also reports insufficient color contrast. Fix the focusable-hidden content and contrast tokens, then recheck the App Store and QR-code handoff on mobile. These are concrete defects in an otherwise disciplined five-page structure.

The homepage writing is unusually disciplined for a consumer app landing page. Its 86 words make a specific promise, use concrete timing, and avoid app-marketing clichés; the line "not everything should be a quick message, wait for the morning." gives the product a point of view. The copy loses force when it reaches the missing context: it does not name the audience, price, or recipient path, and the title's "meaningful conversations" phrase is not supported by visible copy. Preserve the plain language while adding the missing decision facts.

hey postcard is technically stable in the crawl, with fragility caused by its tiny footprint rather than a detected outage. All 5 URLs returned 200, there is no noindex, Googlebot is allowed, there are no redirect chains or loops, and raw and rendered metadata match (js_only_share: 0). The risk is concentration: one bad deploy or stray directive would affect nearly the entire organic surface. Wayback returned no CDX rows and RDAP failed, so history is unverified. Connect Search Console and add a weekly 200/noindex/canonical tripwire for / and /postbox.

The five-page brochure corpus reads plainly, but the homepage and Terms §7 disagree about delivery behavior. All 5 sampled pages pass the AI-tell gate at 0–2 tells, and the legal copy contains useful definitions. The halt-class defect is substantive: the homepage promises delivery between 8 and 10 AM at a random time, while Terms §7 says postcards may be delivered immediately or at a scheduled time. The site also has no question-form heading with a self-contained answer. Reconcile the contract, then add four genuine FAQ-style answers.

Self-serve help is limited to a 43-word support page with one email address and a 2–3 business-day response promise. That is a defensible contact baseline, but it is not documentation: the crawl finds no task answers, no search, and no in-page path for account, postcard, or notification questions. A visitor must begin an email round trip for basic product facts. Rebuild /support from mechanics already present in the legal pages, with clear answers for delivery timing, recipients, postal codes, Android, and account actions.

Technical SEO is the site's strongest operational layer: all 5 crawled URLs return 200, use self-referential canonicals, appear in the sitemap, and render raw HTML identical to the rendered result. The crawl reports no 4xx or 5xx pages, no redirect chains, and no client-side metadata dependency. The remaining ceiling is strategic rather than mechanical: the site has only five known URLs, and the canonical pages do not yet give search systems enough category context. Preserve this baseline while expanding the public product explanation.

hey postcard is a focused, understandable iOS product whose next-morning delivery window gives it a specific position. A first-time visitor can grasp the basic idea quickly from the homepage, and the five crawled URLs have no reported 4xx or 5xx errors, redirect chains, or noindex directives.

The site is not yet a complete discovery or evaluation system. Its homepage needs one aligned category phrase in the title, H1, and opening paragraph; /postbox needs either a distinct purpose or noindex,follow plus a homepage link; and the domain needs indexable explanation and comparison pages. Price is not stated in the crawled corpus, and the Android path ends at a Google Form.

This is best suited to iOS-owning consumers who want a slower way to stay in touch with close friends. The next improvement is not more brand language; it is making the product's category, mechanics, and availability explicit on owned pages.

The first 14 days should establish a measurable baseline and give the homepage one target. Days 15–45 should expand the owned explanation and resolve duplicate intent; days 46–90 should add the first comparison and pillar pages.

Window	Action	Expected effect
Days 1–14	Verify Search Console, run PageSpeed manually, and align the homepage title, H1, and opening paragraph around the product category and 8–10 AM promise	Creates a before-state, restores performance measurement, and clears the homepage relevance gap
Days 1–14	Resolve /postbox with noindex,follow, or give it a distinct H1 and a homepage link	Removes duplicate intent and the orphan
Days 15–45	Add an on-domain Android page, expand the homepage and support content, and add entity/app markup	Makes mechanics, availability, and support more discoverable
Days 46–90	Publish /how-it-works, /slowly-alternative, and one further comparison page, then re-scan against the baseline	Opens category and comparison coverage and makes score change measurable

This review uses crawl evidence from 5 pages captured on 2026-08-12, including rendered and raw HTML, URL and link-graph data, sitemap and robots observations, technical metadata, and the supplied dimension summaries. The review score is 60.4/100; the executive-summary inputs also contain a 57/100 SEO-composite narrative, which is a component summary rather than the overall score.

The assessment does not claim live-user testing, traffic, rankings, or field performance. Usability is a simulated cognitive walkthrough. Search Console was not connected, Wayback returned no snapshot, and all 8 PageSpeed runs returned empty results. Excluded dimensions were 05 Design execution, 07 Performance, 12 Decision-support surfaces, 13 Review-content integrity, 18 Content briefs discipline, 22 Content freshness, 28 Content portfolio health, and 31 Programmatic SEO quality; they were failed or not applicable as supplied.

For the scoring framework and dimension definitions, see How SiteList scores.