What technical SEO covers
Technical SEO is the plumbing of a website. It is rarely visible to visitors, but when it fails, everything above it suffers.
Crawling
Whether search engines can reach your important pages and are not wasting time on unimportant ones.
Indexing
Whether the right pages are stored in Google's index, and the wrong ones are kept out.
Duplicate URLs
Whether one page is reachable at several addresses and Google knows which one you prefer.
Mobile and speed
Whether the phone version has the same content and loads, responds and holds still as it should.
Structure and links
Whether pages connect through clear links, so visitors and crawlers find what matters.
Structured data
Whether markup is valid, honest and matched to what is actually on the page.
Crawling is not the same as indexing
This is the most common technical misunderstanding we see. Google's documentation says robots.txt controls which URLs crawlers may access. It is not a way to keep a page out of Google. A blocked address can still appear in results without a description if other sites link to it.
To keep a page out of the index, Google points to a noindex directive or password protection. Google also warns that mixing crawling and indexing rules can cause some of them to cancel others, so we check the rules together.
We also check that your rules do not block files Google needs to understand a page. Google notes that blocking resources it needs can hurt how it analyses your pages. A single line copied from an old template can quietly hide an entire section of a site.
Symptoms and likely causes
These patterns turn up often. A diagnosis always depends on the evidence from your own site.
| What you notice | A likely cause | What we check |
|---|---|---|
| A key page is missing from Google | Blocked from crawling, set to noindex, or not linked from anywhere | Crawl rules, page directives and internal links |
| The wrong version of a page shows | Several addresses carry the same content and no preferred one is signalled | Redirects, canonical tags and sitemap entries |
| Traffic fell after a redesign | Changed addresses without redirects, lost content or broken templates | Old and new address mapping, template differences |
| Slow on phones | Heavy images, scripts that delay content, layout that jumps | How fast key pages load, respond and stay stable |
| Phone page looks thinner than desktop | Content hidden or removed on mobile | Whether both versions carry the same primary content |
Redirects and status codes: what Google does with each
Status codes are the replies your server gives for every request. A mistake here can drop pages from Google or send visitors to the wrong place, so we read them early in every technical review.
| Response or redirect | What Google does with it | What we check |
|---|---|---|
| 301 or 308 redirect | Treated as permanent, and the preferred method when a page has moved | That the destination is the final page, with no chain in between |
| 302, 303 or 307 redirect | Treated as temporary | That it was not used for a move that is meant to last |
| Meta refresh or JavaScript redirect | A zero-second meta refresh counts as permanent. Google says to use JavaScript redirects only when server-side options are not possible, because rendering can fail | Whether a server-side redirect can replace it |
| 404 or 410 | Treated as a missing page, and a previously indexed URL is removed from the index | That deleted pages return this and live pages do not |
| Error page that returns 200 | Search Console can flag it as a soft 404 | Pages that say not found but send a success code |
| 5xx server error | Google slows its crawling, and persistent errors lead to URLs being dropped | Hosting stability and server error history |
Where we focus first
We do not fix everything at once. Order matters, so we start where the largest loss is likely.
- Blockers: Anything stopping valuable pages being crawled or indexed comes first.
- Duplicates: We settle which version of each page you want found and signal it with redirects and canonicals.
- Mobile equivalence: Google uses the mobile version for indexing, so mobile content must match your desktop content.
- Speed on key pages: We test pages that bring in enquiries, not the whole site equally.
- Structure: We tidy navigation, links and URL patterns so that related pages support one another.
Speed: a recommendation, not a magic lever
Google publishes thresholds for three measures: the largest content loading within 2.5 seconds, interaction response under 200 milliseconds, and layout shift below 0.1. It highly recommends good scores for success in Search.
The documentation does not say how much weight these carry against relevance. We treat speed as a real benefit for visitors and a sound habit for search, and we fix slow pages that cost you enquiries. We do not tell you that a perfect score will lift you to the top.
How we work with your developer
Technical SEO fails when recommendations arrive as vague advice. We write fixes your developer can check and ship.
What we provide
- Exact page addresses and the problem on each
- The change we recommend and why
- A priority and an effort estimate
- A recheck after release to confirm the fix worked
What we leave to you
- Choosing your platform or hosting
- Writing and deploying code in your systems
- Design decisions that do not affect search
- Anything we cannot verify from the outside, which we flag
Technical work in context
Technical work usually follows a review, so most clients start with an SEO audit. Fixes to titles, headings and page copy sit with on-page SEO. Moving to a new site or domain is a separate project, covered under SEO migrations.
Large catalogues carry the heaviest technical load, which is why ecommerce SEO and IT and cyber security SEO often begin here. For a business serving Gungahlin, phone speed and local structure tend to matter most.
Technical foundations also affect how well AI-driven answers can find and read your content. Our answer engine optimisation page explains the limits of what anyone can claim. The complete list of our work is on the services page.
Frequently asked questions
What is technical SEO?
It is the set of fixes that help search engines crawl, index and understand your site. That includes crawl rules, duplicate addresses, redirects, mobile content, speed and structured data. It sits underneath content and links: it will not rank a weak page, but it can stop a strong page being found.
Does robots.txt keep a page out of Google?
No. Google says it is not a mechanism for keeping a page out of search. It controls crawling, and a blocked address can still appear in results if other sites link to it. To keep a page out, use a noindex directive or password protection.
Do Core Web Vitals affect rankings?
Google highly recommends good scores for success in Search and says they align with what its ranking systems seek to reward. It does not say how much weight they carry. We fix real slowness because it helps visitors, but we do not promise a rankings jump.
Why is my site not showing in Google?
Common causes include crawl blocks, a noindex tag left from development, no links pointing to the page, or a recent launch that Google has not yet processed. Google also says it does not guarantee that any site will be indexed. We check each cause against your evidence.
Do I need a sitemap?
A sitemap can help Google discover pages, but Google says it is not required, because it finds most pages through links. We usually recommend one for larger or newer sites and make sure it lists only the addresses you want indexed.
Can you fix issues on my platform?
We specify the fix and verify it, but your developer or platform support usually makes the change. Where you have no developer, we can advise on options. We tell you early if a limitation of your platform stops a fix.
How long do technical fixes take to show?
The time Google takes to reflect a change varies widely, from hours to months by its own account. Some fixes, such as removing a block, are picked up quickly. Others, like restructuring a site, need longer. We recheck after release and report what changed.
How can I check whether Google has indexed a page?
Use the URL Inspection tool in Search Console. It reports whether the URL is on Google, when it was last crawled, whether crawling was allowed and which canonical Google selected. A live test checks the current version of the page. A verdict of URL is on Google means the page is eligible to appear in results, not that it will rank or be shown.
Sources and further reading
- Google Search Central: Introduction to robots.txt: Crawling vs indexing; blocked URLs can still appear; noindex or password protection; blocking needed resources can hurt analysis
- Google Search Central: Consolidate duplicate URLs: Redirects, rel=canonical and sitemaps as signals of a preferred URL
- Google Search Central: Mobile-first indexing best practices: Mobile version used for indexing and ranking; content should be equivalent
- Google Search Central: Understanding Core Web Vitals: LCP 2.5 seconds, INP under 200 milliseconds, CLS below 0.1; recommended for success in Search
- Google Search Central: SEO Starter Guide: Pages found mainly via links; sitemaps help but are not required; no indexing guarantee; changes take hours to months
- Google Search Central: Redirects and Google Search: Permanent and temporary redirect types; server-side preferred; JavaScript redirects only when server-side is not possible
- Google Search Central: HTTP status codes, network and DNS errors: 404 and 410 treatment; soft 404; 5xx and crawl rate
- Search Console Help: URL Inspection tool: Indexed status, crawl details, canonical, live test