Technical SEO services that fix what Search Console is already telling you

What is included in technical SEO services, and what is not?

Technical SEO services cover everything that decides whether search engines can find, fetch, render, understand and quickly serve your pages: crawling, indexing, rendering, speed, structured data, internal linking and site architecture. They do not cover writing blog posts, building backlinks or managing your Google Business Profile.

The dividing line matters because many US site owners buy a general SEO retainer, receive content and outreach, and still have half their product or service pages excluded from Google. Content cannot rank from a URL that is not indexed. Equally, a technically perfect site with thin pages will not rank either, so we are open about which problem you have.

Our version of technical SEO services is developer-led. Another of us on our team handles the SEO diagnosis and one of us handles the full-stack changes, so the person who spots a canonical conflict is working next to the person who edits the template. That shortens the gap between “we found it” and “it is fixed” from months to days.

• In scope: indexing, canonicals, redirects, sitemaps, robots rules, rendering, Core Web Vitals, schema, internal links, pagination, hreflang, migrations.
• Adjacent: on-page titles and headings at template level, image handling, accessibility fixes that overlap with performance.
• Out of scope: link building, review generation, paid ads, and anything that tries to trick a crawler.

How technical SEO services use the Search Console Page indexing report

The Page indexing report lists every URL Google knows about on your property and groups the ones it did not index by reason. Technical SEO work starts there, because the reasons point straight at causes: server errors, redirects, noindex tags, blocked URLs, soft 404s and duplicates.

Google's help documentation lists reasons including server error (5xx), redirect error, URL blocked by robots.txt, URL marked noindex, soft 404, not found (404), alternate page with proper canonical tag, duplicate without user-selected canonical, duplicate where Google chose a different canonical than the user, and page with redirect. Several of those are healthy. A redirect from an old URL, or a filtered URL pointing its canonical to the main page, is exactly what you want to see excluded.

So the first job is sorting. We export each reason, sample URLs, and tag every group as “expected”, “needs a fix” or “needs a decision”. Expected groups are left alone. Fix groups go into the backlog with the template or rule that causes them. Decision groups, such as thousands of tag archive pages, need you to say whether those pages should exist at all.

The Page indexing report documentation explains each status; our job is to turn that list into changes and to watch the counts move over the following weeks.

What do “Discovered – currently not indexed” and “Crawled – currently not indexed” mean?

Google defines “Discovered – currently not indexed” as a page it found but has not crawled yet, typically because crawling it was expected to overload the site, so the crawl was rescheduled. “Crawled – currently not indexed” means Google fetched the page and chose not to index it for now, and Google says there is no need to resubmit it.

They call for different fixes. “Discovered” at scale usually points to crawl efficiency: slow server responses, huge numbers of low-value URLs competing for attention, or weak internal links to the pages you care about. We check server response times, cut parameter and faceted URLs, and make sure important pages are linked from pages Google already crawls often.

“Crawled” is usually about the page itself. Common causes are near-duplicate templates with only a city or product name changed, very thin content, boilerplate that outweighs the unique text, or pages Google sees as less useful than another URL on your site. Resubmitting does little. Consolidating, improving or removing those pages does more.

Fixing duplicate URLs and canonical conflicts

A canonical tag tells search engines which version of a page is the main one. Conflicts happen when your tags, redirects, internal links and sitemap each point to a different version, and Google then picks its own canonical, often not the one you wanted.

On US sites we see the same handful of causes again and again: HTTP and HTTPS both live, www and non-www both resolving, trailing-slash and non-slash versions returning 200, tracking parameters in internal links, printer or AMP leftovers, and CMS plugins that generate paginated or tag URLs with self-referencing canonicals.

The fix is to make every signal agree. One version returns 200; the others return a single 301 to it. Internal links, sitemaps and hreflang tags use that exact URL. The canonical tag matches. After that, “Duplicate, Google chose different canonical than user” usually shrinks over a few recrawls. If it does not, we compare the two URLs Google considers duplicates, because sometimes Google is right and the pages really are too similar to justify separate URLs.

Core Web Vitals in technical SEO services: LCP, INP and CLS thresholds

Google's Search documentation sets the good thresholds as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Google describes these as aligning with what its core ranking systems seek to reward, alongside other page experience aspects.

We always start with field data, meaning what real Chrome users experienced, shown in Search Console's Core Web Vitals report and in the Chrome UX Report. Lab tools such as Lighthouse are useful for finding causes but can pass a page that real users on mid-range Android phones find slow. A US audience on cellular connections in rural areas behaves very differently from a developer on office fiber.

LCP problems on the sites we look at usually come from a hero image that is too large, lazy-loaded by mistake or served without a preload, plus slow server response on uncached pages. CLS usually comes from images without dimensions, late-loading fonts, cookie banners and ad slots that push content down. Both are fixed in templates, once, and every page benefits.

Our redesign work starts from these same thresholds, because building speed in is cheaper than retrofitting it.

How do you fix a poor INP score on a JavaScript-heavy site?

Find the interactions that are slow, find the long JavaScript tasks that block them, and break up or remove those tasks. INP measures how quickly the page responds visually after a click, tap or key press, so it punishes sites that run heavy scripts on the main thread.

The usual suspects on US business sites are tag managers loaded with a dozen marketing tags, chat widgets, session-recording tools, A/B testing scripts that hide the page until they finish, and large single-page-app bundles that hydrate the whole page before anything responds. Menus and filters that re-render hundreds of elements on each click are another common source.

• Audit third-party scripts with the marketing team and remove those nobody reads the data from.
• Delay non-essential tags until after the first interaction or idle time.
• Split long tasks so the browser can respond between chunks.
• Hydrate only the interactive islands of a page instead of the whole thing.
• Give buttons and filters instant visual feedback before the heavy work runs.
• Re-check field data after four weeks, since the report is based on a rolling window of real visits.

JavaScript SEO: does Google render React, Vue and Next.js sites correctly?

Google can render JavaScript, but it does so in a separate step and not every crawler can. Google's JavaScript SEO documentation describes three phases: crawling, rendering in a headless Chromium once resources allow, and indexing based on the rendered HTML. It still calls server-side rendering or pre-rendering a great idea because it is faster for users and crawlers and not all bots run JavaScript.

The same documentation is precise about links: Google can only discover links that are <a> elements with an href attribute, and it advises using the History API rather than URL fragments for routing. In client-side apps, it recommends avoiding soft 404s either by redirecting to a URL that returns a real 404 status or by adding a noindex robots meta tag to error views.

In practice our technical SEO services check three things on every JavaScript site. First, raw HTML versus rendered HTML: are titles, main content, canonicals and links present before scripts run? Second, navigation: are menu items, pagination and filters real links? Third, status codes: does a missing product return a 404, or a 200 with “not found” text? Fixes range from switching a route to server rendering in Next.js or Nuxt to rewriting a click handler as a proper link.

Read Google's JavaScript SEO basics for the full list. Many SaaS marketing sites built as single-page apps benefit the most from these fixes.

Which structured data should technical SEO services implement?

Implement the schema types that match what the page really is and that Google documents as eligible for a search feature: Organization or LocalBusiness on the relevant pages, Product and Offer on product pages, Article on editorial content, BreadcrumbList across the site, and specific types such as Event or JobPosting where they apply.

We generate structured data from the same data the page renders, never typed by hand into a plugin field, so prices, availability and dates cannot drift out of sync. Then we validate in Search Console's rich result reports rather than only in a one-off testing tool, because the reports show errors across every page using a template.

Two warnings. Markup must describe content visible on the page, and it does not by itself raise rankings. Its value is eligibility for richer results and clearer entity signals for search engines and AI systems. If a plugin has sprinkled five overlapping schema blocks on every page, removing the duplicates is often the most useful structured data work we do.

Site architecture and internal linking that search engines can follow

Good architecture puts your most valuable pages close to the home page, groups related pages under clear hubs, and links them with descriptive anchors. Search engines use those links to discover pages and to judge which ones matter.

A US service business with twenty services and fifty cities, for example, should not rely on a footer with a thousand links. A cleaner pattern is a services hub, a locations hub, service pages that link to the cities where they are offered, and city pages that link back to relevant services. Breadcrumbs reinforce the hierarchy and give search results a readable path.

We map your current structure by crawling the site and measuring click depth, orphan pages and links pointing to redirects or errors. Then we propose changes you can see in a simple diagram before any template is edited. Orphan pages found in the sitemap but not linked anywhere are a frequent cause of “Discovered – currently not indexed”.

Technical SEO services for large and programmatic sites

Programmatic sites generate pages from data, such as locations, products, integrations or comparisons. The technical work is making sure each generated page deserves to exist, that crawlers can reach it efficiently, and that empty or near-empty combinations never get published.

Google's sitemap documentation limits a single sitemap to 50,000 URLs or 50MB uncompressed, says it ignores the priority and changefreq values, and uses lastmod only when it is consistently and verifiably accurate. So we split sitemaps by page type, write lastmod from real content changes, and watch each file's indexing rate separately in Search Console. That shows immediately which template Google likes and which it ignores.

• Minimum data rule per template: a page publishes only when it has enough unique fields to be useful.
• Empty combinations return a 404 or are never linked, instead of rendering a “no results” page with a 200.
• Faceted filter combinations are kept out of crawl paths unless they match real search demand.
• Template text is kept short; unique data carries the page.
• Internal links come from hubs and related-item blocks, not only from the sitemap.

If you are planning a programmatic build rather than fixing one, our custom website development starts with these rules baked into the data model.

Does crawl budget matter for my site?

For most small business sites, no. Google's crawl budget guide says it is aimed at roughly three groups: very large sites of about a million pages or more that change weekly, medium or larger sites of about 10,000 pages or more that change daily, and sites with a large share of URLs stuck in “Discovered – currently not indexed”. Google calls those figures rough estimates.

The same guide splits crawling into a capacity limit, which Google raises or lowers depending on how quickly and reliably your server responds, and crawl demand, which depends on size, update frequency, page quality and relevance. That gives two practical levers: make the server fast and stable, and stop presenting Google with endless duplicate URLs.

When crawl budget does matter, our technical SEO services work through server logs to see which URL patterns Googlebot actually spends time on. On an ecommerce or listings site it is common to find most crawl requests going to parameter URLs, calendars or internal search results that should never have been crawlable. Blocking or removing those patterns frees crawling for the pages that earn revenue.

Site migrations: changing CMS, domain or URLs without losing traffic

A migration keeps its search traffic when every old URL that matters redirects once, directly, to its closest new equivalent, and when the new site launches with the same or better content, links and speed. Most traffic drops after a redesign come from missing redirects, changed content and blocked staging settings left in place.

We build the redirect map from three sources: your current sitemap, a full crawl, and the URLs with clicks or links in Search Console and analytics. Every row is tested on staging before launch. On launch day we check robots rules, noindex tags, canonicals and sitemaps within the first hour, then monitor the Page indexing report and server logs for two to four weeks.

See Webflow development and WordPress design if the migration is part of a new build.

Technical SEO for AI search: getting cited by AI Overviews and chat assistants

AI search systems still depend on pages they can fetch and read. The technical groundwork is the same as for classic search: fast, server-rendered HTML, clear headings, accurate structured data, and no accidental blocking of the crawlers you want.

Beyond that, a few choices help. Put a direct one or two sentence answer under each question heading. Keep definitions, prices and specifications in plain text rather than images or tabs that load on click. Make author and organization details consistent across the site. Check your robots.txt deliberately, because some sites now block AI-related crawlers by accident through blanket rules copied from forums, while others want to block them on purpose; either way it should be a decision, not an accident.

We do not promise AI citations, since nobody controls which sources an assistant picks. What technical SEO services can do is remove the reasons a page would be skipped: missing content in raw HTML, slow responses, contradictory canonicals and messy markup.

How much do technical SEO services cost in the US?

From this team, ongoing technical SEO services start from US$150/mo per month. US agencies and consultants price technical work very differently, some hourly, some by audit, some bundled into retainers, so quotes vary widely. The main differences come from site size, platform complexity, and whether the provider also writes the code.

An audit-only engagement is cheapest upfront but leaves your developers to do the work, which is where many audits stall. An implementation engagement costs more per month but turns the backlog into shipped changes. For sites that are structurally broken, such as a page builder theme that cannot hit Core Web Vitals no matter what, a rebuild can cost less over a year than months of patching.

• Site size and template count: ten templates across 50,000 URLs can be cheaper than 60 hand-built pages with no shared layout.
• Platform: hosted platforms limit what can change; custom stacks allow everything but need more testing.
• Access: repository access lets us ship fixes; CMS-only access limits us to settings and theme files.
• Migration or launch deadlines: fixed dates need more hours in a shorter window.

For a wider view of SEO budgets, read our SEO cost guide for small businesses.

How to choose technical SEO services: questions to ask any provider

Ask how they will prioritize, who will write the fixes, and how you will know a fix worked. A strong provider will talk about your Search Console data and your templates within the first call. A weak one will talk about “health scores” from a tool.

• Which three issues from our Page indexing report would you tackle first, and why?
• Will you change the code yourselves, or hand a list to our developers?
• How do you test changes on staging before they reach production?
• Which Core Web Vitals metric is failing in our field data, and on which templates?
• What will you not do? Listen for link schemes or ranking promises.
• How do you report results: changelog, indexing counts, performance trends?
• Who owns the tools, accounts and access after the engagement ends?

Marketplaces such as Upwork and Toptal list many technical SEO specialists; the same questions sort them quickly. You can also review the kinds of sites we build on our portfolio page.

Working with a technical SEO team in India from the US

Most technical SEO work happens in your repository, CMS and Search Console, so location matters less than access and communication. We overlap with US Eastern mornings, which are our evenings, and can take early Pacific calls. Fixes are usually deployed while your office is closed and reviewed by you the next morning.

Access is granted by you and removable by you: a Search Console user, an analytics viewer role, a Git branch or pull-request workflow, and a staging environment. We never need your registrar password. Quotes are in USD and paid by wire, Wise or PayPal against the scope in your written quote; nothing is billed before you approve it.

We do not visit offices or attend in-person meetings, and we are a three-person team, so we are not the right choice for a site that needs twenty engineers. More on how the arrangement works: outsourcing web development to India.

Worked example: a hypothetical Austin SaaS site with indexing problems

Say a B2B software company in Austin runs its marketing site on a React single-page app with 300 integration pages generated from a database. Search Console shows most integration pages under “Discovered – currently not indexed” and the blog failing INP on mobile.

A technical SEO services plan for that site would start by comparing raw and rendered HTML. If integration pages ship an empty shell and load content by script, the first fix is server rendering or static generation for those routes. Next, we would check how the pages are linked: if the only path is a search box, a crawlable integrations hub with category pages is needed. Then sitemaps would be split into blog, integrations and core pages so each type's indexing rate can be tracked.

For INP, we would profile the blog template, likely finding a heavy analytics bundle and a chat widget loading on every post, and defer both. Monthly technical work from US$150/mo would cover this over a few months; a full rebuild of the marketing site would be quoted separately if the framework made the fixes impractical. This is a hypothetical scenario to show our approach, not a client result.

Technical SEO services checklist for your next 90 days

Work through this list in order. Items near the top unblock the rest, and each one is visible in free Google tools, so you can track progress without buying anything.

• Verify the domain property in Search Console and submit current sitemaps.
• Export every reason in the Page indexing report and tag each as expected, fix or decide.
• Make one URL version return 200 and redirect the others once.
• Align canonicals, internal links, sitemaps and hreflang to that version.
• Check raw versus rendered HTML on your five most valuable templates.
• Replace script-only navigation with real links.
• Fix the failing Core Web Vitals metric on the template with the most traffic.
• Remove duplicate or invalid structured data; add the types your pages qualify for.
• Return real 404 or 410 status codes for removed and empty pages.
• Review robots.txt rules on purpose, including those for AI crawlers.

Stuck on any line? Send us the export and we will tell you whether it is a quick fix or a job for monthly technical SEO from US$150/mo. Start on the contact page.