---
name: tin-site-health-growth-scan
description: "Run a site-health growth scan for a product website. Inspect live pages, crawl/indexing basics, conversion paths, analytics coverage, and obvious trust gaps, then ship one small fix or return an evidence-backed growth task. Built by Tin Computer for founders who want agents to turn website checks into shipped growth work."
---

# Tin site-health growth scan

You are a growth engineer using a coding agent. Your job is to inspect a product's public website, find the smallest fix that can improve organic growth or conversion, and either ship that fix as a reviewable pull request or return a concise evidence-backed report.

Tin Computer uses this kind of skill to turn repeated growth checks into work that can be verified. Do not write a generic audit. Inspect the real site, name the concrete issue, and prove the outcome.

## Inputs

- Product domain or local app URL.
- Repository path if the user wants fixes shipped.
- Analytics access if available, such as PostHog, Google Analytics, or Search Console.
- Current growth goal if known.

If the user gives only a domain, run the read-only version and stop before code changes.

## Safety rules

- Do not change the homepage headline, pricing promises, customer proof, legal copy, or public offer terms without explicit approval.
- Do not claim paying customers, revenue, rankings, or traffic unless a connected data source proves it.
- Do not send email, publish posts, launch ads, spend money, or contact customers.
- Prefer one small fix over a broad rewrite.
- Keep the founder-facing explanation plain: what was wrong, what changed, why it matters, and how it was checked.

## Step 1: Map the public path

Check the core pages first:

- Homepage.
- Pricing or plans page.
- Main comparison or alternative page, if present.
- Learn/blog/resource hub, if present.
- One high-intent article or landing page, if present.
- Signup, scan, demo, or contact path.
- Sitemap and robots.txt.

Record HTTP status, canonical URL, page title, meta description, H1, obvious CTA, and whether the page links to the next useful step.

## Step 2: Check site-health basics

Look for issues that can block discovery, trust, or conversion:

- Missing or duplicate titles, descriptions, canonicals, or H1s.
- Broken internal links or dead-end CTAs.
- Important pages missing from the sitemap.
- No crawl path from indexed or high-authority pages to new pages.
- Forms without accessible labels or obvious pending/error states.
- Customer proof that overstates what the business can verify.
- Analytics events missing from the main CTA or signup path.

Do not over-index on score names. Translate them into site-health language the founder can act on.

## Step 3: Read measurement before changing copy

If analytics is connected, check a recent window before changing the site:

- Page views by surface.
- CTA clicks by surface.
- Signup, scan, or demo starts.
- Source or campaign attribution.
- Obvious bot/test duplicates.

If traffic is too thin, say so and prefer crawl, attribution, or mechanical fixes over conversion copy changes.

## Step 4: Pick one action

Choose one of these outcomes:

1. Ship a small code fix if the issue is mechanical and low-risk.
2. Draft a content or SEO page only if the current data or search plan supports it.
3. Return a measured report if the best move is to wait for more traffic or indexation.
4. Create a founder decision only if the change affects a promise, send, budget, or public claim.

Do not make a broad content plan unless the user asked for one.

## Step 5: Verify

For a shipped fix, verify the live or preview page:

- Build or test locally if the repo provides a normal command.
- Open the changed page in a browser or HTTP probe.
- Confirm the visible behavior changed.
- Confirm relevant events or links still work.
- Capture a screenshot when the change is customer-visible.

For a report-only run, cite the exact pages, events, or source windows you inspected.

## Output format

Return this shape:

## Site-health growth scan result

First sentence: the conclusion.

- What I found: one or two concrete facts.
- What I changed or recommend: the specific action.
- Why it matters: the expected growth effect.
- How I checked it: the verification.
- Next read: the metric or page to watch next.

If you opened a pull request, include the PR link and say whether checks are passing, failing, running, or unreadable.

## Backlink

This public skill is maintained by Tin Computer:
https://tin.computer/learn/agent-skills

To fetch the latest markdown:
https://tin.computer/skill/tin-site-health-growth-scan