A technical SEO agency makes sure the rest of your search spend has somewhere to land. The work answers four questions about a website, and when one of them comes back wrong, no volume of content or coverage will rescue the site.

Almost none of it is secret. Google and Bing document most of it publicly. The value sits in knowing which of the four questions your site is failing, by how much, and what the fix costs against what it returns.

1. Can a crawler reach the page. Crawling is the process where a search engine's software follows links and requests addresses. A page nothing links to, or one blocked by a small text file most marketing teams have never opened, does not exist as far as search is concerned.
2. Can it read what is there. A crawler receives the HTML document your server returns. A person sees whatever the browser assembles afterward. On modern builds those are often two different pages.
3. Does the right version get counted. Big sites manufacture near-duplicate addresses constantly, and the engine has to choose one of them to rank. Left undirected, it chooses badly.
4. Does the page hold the person who arrived. Loading, responsiveness and layout stability, measured on the devices your buyers are actually holding.

Brand Vision was established in 2018, and roughly 150 brands and 500+ projects have come through the studio since, with 250+ verified five-star reviews behind that record and a 5.0 rating on Clutch drawn from 64+ interviews with clients. Leads across past programs have risen 250% on average, a number that pools work at wildly different scales and starting conditions and forecasts nothing about yours. The senior team doing the diagnosis sits directly with whoever ships your code, which matters more than it sounds, because a finding that never reaches a developer is a finding that never happened. Reading server logs and writing template specifications are different skills from writing articles, and we hire for both on purpose.

The uncomfortable half of the job is subtraction. Any crawler will hand you hundreds of problems and most of them are not worth an hour of engineering time. Deciding which ones are is the entire service, and it requires somebody willing to be wrong out loud in front of you.

Nine, and most engagements use four or five of them. Which ones apply is decided by how big the site is, what it is built on, and what you are about to change.

Technical audits. A full read of the site against your competitors, your search demand and whatever you are planning to build next, delivered as a ranked list with an owner type and an estimated value beside each item. Available on its own, and it shares inputs with a full SEO audit where you want the content and authority picture in the same document.

Crawlability and indexation. Which addresses get discovered, which get kept, and which are quietly excluded without anybody being told. Most of the recoverable value on sites past a few thousand pages is sitting here.

Site architecture and internal linking. How many clicks separate a page from the homepage, how many internal links point at it, and whether your structure states clearly which pages you consider important. Past a certain scale this stops being hand placement and becomes a rules problem, which is where enterprise SEO work starts.

Core Web Vitals and performance. How quickly the main content appears, how fast the page answers a tap, and whether anything jumps while somebody reads, all checked on the phones your buyers actually hold, with a performance budget set per template so the numbers survive the next six releases.

Structured data and schema. Machine-readable labels that tell a system what a page describes instead of leaving it to infer. We implement the types that earn a visible result or settle who you are, and we leave the rest alone.

JavaScript rendering. What a crawler receives compared with what a browser assembles, and what to change when those two documents disagree. This is now a question of appearing in AI answers as much as a ranking question.

Migrations and redirects. Address inventory, one-to-one mapping, chain flattening, and verification run after cutover instead of only before it.

Log file analysis. The server's own record of what search and AI crawlers requested, which is the only direct evidence of where crawl effort actually goes.

International and hreflang setup. Address structure per market, language and region tags that agree with each other in both directions, and an honest decision about which markets deserve original content instead of a copy.

Nothing on that list is sold as a package. We look first, then tell you which four matter and which five you can safely ignore this year.

They answer different questions and they fail differently, which is why treating them as one budget line produces work that looks busy and moves nothing. On-page decides whether a page deserves the position. Technical decides whether it is eligible for one.

What on-page work owns. The subject a page addresses and how well it addresses it.

• Whether the page matches what somebody typing that query actually wanted
• Titles, headings and body copy written for a reader first and a machine second
• Depth, evidence and originality against the pages currently ranking
• Whether the page has a job in the buying process or exists because somebody had a content quota

What technical work owns. Everything that happens before a human judgment about quality is possible.

• Whether the address is discovered, requested and kept in the index
• Whether the content arrives in the response or only after a script runs
• Which of several near-identical addresses gets treated as the real one
• Whether the page loads and behaves well enough to be worth ranking
• Whether the structure passes importance around the site sensibly

The sequencing question is the one worth arguing about, and the answer depends on your site and not on principle. A clean forty-page site on a hosted platform usually has almost no technical ceiling. A week of work closes the gap and after that the constraint is SEO content strategy and off-site authority, and anybody selling you a rolling technical retainer on a site like that is selling you attendance. A two-hundred-thousand-address store with a broken filter system is the reverse. You can publish for a year into a site that cannot get its category pages crawled and see nothing for it.

So the honest version is that these two are not in competition, they are in sequence, and the sequence is set by evidence. We look at whether your important pages are indexed and ranking somewhere before recommending either. Where the answer is that the technical layer is fine and the pages are simply not good enough, the full search program is the right conversation and this page is not.

Technical work is scoped from the site instead of priced from a menu, because the honest driver of cost is template count and platform, and never page count. A hundred-thousand-page site built from twelve templates is a smaller job than a four-hundred-page site assembled by nine people over six years.

How the phases usually run.

Access, crawl and baseline. One to two weeks. Full site crawl, a log extract from the server or the CDN, analytics and Search Console access, and a benchmark of indexation, rankings and performance recorded before anything is touched. Nothing gets recommended off a screenshot.

Diagnosis and prioritization. One to two weeks. Findings tested against your competitors, your search demand and your roadmap, then ranked by likely commercial return and implementation cost. Every item names who has to do it.

Implementation. Two weeks to a quarter. Set by your release cycle far more than by ours. Configuration changes ship in days. Template and rendering changes wait for an engineering slot, and a filter architecture rebuild is a project.

Verification and monitoring. Ongoing. Re-crawl, re-check the logs, confirm the fix did what it was supposed to and did not break something adjacent. This step gets skipped constantly and it is where half the value of the previous three lives.

What moves the number. The number of distinct templates. The platform, since a hosted stack limits what can be changed and a custom build limits nothing and hides more. Whether raw logs are obtainable at all. How much your own team implements against how much we do. Whether a migration or replatform is already in flight, because auditing an architecture that is about to be deleted is a waste and we will say so before invoicing for it, which usually turns the conversation into a rebuild one instead.

On timing of results, two things are true at once. A genuine indexation or rendering block can turn around inside three or four weeks once fixed, and those are the only fast wins in search. Everything else compounds slowly, and the honest window for gains that reach your pipeline runs from four months out to a year. Anybody promising you first-page positions in thirty days is either describing something that was already broken or targeting terms nobody searches. A six-month minimum applies to any ongoing program, and a scoped consultation is the cheaper way to find out whether you need one at all.

Fixing 400 issues is never a sane use of engineering time, and the crawler that produced the list has no idea which of them costs you money. It applied severity labels written for every website on earth to yours specifically.

We sort findings into three tiers and only the first two reach a developer.

Blocking, which stops the page working in search at all. A section excluded from crawling, a template shipping a noindex instruction, copy that materializes only once a script has finished, a canonical tag pointing somewhere wrong, a soft error page returning a success code so the engine keeps a dead address alive. These are rare, they are usually few, and they are worth interrupting a sprint for. Most sites have between zero and four.

Leaking, where the page works and something is being wasted. Redirect chains eating crawl requests, thin duplicate addresses competing with the page you want ranked, a valuable page sitting five clicks deep with two internal links pointing at it, images shipped at ten times their display size. Each one costs a little. Fixed as a batch during normal release cycles, they add up to something real.

Cosmetic, meaning true and inert. Meta description length, alt text on decorative images, more than one H1, low word count flags on a contact page, missing image dimensions on pages nobody visits. All accurately reported. None of it will change a ranking. This tier is where roughly 380 of your 400 items live, and clearing it produces a green dashboard and no revenue.

What separates the tiers is not severity, it is whether a specific commercial page is affected and whether the engine's behaviour actually changes once you act. That judgment needs your search demand, your competitors and your conversion data in the room, which is why the technical read happens beside the wider audit instead of in isolation, and why we will not hand a list straight to your development team unranked.

The harder conversation is the one where the list is genuinely all cosmetic. Then the correct recommendation is to close the file, stop paying for technical work, and put the budget into the content program. We would rather say that in month one than bill a year of tidying.

Most of the time, on most sites under a few hundred pages built on a modern platform. That sentence costs us work and it is still the most useful thing on this page.

Here is the test, and you can run it yourself this afternoon. Take your ten most commercially important pages. Search for the exact address of each one and confirm it appears. Then check where each ranks for the term it was built for. If those pages are indexed and sitting anywhere in the first five pages of results, your site is being crawled, read and understood. Whatever is holding you back is not technical, and buying technical work will produce a tidier site at the same revenue.

Where the money should go instead, depending on what the test showed.

• Indexed and ranking between ten and forty. That is a quality and authority gap. The pages are eligible and losing on merit, so the answer is better pages and independent coverage that vouches for you.
• Ranking in the top three and producing nothing. The traffic is arriving and the site is losing it. That is a UX audit and a conversion problem, and no technical change touches it.
• Nobody is searching for what you sell. Demand has to be created before it can be captured, which means paid media, brand work and outbound, and search becomes a slow secondary channel instead of the plan.
• A rebuild is already scheduled inside the next two quarters. Review the incoming architecture while somebody can still change it. Documenting a structure that is queued for deletion is a real invoice against no outcome.

The exceptions are worth naming, because they are the sites where technical work genuinely is the constraint. Large catalogues with filter systems. Anything built as a single-page application. Sites that have been through a migration nobody finished. International estates with several market versions. Businesses whose search visibility fell off a cliff on a date somebody can name. If none of those describes you, be suspicious of a technical proposal, including ours.

Because a site will generate addresses on its own, and unless somebody decides which of them deserve to exist, the engine will index a large number of pages nobody meant to publish. The condition has a name in the trade, index bloat, and it dilutes instead of penalizing, which is why it goes unnoticed for years.

Five sources, in the order we usually find them.

1. Filter systems. Faceted navigation is the set of checkboxes that narrow a listing by colour, size, brand or price. Each combination is a new address, and combinations multiply against each other, so four filters with six options each produce more pages than the catalogue contains products. The decision is which single filters earn indexing because people search that way, which ones stay crawlable and unindexed, and which get blocked outright. That call is the highest-value hour in most ecommerce SEO engagements, and on a WooCommerce build it is usually where the theme is fighting you.
2. Parameters. The extra strings after a question mark in an address. Sorting, session identifiers, campaign tracking, print views, internal search results and calendars each hand the engine the same content at a new address. Left alone, one product can exist at forty of them.
3. Canonical handling. A canonical tag is a line in the page's head naming the version you consider real. It is a hint and not an order, so it gets overruled when the rest of the site contradicts it. The failures we see most are canonicals pointing at a redirect, canonicals still naming the staging domain after launch, and every duplicate correctly self-canonicalling while remaining a duplicate.
4. Pagination. Page two onward of a listing. The old next and previous link relationships are no longer used, so paginated pages should stay crawlable and point at themselves, because canonicalling page two back to page one hides everything on it. A single view-all page works where it loads quickly and nowhere else.
5. Market near-duplicates. Two versions of the same English page for two countries read as duplicates unless hreflang is correct, and hreflang is the pair of tags declaring which language and region each version serves, required in both directions. Bilingual sites carry the same risk, which is why work in Quebec starts with the address structure before a word gets translated.

The fix is nearly always a set of rules written into the templates once, and not a monthly cleanup. Deleting bloat by hand on a site that keeps manufacturing it is a treadmill somebody will still be running on next year.

Server logs are the only place you can see what a crawler actually did instead of what a tool predicts it would do. Every web server keeps a line for every request, including which bot asked, which address it wanted, what status code it received and how long the response took.

What logs tell you that a crawl cannot.

• Where crawl budget is going. Crawl budget is the finite number of requests an engine is willing to spend on your site in a given period. Logs show the actual split, and the usual finding is that a large share is being spent on parameters, filters, internal search results and calendar pages while the category pages that earn revenue get visited every few weeks.
• Which sections are being ignored. A crawl proves a page is reachable. Logs prove whether anybody came. A section receiving almost no bot requests over sixty days is a structural problem, and it is nearly always depth and internal links, so a page five clicks from the homepage with two links pointing at it gets read as unimportant because that is exactly what the structure says.
• What the bot was served, not what you see. Logs record the status code delivered to that user agent at that moment, which is how you find pages that return a success code to you and an error to a crawler, or redirect one and not the other.
• Response times as the crawler experienced them. Slow server responses reduce how much a site gets crawled, and this is where you catch it.
• Which AI crawlers are visiting, and what they take. The named assistant crawlers show up in logs as clearly as search bots. Whether they are being served real content is answerable here and almost nowhere else.
• Which bots are lying. Plenty of traffic claims to be Google and is not. Verifying by reverse lookup keeps you from optimizing for a scraper.

Two honest limits. Below roughly ten thousand pages, logs are interesting and rarely actionable, so sites in the hundreds of thousands of addresses are where this earns its fee. And access is not guaranteed. Self-hosted stacks including most WordPress builds give you raw logs. Hosted platforms like Shopify generally do not, and the CDN in front of the site becomes the fallback. We confirm what is obtainable before scoping the work.

Google can execute JavaScript and does, on a delay and within a budget it does not publish. Most AI crawlers do not execute it at all, and that single difference has changed what a safe architecture looks like. There are three ways a page can be assembled and they carry very different risk.

Server-side rendering. The server builds the finished HTML for each request and sends it complete. A crawler gets everything in the first response. Safest option and the one that costs the most to run.

Static generation. Pages are built into files at publish time and served as ready-made HTML. Same visibility benefit as server rendering, cheaper and faster to deliver, and it needs a rebuild step when content changes. For most marketing sites this is the correct answer.

Client-side rendering. The server returns a near-empty shell plus a script, and the browser assembles the page. Search engines can usually cope with this. Everything else in the ecosystem struggles, and the content does not exist until code runs successfully on someone else's machine.

The part that changes the calculus. Several of the largest AI crawlers will download a script file and never run it, so a page whose content only appears after execution reads to them as blank. The usual casualties are marketing sites shipped as a single-page application, feature comparisons drawn at runtime, and pricing tables that only exist once a script has assembled them. Being absent from generated answers is a different kind of loss from ranking tenth, because there is no position ten to recover from. That is why rendering is the first thing we check in AI search optimization work, and why it hits software companies hardest, since their sites are the ones most likely to be built this way by engineers optimizing for something else entirely.

Three checks anybody can run. Request the page and read the raw response before scripts execute, then compare it with what the browser shows. Confirm your navigation is made of real anchor tags with real addresses, because a menu built from click handlers passes nothing anywhere. And check whether any content requires an interaction to appear, since a crawler will never click a tab.

When the remedy turns out to be architectural, it stops being a marketing request and becomes an engineering decision with a cost attached, and that conversation belongs in week two instead of month nine.

They are a real ranking input and a small one, and they are a large conversion input, so the business case almost never rests on rankings. Anybody telling you a performance score is the reason you sit at position eight is selling the easiest thing to measure instead of the thing that matters.

The three measurements and the thresholds Google treats as good.

Largest contentful paint under 2.5 seconds. How long until the biggest visible element, usually a hero image or a headline block, finishes rendering. This is the closest proxy for the moment a visitor believes the page has loaded.

Interaction to next paint under 200 milliseconds. How long from a tap or a click until the screen visibly responds. It replaced the older first input delay measurement and it is stricter, because it looks at every interaction in the session instead of only the first.

Cumulative layout shift under 0.1. How much the content jumps around while it loads. Late-loading images without reserved space, injected banners and font swaps are the causes, and this is the one users hate most viscerally.

The distinction that decides whether a report is worth reading is field data against lab data. A synthetic test runs one page on one simulated connection and gives you a score. Field data is collected from real Chrome users on real networks, reported at the 75th percentile over a rolling twenty-eight days. Search uses the field data. A perfect lab score alongside failing field data means your actual visitors are having a worse time than your tooling admits, and that happens constantly on image-heavy pages and on sites carrying a decade of third-party tags.

Where the failures genuinely come from, in rough order of frequency, are oversized images, third-party scripts nobody has audited, render-blocking fonts, and heavy JavaScript doing work before anything appears. Hosted platforms like Webflow handle the delivery layer for you and can still be ruined by the tag manager.

The commercial argument is cleaner than the ranking one. A slow page wastes every visit you paid for, so the same fix that nudges organic performance also raises the return on your paid media budget immediately and measurably. Going from 3.1 seconds to 2.4 will not beat a better answer. It will stop you losing the people you already earned.

Sometimes, and only when it does one of four specific jobs. Structured data is a machine-readable description of what a page contains, added in the code where a reader never sees it, and marking up a site for the sake of having marked it up returns nothing at all.

Four tests. If a proposed schema type passes none of them, we do not implement it.

1. It unlocks a result that changes how the listing looks. Product price and availability, event dates, job postings, recipes, breadcrumb trails, and star ratings where the reviews are genuinely third party. A listing that occupies more space and answers more of the question earns clicks it would not otherwise get, and that is measurable within weeks. Catalogue sites see this most clearly, which is why product and offer markup sits inside product-level search work instead of beside it.
2. It settles who you are. Organization markup with your legal name, logo, addresses and links to the profiles that confirm you exist. This resolves entity ambiguity, meaning the system stops guessing whether three mentions of a similar name are one company or three. It is also the cheapest work on this list.
3. It feeds a surface you actually want to be in. Local business markup supporting map and profile visibility ties directly to local SEO. Merchant feeds, job boards and course listings each read specific types.
4. It makes a fact quotable. A specification, a price, a service area or a credential stated in structured form is easier for an answer engine to lift and attribute than the same fact buried in a paragraph.

What we refuse, and this is where most agencies quietly generate work. Marking every page as an article. Stuffing invented questions into question markup because it once produced extra listing space and now mostly does not. Adding review markup for your own business on your own site, which contravenes the guidelines and earns manual penalties in exactly the regulated categories where it is most tempting, so legal practices should treat any agency offering it as disqualified. And markup that describes something the visible page does not contain, which is the fastest route to losing rich results permanently.

Schema is plumbing. Correct plumbing is invisible and worth having. Decorative plumbing is a line item.

By treating the redirect map and the crawl directives as the deliverable, and by verifying them after the switch instead of trusting the plan. The catastrophic launch mistakes are all recoverable and all of them cost weeks, so the whole discipline is refusing to assume.

The distinction that causes most of the damage is between two mechanisms people use interchangeably. A robots file at the root of the domain tells crawlers which addresses not to request, so it prevents crawling and does nothing about indexing. A noindex instruction sits in the page itself and tells engines not to keep it, which requires the page to be requested and read. Blocking a page you want removed means the removal instruction can never be seen, so it stays in the index indefinitely with no description under it. Getting these backwards is the single most common technical misunderstanding in marketing teams, and it is not a small one.

What gets verified, in this order.

• Every crawl directive, after cutover and not before. A staging environment blocks the whole site and carries a site-wide noindex. Shipping either of those to production is the fastest way to remove a business from search, it happens to real companies every month, and the only defence is checking the live domain within the hour.
• Canonical and hreflang targets on the live domain. Both routinely survive a launch still pointing at the staging address, which quietly tells the engine the real site is somewhere it cannot reach.
• Every old address, mapped one to one. Pointing everything at the homepage passes almost nothing and reads as though the pages stopped existing.
• Chains flattened to a single hop. A redirect chain is one address sending to a second which sends to a third. Each hop wastes a crawl request, and engines abandon the trail after a handful of them. The protocol and trailing slash variants get folded into the same single hop.
• Status codes on a sample of real traffic, since a redirect that works in a spreadsheet and returns an error under load is still an outage.

Then monitoring, because a clean migration still fluctuates. The first two days are for crawl errors and redirect behaviour, the first fortnight for indexation and rankings against the benchmark taken beforehand, and the first quarter for whether the recovery finished. You can see migrations we have run, and where a replatform is the actual project the website redesign engagement carries this work inside it. Send us the site and the risk gets read back to you plainly before a launch date is chosen.