Onsite SEO is the optimization work done on your own site, as opposed to off-site work like backlinks: title tags, headings, internal linking, URL and site structure, canonical tags, page speed, and sitemaps. Most guides treat “onsite” and “on-page” as the same thing; the more useful distinction is that on-page covers one page’s content and HTML, while onsite also covers sitewide structure, crawl paths, and the technical layer underneath every page, including how fast the server responds. Fix the checklist below in order and you have covered the part of ranking that is entirely within your control.
Search this term and you get a glossary definition followed by a list of ranking factors, repeated across a dozen agency sites with the same six headings. None of them walk through the checklist in an order that reflects how a real site gets fixed, and most skip the one item that quietly undermines the rest: a slow or unreliable host makes every other fix worth less. Here is the checklist, in order, with the technical layer included instead of assumed.
Table of contents
- On-site vs on-page: the distinction that actually matters
- Titles, headings, and content structure
- Internal linking and site structure
- Canonical tags and duplicate content
- Site speed and Core Web Vitals
- Sitemaps, robots.txt, and crawlability
- How this fits the rest of the stack
- FAQ
On-site vs on-page: the distinction that actually matters
On-page SEO is what you can change on a single URL: its title tag, its headings, its body content, its image alt text. On-site SEO includes all of that plus the things that apply across the whole domain: URL structure, internal linking patterns, sitemap coverage, canonical rules, and server response time.
The practical reason to keep the terms separate is that on-page fixes are cheap and page-by-page, while on-site fixes are structural and tend to affect every page at once, for better or worse. A bad canonical rule or a slow server does not cost you one page’s ranking, it costs a fraction of every page’s ranking simultaneously.
This post covers both layers, because a site with perfect title tags and a broken sitemap is still an on-site SEO problem, and no amount of on-page polish fixes it. It is also the deliberate counterpart to offsite SEO: everything here is within your own control, where backlinks and mentions are not.
Titles, headings, and content structure
Every page needs one H1 that states what the page is about, followed by H2 and H3 headings that break the content into scannable sections in a logical order, not just wherever a subheading felt due.
- Title tags under 60 characters, primary keyword near the front, unique per page. Duplicate titles across a site read as a template that nobody customized.
- Meta descriptions under 160 characters, written to earn the click, not to stuff keywords, since Google frequently rewrites them anyway but a good one still helps.
- One topic per URL. Two pages competing for the same query split the ranking signal between them instead of adding up.
- Descriptive image alt text, which helps accessibility and gives search engines a second signal about page content.
None of this is exotic. It is also the part people finish and then stop, as if the checklist ended there.
Internal linking and site structure
Internal links do two jobs: they help visitors find related content, and they tell search engines which pages matter most by how many links point at them and from where.
A flat structure, where every page links back to a handful of hub pages and those hub pages link out to everything relevant, distributes authority better than a chain of pages linking only to the next post in sequence. Orphan pages, ones with no internal links pointing at them at all, are effectively invisible to a crawler no matter how good the content is.
URL structure should mirror this hierarchy: a folder-like path (/blog/topic/post) reads as organized, a flat pile of unrelated slugs does not. Keep URLs short, lowercase, and hyphenated, and never change one without a redirect once it has been indexed.
Canonical tags and duplicate content
Every page should have exactly one canonical URL, declared in a <link rel=“canonical”> tag, even if it just points at itself. Without it, a site that is reachable with and without www, with and without a trailing slash, or over both http and https, is quietly splitting its ranking signal across several URLs that all serve the same content.
Faceted navigation, filters, and sort parameters on ecommerce or listing pages are the most common source of accidental duplicate content: /shop?sort=price and /shop?sort=name are the same page to a visitor and two separate URLs to a crawler unless the canonical tag says otherwise.
This is boring, invisible work, and it is also one of the few fixes that improves ranking sitewide the moment it is deployed correctly.
Site speed and Core Web Vitals
Speed is on-site SEO, not a separate performance project. Google measures Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift as ranking inputs, and all three are shaped by decisions made before a single word of content is written: image sizes, how many scripts block rendering, and how fast the server answers the first request.
A CDN in front of static assets, compressed and correctly sized images, and a host that responds in under 200 milliseconds cover most of the gap between a slow site and a fast one. No amount of content rewriting fixes a server that takes two seconds to respond before the page even starts rendering.
This is the point where onsite SEO stops being a content task and becomes a hosting decision, which is also where most SEO checklists quietly go silent.
Sitemaps, robots.txt, and crawlability
An XML sitemap lists every URL you want indexed and should be submitted through Search Console and referenced in robots.txt. It does not force indexing, but it removes the excuse that a crawler never found the page.
robots.txt should block only what genuinely should not be crawled, admin paths, internal search results, staging environments, not entire content sections out of caution. A blocked page cannot pass or receive internal link value, so over-blocking quietly shrinks the site’s own link graph.
Check Search Console’s Coverage report periodically for pages marked “crawled, not indexed” or “discovered, not indexed”: that is usually a thin-content or duplicate-content signal, not a crawling problem, and it is worth fixing before adding more pages to the pile.
How this fits the rest of the stack
Onsite SEO is finishing work, not a one-time audit: titles and headings get revisited as content ages, internal links need adding as new pages go up, and speed regresses quietly as a site grows unless something is watching it. The infrastructure half, page speed, uptime, and a CDN in front of static assets, comes from the RunxBuild hosting calculator alongside the plan sizing. Static sites on RunxBuild covers the build-from-repository path that keeps the technical layer out of the way, and the dashboard shows the deploy history once it is live.
Useful related references:
- Offsite SEO: The Off-Page Levers, and the On-Server Ones People Forget
- Restaurant SEO: The Technical Half Local Guides Leave Out
- Real Estate SEO: The Checklist That Actually Moves Local Rankings
- Static sites on RunxBuild
FAQ
Is on-site SEO the same as on-page SEO?
They overlap heavily but are not identical. On-page SEO usually means content and HTML on a single URL: titles, headings, body text. On-site SEO also includes sitewide structure, internal linking, sitemaps, and technical factors like page speed, which apply across every page at once.
What is the difference between onsite and offsite SEO?
Onsite SEO is everything you control directly on your own site: structure, content, speed, and technical setup. Offsite SEO is what happens elsewhere and points back at you, mainly backlinks, mentions, and citations. Both matter; only onsite is entirely within your own control.
How do I check my on-site SEO?
Start with Google Search Console’s Coverage and Core Web Vitals reports for indexing and speed issues, then crawl the site with a tool that flags duplicate titles, missing canonicals, and broken internal links. Fix technical issues before touching content, since a crawl or speed problem caps everything else.
Does site speed really affect SEO ranking?
Yes. Core Web Vitals are a confirmed ranking input, and slow pages also increase bounce rate, which correlates with worse rankings independent of the direct signal. Speed sits at the intersection of on-site SEO and hosting decisions rather than being a separate concern.
How often should on-site SEO be reviewed?
Quarterly for a content-heavy site is a reasonable baseline: check for broken internal links, orphaned pages, duplicate titles introduced by new content, and any speed regression from added scripts or images. A full technical crawl once or twice a year catches what quarterly spot checks miss.