depthfirst SEO Teardown: 40 Mirrored Pages, 16 JobPosting Schemas, 4 Broken Privacy Links

depthfirst is doing something most security startups struggle to do well: the site is small, compact, and tightly linked. There are no orphan pages in the crawl. The main commercial pages are easy to reach. The architecture is simple enough that important URLs are getting internal support.

But the crawl also shows a second story.

The public site appears to exist twice: once on depthfirst.com and again on marketing-v2.depthfirst.com. Most pages have no schema at all. And the research and blog layer often exposes only a handful of crawlable words on pages whose titles suggest much deeper content.

This is not a teardown about a site collapsing under SEO debt. It is a teardown about a site with a strong base and a few structural choices that are quietly capping how much search value the content can actually capture.

What We Crawled

The crawl found 83 URLs in total:

• 40 pages on depthfirst.com
• 40 pages on marketing-v2.depthfirst.com
• 1 page on app.depthfirst.com
• 1 page on trust.depthfirst.com
• 1 page on www.depthfirst.com

Status-code breakdown:

• 80 pages returning 200
• 3 pages returning 404

Just as notable as what the crawl found is what it did not find:

• 0 orphan pages
• 194 internal-link suggestions across the crawl

That usually means the site structure is at least coherent enough for the crawler to move through it cleanly. The main SEO questions here are not discovery and not link coverage. They are duplication, structured data, and how much crawlable substance exists on the pages depthfirst is asking Google to rank.

Section 1: The marketing-v2 Mirror Is the Biggest Structural Risk

The most important finding in this crawl is not the broken links. It is duplication.

The site appears to have a near-complete mirror on marketing-v2.depthfirst.com. The mirrored set includes:

• Homepage
• Product pages like /code, /platform, /dynamic-testing, and /secrets
• Case studies
• Careers pages
• Blog and post URLs
• Legal pages

In practical terms, that means 40 public pages exist in two live versions.

The good news is that the canonical tags are mostly pointing the marketing-v2 pages back to the depthfirst.com versions. That is better than leaving Google to guess. But canonical tags are still a weaker signal than not exposing a second public copy in the first place.

This matters for three reasons:

1. Crawl budget gets diluted. Search engines still have to crawl and process the mirrored URLs before consolidating them.
2. Link equity can fragment. If internal or external links point at both versions, signals are spread before canonicals are interpreted.
3. Quality signals get noisier. When the same page exists twice on public hosts, Google has more work to do to decide what is primary.

Here is what that duplication looks like in the actual crawl:

The fact that the mirrored pages are not random is what makes this important. These are not a few staging leftovers. This looks like a parallel public marketing environment that remains indexable.

Takeaway: If marketing-v2.depthfirst.com is not meant to be a public search surface, it should not remain publicly crawlable at this scale. A consistent redirect or noindex strategy would be a cleaner solution than relying on canonicals across a 40-page mirrored set.

Section 2: The Site Is Compact, But the Crawlable Content Layer Is Thin

The crawl found an average word count of 104.5 words and a median of just 11 words across all 83 URLs.

Those numbers are distorted slightly by app, trust, and utility pages. But even after focusing on the main content set, the picture stays unusually thin.

The clearest example is the /post/ library on the canonical domain:

• 13 post URLs
• 67.2 average words
• 11-word median

That would be unremarkable if these were just placeholder posts. They are not. Their titles suggest high-value, expert-led content:

• Agent Capability Is a System Design Problem
• Esbuild's XSS Bug that Survived 5 Billion Downloads
• Anatomy of an Automated Patch
• The Masked Namespace Vulnerability in Temporal

From the crawl’s point of view, though, most of these pages expose between 6 and 14 words of crawlable text.

That creates a mismatch between brand signal and search signal. To a reader, these look like serious research or product-thinking pieces. To a crawler, many of them look barely populated.

This is also where the teardown needs one caution flag. A crawl cannot always tell the difference between content that is genuinely thin and content that is rendered in a way the crawler cannot fully extract. The evidence here is still strong enough to warrant concern, because the homepage and several commercial pages expose substantial text just fine. That makes the /post/ pattern look less like a global rendering limit and more like a page-type-specific issue.

There are exceptions. The main homepage exposes 664 words. Pages like /platform, /dynamic-testing, /secrets, and /code sit in the 250-367 word range. The Series B post comes in at 754 words.

So this is not a site-wide inability to render content. It looks more like the research and blog layer is either:

• rendering most content in a way the crawl could not fully extract, or
• publishing pages where the visible body copy is much lighter than the page title implies

Either way, the SEO implication is the same: Google can only evaluate what it can reliably access.

If depthfirst is troubleshooting that layer, the best next check is a focused crawlability pass rather than a generic content audit. Our guide on how to do a technical SEO audit in 30 minutes is the right workflow for validating whether the issue is rendering, template output, or genuinely thin page bodies.

Takeaway: If those post URLs are meant to rank, the first question is not more backlinks or more internal links. It is whether the actual article body is consistently available as crawlable HTML.

Section 3: Schema Exists, But Almost Only on Careers Pages

The crawl found 67 pages with no schema at all.

The only structured-data footprint visible in the export is:

• 16 pages using JobPosting schema

That means careers content is getting structured data, while the rest of the public marketing site is largely going without it.

For a company like depthfirst, that is a missed opportunity across several page types:

• Homepage should typically carry Organization schema
• Product and platform pages could support cleaner entity understanding
• Case studies could benefit from richer content classification
• Post pages could use Article or BlogPosting markup if they are intended to function as editorial content

This is not a case where the site has zero schema maturity. The careers system clearly knows how to emit structured data. The issue is that the rest of the stack does not appear to be using the same discipline.

The interesting part is what this says about implementation priorities. depthfirst has wired schema where it is operationally obvious, but not where it would help shape the broader understanding of the site.

Takeaway: A template-level schema pass across the main marketing and editorial pages would likely be one of the fastest technical improvements available here. The fix is not page by page. It is template by template.

Section 4: The Broken Link Problem Is Small, Repeated, and Easy to Miss

The broken-links CSV is small. That is the positive part.

The crawl found 4 broken internal links. All four point to some version of a missing privacy-policy URL:

• https://depthfirst.com/privacy-policy
• https://marketing-v2.depthfirst.com/privacy-policy
• https://www.depthfirst.com/privacy-policy

The broken links appear on:

• https://depthfirst.com/book-a-demo
• https://depthfirst.com/legal/terms-conditions
• https://marketing-v2.depthfirst.com/book-a-demo
• https://marketing-v2.depthfirst.com/legal/terms-conditions

That pattern matters more than the raw count.

This is not a site with broad link rot. It is a site with a repeated legal-link mismatch. The valid privacy URL appears to live at /legal/privacy-policy, while some pages still point to /privacy-policy.

These are exactly the kinds of issues teams ignore because the count looks small. But they tend to live in high-trust sections like forms, legal pages, and footers, which means they affect pages users expect to be reliable.

Takeaway: This is a small fix with outsized trust value. Update the links to the live privacy URL or redirect the legacy path permanently. If depthfirst wants a repeatable way to catch this class of issue after launches and template updates, how to find broken links on your website is the closest supporting workflow.

Section 5: What depthfirst Gets Right

This crawl is not all negative. A few things stand out positively.

1. No orphan pages

This is rare enough to call out directly. The site may be duplicated, but it is not disconnected. Important pages are getting linked.

2. Strong internal-link concentration on key commercial pages

Pages like /code, /dynamic-testing, /secrets, /supply-chain, /platform, and /company all sit around 114-120 incoming links in the export. That suggests the site knows which URLs matter commercially and routes navigation toward them.

3. Reasonable image-alt performance

Across the crawl, average image alt coverage is 78.4%. That is not exceptional, but it is healthier than what shows up on many SaaS sites of similar size.

4. A narrow technical issue set

The site does not appear to be suffering from the usual mess of orphan pages, dozens of broken internal URLs, or broad metadata collapse. The core issues are concentrated, which makes them easier to fix.

That matters because focused fixes compound faster than sprawling audits.

How depthfirst Can Think About Optimization

Quick Wins

• Decide whether marketing-v2.depthfirst.com should remain publicly crawlable. If not, consolidate it with redirects or a stronger exclusion strategy.
• Redirect /privacy-policy to /legal/privacy-policy everywhere it still exists.
• Add Organization schema to the homepage and template-level schema to core marketing pages.
• Verify that the /post/ content is fully server-rendered or otherwise exposed as crawlable HTML.

Next Phase

• Add Article or BlogPosting schema to the post library if those pages are intended to rank as editorial content.
• Review the mirrored-page link graph to make sure internal links are not unnecessarily pointing at marketing-v2.
• Improve metadata and social-tag coverage on the handful of pages where fields are still missing, especially utility and legal routes.

Longer-Term Opportunity

• Decide what role the post library plays in search. If it is meant to be a real editorial asset, increase crawlable depth and internal support around the strongest posts.
• Turn the strongest security and research content into clearer topic clusters so posts reinforce product pages rather than sitting as isolated thought leadership.
• If the mirrored environment remains live for operational reasons, monitor it explicitly so duplicate surfaces do not keep drifting. How to monitor broken links automatically is adjacent, but the same principle applies to ongoing structural QA.

Key Takeaways

• 83 crawled URLs, but only 43 primary URLs once the marketing-v2 mirror is set aside
• 40 public mirrored pages on marketing-v2.depthfirst.com, with canonicals doing cleanup that infrastructure should handle more directly
• 67 pages with no schema, while 16 career pages are the only ones emitting JobPosting
• 4 broken internal links, all tied to an outdated privacy-policy path
• 0 orphan pages, which is a real strength
• 11-word median crawlable content depth, with much of the /post/ library looking far thinner to crawlers than the titles suggest

depthfirst does not have a chaos problem. It has a focus problem. The site architecture is compact and the internal linking is healthy, but those strengths are being diluted by a public mirrored environment and a content layer that often looks much lighter to search engines than it likely intends to be. Fix the duplication, make the post content fully crawlable, and extend structured data beyond the careers system. That would move the site from technically decent to much easier for search engines to trust and interpret.

Want to run a crawl like this on your own site? Try redCacti