Our technical SEO foundation

Technical SEO is the work of making the website's technical signals boringly consistent. That is a compliment. The technical layer should not create mysteries about which URL is canonical, whether the page can be indexed, where the content lives, what changed, how pages relate, or whether the main document can be rendered.

It cannot make weak content relevant. It can stop the implementation from getting in the way of strong content.

The important content exists as crawlable HTML

Our public business pages are usually server rendered or statically generated. The headings, paragraphs, links, and navigation exist in the response. Search engines are capable of rendering JavaScript, but we do not see a reason to make core service content depend on that extra step when the server can already provide the document.

This also helps accessibility and resilience.

URLs are designed to remain stable

A URL is an address that can accumulate search history, links, analytics, bookmarks, and customer familiarity. We prefer simple route families such as:

• /services/topic
• /locations/place
• /blog/article
• /portfolio/project
• /docs/subject

The route describes the information architecture. We do not add meaningless directory depth merely to make the site look larger. We also avoid changing established URLs without a reason and a redirect plan.

Canonicals come from a shared policy

Several of our repos centralize metadata creation. A route supplies its page path, title, description, and image. The metadata helper turns that into the canonical URL and social metadata. That reduces the risk of copied canonicals, old hostnames, and inconsistent sharing fields.

Read Why we centralize page metadata.

Preview deployments are not allowed to become competing public copies

Branch previews are useful because they contain nearly the same site as production. That is also why they are dangerous if indexed. Our production projects include environment-aware robots controls, and some enforce the rule through an X-Robots-Tag response header in nonproduction environments.

The public production domain remains the source of truth. See Why preview deployments are explicitly noindex.

Structured data is generated from the same content model

A service route can emit Service schema. An article can emit Article or BlogPosting schema. Documentation can emit TechArticle schema. Breadcrumbs can describe the page hierarchy. We generate these objects from the same normalized content that renders the page. That reduces the chance that invisible structured data tells a different story than the visible document.

Schema is clarification, not a ranking shortcut.

The sitemap is generated from the application

We do not want an XML file that somebody has to remember to edit every time a route changes. The sitemap can read the same service, article, location, portfolio, and documentation registries that power the pages. That makes it an output of the architecture.

If the route model changes, the sitemap code can change with it.

Modification dates reflect actual source history

A redeployment does not mean every page changed. Several of our repos generate lastmod values from Git history so a page's sitemap date changes when its source changes, not whenever the entire application happens to be built. Shared template changes can also be considered for dynamic page families.

The deeper reasoning is in Why lastmod should come from real source history.

Internal links describe relationships

Navigation handles major sections. Contextual links connect specific ideas. An article about a rebuild can link to the web-development service. A documentation page about metadata can link to canonical or sitemap documentation. A service page can link to a relevant case study.

We avoid forcing unrelated links into content merely to inflate a link count. Internal linking should make the site easier to understand for people first.

Location pages are not generated just because we have a city list

A dynamic route makes it technically easy to create large numbers of local pages. That is not our quality standard. A location page needs enough local substance to deserve its URL. The content model can include unique copy, images, service context, FAQs, SEO fields, and related areas while the shared route keeps the implementation consistent.

Read Why location pages are content models, not city-name swaps.

Technical rules are validated during the release process

One production site validates article fields, dates, slugs, metadata exports, canonicals, and preview indexing controls from source. The connectrader site audits generated HTML after the production build. It checks headings, titles, descriptions, canonicals, robots state, Open Graph fields, Twitter fields, image alt attributes, JSON-LD, internal links, source image references, robots.txt, and sitemap dates.

That is explained in Why we validate SEO in the build.

Technical SEO is not a score

There is no meaningful single number that proves a site's technical SEO is finished. The technical foundation is a set of consistent behaviors:

• important pages are renderable
• URLs are stable
• canonicals are correct
• public pages can be indexed
• previews cannot
• metadata matches the page
• structured data matches the page
• internal links resolve
• the sitemap reflects the site
• modification dates are honest
• redirects preserve moved URLs
• the build catches common regressions

Once that floor is strong, the harder work remains. The page still needs a reason to exist. It still needs useful content, credible proof, commercial relevance, and a clear relationship to the searches the business wants. Technical SEO does not replace those things.

It gives them a cleaner platform to compete from.