TECHNICAL SUITE
Technical SEO, from crawl to fix.
Technical Suite crawls your entire site, diagnoses what's wrong, prioritises what matters, fixes what it safely can, verifies the result, and keeps watching for what changes next. The crawl is where it starts.
A workflow it runs. A surface it understands.
Six stages, run continuously on every site, looping back to Crawl.
Ten technical layers, all fed by the same crawl.
That's what "Suite" means here: one workflow acting on the whole surface.
The story that matters: yours.
Figures for the whole platform are further down. These are the loop's numbers for one site.
A finding isn't a fix.
Audits tend to end at the export. Somewhere between the crawl and an applied fix, most findings stop moving.
1,204 issues surface in the audit, exported to a spreadsheet.
Prioritised behind feature work. Not urgent enough to jump the queue.
Eighteen "critical" items from Q1's audit are still sitting here, next to a shrug and "we know."
Technical Suite is built to close that whole chain rather than only the first link. Six stages, one system.
See your entire technical surface.
Every discoverable URL within crawl scope gets crawled, on a schedule, run after run. A one-off audit tells you about the day it ran. A continuous crawl tells you what's true right now.
Discovered ≠ crawled ≠ indexable ≠ indexed. Each is a different failure point, reported separately.
*Crawlable and indexable are determined directly from the crawl. Indexed status reflects Search Console or another connected data source, where available.
Every dimension checked on every page: crawlability · indexability · rendering · status codes · canonicals · links · schema · performance · robots · sitemaps.
More than a list. The technical condition of the site.
Diagnosis is the layer between a crawl and a to-do list. It turns raw findings into a model of where the site stands.
Not every issue deserves the same response.
Finding 1,204 issues is the easy part. The hard part is knowing which ten to fix first. Every issue is scored on impact and scale rather than only severity.
↑ HIGH IMPACT
Near-duplicates splitting crawl budget across one real page.
The layer dragging technical health down the most this cycle.
340 documentation pages unreadable by two AI engines.
Mostly chains left over from the last platform migration.
The suite diagnoses. AutoFix executes.
Every issue the crawl finds falls into one of two categories, and the page always tells you which.
Applied automatically
- ✓Schema errors: missing or malformed JSON-LD
- ✓Meta tag issues: missing titles, duplicate descriptions
- ✓Heading tag issues: missing or duplicate H1s
- ✓Missing image alt text
- ✓Canonicalisation problems with a single correct answer
- ✓Orphan pages: linked back into the site automatically
Diagnosed, not auto-applied
- →Redirect chains of any length, and server-side redirects
- →Duplicate-content strategy: which page should canonicalise where
- →Performance root causes: unsized images, render-blocking scripts
- →Content gaps and anything touching application code
340 product pages share the same meta description, and 88 are missing an H1 entirely.
Each description generated uniquely from page content. H1 added, matching the page's topic.
Every AutoFix change is logged with a before-and-after diff and can be rolled back from the fix history at any time. Nothing is applied silently.
Explore AutoFix in depth →Confirm the fix held.
A fix that isn't verified is a guess. The next crawl checks every change against what it was supposed to do.
Your site keeps changing. Technical Suite keeps watching.
Crawl history is kept run over run, not overwritten. A regression shows up as a change, not as something you have to notice yourself.
Appeared since the last crawl, mostly under /products/discontinued-line/*.
Applied automatically by AutoFix this cycle.
Worth a look: a template change likely touched more than one page.
A change here triggers the next crawl. ↻ back to CRAWL.
Diagnosis goes deeper than a pass/fail score.
A handful of the diagnostic layers behind the score above, in more detail.
Crawlable. Indexable. Indexed. Not the same thing.
A page can be perfectly crawlable and still be blocked from indexing by its own canonical or a noindex tag. Technical Suite reports the three separately, because collapsing them into one status hides exactly where a page is failing.
What the server sends. What the browser shows.
For JavaScript-driven pages, the crawl checks both the raw HTML response and the rendered DOM, because content, links and metadata that only appear after a script runs are invisible to anything that only reads the server response.
Server response
- →Title: "Product"
- →No product links present
- →No meta description
Rendered DOM
- ✓Title: "Trail Runner 3 | Ledgerly"
- ✓42 product links present
- ✓Full description rendered
This page checks out fine once rendered. The gap matters most when it doesn't: content or links that never make it into the rendered version at all.
Search engines and AI agents don't necessarily see your site the same way.
Understand your site's structure. Automatically.
Finding orphan pages and fixing the internal links pointing to them is normally a manual audit: someone maps the site by hand, decides where a page should link from, and edits the template. The crawl finds the orphan on its own. AutoFix links it back in.
⚠ P4: orphan, zero internal links in
Home ├─ /collections/running │ ├─ /products/trail-runner-3 ✓ linked │ └─ /products/road-runner-1 ✓ linked └─ (no path found) └─ /products/trail-runner-4 ⚠ orphan: 0 inlinks
Home ├─ /collections/running │ ├─ /products/trail-runner-3 ✓ linked │ ├─ /products/road-runner-1 ✓ linked │ └─ /products/trail-runner-4 ✓ linked: added to "Related" module
Example: 214 orphan pages found across 40,000 URLs in this crawl. Found by the crawl that discovers them, not on an audit someone remembers to run.
Before you move platforms, crawl it. After, crawl it again.
A migration is the same crawl history you already have, applied to the moment it matters most: a full crawl before launch, another after, compared against each other.
Every URL, redirect, canonical and indexable page recorded ahead of launch.
The same site, crawled again, compared against the baseline automatically.
Pages that lost their redirect, their canonical, or their indexable status, flagged, not discovered six weeks later in Search Console.
One crawl. Ten technical layers. One system.
Everything above runs off the same crawl, grouped into what it does for the system.
Ask SEORCE sits across every layer. Ask a plain-language question about any of it instead of building a filtered report.
Full crawl, every page
No sampling: depth, status codes and orphan pages, on a schedule.
Explore crawl & discovery →Crawlable vs indexable vs indexed
The three statuses reported separately, per URL.
Explore indexability →Raw HTML vs rendered DOM
Checks what JavaScript changes rather than only the server response.
Explore rendering →Chains, loops, mismatches
Mapped across the whole site, not the pages you thought to check.
Explore redirects & canonicals →Schema, by page type
Validated against what AI engines and rich results read.
Explore structured data →Duplicate & thin pages
Near-duplicate clustering across large catalogues, prioritised by impact.
Explore content issues →Core Web Vitals
Per-page, tied to the actual cause, not one hidden site-wide score.
Explore performance →Sitemap, robots.txt, AI crawlers
Whether search and AI crawlers can reach each page.
Explore crawlability →Images & media
Missing alt text, oversized images, broken references, audited at scale.
Explore assets & media →Exportable audit trail
What was found, what was fixed, and when: ready for a client update.
Explore reporting →The same loop, running at platform scale.
The numbers above come from one site. The same loop runs on a schedule across every site on SEORCE.
Where this earns its keep.
Fixing the site is one part of the loop.
What is Technical Suite?
Technical Suite is SEORCE's technical SEO operating system: it crawls a site, diagnoses what's wrong, prioritises what matters, fixes what it safely can, verifies the result, and keeps monitoring for what changes next. A continuous full-site crawl covers every page, not a sample, and reports crawlability, indexability, rendered content for JavaScript-driven pages, redirects and canonicals, structured data, duplicate and thin content, internal linking, Core Web Vitals, crawlability for AI crawlers, and media assets. Issues are scored by impact and scale so the highest-value fixes surface first. AutoFix applies the correction automatically for the class of issue that has a single correct answer: schema errors, meta tag issues, missing image alt text, canonicalisation problems, orphan pages needing an internal link, logged with a before-and-after diff and fully reversible. Everything else is diagnosed with the exact fix already worked out, left for a person to apply. Crawl history is kept run over run, so what changed is visible as a comparison. Plain-language questions about the data are answered through Ask SEORCE, a WhatsApp assistant linked to the account.
Key facts
- Crawls every page on the site on a schedule, not a one-off audit or a sample
- Scores every issue by impact and scale so the highest-value fixes surface first
- Reports crawlable, indexable and indexed status separately per URL
- Compares raw HTML against the rendered DOM for JavaScript-driven pages
- Applied automatically: schema errors, meta tag issues, missing image alt text, canonicalisation problems, orphan pages missing internal links
- Diagnosed, not auto-applied: server config, redirect chains of any length, duplicate-content decisions, performance causes, content
- Every automatic fix is logged with a before-and-after diff and can be rolled back at any time
- Checks whether AI crawlers such as GPTBot, ClaudeBot and PerplexityBot can access each page
- Enabled by a single script tag, which also enables Web Analytics; Google Search Console connection adds keyword-level context
Last reviewed 15 October 2026 by the SEORCE team.
Frequently asked about Technical Suite.
Every page on the account, not a sample, on a running schedule. Each crawled page's status is checked against what search engines and AI crawlers can reach rather than only what the crawler itself sees.
No. Orphan pages, pages with no internal links pointing to them, are found automatically by the continuous crawl, and AutoFix links them back into the site's structure automatically, rather than leaving that as a manual internal-linking audit.
The whole site. Every discoverable URL within crawl scope is crawled on a schedule, not sampled once and left stale.
Every issue is scored by impact and scale rather than only severity, and surfaced as a ranked list of next actions. The point is knowing which ten matter most this week.
Crawlable means a bot can reach the page at all. Indexable means nothing on the page itself blocks indexing, such as a noindex tag or a canonical pointing elsewhere. Indexed means Search Console or the search engine has confirmed it, where that data is connected. SEORCE cannot claim index status from a crawl alone. A page can be crawlable without being indexable, and indexable without ever being indexed. Technical Suite reports all three separately.
Yes. For JavaScript-driven pages, the crawl compares the raw server response against the rendered DOM, so content, links, metadata or canonicals that only appear after JavaScript runs are checked too.
Schema errors such as missing or malformed JSON-LD, meta tag issues like missing titles and duplicate descriptions, missing image alt text, basic canonicalisation problems, and orphan pages missing internal links. Each fix is logged with a before-and-after diff and can be rolled back.
Server configuration changes, redirect chains of any length, duplicate-content strategy calls, content gaps, and the root causes behind slow pages. Each is flagged with the exact fix already worked out, but applying it is a judgement call left to your team.
Yes. A full crawl maps every redirect and keeps checking after launch rather than only once on migration day. Every chain, of any length, is flagged with the exact fix needed, for your team to apply.
Yes. The crawl covers every URL a filter or variant combination generates and clusters near-duplicates by section. This is diagnosed rather than auto-fixed, since canonicalisation strategy is a judgement call.
Yes. Crawl history is kept run over run, so new issues, resolved issues, and pages that changed status are visible as a comparison rather than only a fresh snapshot each time.
Yes, through Ask SEORCE, a WhatsApp-based assistant linked to your account. It answers questions about your project's data in natural language rather than requiring you to build a filtered report first.
No. AutoFix handles the class of fix that is well defined and low risk. Anything touching server configuration, application code or content still goes to your team, now with an exact diagnosis instead of a vague ticket.
Crawl your site. Find what matters. Fix what matters.
One system, six stages: crawl, diagnose, prioritise, fix, verify, monitor. See what SEORCE finds on your site and what it can fix automatically.
Cookies on seorce.com
We use cookies the site needs to work. With your permission we would also like to use analytics cookies to see how the site is used, and marketing cookies to measure our ads. You can change your choice at any time from Cookie preferences at the foot of every page. Read the cookie policy.
Your browser is sending a Global Privacy Control signal, so marketing cookies stay off.