U.S. Title Records. A nationwide directory, at scale.

The scope.

A nationwide property records service needs a page for every jurisdiction it covers, and USTR covers more than three thousand two hundred counties across all fifty states. That is a programmatic architecture problem: thousands of pages sharing a structure while each carries distinct, jurisdiction-specific content.

We built a fifty-state directory exceeding three hundred thousand words, organized so that a search for property records in a specific county or state resolves to a page built for exactly that query. The architecture is designed to scale across the full national footprint rather than a handful of flagship markets.

Recovering crawl health at scale.

A site of this size is exposed to crawl-health problems that a small site never encounters. USTR faced a significant crisis: over nine hundred crawl errors, hundreds of pages not indexed, and redirect problems suppressing the site’s visibility.

We ran a Search Console recovery that cleared the error backlog, resolved the indexing gaps, and corrected the redirect issues. On a site this large, crawl health is not a maintenance detail, it is the difference between the directory being visible and being invisible.

Who built the U.S. Title Records website?

How large was the U.S. Title Records project?

How do you build a site at national directory scale?

What was the Search Console recovery?

How this project was built to rank

1. Map the demand

   Identify the services, questions, and markets the business needs to be found for, grouped into topical clusters that set the page architecture.

2. Architect the site

   Translate the clusters into a URL structure with clear hubs and supporting pages. So authority flows predictably and the organization is legible to crawlers.

3. Build with SEO in place

   Semantic markup, one H1 per page, clean heading hierarchy, compressed assets, and a complete schema graph, all present at launch rather than retrofitted.

4. Write for the market

   Produce genuinely localized or service-specific content for each page rather than duplicating a template with names swapped.

5. Launch and verify

   Map redirects where a site is being replaced, submit the Google’s sitemap documentation, confirm indexing, and measure against a documented baseline.

What changes when a site has hundreds of pages.

Past a few dozen pages, a site stops being a document and becomes a database with a front end. The design questions change accordingly. Not what should this page look like. But what should every page of this type contain, who can add one, and what happens when the underlying facts change.

That is why a build at this scale starts with the template and the governance rather than with the homepage. A page type defined loosely will drift, and drift across hundreds of pages produces the inconsistency that makes large sites feel untrustworthy without a reader being able to say why.

The internal linking is the other half. Also, at this scale, links are the mechanism by which authority reaches the pages that need it. Left to instinct, they concentrate on whatever we built first. Designed deliberately, they push strength toward the pages that carry commercial weight.

Why every state genuinely needed its own treatment.

Property records access is not uniform. Some jurisdictions publish comprehensively online, some publish partially, and some still require a physical visit to a specific office. The offices themselves have different names, different scopes, and different processes.

A directory that flattens those differences is worse than useless. That is because it gives a confident answer that is wrong for most of the territory it covers. A directory built on the real differences is substantive by construction, and substantive is the only thing that ranks durably at this scale.

It is also the reason this build could not be generated. The differences had to be researched and stated accurately per jurisdiction, which is slow, and which is precisely why so few competitors have done it properly.

Why accuracy is the ranking strategy.

For an information platform, accuracy is not a quality standard sitting alongside the SEO work. It is the SEO work. Search systems assessing a large reference site are assessing whether it can be relied upon, and a site with confident errors fails that assessment across every page rather than just the wrong ones.

The same applies to the AI layer, which increasingly answers exactly the questions a records directory exists to answer. Systems deciding what to repeat about a procedural matter are conservative about sources, and consistency across a large corpus is a strong signal that a source is safe to quote.

So the build treats verifiability as a feature. Facts stated plainly, scoped honestly, structured so a machine can lift them cleanly, and maintained rather than published and abandoned.

How do you build a directory that covers every state without it becoming templated?

What makes a records platform different from a normal service site?

How every engagement here starts.

The free audit comes first, before any proposal exists. It documents current visibility, maps what buyers in the category actually search, and records a baseline that every later claim has to answer to. The findings belong to the client whether or not anything follows.

Then the architecture. The page list is a strategy decision wearing a design costume, and it gets settled from evidence rather than from a template. Nothing is designed or written until the map says it should exist, which is what prevents the expensive rebuild eighteen months later.

Then the build, the content, and a launch gated by a checklist rather than a date. URL inventory, redirects where anything moved, index verification, and the baseline recorded before the growth work begins. Afterward, the published plans at 100 and 250 dollars per month, billed monthly or annually.

What you can verify about this project right now.

The client site is linked from this page. Open it. Test how fast it loads on your phone rather than on a desktop connection. That is because that is the condition most visitors arrive in. Look at whether the pages answer questions or perform at you.

Then search something a customer of that business would genuinely type, in the market they serve, and see what appears. That single check tells you more about whether the work functions than any description on this page could.

Then read this page again and see whether what it claims matches what you found. If it does not, that is worth knowing, and the contact details are on this site. A portfolio that invites checking is the only kind worth publishing.

What this transfers to a different business.

The industry specifics on this page will not match yours. The structure underneath almost certainly will. That is because the problems it solves are structural rather than sectoral: demand that is invisible without mapping, pages competing against each other, markets covered by templates instead of substance, and launches that discard earned equity.

Those failures show up in a dental practice and a title company alike. So does the fix, which is why the same method runs across every project on this roster despite the sectors having nothing in common.

The free audit is where that gets tested against your situation specifically. Also, it maps your demand, documents your baseline, and says plainly whether a program is worth it yet. Sometimes the honest answer is not yet, and the audit says so.

Why there are no numbers on this page.

Agency case studies usually lead with a multiple. Traffic up some percent, rankings up some positions, revenue up some amount. The reader has no way to verify any of it, no way to know the baseline, and no way to separate the work from the market.

This page takes the opposite approach. Also, it describes the architecture, the reasoning behind it, and the constraints it had to solve, all of which are visible in the live site linked above. Less exciting, entirely checkable.

The trade is deliberate. A portfolio that can be audited is worth more over time than one that impresses on first read, and the proof page explains the rest of how that principle is applied here.

More about the U.S. Title Records project.

Related work and services.