What a technical SEO agency does
A technical SEO agency makes sure search engines can crawl, render, index and understand the pages you want found, and that those pages load and respond quickly for real users. It does not write your blog or build your links. It removes the technical reasons good pages fail to show up, and it stops new releases from quietly breaking what already works.
In practice the work falls into three layers:
- Access. Can Googlebot and other crawlers reach the URLs that matter, and are they kept away from the ones that do not? This layer covers robots.txt, internal links, status codes, redirects and XML sitemaps.
- Understanding. Once a page is fetched, does the rendered HTML contain the content, links and signals you intended? This layer covers JavaScript rendering, canonical tags, hreflang, meta robots and structured data.
- Experience. Is the page fast, stable and responsive on a phone? This layer covers Core Web Vitals and the mobile version of the site, which is the version Google uses for indexing.
Mediardx is a technical SEO agency based in India that works remotely with companies in the US, UK, Canada and Australia. We diagnose issues, write developer-ready tickets, check fixes on staging and in production, and watch Search Console to confirm Google has processed them. We do not promise rankings. Google's own guidance says no one can guarantee a #1 ranking, and an agency that claims otherwise is telling you something about its standards.
Technical SEO audit or ongoing technical SEO: which do you need?
People searching for a technical SEO agency often want one of two different things. Some need a one-off diagnosis. Others need a team that stays involved while the site keeps changing. We keep the two separate so you only pay for what you need.
| Technical SEO audit | Ongoing technical SEO (this page) | |
|---|---|---|
| What it is | A point-in-time review with a prioritized issue list | A continuing engagement that fixes, verifies and prevents issues |
| Best when | You want to know what is wrong before committing budget | You ship code often, run a large or JavaScript-heavy site, or are planning a migration |
| Output | Audit report and a ranked fix list | Tickets, release QA, monitoring, migration plans and monthly reporting |
| Where to start | SEO audit services | A scoping call through the contact form |
Most ongoing engagements begin with an audit anyway, because nobody should fix things in a random order. The difference is what happens next. An audit hands you the list. An ongoing engagement works through it with your developers, re-crawls to confirm each fix, and adds a check so the same problem gets caught before the next release.
What we cover in a technical SEO engagement
Each area below lists what we check and the Google documentation that defines the expected behavior. We use Google Search Central as the reference because it describes how Google says its systems work. Third-party tools are useful for finding issues, but Google's documentation is what we use to judge them.
Crawling and crawl budget
We map how crawlers discover your URLs through internal links, sitemaps and redirects, and we look for crawl traps such as faceted filters, calendar pages and session parameters that create near-endless URL combinations. Crawl budget gets a lot of attention, but it matters for fewer sites than most audits suggest. Google's crawl budget guide is written for large sites (around a million or more unique pages that change about weekly), medium sites (10,000 or more pages that change daily) and sites with a large share of their URLs reported as "Discovered - currently not indexed". It also says that if your pages are usually crawled on the day they are published, you do not need it. For a 200-page service site, crawl budget is rarely the problem, and we will say so rather than bill for it.
Rendering and JavaScript SEO
Google processes JavaScript pages in three phases: crawling, rendering and indexing. Pages returning a 200 status go to a rendering queue, and Google says they can wait there for a few seconds or longer. We compare the raw HTML with the rendered HTML to find content, links or canonical tags that only appear after scripts run, and we check that important links are real HTML links (a elements with an href). Google also notes that server-side rendering or pre-rendering is still a good idea because it makes sites faster and not all bots can run JavaScript. That matters for AI crawlers as well as search engines.
Indexing controls: robots.txt, meta robots and X-Robots-Tag
These three tools are often mixed up. Google states that robots.txt is not a mechanism for keeping a page out of Google: a blocked URL can still be indexed if other sites link to it. To keep a page out of the index you use noindex, either as a meta robots tag or as an X-Robots-Tag HTTP header, which also works for non-HTML files such as PDFs. One trap we see often is a page that has noindex and is also blocked in robots.txt. Google cannot crawl it, so it never sees the noindex rule.
Canonicalization and duplicate URLs
Google treats redirects and rel="canonical" as strong canonical signals and sitemap inclusion as a weak one, and it recommends not using robots.txt or noindex for canonicalization. A canonical tag is a preference, not a command, so we check whether Google agrees. The Page indexing report shows this as "Duplicate, Google chose different canonical than user". When that status appears on important pages, it usually means conflicting signals: internal links, sitemaps, hreflang and canonicals pointing at different versions.
XML sitemaps
A sitemap should list only canonical, indexable URLs that return 200. Google's limits are 50,000 URLs or 50MB uncompressed per sitemap file. Google ignores priority and changefreq, and uses lastmod only when it is consistently accurate. We split sitemaps by page type so the Page indexing report tells you which template has problems.
Hreflang and international setups
For sites with language or country versions, every version must list itself and all other versions. If page A points to page B and B does not point back, Google may ignore the annotations. We validate language codes (ISO 639-1, with optional ISO 3166-1 alpha-2 regions), the x-default fallback, and whether hreflang targets are canonical and indexable. Larger multi-country programs are covered on our enterprise SEO page.
Core Web Vitals, including INP
Google's Core Web Vitals guidance sets the "good" targets: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. INP replaced First Input Delay as a Core Web Vital on March 12, 2024, so any audit that still reports FID is out of date. These metrics are judged on field data at the 75th percentile, so we work from Chrome UX Report and Search Console data, not just a single lab test. Google says Core Web Vitals align with what its ranking systems reward, but they are one factor among many. We prioritize them when they are poor on templates that earn traffic or revenue, not as a vanity score.
Structured data
We implement and validate JSON-LD that matches the visible content on the page: Organization, Product, Article, BreadcrumbList, LocalBusiness and others where they fit. Google is clear that it does not guarantee structured data will produce rich results, even when the markup passes the Rich Results Test. Markup makes a page eligible. It does not entitle it to anything.
Mobile-first indexing
Google uses the mobile version of a page for indexing and ranking. We check that the mobile version has the same primary content, titles, meta descriptions, structured data and robots tags as desktop, and that primary content is not lazy-loaded behind a user interaction.
Log-file analysis
Server logs show what crawlers actually requested, not what a crawling tool guesses they might request. Where logs are available, we use them to find crawl time wasted on parameters and redirects, and to spot important templates that Googlebot rarely visits. Because user agents can be faked, we verify Googlebot hits by reverse and forward DNS lookup or against Google's published IP ranges before drawing conclusions. Log analysis earns its cost on large, frequently changing sites. On a small site we usually skip it and say why.
Search Console reports
Search Console is how we confirm Google has processed a fix. We use the Page indexing report, URL Inspection, the Core Web Vitals report, Crawl stats and the rich result reports. Google notes that you should not expect every URL to be indexed, only canonical pages. Part of our job is telling you which "not indexed" rows are normal and which ones need action.
How we decide what to fix first: the severity and effort matrix
A crawler export with 4,000 "issues" is not a plan. We score every finding on two axes. Severity is how much traffic, revenue or indexation the issue puts at risk, based on the templates and URL count it affects. Effort is how much developer time and release risk the fix needs. The matrix below is our working method, not a statistical model, and the examples are typical placements that change with your site.
| Low effort | High effort | |
|---|---|---|
| High severity | Fix now. Examples: a staging noindex left on live templates, robots.txt blocking a key directory, canonicals pointing to redirected URLs, sitemaps full of 404s. | Plan and schedule. Examples: moving client-side rendering to server-side rendering, reworking faceted navigation, a platform or domain migration. |
| Low severity | Batch into routine releases. Examples: missing alt text on decorative templates, redirect chains of two hops on low-traffic URLs, inaccurate lastmod values. | Park or drop. Examples: chasing perfect lab performance scores on pages with no search demand, rewriting URL structures that already work. |
We re-score after every release. A low-severity issue becomes high severity if it spreads to a template that earns most of your organic revenue.
What to fix first, by type of site
The right first move depends on how your site is built and how big it is. These are the starting points we use most often. Each one gets confirmed against your own data before we commit to it.
| Site type | Usual first priorities | Often overrated or misused for this type |
|---|---|---|
| Ecommerce (thousands of product and category URLs) | Faceted navigation and parameter control, canonical consistency across variants, out-of-stock and discontinued product handling, product structured data | Chasing a perfect lab score on every product page |
| SaaS or JavaScript app marketing site | Rendered versus raw HTML, client-side routing and links, docs and help-center subdomains, INP on interactive pages | Crawl budget, when the site is a few hundred pages |
| Publisher or large content site | Crawl efficiency and log analysis, pagination and archives, Article structured data, sitemap freshness and accurate lastmod | Micro-optimizing individual article templates before fixing archive bloat |
| Local or service business (under about 500 pages) | Indexation of service and location pages, duplicate city pages, mobile Core Web Vitals, LocalBusiness markup | Log-file analysis and crawl budget work |
| Multi-country or multi-language | Hreflang return links and codes, canonical and hreflang alignment, country-specific sitemaps | Using IP-based redirects as a substitute for hreflang |
Industry-specific work is covered in more depth on our ecommerce SEO, SaaS SEO and local SEO pages.
Site migrations: the checklist we run
Migrations are where technical SEO is most likely to save, or lose, a lot of traffic in a short time. Google's site move guidance says a medium-sized site can take a few weeks or more for the new URLs to replace the old ones, larger sites take longer, and rankings may fluctuate while Google recrawls. It also advises keeping redirects for as long as possible, generally at least a year. Our checklist follows that guidance:
- Inventory. Export every URL that matters from the current sitemaps, server logs, analytics, Search Console and backlink data, not just the CMS.
- Benchmark. Record traffic, rankings for key queries, indexed counts and Core Web Vitals by template before anything changes.
- URL map. Map each old URL to its closest equivalent new URL. Avoid sending everything to the homepage, and avoid redirect chains.
- Staging QA. Crawl staging (kept out of the index with authentication, not robots.txt alone) to check status codes, canonicals, hreflang, structured data, internal links and rendered content.
- Launch-day checks. Confirm server-side 301s on a sample of the map, remove any leftover staging noindex, submit the new sitemaps, and use the Change of Address tool if the domain is changing.
- Post-launch monitoring. Watch the Page indexing report, Crawl stats, 404s in logs and key landing pages daily at first, then weekly. Fix mapping gaps as they show up.
- Keep the old setup alive. Keep redirects in place for at least a year, keep control of the old domain, and update the important external links you can influence.
How we work with your developers
Technical SEO only helps once the fix ships, and most fixes are shipped by someone else's developers. We write every recommendation as a ticket your team can pick up without a meeting. Each ticket includes the affected URLs or templates, the current and expected behavior, acceptance criteria, how to test, and the Google documentation behind it. We review pull requests or staging builds when you give us access, re-crawl after release, and flag regressions. If you already use Jira, Linear, GitHub Issues or a shared sheet, we work in that tool rather than adding another one. Our process page explains how engagements are structured.
What results to expect, honestly
Technical SEO removes barriers. It does not create demand. If your pages are not being indexed, fixing indexation can open up traffic you were already in a position to earn. If your content is thin or your competitors have far more authority, a clean crawl report alone will not change that, and we will say so early.
What we can commit to is the work itself: a diagnosis grounded in Google's documentation, a prioritized backlog, verified fixes and clear reporting. A typical sequence looks like this. Weeks one to three cover access and the audit. Weeks three to six cover high-severity fixes. After that comes ongoing monitoring and release QA. These are typical activity timelines, not promised outcomes, and how fast Google reprocesses a fix depends on your site's size and crawl frequency.
How to choose a technical SEO agency
Whoever you hire, these questions separate real technical work from rebadged tool exports:
- How do you prioritize? Ask to see how findings are ranked. A list sorted by tool severity is not prioritization.
- Do you check rendered HTML? On a JavaScript site, an audit based only on raw source code will miss things.
- How do you confirm a fix worked? The answer should involve re-crawls and Search Console, not just "the ticket was closed."
- Who writes the developer tickets? If the answer is "your team", you are buying a report, not an engagement.
- Is the information current? An agency still reporting First Input Delay, or treating crawl budget as urgent for a small site, is working from old playbooks.
- What do you promise? Walk away from guaranteed rankings. Google tells site owners to be wary of them.
Technical health also matters for AI-driven search. AI assistants can only cite pages they can fetch and parse. Crawlable, server-rendered HTML with clear structure helps there too. Our AI SEO and generative engine optimization services build on the same technical foundation.