// search visibility
Technical SEO for Software and B2B Companies
The deliverable is a pull request. It is a branch in your repository with a diff against the template producing the problem. It carries a note naming the Search Console number it should move, and one of your engineers approves it before it merges. It is not a PDF, and not a backlog handed to a team with no room for it. An audit nobody merges leaves the same crawl errors in Search Console six months later.
Two neighbouring jobs are out of scope here. Authority earned from other sites is link building. Being quoted inside AI answers is the sibling service linked at the top of this page. What this engagement covers is your own site: crawl, index, architecture, and the on-site content that has to hold a position.
What technical SEO actually is
It is three questions, answered against your real site:
- Can search engines reach your pages? Crawl budget, robots directives, redirect chains, pagination that runs forever, orphaned templates.
- Do they understand what they reached? Canonicals, structured data, internal link architecture, duplicate and near-duplicate content across templates.
- Is the experience good enough to keep the ranking? Core Web Vitals measured in the field, on the devices your buyers actually use.
Everything else people sell as technical SEO is a subset of those three.
Why we group findings by template
A crawl that reports 1,400 issues is not a list of 1,400 problems. One bad title expression in one layout file produces a duplicate title on every page built from it, and the crawler counts each page separately. Grouping by cause collapses that back down. The report names the template and the line, so the fix is one change an engineer makes once.
Who rewrites your page copy
Two services in this hub ship rewrites, and a buyer deserves to know which is which before signing either. Rewrites here serve crawlability, architecture and ranking. They touch the template, the internal link graph, the canonical set, and the on-site content that has to hold a position for a query. The sibling service rewrites the same pages for a different property: whether a passage can be lifted into a generated answer and attributed. If you buy both, it is one set of pull requests on one branch, not two teams editing the same file.
Where we draw the line
Links do not get bought out of this engagement, and content we would not put our own name on does not get published. Positions are not promised. A programmatic page set does not ship without a uniqueness gate either. Google’s spam policies name scaled content abuse. We treat it as a site-wide risk, not a per-page one, because the thinnest template is judged alongside the rest of the domain.
What you get
- A crawl and index audit run against your real site, not a sample, with every issue tied to the template that causes it
- The fixes shipped as pull requests to your repository, reviewed by your engineers
- An internal linking architecture generated from a keyword map, so the link graph cannot drift from the plan
- Structured data implemented and validated in your CI, so a broken graph fails the build
- Core Web Vitals work targeted at the field data in Search Console, not at a lab score
- A monthly readout that reports what moved and what did not, including the tests that failed
How it runs
- 01
Measure before touching anything
We pull Search Console, crawl the site, and record the current state per template. Without a baseline per template, nothing that follows can be attributed, and every later claim becomes an opinion.
- 02
Find the causes, not the symptoms
A thousand duplicate title tags is one template bug. We group every issue by the template that produces it, so the fix list is short. Each item is one real change instead of one of a thousand tickets.
- 03
Ship the fixes as code
We write the pull requests and your engineers review them. An audit that hands over a spreadsheet moves nothing. The work only counts when it is merged and deployed.
- 04
Verify in the field
We watch Search Console and field Core Web Vitals for the templates we changed. A normal post-change dip is expected and we say so. A sustained coverage loss is a problem, and we say that too.
Questions we get asked
- How is this different from the SEO on your other pages?
- This page is about your own site, and whether search engines can crawl it, index it and understand its architecture. Link building is about authority earned from other sites. The third service in this hub is about being quoted inside AI-generated answers, and it is linked at the top of this page. They are different deliverables with different measurements, and we keep them separate so you can buy one without the others.
- Do you need access to our codebase?
- For the fixes, yes. We deliver changes as pull requests against your repository, reviewed by your engineers before they merge. If that is not possible we will write the specifications instead, but understand what changes. The result then depends on someone else finding time to implement them, and a recommendation that never ships moves no number at all.
- Our site is a JavaScript app. Does that change anything?
- It changes a lot. Google renders JavaScript, but most AI crawlers do not. Measurements by Vercel and MERJ found that none of OAI-SearchBot, ChatGPT-User, GPTBot, ClaudeBot or PerplexityBot render JavaScript. If content only exists after hydration, those engines never see it. We will tell you which of your content is affected before proposing anything.
- How long before we see movement?
- Technical fixes that unblock crawling can show up within a crawl cycle, often two to six weeks. Architecture and content changes take longer, and anything competitive takes longer still. Until we have read your Search Console data we cannot narrow that range. Saying so beats picking a date because it sounds decisive.
- What if the audit finds our problem is not technical?
- We will say so. A technically perfect site that nobody links to and nothing distinguishes will not rank. Selling you an audit you do not need is a bad trade for a firm that wants the next engagement.