This guide is for small public-facing marketing microsites, typically:
1–30 pages
The goal is:
Build websites that are easy for people, Google, and AI search systems to find, understand, trust, and use.
Keep SEO simple.
Do the fundamentals exceptionally well.
Always prioritise:
Never use:
A useful test:
Would this page still be valuable if Google did not exist?
If not, improve the page.
Think about every page in this order:
DISCOVER
↓
CRAWL
↓
INDEX
↓
UNDERSTAND
↓
RANK
↓
SEARCH APPEARANCE
↓
VISITOR
Before trying to improve rankings, make sure Google can:
Keep microsite architecture simple.
Example:
/
├── about/
├── services/
│ ├── service-a/
│ └── service-b/
├── projects/
├── faq/
└── contact/
Every important page should be reachable through normal navigation or contextual internal links.
Avoid orphan pages.
Do not create unnecessary layers of navigation.
Use clean, descriptive URLs.
Good:
/services/home-loans/
Bad:
/page?id=38291
Prefer:
lowercase
hyphens
short descriptive paths
stable URLs
Avoid unnecessary:
parameters
IDs
dates
tracking information
in canonical URLs.
Do not change an established URL without a reason.
If a page genuinely moves:
OLD URL
↓
301 / 308
↓
NEW URL
A canonical tells Google:
This is the preferred official URL for this page.
Every normal indexable microsite page should generally have a self-referencing canonical.
Page:
https://example.co.za/services/home-loans/
Canonical:
<link
rel="canonical"
href="https://example.co.za/services/home-loans/"
>
This also helps when URLs gain tracking parameters.
For example:
https://example.co.za/services/home-loans/?utm_source=facebook
should still canonicalise to:
https://example.co.za/services/home-loans/
Keep these aligned:
PAGE URL
↓
CANONICAL
↓
INTERNAL LINKS
↓
SITEMAP
↓
STRUCTURED DATA
↓
OPEN GRAPH URL
They should normally point to the same preferred URL.
Use:
duplicate/variant URL
→ canonical
Use:
page permanently moved
→ 301/308 redirect
canonical
= this is the preferred version
noindex
= do not include this page in Search
Do not confuse them.
Navigation must use real links.
Good:
<a href="/services/">Services</a>
Avoid using JavaScript-only navigation when a normal link is appropriate.
Rule:
NAVIGATION
→ <a>
ACTION
→ <button>
Use descriptive anchor text.
Good:
home loan application process
Weak:
click here
Every important page needs a unique <title>.
Good:
<title>Home Loans in Durban | Brand Name</title>
Weak:
<title>Home</title>
Useful patterns:
Page Subject | Brand
or where genuinely relevant:
Service in Location | Brand
Titles should be:
Do not keyword stuff.
Do not optimise against an arbitrary character count.
Google may rewrite the displayed title.
Give important pages useful unique descriptions.
Example:
<meta
name="description"
content="Expert home loan guidance, bank comparisons and application support."
>
Descriptions should:
Do not use keyword lists.
There is no magic 155/160-character requirement.
Google may generate a different snippet.
That is normal.
Keep <head> clean and valid.
Typical structure:
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>...</title>
<meta name="description" content="...">
<link rel="canonical" href="...">
<link rel="icon" href="/favicon.png">
<!-- Social metadata -->
<!-- Structured data -->
<!-- CSS/scripts -->
</head>
Do not place normal body content inside <head>.
Never put elements such as:
<img>
<iframe>
<h1>
<section>
<div>
inside <head>.
Invalid markup can interfere with Google’s processing of metadata that follows it.
Also avoid duplicate:
<title>
description
canonical
robots
metadata.
Centralise <head> generation wherever possible.
Use headings to describe document structure.
Example:
H1 Home Loans
H2 How We Help
H3 First-Time Buyers
H3 Property Investors
H2 How It Works
H2 Frequently Asked Questions
Normally use one clear primary H1.
Do not choose heading levels based on visual size.
Use CSS for presentation.
Every page should answer:
Who is this for?
What problem does it solve?
What does the visitor need to know?
Why should they trust this business?
What should they do next?
Prefer:
Avoid filler written merely to make pages longer.
There is no required SEO word count.
AI can help with:
But the preferred workflow is:
REAL BUSINESS KNOWLEDGE
↓
AI ASSISTANCE
↓
FACT CHECK
↓
HUMAN / AGENT REVIEW
↓
PUBLISH
Never allow AI to invent:
Do not mass-produce pages simply to target search queries.
Use words customers naturally use.
Do not optimise for keyword density.
Do not repeatedly force exact-match phrases into content.
Use:
primary topic
related concepts
natural synonyms
questions customers ask
industry terminology
location where genuinely relevant
Do not use:
<meta name="keywords">
for Google SEO.
Important pages should receive useful internal links.
Example:
Learn more about our
<a href="/services/home-loans/">
home loan application service
</a>.
Internal links help:
users
Google discovery
site structure
page relationships
importance
Do not rely only on the sitemap to expose important pages.
Important images should:
Example:
<img
src="/assets/img/home-loan-consultation.webp"
alt="Home loan adviser meeting with a client"
width="1200"
height="800"
>
Do not place important information only inside an image.
Use useful alt text for meaningful images.
Good:
alt="Amanda Strydom, Property Finance Specialist"
Bad:
alt="image"
Bad:
alt="best cheap home loans mortgage Durban finance"
Decorative imagery generally uses:
alt=""
Accessibility comes first.
Prefer:
<header>
<nav>
<main>
<section>
<article>
<footer>
Use real:
<a>
<button>
<label>
instead of making generic <div> elements imitate them.
Semantic HTML improves:
accessibility
SEO
browser behaviour
maintainability
machine understanding
For most production microsites:
User-agent: *
Allow: /
Sitemap: https://example.co.za/sitemap.xml
That is normally enough.
Do not create complicated crawler rules without a genuine reason.
Do not unnecessarily block:
CSS
JavaScript
images
Never accidentally deploy:
User-agent: *
Disallow: /
to production.
Treat that as a release blocker.
robots.txt controls crawling.
It does not secure information.
ROBOTS.TXT
= crawl control
NOINDEX
= indexing control
AUTHENTICATION
= access control
Sensitive content requires real access protection.
For a ≤30-page microsite use:
/sitemap.xml
One sitemap is normally enough.
It should contain the canonical URLs of important public indexable pages.
Include:
200
public
canonical
indexable
production URLs
Exclude:
redirects
404s
noindex pages
drafts
staging URLs
private pages
Do not normally build:
sitemap indexes
image sitemaps
video sitemaps
news sitemaps
for a small marketing site.
Use <lastmod> only when accurate.
Do not set every page to today’s date simply because the site was rebuilt.
Rule:
accurate lastmod
>
no lastmod
>
fake lastmod
Do not spend time on:
changefreq
priority
for Google.
Focus on making the normal Google result excellent:
FAVICON
SITE NAME
TITLE
URL
SNIPPET
IMAGE
BUSINESS IDENTITY
Do this before chasing rich results.
Google ultimately decides how a search result appears.
Every production microsite needs a favicon.
Example:
<link rel="icon" href="/favicon.png">
Use a recognisable brand mark that remains clear at small sizes.
The favicon can appear in Google Search results.
Keep schema simple.
Typical homepage:
WebSite
+
Organization
or when appropriate:
WebSite
+
LocalBusiness
Conditional:
BreadcrumbList
Article
VideoObject
Event
only when the content genuinely warrants it.
Do not schema-stuff.
Structured data should describe reality.
VISIBLE REAL INFORMATION
↓
STRUCTURED DATA
Never:
SEO WISH
↓
FAKE SCHEMA
Never invent:
reviews
ratings
prices
locations
authors
qualifications
opening hours
offers
Passing a schema validator does not guarantee a rich result.
FAQ sections remain useful for:
But do not add FAQ schema expecting expandable FAQ Google results.
Build FAQs because they help users.
For local businesses keep these accurate and consistent:
business name
address / service area
telephone
opening hours
website
business category
Align the website with Google Business Profile.
Do not create fake location pages.
Avoid:
/home-loans-durban/
/home-loans-kloof/
/home-loans-westville/
/home-loans-pinetown/
where the only meaningful difference is the town name.
Location pages need genuine local value.
Microsites should be fast.
Avoid unnecessary:
huge JavaScript bundles
giant images
multiple font families
unused libraries
heavy animation frameworks
third-party scripts
Good Core Web Vitals targets:
LCP ≤ 2.5s
INP < 200ms
CLS < 0.1
Do not chase Lighthouse 100 merely for the score.
The hero often determines LCP.
Therefore:
Keep important hero text as actual HTML rather than baking it into an image.
Every page must work properly on mobile.
Check:
navigation
font sizes
tap targets
forms
images
spacing
horizontal overflow
modals
CTA buttons
Do not hide important content from mobile users.
Production sites should use Google Search Console.
Monitor:
search queries
impressions
clicks
pages
indexing
sitemaps
Core Web Vitals
security issues
Do not confuse third-party SEO scores with Google ranking scores.
Do not create a separate technical SEO system for AI.
Good foundations remain:
USEFUL CONTENT
+
CLEAR ENTITIES
+
SEMANTIC HTML
+
ORIGINAL INFORMATION
+
INTERNAL LINKS
+
IMAGES
+
STRUCTURED DATA
+
NORMAL SEO
Do not automatically add:
AI schema
GEO schema
AI keyword density
forced content chunking
special Google AI markup
because somebody claims it guarantees AI visibility.
Centralise SEO.
Use one clear source of truth for shared SEO metadata. A site may use a plugin such as jekyll-seo-tag, or it may use local includes such as seo.html and schema.html, but it should not generate duplicate title, description or canonical tags.
_config.yml
_includes/
├── seo.html
└── schema.html
_layouts/
└── default.html
robots.txt
sitemap.xml
For Jekyll, jekyll-seo-tag is a good default for title, description, canonical, Open Graph and basic JSON-LD metadata. If a site uses it, add only complementary structured data by hand and avoid duplicating tags it already emits.
Page front matter can provide:
---
title:
description:
permalink:
image:
---
Generate the canonical from:
production domain
+
page URL
For example:
<link
rel="canonical"
href="https://thebondcellar.co.za/seo-overhail.html"
>
Do not manually duplicate SEO markup throughout layouts.
First identify whether the site uses:
SPA
SSG
SSR
Nuxt
prerendering
For public marketing sites prefer SSG, SSR or prerendering where practical.
For every public route verify:
direct URL works
title is correct
description is correct
canonical is correct
H1 exists
content renders
links are crawlable
Every important page should have:
[ ] clear purpose
[ ] clean URL
[ ] unique title
[ ] useful description
[ ] self-referencing canonical
[ ] clear H1
[ ] logical H2/H3 structure
[ ] useful original content
[ ] internal links
[ ] relevant images
[ ] appropriate alt text
[ ] clear CTA
[ ] semantic HTML
[ ] mobile support
[ ] good performance
Before deployment:
[ ] HTTPS works
[ ] production domain correct
[ ] preferred hostname correct
[ ] robots.txt allows crawling
[ ] sitemap.xml works
[ ] sitemap contains production canonical URLs
[ ] no accidental noindex
[ ] canonicals use production domain
[ ] internal links use preferred URLs
[ ] redirects work
[ ] missing pages return 404
[ ] titles correct
[ ] descriptions correct
[ ] H1s correct
[ ] head markup valid
[ ] no duplicate metadata
[ ] navigation works
[ ] images work
[ ] alt text reviewed
[ ] schema is accurate and valid
[ ] mobile works
[ ] performance acceptable
[ ] no major browser console errors
Classify findings:
site-wide noindex
Disallow: /
wrong-domain canonical
production unavailable
missing titles
broken navigation
broken canonicals
important orphan pages
incorrect redirects
weak descriptions
poor internal linking
missing useful alt text
oversized images
weak content
minor filename improvements
optional schema
small metadata refinements
Do not treat every SEO issue as critical.
When asked to review or improve SEO:
1. Understand the business and audience.
2. Map the public pages.
3. Check crawlability and indexability.
4. Check URLs and canonicals.
5. Review titles and descriptions.
6. Review headings and content.
7. Review internal linking.
8. Review images and alt text.
9. Review structured data.
10. Review mobile and performance.
11. Fix P0/P1 issues first.
12. Build the site.
13. Inspect rendered HTML.
14. Verify production.
Do not blindly rewrite the entire site.
Report findings clearly:
SEO REVIEW
Overall
Good / Needs Work / Critical
P0 — Critical
- ...
P1 — High
- ...
P2 — Improvements
- ...
Implemented
- ...
Recommended Next
- ...
Where useful identify:
route
file
problem
change
Example:
/services/home-loans/
Problem:
Generic page title.
Change:
Home Loans in Durban | Brand Name
Do not waste development time on:
meta keywords
keyword density
exact title character counts
exact description character counts
crawl budget for a 20-page site
sitemap priority
sitemap changefreq
sitemap indexes
mass location pages
fake reviews
fake ratings
schema stuffing
AI schema
GEO schema
SEO plugin scores
Unless the project has an unusual requirement, these are distractions.
SEO is in good shape when:
Google can find the pages.
Google can crawl them.
Google can index the intended pages.
URLs are clean.
Canonicals are consistent.
Titles describe the pages.
Content answers real questions.
HTML is semantic.
Internal links make sense.
Images are optimised.
Business information is accurate.
Structured data reflects reality.
Mobile works well.
Pages are fast.
robots.txt is simple and correct.
sitemap.xml is simple and correct.
Production output has been checked.
Then stop adding SEO infrastructure.
Improve the actual website.
For a microsite:
Make the website exceptionally easy to understand.
For:
PEOPLE
SEARCH ENGINES
AI SYSTEMS
BROWSERS
ASSISTIVE TECHNOLOGY
DEVELOPERS
Prefer:
simple
semantic
fast
useful
accurate
crawlable
well structured
maintainable
over:
complex
over-optimised
keyword-heavy
schema-heavy
plugin-heavy
AI-generated
For a 1–30 page microsite, excellent fundamentals are the SEO strategy.