Introduction
At Portocarrero we mainly work with B2B industrial websites. Technical catalogues, product sheets with specifications, sectors with specific regulations. And there's something we see over and over: technical SEO is treated as a plugin checklist instead of an architectural decision.
Our position is clear: without clean architecture, no SEO will save you. You can install Yoast, RankMath or whatever you want. If your site runs 45 SQL queries per page, if your URLs are a mess of parameters, if you don't have standard schema.org... no plugin will save you.
This article explains what we believe about industrial technical SEO, what we see in the websites we analyse, and what works when we implement it. With real PHP code and metrics from projects like ProSilicones64.
The Problem
When we analyse an industrial website for the first time, the pattern repeats. Whether it's WordPress, PrestaShop or an old custom development. The problems are almost always the same:
- URLs mixing numeric IDs, slugs and GET parameters without criteria
- Poorly implemented or completely absent canonicals
- TTFB above 800ms because each page runs dozens of queries
- Zero schema.org, or worse: badly implemented schema.org confusing Google
- Monolithic sitemaps with thousands of URLs without segmentation
- Core Web Vitals in red because nobody measured before launch
What we see is that these problems don't come from lack of SEO knowledge. They come from lack of architecture. From websites that grew without a plan, adding plugins and patches until nobody knows what does what.
URL architecture: if it's not predictable, it won't scale
We believe URL structure is the most important SEO decision you can make. Not because Google says so (which it does), but because a predictable URL means your system has internal logic. And that logic is what allows you to grow without chaos.
What we see on industrial websites is this:
/product.php?id=847&cat=3&lang=en
/catalog/view/847
/en/products/847-silicone-profile
/product-847/
/products/
/products/{category}/
/products/{category}/{product}/
# Real examples:
/products/extrusion/
/products/extrusion/railway-silicone-profiles/
Four URLs for the same product. Four ways to reach the same content. For Google, four different pages competing against each other.
Our position: a strict hierarchical structure, no exceptions.
We went from 127 "Duplicate without user-selected canonical" to 12 in 4 weeks. 91% of duplicates eliminated with clean architecture alone.
TTFB and Core Web Vitals: the problem isn't HTML, it's the database
We see industrial websites with 2-second TTFB. Two seconds for the server to start responding. And when we analyse why, it's almost never the HTML. It's the database.
A typical industrial catalogue has products related to series, sectors, certifications, materials. Each product page may need data from 5-6 tables. Without cache, every visit triggers the same queries over and over.
Our position: cache isn't optimisation, it's basic architecture. If your system doesn't have cache from day one, it's badly designed.
| Metric | Target | What we usually see |
|---|---|---|
| LCP | < 2.5s | 4-6s |
| TTFB | < 200ms | 800-1500ms |
| CLS | < 0.1 | 0.2-0.4 |
| Queries/page | < 10 | 30-50 |
From 45 queries per page to 8. TTFB from 890ms to 180ms. LCP dropped from 6.2s to 1.1s.
Schema.org: either do it right or don't do it
We see two extremes. Websites with no schema.org at all, and websites with plugin-generated schema.org that includes incorrect or incomplete data. Both are bad, but the second is worse because it confuses Google.
Our position: schema.org must reflect real data from your database. Not generic templates. If your product has an SKU, a maximum operating temperature and an EN 45545-2 certification, that has to be in the schema.
From 0 rich results to 47 in 3 weeks. CTR on long-tail queries up 24%.
Sitemaps: divide and you'll control
We see sitemaps with 15,000 URLs in a single file. No priorities, no real modification dates, no segmentation. Google processes them, yes. But you have no control over what gets indexed first and can't diagnose problems by content type.
We believe an industrial catalogue needs segmented sitemaps: products, sectors, processes, static pages. Each with its own file, its own update frequency, its own Search Console monitoring.
New product indexation time: from 2-3 weeks to 3-5 days.
Hreflang: if you have multiple languages, do it right or don't bother
We see multilingual sites with half-implemented hreflang. Only on some pages. Or with incorrect language codes. Or without x-default. Google ignores badly implemented hreflang, so either do it completely or you're wasting time.
Our position: hreflang on all pages, automatically generated from the routing system, with validation.
Impressions in France +340% in 2 months after implementing hreflang correctly.
Reference metrics: ProSilicones64
These are real data from a project where we implemented all of the above. Not promises, measured results.
| Metric | Before | After | Change |
|---|---|---|---|
| TTFB | 890ms | 180ms | -80% |
| LCP | 6.2s | 1.1s | -82% |
| SQL queries/page | 45 | 8 | -82% |
| Duplicates in Search Console | 127 | 12 | -91% |
| Active rich results | 0 | 47 | +47 |
| Long-tail CTR | 2.1% | 2.6% | +24% |
| Quote requests/month | 8 | 31 | +287% |
Conclusion
What we believe at Portocarrero is simple: technical SEO isn't a layer you add at the end. It's a consequence of having clean architecture. Predictable URLs, cache from day one, schema.org with real data, segmented sitemaps, complete hreflang.
We see industrial websites spending thousands on content and linkbuilding while their TTFB sits at 2 seconds and they have 200 duplicates in Search Console. That's throwing money away.
The good news is that fixing the technical foundation isn't magic. It's code, it's architecture, it's correct decisions. And once it's right, the rest of SEO works.
If you want to know how your industrial website stands technically, we can run a real audit: measure TTFB, count queries, review schema.org, analyse duplicates, verify hreflang. No fluff, no empty promises. Verifiable data you can use to make decisions.
Request technical audit →