# Technical SEO for Software and B2B Companies > Technical SEO for software companies. We fix crawl, index and architecture problems in your codebase, not in a slide deck, and prove it in Search Console. Page: https://synapsereality.io/services/search-visibility/seo/ Last changed: 2026-09-23 ## Scope ### This covers Crawl, index, site architecture and the on-site content that supports them. ### This is not Off-site authority, which is link building, or being quoted inside AI answers, which is answer engine optimization. ### Measured by Position for the queries that produce pipeline. ## Overview 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 scaled content policy](https://developers.google.com/search/docs/essentials/spam-policies#scaled-content) concerns pages made mainly to manipulate rankings without helping readers. We assess that purpose and usefulness before indexing them. [Google documents its JavaScript rendering process](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics). [Vercel and MERJ's crawler measurements](https://vercel.com/blog/the-rise-of-the-ai-crawler) describe a separate sample from December 2024. We keep those scopes separate when checking a site's current behavior. ## Who it is for A head of growth or a technical founder whose site has more pages than anyone can audit by hand, and whose rankings stopped moving. ## 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 1. 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. 2. 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. 3. 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. 4. 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 ### 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 what we test. Google can render JavaScript. Vercel and MERJ observed several AI crawlers that did not render it in December 2024. We check your current templates and delivery paths before proposing a rendering change. ### 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. ## Related services - [Answer Engine Optimization](https://synapsereality.io/services/search-visibility/answer-engine-optimization/) - [Link Building](https://synapsereality.io/services/search-visibility/link-building/)