Technical SEO that makes your site easy to crawl and render
Content planning assumes a search engine can see the page. Technical SEO is the work that makes the assumption true, and on large catalogues and JavaScript heavy sites it very often is not.
What is technical SEO?
Technical SEO is the engineering side of search: making sure crawlers can reach your pages, that the correct version of each is indexed, that JavaScript renders into visible content, and that pages load within measurable performance limits. It suits Australian sites large or complex enough that discovery and rendering, rather than content, are the constraint.
Get a fixed written quote- Typical timeline
- 3 to 6 weeks for the audit and the priority fixes
- What drives cost
- Site size and how many URL patterns exist, whether we can get log files, how much content is JavaScript rendered.
- Best for
- Large catalogues, JavaScript rendered sites, and any site facing a migration
- You own
- The audit, the fix specifications and every change made to your codebase
- Built with
- Log file analysis, crawlers, Search Console, Lighthouse and CrUX field data
Your handover
What technical SEO changes, and where it stops
Technical SEO deals with four questions and nothing else. Can a crawler discover the page. Will it choose to spend requests on it. Does the page render into HTML that contains your actual content. Does it load fast enough that a real visitor on a mobile connection stays. Every deliverable we produce answers one of those, which is why the work is specifiable, testable and finite in a way that content work is not.
- 01Full crawl and server log file analysis
- 02Index coverage audit with causes and fixes
- 03Rendering comparison for key templates
- 04Core Web Vitals field data by template and device
- 05Structured data validation and entity review
- 06Robots.txt, sitemap and canonical strategy
- Ranked fix list specified for developers
- Redirect map for any planned migration
- Post implementation verification report
Being clear about that boundary matters commercially
It does not decide what you should publish or which queries to chase, which belongs in search strategy, and it has nothing to do with your Google Business Profile or map coverage, which sits in local SEO. Being clear about that boundary matters commercially. A technical audit sold as a growth strategy disappoints everyone, because fixing crawl waste on a site with no demand and no content produces a beautifully engineered page that still nobody wants.
Rendering and Core Web Vitals, measured on real devices
Google can execute JavaScript, but on its own schedule and with its own limits, and other crawlers are far less capable. If your product data, reviews, internal links or main copy only appear after a client-side fetch, your visibility depends on a rendering queue you do not control. The failure is quiet: the page indexes, the shell is stored, and the content the buyer searched for is simply absent. We compare the initial HTML response with the rendered output on every important template, then move what matters into server rendered or static output. Internal links matter most here, because links injected by JavaScript may never be followed, which silently severs whole sections of a site.
Speed is judged on the same evidence standard
Speed is judged on the same evidence standard. A Lighthouse score is a lab simulation, while Google uses field data from real Chrome users assessed at the seventy fifth percentile, and the two routinely disagree. Australian conditions widen the gap, since your Sydney office fibre is nothing like regional mobile. So we set budgets and enforce them: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1, measured in the field. The usual culprits are uncompressed images, render blocking fonts, layout shift from embeds and third party tags nobody costed. We quantify each tag in milliseconds so the trade off becomes a decision rather than an argument. This is engineering work, so it runs with your developers, and ongoing enforcement sits with maintenance, since one new script can undo a quarter of effort.
How the engagement runs
How the audit runs, and why migrations need it most
A technical audit that arrives as a two hundred page PDF of tool output is a way of transferring work back to you. Ours arrives as a ranked list of specified fixes, each with the evidence, the expected effect and enough implementation detail for a developer to act without interpreting anything. We are happy for your team to do the work, and equally happy to do it ourselves.
- 01Crawl and log analysisWhat exists, what is linked, what crawlers actually request and how often
- 02Index auditWhat is indexed against what should be, with the causes of every mismatch identified
- 03Render testingInitial HTML compared with rendered output on the templates that matter
- 04Field performanceCore Web Vitals from real users, segmented by template and by device
- 05Structured data and entity reviewWhat is present, what is valid and what still earns anything
- 06Ranked fix listEvery item specified with evidence, effort and expected impact
- 07Implementation and verificationFixes shipped or handed to your developers, then retested against the baseline
Two decisions on your side that keep the project moving
Migrations are where this discipline pays for itself most obviously, because a rebuild, replatform or domain change can erase years of accumulated visibility in a weekend. Traffic losses after a launch are almost never mysterious. They are unmapped URLs, redirect chains, a staging robots.txt file pushed to production, lost internal links or a new template that dropped the content. If you are planning a migration or a redesign, involve this work before the build, not after the drop.
Choose the right level
Crawl budget, index bloat and pages Google should never see
Google allocates a finite amount of crawling to your site, and most large Australian sites spend a startling share of it on rubbish. Faceted navigation generates thousands of filtered combinations. Session parameters, sort orders, tracking tags and internal search results each spawn their own URLs. Pagination is handled inconsistently. Meanwhile the twelve pages that make money get crawled once a fortnight because they are buried nine clicks deep and linked from nowhere useful.
Problem
01
Filtered category URLs multiplying
Common wrong fix
Block the parameters in robots.txt
What we do instead
Decide which facets have search demand, index those, leave the rest uncrawlable by link structure
02
Duplicate product pages across categories
Common wrong fix
Rewrite the descriptions
What we do instead
One canonical URL per product with consistent internal links pointing to it
03
Thin pages already in the index
Common wrong fix
Add them to robots.txt
What we do instead
Serve noindex until they drop out, then remove the links, then block if still needed
04
Old URLs after a rebuild
Common wrong fix
Redirect everything to the homepage
What we do instead
Map each URL to its closest equivalent, with a single hop and no chains
05
Sitemap listing every URL that exists
Common wrong fix
Leave it to the plugin defaults
What we do instead
Sitemaps containing only canonical, indexable, valuable URLs, split so errors are traceable
How we work this out during scoping
We start with server log files, because they show what crawlers genuinely requested rather than what a crawling tool simulates. From there the fixes are surgical: decide per URL pattern whether it should be crawled, indexed, both or neither, then implement that with the right mechanism rather than the convenient one. Blocking a page in robots.txt when it is already indexed, for example, freezes the bad version in place because the crawler can no longer see the tag telling it to leave.
Structured data and AI crawlers after the rich result cull
Structured data advice has aged badly, and a lot of Australian sites are still carrying markup that earns nothing. Google retired HowTo rich results entirely and narrowed FAQ rich results to a small set of government and health sites, so for almost every commercial business those two markup types no longer buy extra space in the results. Keeping them is harmless. Paying for them as a deliverable is not.
Blocking them protects content from training use and removes you from those answers
What still earns visible treatment is the practical list: Product with price and availability, Review where it is legitimately yours to display, Event, Recipe, Job Posting, Breadcrumb and Video. Beyond appearance, schema now does a second job by describing your entities so machines can tell which organisation, location and service a page refers to, which matters when an AI assistant is deciding whether to cite you. Related to that, robots.txt controls whether crawlers such as GPTBot, ClaudeBot, Google-Extended and PerplexityBot may read your site at all. Blocking them protects content from training use and removes you from those answers. That is a strategic decision, so we surface it deliberately rather than leaving it to a default.
When a technical SEO audit is not worth commissioning
If you run a well built thirty page site on a modern platform, with clean URLs and green field data, a technical audit will hand you a short list of minor items and an invoice. The honest recommendation is to spend that money on content and authority instead. Technical work has a floor, and once a site is over it, further optimisation returns very little.
The rest of the answer
The threshold where this becomes genuinely valuable is a large or generated URL space, a JavaScript framework rendering key content, a history of platform migrations, an international or multi region setup, or a visible drop nobody has explained. If none of those apply and traffic is simply flat, the constraint is probably demand or conversion rather than crawling, and you would get more from search strategy or a look at conversion. We will tell you which after a short look at your Search Console data.
How we scope it
Four ways to scope your Technical SEO project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Foundations
The technical and structural work that has to come first
Fixed written quote, agreed before work starts
- Full crawl and server log file analysis
- Index coverage audit with causes and fixes
- Rendering comparison for key templates
Growth program
A running program with reporting you can act on
Fixed written quote, agreed before work starts
- Everything in Foundations
- Core Web Vitals field data by template and device
- Structured data validation and entity review
- Robots.txt, sitemap and canonical strategy
Full program
Content, technical and authority work together, at pace
Fixed written quote, agreed before work starts
- Everything in Growth program
- Ranked fix list specified for developers
- Redirect map for any planned migration
- Post implementation verification report
Technical SEO Ongoing
Month to month, with the working shown
Rolling monthly, quoted in writing
- Monthly reporting that says what changed and why
- A named person who knows the account
- The next quarter planned, not just the last one reported
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does a technical SEO audit take?
Three to six weeks for the audit and the first round of priority fixes on a typical site. Log file access and a staging environment speed it up considerably. Very large eCommerce catalogues or sites with several legacy platforms take longer, mostly because reconciling what exists against what is indexed is slower when nobody has a definitive URL inventory.
What makes one technical SEO project cost more than another?
Site size and how many URL patterns exist, whether we can get log files, how much content is JavaScript rendered, and whether we implement the fixes or hand specifications to your developers. A migration adds scope because redirect mapping and pre-launch verification are substantial work in themselves. We quote in writing once we have seen a crawl sample.
Do we get the audit and the fix specifications to keep?
Yes. The audit, the crawl exports, the redirect map and the fix specifications are yours, written so another developer or agency can act on them. Any code we write lives in your repository. We deliberately avoid keeping findings inside a proprietary dashboard you would lose access to when the engagement ends.
Should we still add FAQ schema to our pages?
It will not produce a rich result for a commercial Australian site, since Google restricted that display to a narrow set of government and health sources. It is still cheap and helps machines parse the page, so we leave existing markup in place. What we will not do is bill for FAQ markup as though it earns extra space in the results, because it no longer does.
Will fixing technical issues increase our traffic?
Sometimes dramatically, sometimes not at all. Fixing a rendering fault that hid your product content, or reversing an accidental noindex, can produce a fast and obvious recovery. Trimming crawl waste on a healthy site usually will not move anything by itself. We say which category you are in before you commit, based on the evidence rather than optimism.
Can you work with our in-house developers?
That is the usual arrangement. We write fixes as tickets with reproduction steps, acceptance criteria and test cases, join a planning session to answer questions, then verify each item once it reaches production. Teams running large stores often pair this with eCommerce development work so template level fixes ship with a normal release rather than as a separate project.
Related services
Get a technical read on your site
Send us the domain and, if you can, access to Search Console. We will tell you within one business day whether there is a real technical problem worth paying to fix.