SEO Case Study: Site Architecture and Internal Linking - SL Development

Most internal linking advice stops at "add more internal links." This case study is useful because it shows the opposite failure mode: a site with a dense internal link graph that was quietly routing almost all of it into pages with zero commercial value. It is a pattern that shows up on a large share of template driven sites, and it is invisible until you actually count.

What the case study covers

The published work documents a luxury real estate company competing for high end property listings in a single competitive city market, running on a Node.js stack with a content management system behind it. The engagement was an architecture and internal linking rebuild rather than a content or link acquisition program, which is what makes it a clean illustration of structural SEO.

Two structural problems were identified. The listings page offered filtering, but the filters were dynamic and produced no corresponding URLs or parameters, so neighborhood level searches had no dedicated page to compete with. Separately, low quality blog categories and tags created confusion around the primary keywords, and the FAQ and privacy policy pages ended up as the most linked to pages other than the homepage because footer links appeared across a large number of thin pages.

The two failures, and how to detect each one

Both problems are cheap to diagnose once you know what to look at. The table below turns each one into a repeatable check you can run on any site this week.

A four check diagnostic pass derived from the failures documented in the source case study.

Running the diagnostic yourself

The whole audit fits inside a standard crawl. In Screaming Frog, run the crawl with JavaScript rendering enabled so you see the site the way Googlebot does, then work through three reports.

Open the Internal tab and sort by the Inlinks column, highest first. The homepage should top the list. Whatever sits in positions two through five is what your templates are actually promoting. If those slots hold the FAQ, the privacy policy, the terms page or a login screen, you have reproduced the exact finding in this case study.

Next, open Reports then Crawl Overview to see how many URLs sit at each depth. Commercial templates buried at depth four or deeper are being told, structurally, that they are unimportant. Finally use Bulk Export then Links then All Inlinks to get a row per link, which lets you group by source template and prove which template is generating the sprawl.

Cross reference the result with Search Console. In the Performance report, filter queries by neighborhood or facet terms and look at which URL Google is choosing to serve. When a generic listings page is being returned for a dozen distinct neighborhood queries, that is the demand signal telling you which dedicated pages to build first. See our complete internal linking guide for the full crawl to fix workflow.

Building crawlable neighborhood pages

The core fix was creating dedicated neighborhood property listing pages that matched search intent. The principle generalises well beyond real estate: any filter that has genuine, repeated search demand deserves a real URL, and any filter that does not should stay as a JavaScript refinement.

A workable URL pattern keeps the hub in the path so the hierarchy is self describing:

/listings/                        hub, links to every neighborhood
/listings/riverside/              neighborhood landing page, indexable
/listings/riverside/condos/       second level facet, only if demand exists
/listings/riverside/?sort=price   refinement only, canonical to the parent

The last line matters as much as the first three. Sort orders, pagination states and price sliders multiply combinatorially and will generate an unbounded crawl space if you let them into the index. Keep them out of the XML sitemap, keep them out of internal links, and point their canonical at the clean parent. Our reference on faceted navigation covers where to draw that line.

Breadcrumbs in HTML and in JSON

The case study notes that breadcrumb navigation was added in both JSON and HTML. That pairing is deliberate and worth copying: the visible trail gives users and crawlers a real link path, and the markup makes the hierarchy explicit for rich results. Shipping only the markup, with no visible breadcrumb, is a common implementation error and it passes no link equity at all.

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li><a href="/listings/">Listings</a></li>
    <li><a href="/listings/riverside/">Riverside</a></li>
    <li aria-current="page">12 Harbour Street</li>
  </ol>
</nav>

The matching structured data mirrors that trail item for item. Position values must be sequential and the final item is conventionally left without a URL because it is the current page.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type":"ListItem","position":1,"name":"Home","item":"https://example.com/"},
    {"@type":"ListItem","position":2,"name":"Listings","item":"https://example.com/listings/"},
    {"@type":"ListItem","position":3,"name":"Riverside","item":"https://example.com/listings/riverside/"},
    {"@type":"ListItem","position":4,"name":"12 Harbour Street"}
  ]
}

Full property level implementation notes are in our breadcrumb schema guide.

Footer discipline

Revising the footer to prioritise internal linking to top pages is the least glamorous item on the fix list and probably the highest leverage one. A global footer is the single most repeated block on a website, so every link in it is multiplied by your total page count. Treat those slots as scarce.

The practical rule: legal and utility links belong in one compact row, ideally as a short list rather than a column of equals. The remaining footer space should point at the hub pages and the top commercial categories you actually want to rank. Anchor text should describe the destination rather than repeat a single head term across every slot, which is covered in our footer link strategy notes.

The rest of the change set

Architecture was the headline, but the engagement shipped several other changes at the same time, and being honest about that matters when you read the results. Alongside the neighborhood pages and the footer rewrite, the team eliminated the problematic blog categories and tags, rewrote metadata using dynamic templates, added structured data for property listings and open house events, updated the sitemaps and implemented Cloudflare caching.

Dynamic metadata templates deserve a note. On an inventory site with hundreds of listings that change weekly, hand written titles are not maintainable. A template that assembles the title from stable fields, such as bedroom count, property type, neighborhood and brand, gives you unique metadata at scale without creating an editorial backlog. Open house event markup is the same idea applied to a time bound opportunity: it only pays off if the dates are generated from the same source of truth the site uses, because stale event data is worse than none.

Reported results

The case study reports outcomes across two years.

Figures as reported by SL Development in the source case study linked below. SEO ProCheck has not independently verified the underlying analytics.

Read the second year carefully. Traffic growth held steady while conversion growth fell from 19% to 7%. That shape is typical when an architecture fix first captures high intent queries that were previously unservable, then continues expanding into broader, less transactional terms. It is a reminder to keep reporting traffic and conversions side by side rather than celebrating a single line.

What to copy, and what not to

• Copy the diagnostic. The inlink sort takes ten minutes and finds the problem or rules it out.
• Copy the demand test before building pages. Build neighborhood or facet pages only where Search Console and keyword data show repeated demand. Generating one page per filter value regardless of demand is how sites end up with doorway page problems.
• Do not copy the percentages as a forecast. A single client result on a Node.js real estate site in one city is not a benchmark for your site, your market or your starting authority.
• Do not treat archive removal as free. Before deleting tags and categories, check whether any of them earn traffic or hold backlinks, and redirect rather than delete where they do.
• Watch for orphans after the rebuild. Restructuring navigation frequently strands old URLs. Recrawl and check for orphan pages once the new templates are live.

FAQ

Source: https://www.sldev.io/real-estate-site-structure-internal-linking/