Foreclosure Data Hub

Every SEO primitive lived in a single module: the canonical origin, the URL normaliser, the Open Graph and Twitter builders, and the JSON-LD factories. No page ever hardcoded the domain.

This sounds like housekeeping and it is not. One typo in a domain constant silently splits canonical signals across two hostnames, and it is close to invisible in review. Centralising made that class of bug impossible rather than unlikely.

A permanent redirect at the edge forced every apex-domain request to the www host, so link equity never split between the two.

Every public page rendered its HTML on the server, so crawlers never depended on client hydration to see content. All roughly 2,100 URLs were prerendered at build time.

Content that changed used incremental revalidation rather than client fetching, so live counts stayed fresh without giving up static HTML. Time to first byte stayed flat regardless of database latency.

Foreclosures are noticed and auctioned county by county, so the county tier matched the unit the market actually searches in. That single choice mattered more than any on-page work that followed.

A state-only build would have produced 50 pages competing with every national aggregator. A ZIP-code build would have produced tens of thousands of pages with nothing unique on any of them.

Nothing became a public URL unless it resolved against an authoritative US county reference list. Scraped county values are polluted with malformed spellings, and without that gate the generator would have produced hundreds of near-duplicate pages for entities that do not exist.

Each county page carried its own numbers: total listings, upcoming auctions, next scheduled sale date, share of state volume, and rank among tracked counties in that state.

It also carried a real preview table of listings from that county, with an explicit honest label when inventory was too thin and a statewide sample was shown instead. FAQ answers were computed from those same numbers and fed both the visible accordion and the structured data.

The test that governs this: strip the entity name from the page. If nothing unique remains, the tier should not be published. Templated answers with only the place name swapped are what triggers a doorway classification, and that classification is site-level and is not appealable by argument, only by deletion.

The sitewide graph was a single @graph array with stable @id anchors, so the organisation, site, business and software nodes cross-referenced each other instead of duplicating. The site node pointed at the organisation by id rather than restating it.

Honestly: breadcrumbs and FAQ markup changed what appeared in results. Dataset markup opened a channel most competitors ignore. The remaining types produced no visible rich result. They are not wasted, they contribute to entity understanding, but adding eleven schema types does not produce eleven rich results.

Two rules prevented rejections. Optional fields were omitted rather than filled with empty strings, and every number inside the structured data was computed from the same source as the visible text. Markup that disagrees with the page is a standard cause of rich-result rejection.

Search crawlers and citation engines were allowed: Googlebot, Bingbot, and the answer engines that produce cited, clickable links. Training-only crawlers that take the corpus and return no referral traffic were disallowed.

This is the highest-leverage robots decision available right now, and it is a decision rather than a default. Blocking everything labelled AI costs citations. Allowing everything donates the corpus for free.

robots.txt was generated from code rather than kept as a static file, so the disallow list could not drift from the routes.

The sitemap was generated from the same data modules the pages rendered from, so a new county page could not exist without a sitemap entry.

Last-modified dates were differentiated per content type rather than stamped with one build timestamp. A sitemap where every URL changed at the same second is a freshness signal crawlers learn to ignore. County entries used a constant stamped by the data regeneration job, so the date was genuinely true.

The same constant fed the visible data-as-of label on the page, so the page and the sitemap could never disagree.

The site published a machine-readable brief with an entity definition, a key facts block, and explicit statements about what the company is not, plus an extended file carrying a canonical question and answer block and citation guidance naming which URL to cite.

Two techniques changed citation behaviour across a set of seed queries. First, answers were written as self-contained sentences that restate the subject, so an extracted sentence stands alone as a citable fact. Multi-paragraph answers to the same questions produced no citations where single self-contained sentences did.

Second, explicit entity boundaries. Stating that the company is not a government agency, not a county recorder and not a brokerage stopped models conflating it with adjacent entities, which in a government-adjacent niche was a recurring problem.

Scheduled jobs regenerated the county data snapshots weekly and committed the diff, submitted the URL set to participating engines, and refreshed the underlying listing data daily.

Generated snapshots were committed to the repository, so builds were deterministic and a bad data pull showed up as a reviewable diff rather than a silent change on the live site.