Abdur Rouf
Home/Services/SEO Services/Technical SEO
Technical SEO for sites that aren't being crawled, indexed or loaded the way they should. I find the root causes of indexing problems, slow pages and messy site structures, then fix them or brief your developers so they stay fixed.
Large or growing sites, sites after a redesign, and anything built on JavaScript or a custom platform.
Technical SEO is the work of making sure search engines can find, crawl, render and index your pages, and that visitors get a fast, stable experience. It covers site structure, robots.txt, sitemaps, canonical tags, redirects, structured data, page speed and how JavaScript content is handled.
Content and links can't help a page Google never indexes. Technical problems are often invisible from the front end: a stray noindex tag, a canonical pointing at the wrong page, filters creating thousands of near-duplicate URLs, or content that only appears after JavaScript runs.
Google publishes detailed documentation on crawling and indexing and on how it processes JavaScript. I work from that, from Search Console, and from crawling your site the way a search engine would.
The aim isn't a perfect score in a tool. It's making sure your most important pages are discoverable, indexable and fast, and that new problems are caught before they cost you traffic.
Which pages Google can find, crawl and index, and why others are excluded, using Search Console reports and a full crawl of the site.
Click depth, menus, breadcrumbs, orphan pages and internal links, so important pages are easy to reach for people and crawlers.
Duplicate URLs, URL parameters, pagination and canonical tags sorted, so Google indexes the version you want.
Redirect chains and loops, broken links, soft 404s and server errors found and fixed at the source.
XML sitemaps that list only the pages you want indexed, and a robots.txt that blocks what it should and nothing more.
Loading, responsiveness and layout stability improved on real devices, starting with your most visited templates.
Rendering, links and lazy-loaded content checked, so content built with JavaScript frameworks can still be seen and indexed.
Schema markup added or repaired and validated, so search engines understand your organisation, services, products and articles.
Not sure where the problem is? Start with an SEO audit. Moving platform or domain? See website migration.
SEO is usually split into three areas. They work together, but each answers a different question and is usually handled by different people.
| Compare | Technical SEO | On-page SEO | Off-page SEO |
|---|---|---|---|
| Question it answers | Can search engines reach and index your pages? | Does each page clearly answer a search? | Do other sites trust and mention you? |
| Typical work | Crawling, indexing, speed, redirects, schema | Titles, headings, content, internal links | Links, mentions, digital PR, reviews |
| Who makes changes | Developers, guided by an SEO | Content editors and SEO | SEO and PR, through outreach |
| Matters most for | Large, new, redesigned or JavaScript sites | Every page you want to rank | Competitive markets |
Want to check your site yourself? My technical SEO checklist walks through the main checks.
We talk about your platform, your team, recent releases and the problems you already know about.
I crawl the site, review Search Console and server logs where available, and prioritise fixes by impact.
I fix issues directly or write clear tickets for your developers, and test changes before and after release.
Indexing, speed and errors monitored over time, with checks after each major release.
Technical SEO makes sure search engines can reach, render and index your pages. On-page SEO makes each page clearly answer a search through its content, headings and links. You need both.
It means Google has seen the page but chose not to add it to its index, at least for now. Common reasons include thin or duplicate content, weak internal links or a site with many similar pages. It isn't always a technical fault, which is why each case needs checking.
Google says Core Web Vitals are used by its ranking systems as part of page experience. They matter, but relevance and content quality usually matter more. A fast page that doesn't answer the search still won't rank well.
Yes, Google can render JavaScript, but it adds a step and things can go wrong. Links built only with JavaScript, content loaded after interaction and blocked resources are common problems. I test what Google actually sees.
Yes, and that's the usual setup. I write clear tickets that explain what to change, why it matters and how to check it's done, then review the changes before they go live.
A canonical tag tells search engines which version of a page is the main one when several URLs show the same or very similar content. Google treats it as a strong hint rather than a rule, so the rest of the site needs to point the same way.
Robots.txt stops search engines crawling a URL, but the URL can still appear in results if other pages link to it. A noindex tag keeps a page out of the index, but Google has to be able to crawl the page to see it. Using the wrong one is a common mistake.
Yes. Migrations are where technical SEO matters most. See website migration for how I plan redirects and protect rankings.
The first round of fixes often is. After that, sites keep changing, so regular checks after releases stop new problems undoing the work.
Crawl budget is how much of your site Google is willing and able to crawl. Google says it mostly matters for very large sites or sites that change very often. For most sites, fixing duplicates and weak structure matters more.
It makes your pages eligible for some rich results, but Google decides whether to show them. Correct, honest schema is still worth having because it helps search engines understand your content.
Some fixes are picked up as soon as Google recrawls the affected pages; others take longer to show in traffic. I'll give you a realistic view once the audit shows what needs fixing.
It depends on the size of the site, the platform and whether I make the changes or brief your developers. I'll give you a clear quote after a short call.
Not usually. Search Console, a crawl and CMS access cover most work. Server logs are helpful for large sites, and your developers can share them if needed.
Tell me where things stand and what you'd like to change. I'll reply personally with honest next steps.
