Site index and SEO setup

Machine-readable files

• /sitemap.xml — every public page, generated from a single list of routes so it can never drift out of date.
• /robots.txt — allows all crawlers and points at the sitemap.
• /llms.txt — a short summary of the site for AI assistants, with the same page list in plain text.
• /ads.txt — declares the authorised advertising publisher for this domain.

How the sitemap is built

The sitemap is served by the application rather than hand-written, from one array of paths with a priority and change frequency per entry. When a new guide is added, it is added to that array in the same change, so the sitemap and the site cannot disagree. We deliberately do not emit a lastmod value derived from build time — a timestamp that changes on every deploy tells crawlers nothing useful and can slow re-crawling of the pages that genuinely changed.

On-page signals

1. One H1 per page, matching the page's subject, with H2s marking real sections rather than styling.
2. Unique title and meta description on every route — titles under 60 characters, descriptions under 160.
3. Canonical tag on each content page pointing at the single preferred URL, so the www and non-www forms never compete.
4. Open Graph and Twitter card tags so shared links render properly.
5. Internal links from the How to Play hub and the guides index to every article, and cross-links between related guides, so nothing is more than two clicks from the home page.

How we set up Google Search Console

Search Console is what turns "the pages exist" into "Google knows the pages exist". The setup we used, in order:

1. Add the property as a Domain property (golfgamecalculator.app) rather than a URL prefix. A domain property covers http, https, www and every subdomain in one place, which avoids maintaining several properties that each see part of the traffic.
2. Verify with a DNS TXT record. Search Console issues a google-site-verification value; add it as a TXT record at the domain apex with your DNS provider, wait for propagation, then press Verify. Leave the record in place permanently — removing it un-verifies the property.
3. Submit the sitemap. Sitemaps → enter sitemap.xml → Submit. Status should read "Success" with a discovered-URL count matching the number of public pages. If it reads "Couldn't fetch", open the sitemap URL in a browser first — it is almost always a routing problem, not a Search Console one.
4. Request indexing for the important pages. Use URL Inspection on the home page and the hub pages, then "Request indexing". This is rate-limited to a handful per day, so spend the requests on hubs and let internal links carry the crawler to the individual guides.
5. Check coverage after a week. Pages → look for "Crawled - currently not indexed" and "Discovered - currently not indexed". The first usually means the page is thin or duplicative; the second usually means crawl budget, which internal linking fixes.
6. Confirm mobile usability and Core Web Vitals once traffic starts, since most golfers arrive on a phone mid-round.

What speeds up indexing in practice

• Publish substantive pages, not stubs. Thin pages get crawled and dropped, and a run of them slows crawling of the whole site.
• Link new pages from an existing hub immediately. A page with no internal links can sit undiscovered for weeks even when it is in the sitemap.
• Keep URLs stable. Renaming a guide's path throws away whatever authority it had; if you must, redirect the old path.
• Serve fast HTML. Content that only appears after a client-side fetch is slower to index than markup present in the initial response.

Where to go next

Start with the How to Play hub for the format guides, or read about the app for what it does and does not do with money.