Technical SEO
Most search problems are build problems.
Technical SEO is the part of search visibility you control by how the site is built, structured, rendered, linked, and maintained. It is not a discipline bolted onto a finished website — it is the website, examined from the crawler's side.
The work is removing friction along one path: the site has to be reachable, the crawler has to see what a visitor sees, the index has to hold the right pages, and those pages have to be fast enough to be worth serving.
Who it is for
Who it is for
Sites where traffic dropped and nobody can say why
Usually a change nobody connected to search: a migration, a template rewrite, a directive that applied more widely than intended.
Rebuilds and migrations, before they ship
URL maps, redirects, and canonicals are cheapest to get right while the new structure is still a decision rather than a deployment.
Sites where content is published but never appears
Pages that look finished in a browser and are never crawled, never indexed, or indexed as a duplicate of something else.
Growing sites that outgrew their structure
Service, location, and article pages that multiplied faster than the linking between them, so new pages land with nothing pointing at them.
What technical SEO covers
Grouped rather than listed, because most of these turn out to be the same few causes seen from different angles.
Crawling and indexation
Robots directives, XML sitemaps, and the gap between a page a crawler can reach and one it should keep. Most indexation problems are the wrong pages indexed, or a directive doing more than intended.
Canonicals, redirects, and URL history
Every site accumulates moved and retired URLs. We check that canonicals, sitemap, and internal links name the same URL, and that redirects resolve in one hop to a live page.
Rendering and JavaScript
If content only exists after client-side JavaScript runs, a crawler may not see it. We compare the served HTML against the rendered page and change the rendering strategy where the gap matters.
Performance on real pages
Loading, responsiveness, and layout stability traced to their causes: image delivery and dimensions, script cost and timing, caching, and third-party overhead the site owns but did not write.
Structure, markup, and internal linking
Metadata architecture, structured data that matches the page, heading hierarchy, and internal links that carry discovery rather than decorate a footer. This part compounds as a site adds pages.
What we check first
Each question resolves to a finding with a cause attached, or a clean result — and a clean result is worth knowing before anyone changes anything.
Can search engines crawl the pages that matter?
Whether the important pages are linked from somewhere a crawler goes, and whether directives, parameters, or authentication are blocking anything they should not.
Are the right pages indexable, and the wrong ones not?
Thin, duplicated, paginated, and filtered pages compete with the ones that should rank. We check what is eligible versus what belongs, and which directive decides it.
Is JavaScript hiding content from the crawler?
We compare the initial HTML against the rendered page. Content that only appears after hydration is the usual cause of a page that looks complete in a browser and empty to everything else.
Do the canonicals agree with each other?
A canonical pointing one way, a sitemap another, and an internal link a third is common and quiet. All three should name the same URL.
Are the redirects still correct after every past change?
Chains, loops, soft 404s, and rules left behind by an earlier migration. Each should resolve in one hop to a live, indexable page.
Is internal linking helping discovery, or filling a footer?
Which pages are reachable in few clicks, which are effectively orphaned, and whether links describe real relationships or repeat the navigation everywhere.
Are structured data and metadata accurate?
Titles that describe the page, headings that match its structure, and schema reflecting what is genuinely there. Inaccurate markup is worse than none.
Are Core Web Vitals acceptable on real devices?
Measured on the pages that matter, at the hardware and connection your visitors actually use — not a fast desktop run. Each result traced to its cause first.
When the URLs change
A redesign or platform migration is partly a technical SEO problem, and the one with the shortest window to get right. Everything a site has earned is attached to its URLs, so the map from old to new has to exist before the new structure is built.
The same applies whenever a site adds or reorganizes service and location pages. For the Las Vegas contractors, restaurants, and professional practices this studio works with, that structure decides whether a location page supports the rest of the site or sits unlinked and undiscovered.
A URL inventory of what exists today, including what already redirects
A decision for every old URL: kept, moved, merged, or deliberately retired
Redirects planned from that map, resolving in one hop to a live page
Canonicals and internal links updated to name the new URL directly
Sitemaps regenerated to list the new structure, not the old one
Indexation checked after launch rather than assumed
Field data and crawl behaviour monitored while the change settles
What this looks like in a build
Performance decided while the site was built
ClearWaters Alliance
Business demoClearWaters Alliance is a fictional public-service and nonprofit showcase built to demonstrate how a flexible WordPress CMS can support education, training, community events, and public resources within one coherent content system.
- Type
- Nonprofit and public-service WordPress platform
- Role
- Strategy, UX/UI, content architecture, WordPress development, accessibility, and performance optimization
Performance work in the record
- Responsive WordPress image derivatives with srcset and sizes
- Width and height on every image, reserving layout space up front
- Lazy loading on below-the-fold media
- One variable woff2 per family instead of a file per weight
- Zero third-party requests — no external font or CDN dependency
ClearWaters Alliance is a fictional organization and a studio demo, not a client engagement — it has no members, programs, or events, and claims no results. See the full record.
How we work
Four rules, applied in that order
Diagnose before changing
Applying best practices to a site nobody inspected produces work that is hard to attribute. Finding what is actually wrong first usually makes the list shorter and the changes more specific.
Fix causes, not scores
A tool's number is a symptom. Treating the number — deferring a script that was never the problem — makes the report look better and the site behave the same.
Measure on real pages
Templates fail differently depending on what fills them, so we measure the pages carrying the traffic rather than a sample — then re-measure those same pages afterwards to confirm the fix, instead of treating the deploy as the result.
Prioritize by impact and effort
Audits produce more findings than anyone will act on. We sort by impact against cost, say which ones we think are not worth doing, and leave a list you can stop partway down.
Questions
What clients ask before starting
Do we actually need a full technical audit?
Often not. If you have one specific symptom — a section that stopped appearing, a page that will not index, a slow template — we would rather diagnose that than bill you for a survey of everything. A full audit earns its cost when the site is large, has been migrated before, or nobody can say why traffic changed.
Can you fix this without rebuilding the site?
Usually. Most technical SEO problems live in templates, directives, redirects, and delivery rather than the platform underneath, and those change in place. We will tell you when a problem is genuinely architectural, because a rebuild is a much larger decision than a fix.
How do you decide what to fix first?
By impact against effort, and we show the ordering rather than just the result. Something blocking indexation on a revenue page outranks a minor markup warning even if the warning is easier to close. We also mark the findings we think you should skip.
Will technical SEO improve our rankings?
It removes reasons you cannot rank — pages a crawler never reaches, content it never sees, duplicates competing with each other. That is necessary and it is not sufficient. Rankings also depend on content, relevance, competition, and authority, so we do not promise positions and would be suspicious of anyone who does.
What should happen before a redesign or migration?
Map the URLs before anything is built. We inventory what exists, decide what each old URL becomes, plan redirects and canonicals from that map, and point sitemaps and internal links at the new structure directly. Doing this afterwards is how sites lose visibility they had earned.
How do you know whether a fix actually worked?
We re-measure the same pages the same way, confirm the crawler now sees what a visitor sees, and watch indexation and field data settle afterwards. Some changes confirm in days and some need a full recrawl, so we say which we expect rather than reporting a deploy as a result.
Start a project
Start with the symptom, not the audit
Tell us what changed — a section that stopped appearing, a page that will not index, a template that got slow — and WebCraft Labz will tell you what is causing it and whether it is worth fixing.