What is a technical SEO audit, and when does an Australian site need one?
A technical SEO audit is a structured check of everything that stops search engines from crawling, rendering, indexing and serving your pages, from robots rules and redirects to page speed and JavaScript. It deals with the machinery, not the words.
Content and links can only work if the plumbing underneath them works. A beautifully written service page does nothing if it carries a stray noindex tag, loads its main text through a script Google renders late, or sits behind three redirects left over from the last redesign. A technical SEO audit finds those faults systematically instead of by accident.
The moments when Australian businesses usually commission one:
- Traffic dropped after a redesign, platform change or domain move
- Search Console shows a growing number of pages “crawled, currently not indexed”
- The site serves both Australia and New Zealand and the wrong version appears in each
- A new React or Next.js front end replaced a traditional CMS
- Core Web Vitals in Search Console show pages as “poor” on mobile
- Nobody has looked under the bonnet since the site launched
What does a full technical SEO audit check?
A full technical SEO audit covers crawlability, indexability, rendering, site architecture, page experience, structured data, international targeting and redirects. Each area produces findings with a severity and an estimated effort to fix.
Plenty of audits stop at a crawler export. Ours starts with your own data, because Search Console tells us what Google actually did with your pages, while a crawler only tells us what a bot could do. We combine both and then look at templates, since one broken template can explain thousands of problem URLs.
- Crawlability: robots.txt rules, internal links Google can follow, orphan pages, crawl traps
- Indexability: noindex tags, canonicals, duplicate clusters, soft 404s, sitemap accuracy
- Rendering: whether key content and links exist in the rendered HTML Google indexes
- Architecture: click depth, URL structure, pagination, breadcrumbs
- Page experience: Core Web Vitals from field data, HTTPS, mobile layout
- Structured data: validity and eligibility per template
- International: hreflang, regional URLs, currency and language signals
- Redirects: chains, loops, lost legacy URLs, internal links to redirected pages
You receive the findings as a sortable sheet, not a static document, so your team can filter by template, severity or owner.
Reading Search Console crawl and index coverage in a technical SEO audit
Start with the page indexing report and work through each “not indexed” reason, asking whether the exclusion is intended. Some exclusions are healthy, such as redirected URLs or deliberate noindex pages; others point to real problems.
Google's help documentation for the page indexing report defines “Discovered, currently not indexed” as a page Google found but has not crawled yet, and “Crawled, currently not indexed” as a page it crawled but chose not to index. The first often signals crawl budget spent elsewhere, typically on filters or parameters. The second usually signals pages Google judged too thin or too similar to others.
How we classify each reason during a technical SEO audit:
Usually fine
Page with redirect, alternate page with proper canonical tag, and URLs marked noindex on purpose, such as cart, account and thank-you pages.
Needs investigation
Duplicate without user-selected canonical, Google chose a different canonical than the one you set, soft 404, and large volumes of discovered but not crawled URLs.
Usually a fault
Server errors, redirect errors, important pages blocked by robots.txt, and key pages noindexed by a template or plugin setting.
We also compare your XML sitemaps against the indexed set. A sitemap full of redirected, noindexed or canonicalised URLs sends mixed signals, and cleaning it is one of the quickest fixes an audit produces.
Core Web Vitals on Australian mobile networks
Judge Core Web Vitals on field data from real visitors first, then use lab tests on a throttled mobile profile to find causes. Your visitors on a train between suburbs or in a regional town see a different site from the one on your office fibre connection.
According to Google's web.dev guidance on Web Vitals, a good experience means Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads and split between mobile and desktop. The 75th percentile matters: it means three in four visits need to meet the threshold, so the slower phones and patchier connections in your audience count.
Common causes our technical SEO audits find on Australian sites:
- Hero images served at desktop size to phones, or loaded lazily when they are the largest element
- Chat widgets, review badges and tracking tags loading before content
- Web fonts that shift text when they arrive
- Cookie or promo banners pushing content down after load
- Hosting or CDN edge locations far from Australian visitors, adding latency to every request
- Heavy JavaScript frameworks hydrating the whole page before buttons respond
Speed also matters beyond rankings, since slower pages lose enquiries. We report each fix with the metric it targets, so you can see what changed.
Do Australian sites need en-AU and en-NZ hreflang?
Only if you have genuinely different versions for Australia and New Zealand, such as separate prices, shipping, legal pages or contact details. If one English site serves both, hreflang adds complexity without benefit.
Google's documentation on localized versions explains that hreflang pairs a language code with an optional region code, so Australian English is en-AU and New Zealand English is en-NZ, and that a country code on its own is not valid. It also says each version must list itself and every other version, and that if page X points to page Y, Y must point back; otherwise the annotations may be ignored. The reserved x-default value covers visitors who match none of the versions.
What a technical SEO audit checks when a site runs AU and NZ versions:
- Every page in each version references itself and its counterpart
- Return links exist in both directions, with no references to redirected or noindexed URLs
- Canonical tags point to the page's own version, not to the Australian one
- Codes use a valid format (en-AU, en-NZ), not “en-AUS” or a bare country
- x-default is set to the version you want for everyone else
- Prices, currency and shipping details on each version match its market
Mismatched canonicals are the most common fault here: an NZ page canonicalised to its Australian twin tells Google to ignore the NZ version entirely.
Technical SEO audit after a site migration: checking redirects
After a migration, test every old URL that had traffic or links, confirm it lands in one hop on the most relevant new page with a permanent redirect, and trace any lost traffic to specific templates. Most post-migration drops come from missing or wrong redirects.
Google's guidance on site moves with URL changes recommends server-side permanent redirects such as 301 or 308 and keeping them for as long as possible, generally at least a year, so signals transfer to the new URLs. It also says the Change of Address tool is only needed when moving between domains or subdomains, not for HTTPS or path changes.
Our migration checks during a technical SEO audit:
- Build a list of old URLs from analytics, Search Console, backlinks and archived sitemaps
- Test each one for status code, number of hops and final destination
- Flag redirects that land on the homepage instead of a matching page
- Collapse chains created by earlier migrations stacked on top of each other
- Update internal links so they point straight to final URLs
- Compare pre- and post-launch clicks by template to find where traffic went
If you are planning a move rather than recovering from one, involve an auditor before launch. The redirect map is far cheaper to get right in advance.
JavaScript rendering on Shopify, Webflow and React sites
Check what Google's rendered HTML contains, not what the browser shows you. If titles, main content or internal links only appear after client-side scripts run, indexing can be slower or incomplete, even though the page looks perfect to a visitor.
Google's JavaScript SEO documentation describes three phases, crawling, rendering and indexing, and notes that pages wait in a render queue that can take longer than a few seconds. It still recommends server-side rendering or pre-rendering because it is faster for users and crawlers and not every bot runs JavaScript. It also warns that links must be real anchor elements with an href, and that hash-based routing cannot be resolved reliably.
Shopify
Themes render server-side, which helps. Problems tend to come from apps that inject content, reviews or filters through scripts, and from variant pickers that set prices only in JavaScript.
Webflow
Pages are published as static HTML, so rendering is usually sound. Audits focus on CMS collection templates, interactions that hide content, and whether the staging subdomain is kept out of the index.
React and Next.js
A pure client-side React app ships nearly empty HTML. Next.js with server rendering or static generation fixes most of that, but we still check metadata, soft 404 handling on client routes and links built as buttons.
When a React site needs deeper rework, such as moving pages to server rendering, that becomes development work, quoted from US$900 for larger changes.
Robots.txt, sitemaps and canonicals: the quiet causes of lost pages
Robots.txt controls what can be crawled, sitemaps suggest what should be indexed, and canonicals say which version of duplicate content counts. When the three disagree, Google makes its own choice, and it may not be yours.
The classic mistakes are small and devastating. A staging site's “Disallow: /” copied to production. A canonical tag hard-coded to the homepage in a template. A sitemap generated by a plugin that lists tag archives and attachment pages but misses the service pages built with a page builder. A technical SEO audit catches these in the first day.
What we verify:
- robots.txt blocks crawl traps but not CSS, JavaScript or important sections
- Every indexable page appears in a sitemap; nothing else does
- Canonicals are absolute, self-referencing by default, and consistent with sitemaps and internal links
- Parameter URLs from tracking, sorting or filtering do not become indexable duplicates
- Noindex is not combined with a robots.txt block on the same URL, which stops Google seeing the noindex
Structured data checks within a technical SEO audit
Validate markup per template, remove duplicates and fields that do not match the visible page, and keep only types that describe what the page really is. Structured data helps search engines and AI tools understand a page; broken markup helps nobody.
Most Australian sites carry markup from several sources at once: the theme, an SEO plugin, a reviews app and sometimes hand-coded snippets. The result is two Organization blocks with different phone numbers, Product markup with a price in the wrong currency, or FAQ markup on pages without visible FAQs. Each conflict weakens the signal.
We check the markup types most Australian sites use:
- Organization or LocalBusiness with one consistent name, address format and contact details
- BreadcrumbList matching the visible breadcrumb trail
- Product and Offer with AUD or NZD prices matching the page, on stores
- Article with author and date on blog content
- FAQ markup only where questions and answers are visible on the page
For stores, the deeper markup and Merchant Center work lives on our ecommerce SEO page, and for local businesses the local SEO services page covers business profile signals.
Does a technical SEO audit help with AI search visibility?
Yes, because AI search features draw on pages that search engines can crawl, render and index. A page Google cannot index is not available to be quoted in AI Overviews, and content hidden behind scripts is harder for any crawler to read.
A technical SEO audit adds a few checks with AI search in mind. We look at whether key answers sit in plain HTML near the top of the page, whether headings describe what follows, whether robots rules block AI crawlers you actually want to allow, and whether structured data states facts consistently. None of this guarantees a mention in an AI answer, but it removes the technical reasons you would be left out.
- Main answers present in server-rendered HTML
- Question-style headings followed by direct answers
- robots.txt rules reviewed for search and AI user agents you want to allow or refuse
- Consistent business facts across pages, markup and profiles
How much does a technical SEO audit cost in Australia, and what drives it?
Costs vary widely across providers because scope varies: a tool-generated report and a template-by-template review with fixes are different products. The main drivers are URL count, the platform, whether JavaScript rendering is involved, and whether international versions or a recent migration add work.
We quote each technical SEO audit after a short scoping step: a look at Search Console, a sample crawl and a list of your templates. That keeps the quote honest. A small Webflow site with clean templates needs little time. A large Shopify store with filters, several apps and an old migration needs more. A React application with client-side routing needs rendering comparisons across every template.
- Size: number of indexable URLs and distinct templates
- Stack: server-rendered CMS versus JavaScript framework
- History: past migrations, domain changes, redirect layers
- Markets: one site or separate AU, NZ and other versions
- Fix scope: report only, or report plus implementation
Fixes are quoted separately and line by line. Ongoing monitoring and improvement afterwards start from US$150/mo a month. For broader budgeting see how much a website costs in Australia.
How long does a technical SEO audit take, and what do you receive?
Small sites can be audited within days of access; larger or JavaScript-heavy sites take longer. You receive a prioritised findings sheet, a short summary of the five things that matter most, and an itemised quote for fixes.
The summary is written for a business owner, not an SEO specialist. It explains each major finding in a sentence, why it matters, and what the fix involves. The detailed sheet is for whoever implements the changes, us or your own developer, and lists affected URLs, the template responsible, severity, effort and the recommended fix.
What the deliverable includes:
- Executive summary with the top findings in plain English
- Findings sheet sortable by severity, effort, template and owner
- Evidence for each finding: screenshots, URL samples, Search Console exports
- An itemised fix quote you can approve line by line
- A recheck plan saying when and how each fix will be verified
How to choose a technical SEO audit provider
Ask to see a sample findings sheet, ask who will implement fixes, and ask how they will verify results. A provider who cannot answer those three questions is likely selling a tool export.
Good technical SEO audits share a few traits. Findings are grouped by cause rather than listed by URL. Severity reflects business impact, not tool colour codes. And the auditor understands your platform well enough to say whether a fix is a setting, a theme edit or a rebuild. That last point is where developer-led audits have an edge, since the person diagnosing the problem also knows what the fix costs.
- Do you use our Search Console data or only a crawler?
- How do you check JavaScript rendering on our templates?
- Will findings be grouped by template and root cause?
- Who implements the fixes, and are they quoted separately?
- How will you confirm each fix worked?
- What will you not cover?
Our honest limits: we do not run paid ads, build backlinks, or give legal advice on privacy or accessibility law. For accessibility requirements, our WCAG compliance page explains what we build.
Red flags in a technical SEO audit
Be cautious of audits that give a single score out of 100, list thousands of warnings without priorities, or promise ranking gains from technical fixes alone. Technical work removes barriers; it does not guarantee rankings.
Automated tools flag everything they can measure, including issues that do not matter: missing meta keywords, slightly long titles, images without a title attribute. When those sit alongside a real problem such as a noindexed service section, the real problem gets lost. A useful audit throws most warnings away.
- One overall “SEO score” presented as the goal
- No reference to your Search Console data
- Hundreds of pages with no summary or priority
- Recommendations that ignore how your platform works
- Guaranteed traffic or ranking outcomes
- An auditor asking to own your Search Console property
Running a technical SEO audit with a team in India from Australia
You add us as a user in Search Console and analytics, give read access to the CMS or a staging copy, and we do the audit remotely. A short call in your afternoon walks through the summary, and you decide which fixes to approve.
The time difference helps rather than hurts. Our working morning in India overlaps the Australian afternoon: four and a half hours behind Sydney, Melbourne, Canberra and Hobart on standard time, five and a half during daylight saving, the same gap to Brisbane all year, and two and a half hours to Perth. Crawls and rendering tests run while you are offline, so the findings are waiting in the morning.
- Days 1–2: access set up, scoping crawl, quote for the full audit
- Following days: full crawl, Search Console review, template rendering checks, Core Web Vitals analysis
- Delivery: summary, findings sheet and itemised fix quote
- Walkthrough call: in your afternoon, around 30 minutes
- Fix phase: approved fixes made on staging first, then live, then rechecked
Quotes are in USD and payable in AUD via Wise or by bank wire; invoices come from India. Your accounts stay yours, and our access can be removed the day work ends. See our terms for general conditions.
Worked example: a technical SEO audit for a hypothetical Perth services site
Imagine a Perth building-services business that moved from WordPress to a React front end with a headless CMS. Six months later, organic enquiries have fallen and Search Console shows hundreds of service-area pages “discovered, currently not indexed”. This scenario is invented to illustrate the method.
Day one of the audit would compare source and rendered HTML on each template. Suppose service-area pages load their text from an API after the page mounts, and internal links in the menu are buttons with click handlers rather than anchors. Google finds the pages through the sitemap but has few crawlable links pointing at them, and each page initially looks nearly empty.
The redirect review might show that old WordPress URLs with trailing slashes redirect to the homepage rather than to matching new pages. Core Web Vitals field data might flag poor INP on mobile because the full application hydrates before the enquiry form responds.
The prioritised fixes would be server rendering for service pages, real anchor links in navigation, a corrected redirect map, and deferring non-essential scripts. Each would be quoted separately, with rendering work as development from US$900. No result is promised; the audit simply removes the reasons Google could not index the pages.
Technical SEO audit checklist for Australian websites
Use this list to run a quick self-check, or to judge whether a technical SEO audit you have received covered the basics.
- Every “not indexed” reason in Search Console explained as intended or a fault
- robots.txt reviewed; no important sections or assets blocked
- XML sitemaps list only indexable, canonical, 200-status URLs
- Canonicals self-reference by default and match internal links
- LCP, INP and CLS checked on mobile field data against Google's thresholds
- hreflang for en-AU, en-NZ and others is reciprocal and self-referencing
- Old URLs from past migrations redirect in one hop to relevant pages
- Rendered HTML contains main content, titles and crawlable links
- Structured data validates and matches visible content
- Staging and development copies are not indexable
If you find more than a couple of failures, a full audit will likely pay for itself in saved guesswork.