Technical SEO services that fix the cause, then prove it

Who needs technical work, and who does not

Technical work matters most when the content is fine but Google is not using it. You see it in Search Console as pages left out of the index, the wrong page ranking for a search, or a fall right after a change to the site.

What technical SEO means, in plain words

Google handles a page in stages. It crawls the page by following links, renders it by running the code, and then decides whether to index it. Only indexed pages can rank. Technical SEO is the work of making sure nothing on your site breaks one of those stages.

Crawling depends on links. Google's guide to JavaScript says it can only find links that are <a> elements with an href attribute. A menu built from buttons, or products that appear only after a click, can stay invisible.

Rendering depends on code. Google runs JavaScript, but its guide still calls server side rendering or pre-rendering a great idea, because it makes pages faster for people and crawlers, and not every bot runs JavaScript.

Indexing depends on clear signals. If the same page lives at several addresses, Google picks one. If your canonical tags, sitemap, and internal links disagree, it may pick the one you did not want.

The problems I fix most often

These come up again and again in my technical SEO services work. Each one has a check that confirms it, so no fix is made on a guess.

1. 01

   The same page at several addresses

   Tracking tags, upper and lower case paths, trailing slashes, and old category paths all create copies. Google chooses its own version when the signals disagree.

   How I confirm it. I run URL Inspection on key pages and compare the canonical Google chose with the one the page declares.

2. 02

   Filter and sort URLs that Google keeps crawling

   Stores and listing sites create a new address for every filter mix. Google can spend its visits on those instead of on your real pages.

   How I confirm it. I count filter and sort URLs in a crawl and in the Search Console reports, compared with real pages.

3. 03

   Important pages with almost no internal links

   Service and category pages linked only from a footer, or not at all, sit too deep for Google to treat as important.

   How I confirm it. I map click depth from the home page and list pages with no links pointing to them.

4. 04

   Sitemaps full of redirects and errors

   A sitemap that lists redirected, broken, or noindex pages sends mixed signals about which pages count.

   How I confirm it. I crawl every sitemap entry and compare the status codes with what a live, indexable page returns.

5. 05

   Content or links that need JavaScript to appear

   Pages built in the browser can look fine to visitors and empty to a crawler, especially when links are not real links.

   How I confirm it. I compare the raw page source with the rendered page and with what URL Inspection shows Google saw.

6. 06

   Slow templates and layout jumps

   Heavy themes, sliders, chat widgets, and unsized images hurt loading and make pages jump as they load.

   How I confirm it. I read Core Web Vitals field data by page type and trace each failure to the scripts or images behind it.

7. 07

   Redirect chains after a site move

   Old addresses that hop through two or three redirects, or land on the home page, lose the value the old page had.

   How I confirm it. I crawl the old address list and record where each one ends up and in how many hops.

8. 08

   Error pages that return a normal status

   A page that says "not found" but returns a 200 status is a soft 404. Google may keep crawling it or treat real pages as errors.

   How I confirm it. I test missing addresses and check the status code each one returns.

When these problems sit in a store, the product side of the story is covered in my guide to stores whose products Google ignores. When they follow a redesign or a platform change, the starting point is the guide to a fall in traffic after a site move.

Core Web Vitals, without the noise

Core Web Vitals measure how real visitors experience your pages. Google publishes a good threshold for each one.

Google says good Core Web Vitals line up with what its core ranking systems seek to reward. In my experience, a fast page still does not beat a more useful one. I treat speed as a barrier to remove, not a ranking lever, and I fix the templates that carry the most traffic first.

When crawl budget matters, and when it does not

Crawl budget is the set of pages Google can and wants to crawl on your site. Google's guide on it is written for very large sites, sites whose content changes every day, and sites with a large share of pages marked as discovered but not indexed. Most small business sites do not need to think about it.

When it does matter, Google's own list of fixes is the right place to start, and it is mostly cleanup:

• Merge duplicate pages so Google is not crawling copies
• Block crawling of URLs that should never be visited, such as endless filter mixes, with robots.txt
• Return a 404 or 410 status for pages removed for good
• Remove soft 404 pages
• Keep sitemaps current, with only live, indexable pages
• Avoid long redirect chains
• Make pages load faster and use HTTP caching

How the work runs

1. Step 01

   Baseline

   You give read access to Google Search Console and analytics, and for large sites a server log export. I record indexing, crawl stats, Core Web Vitals, and the pages that bring your traffic.

   What this finds. The starting numbers that every later change is compared with.

2. Step 02

   Diagnosis

   I crawl the site, compare it with the Search Console reports, and isolate the causes behind the symptoms.

   What this finds. A short list of confirmed problems, each with its proof, instead of a long list of warnings.

3. Step 03

   Tickets

   Each fix is written as a ticket: the exact change, the templates and pages it touches, an example where useful, and the test that proves it worked.

   What this finds. Work your developer can start without asking what I meant.

4. Step 04

   Changes made

   Your developer builds from the tickets, or I make the changes myself where I have access and the platform allows it.

   What this finds. Fixes live in production, in the order that helps the most pages first.

5. Step 05

   Review and recheck

   I test changes on staging before release, check production after it, and recrawl a few weeks later.

   What this finds. What changed in Search Console terms: pages indexed, crawl waste removed, vitals passing.

If you only want the written diagnosis, the audit on its own covers that. If your developer will make every change and you want someone senior checking the work, a consultant to review your developer's changes may fit better.

What you receive

• A written diagnosis with every confirmed problem, its proof, and its impact ranked high, medium, or low
• Tickets for every fix, ready to paste into your task tool
• A canonical and indexing table for each page type on the site
• A Core Web Vitals list per template, ordered by traffic
• Structured data checked and corrected where it is wrong or missing
• A recheck report comparing indexing, crawl, and vitals with the baseline

Moving a site without losing rankings

A redesign, a new platform, or a domain change is where technical mistakes cost the most. Google's hiring advice even says the best time to bring in an SEO is before a redesign or a new site, and the earlier the better.

For a move, I build the old to new address map from a full crawl and the pages that earn traffic, review the redirects before launch, test the staging site with crawlers blocked from indexing it, and check the live site in the first days after launch. Every old address with traffic or links should end on its closest new page in one hop.

Proof from client work

Two results came from technical work. Both compare the last 3 months of Search Console data with the 3 months before, neither screenshot shows exact dates, and neither client is in Pakistan.

A B2B services firm had four regional pages competing for the same searches. We merged them into single pages, rebuilt the service markup, and improved page speed. Organic clicks grew +309% organic clicks, last 3 months vs the previous 3 months, view evidence, from 5.7K to 23.3K. The details are in the service page merge case.

An international store had the same collections at several addresses, filter combinations Google could index, and no self referencing canonicals on catalog pages. After those were fixed, organic clicks grew +572% organic clicks, last 3 months vs the previous 3 months, view evidence, from 2.74K to 18.4K. You can read the duplicate collections case for the order of fixes. Stores that want the category content handled too can look at full SEO for an online store.

Myths about technical SEO

What technical SEO costs

Technical SEO services are priced by the size of the job. Every price below is in Pakistani rupees, from the price list I publish.

The effort depends on the number of page types, the platform, how much control it gives over addresses and code, and whether a move is involved. The monthly plans, including the plans that include monthly crawl checks, list what each covers.

How long before fixes show

1. Week 1

   Baseline and diagnosis

   The starting numbers are recorded and the first problems confirmed and ranked.

2. Month 1

   Top fixes live

   Canonicals, redirects, internal links, and sitemaps are corrected first, because they touch every page.

3. Month 3

   Recheck

   The site is recrawled and Search Console is compared with the baseline.

Fixes can show as soon as Google recrawls the affected pages, which on a large site can take weeks. Speed fixes show in field data only after enough visits are recorded. I cannot promise when any page will rank, and nobody else can either.

Notes for websites in Pakistan

Many Pakistani business sites run on shared hosting with slow server response. Caching, image compression, and removing unused plugins often fix most of the problem before anyone needs a new host.

Most visitors here browse on phones, often on mobile data rather than office Wi-Fi. Test your main pages on a phone, away from fast internet, before you decide speed is fine.

Sites with Urdu content sometimes load large Urdu web fonts on every page. Loading the font only where Urdu text appears, and showing a fallback font while it loads, keeps pages readable and stops the layout jumping.

WordPress page builders and Shopify apps are common here, and each one adds scripts. Before adding another plugin for SEO, check what the current ones load on every page.

Businesses that serve one city also need correct local markup and a matching Business Profile. That side is covered by local rankings and the Map Pack. If AI assistants cannot read your pages because content loads late, see AI tools that cannot read your pages. Once the technical base is sound, getting your pages into AI answers builds on it. So does the content side of the work, which decides how well the indexed pages answer a search. To see how this fits the rest, read how this fits with my other services.

Your next step

Send me your site and the problem, with what changed and when. I reply within 24 hours. If you want a first look before writing to me, start with a quick free check of your home page.