Technical SEO is the part of search engine optimisation that focuses on whether a website can be crawled, understood, indexed and used properly.
A business can have excellent service pages, strong reviews and a well-managed Google Business Profile, but technical problems can still limit performance.
A page may be blocked from indexing.
A redirect may send visitors to the wrong place.
A mobile layout may hide important content.
A site may load so slowly that customers leave.
A canonical tag may point to the wrong URL.
A broken plugin may produce duplicate pages.
A migration may leave hundreds of old links returning errors.
These problems are particularly important for local businesses because many customers search from mobile devices and may need an answer quickly.
Someone searching for an emergency plumber is unlikely to wait patiently for a heavy website to load.
A tourist searching for directions does not want a broken map.
A customer looking for a quotation should not encounter a form that fails silently.
Technical SEO is therefore not only about search engines.
It is also about making the website reliable.
What Is Technical SEO?
Technical SEO covers the underlying structure and behaviour of a website.
It helps search engines access pages and helps users interact with them successfully.
Typical areas include:
Crawling.
Indexing.
Page speed.
Mobile usability.
HTTPS.
URL structure.
Redirects.
Canonical URLs.
Sitemaps.
Robots.txt.
Structured data.
Broken links.
Server errors.
JavaScript rendering.
Image optimisation.
Website architecture.
Duplicate content.
For local businesses, technical SEO should support the content and local strategy rather than become an isolated technical exercise.
A perfect technical score does not replace useful service information.
Likewise, excellent content cannot perform well if Google cannot access it.
Crawling and Indexing
Crawling and indexing are related but different.
Crawling happens when a search engine accesses a webpage and follows links to discover content.
Indexing happens when the search engine processes the page and decides whether it should be stored and become eligible to appear in search results.
Google explains that it discovers pages through methods including links and sitemaps, then crawls and processes eligible pages before they may appear in Search. (developers.google.com)
A page can be crawlable but not indexed.
It can also be blocked from crawling entirely.
Understanding this distinction helps diagnose problems correctly.
Not Every Page Needs to Be Indexed
A common beginner mistake is assuming that every URL on a website should appear in Google.
Some pages are useful to visitors but not useful as search results.
Examples may include:
Account pages.
Checkout pages.
Internal search results.
Thank-you pages.
Private dashboards.
Temporary previews.
Admin pages.
Filtered duplicates.
Some legal or utility pages may still be indexed naturally, while others may not need search visibility.
The objective is not to maximise the number of indexed URLs.
The objective is to make sure the important pages can be discovered and indexed correctly.
Important Pages Should Be Easy to Discover
Search engines discover many pages by following links.
Important service and location pages should be connected through logical internal navigation.
A page should not exist only inside a sitemap with no links pointing towards it from the rest of the website.
For Addweb, the local SEO service page might be linked from:
The services page.
The homepage.
Related blog articles.
Location pages.
Footer navigation where appropriate.
This improves both usability and discovery.
Google’s documentation notes that links are a major way its systems discover new pages. (developers.google.com)
Check Indexing With Google Search Console
Google Search Console is one of the most useful technical SEO tools available to website owners.
Its URL Inspection tool can show information about a specific page, including whether Google knows about it, whether it was indexed and which canonical URL Google selected.
Search Console also reports indexing issues across groups of URLs. (support.google.com)
For an important page, check:
Can Google access it?
Is indexing allowed?
Has it been indexed?
Which canonical did Google select?
Was the page crawled recently?
Are there detected problems?
This is more reliable than searching manually for the page and assuming that its absence means it is blocked.
The Difference Between noindex and robots.txt
These are often confused.
A noindex directive tells search engines not to include the page in search results.
A robots.txt rule can prevent crawling of a URL pattern.
These are not interchangeable.
If a page is blocked by robots.txt, Google may be unable to access a noindex directive placed on that page.
Google’s documentation explains that noindex must be visible to the crawler to be processed. (developers.google.com)
For beginners, the safest rule is:
Use noindex when you do not want a page in search results.
Use robots.txt carefully to control crawling where there is a clear technical reason.
Do not block important service pages accidentally.
Robots.txt
The robots.txt file normally appears at the root of the domain.
For example:
https://addweb.co.za/robots.txt
It contains rules telling crawlers which parts of the site they may or may not crawl.
A WordPress installation may use rules that prevent crawling of certain administrative paths while still allowing access to public content.
Robots.txt is not a security system.
A blocked URL can still be accessed directly by someone who knows its address.
Do not use robots.txt to protect confidential information.
Private content should require proper authentication.
Common Robots.txt Mistakes
One serious mistake is accidentally blocking the entire website.
A rule such as:
Disallow: /
can prevent normal crawling.
This sometimes happens when a development site is moved to production and the temporary blocking rule is not removed.
Another mistake is blocking CSS or JavaScript resources needed for proper rendering.
Search engines may need to access these resources to understand how the page behaves.
A third mistake is assuming robots.txt removes pages that are already indexed.
It does not function as a guaranteed removal tool.
Review robots.txt after migrations, redesigns and staging-to-live launches.
WordPress Search Engine Visibility
WordPress includes a setting commonly labelled:
“Discourage search engines from indexing this site.”
This can add indexing directives intended to keep a development site out of search results.
It is useful during development.
It can be disastrous when left enabled after launch.
Every WordPress launch checklist should include checking this setting.
A new website can appear perfect to the client while remaining effectively invisible to search if indexing is discouraged.
Do not assume the setting changed automatically when the site moved from staging to production.
Staging Websites
A staging site is a copy used for development and testing.
Examples may use domains such as:
staging.example.com
dev.example.com
or a temporary hosting URL.
Staging environments should not compete with the live website in search results.
They can be protected using authentication and appropriate indexing controls.
Password protection is often better than relying entirely on robots.txt.
Once the live site is launched, check whether the staging domain has accidentally been indexed.
If so, remove or restrict access appropriately.
Do not leave public duplicate copies online indefinitely.
XML Sitemaps
An XML sitemap lists important URLs that a website wants search engines to know about.
Google describes sitemaps as a way to provide information about pages, videos and files and the relationships between them. (developers.google.com)
Most modern WordPress SEO plugins can generate sitemaps automatically.
WordPress itself also has native sitemap functionality.
A sitemap may include:
Service pages.
Location pages.
Blog posts.
Product pages.
Category pages.
Other important content.
It should not become a dumping ground for every technical URL.
What Should Not Be in a Sitemap?
Avoid listing URLs that are:
Redirecting.
Blocked intentionally.
Marked noindex.
Returning errors.
Duplicate parameter versions.
Old deleted pages.
Private account pages.
Staging URLs.
A sitemap should mostly contain canonical, indexable pages that the business actually wants searched.
If the sitemap lists thousands of low-value URLs, it becomes less useful as a representation of the website’s important content.
Submit Sitemaps Through Search Console
Once a sitemap is available, it can be submitted in Google Search Console.
This helps Google discover its location.
Submission does not guarantee that every URL will be crawled or indexed.
Google still evaluates the pages individually.
The sitemap should update automatically when pages are created or removed.
Check it periodically after major website changes.
Canonical URLs
A canonical URL indicates the preferred version of a page when multiple URLs contain identical or very similar content.
For example, an online store might allow several parameter variations that show essentially the same category.
Canonical signals help search engines consolidate these variations.
Google treats rel="canonical" as a strong signal, but not an absolute command. (developers.google.com)
For ordinary service pages, the canonical usually points to the page itself.
For example:
https://addweb.co.za/local-seo/
should generally canonicalise to itself unless there is a deliberate reason otherwise.
Common Canonical Mistakes
One of the worst mistakes is making every page canonical to the homepage.
This effectively tells search engines that all pages are duplicates of the homepage.
Another problem occurs after cloning a website.
The new live site may still contain canonical URLs pointing to the old staging domain.
A third problem occurs when HTTP pages canonicalise to HTTP while the live site uses HTTPS.
A fourth occurs when pagination or filtered pages are canonicalised incorrectly.
Check canonicals after migrations, staging launches and domain changes.
HTTP and HTTPS
HTTPS encrypts information transmitted between the browser and website.
A secure website should use a valid TLS certificate and redirect HTTP traffic to HTTPS.
For example:
http://addweb.co.za/
should redirect to:
https://addweb.co.za/
Google has used HTTPS as a ranking signal for many years, but its practical importance extends beyond rankings.
Customers expect secure websites.
Browsers may warn users when forms or payment pages are insecure.
For local businesses collecting contact details, bookings or payments, HTTPS is essential.
Mixed Content
Mixed content happens when an HTTPS page loads some resources over insecure HTTP.
Examples include:
Images.
Scripts.
Fonts.
Stylesheets.
Embedded content.
Browsers may block insecure resources or display warnings.
This often occurs after a website migrates from HTTP to HTTPS and old hard-coded URLs remain in the database.
WordPress sites may require search-and-replace work or plugin configuration to update historical asset paths.
Do not solve mixed content simply by hiding browser warnings.
Correct the underlying URLs.
URL Structure
A clean URL structure improves readability and site organisation.
Examples:
/local-seo/
/wordpress-web-design/
/web-design-durban/
/blog/local-seo-guide/
Avoid unnecessary parameters and repeated folder names where possible.
Weak examples include:
/?page_id=1284
/services/web-services/website-services/web-design-service/
A URL should remain stable once published.
Frequent URL changes create unnecessary redirects and maintenance.
Trailing Slashes and URL Consistency
Some websites use trailing slashes:
/local-seo/
Others do not:
/local-seo
Either can work.
The important point is consistency.
The non-preferred version should resolve or redirect appropriately.
The canonical should match the preferred structure.
Avoid situations where several variants are accessible separately:
HTTP and HTTPS.
WWW and non-WWW.
Uppercase and lowercase paths.
Trailing and non-trailing slash.
Tracking versions.
Search engines can usually handle many of these cases, but a clean setup reduces ambiguity.
WWW Versus Non-WWW
A website may use:
https://www.example.com
or:
https://example.com
Neither is inherently better for SEO.
Choose one and redirect the other consistently.
The canonical URLs, sitemap, internal links and structured data should support the preferred version.
Do not allow both to behave like separate websites.
Redirects
Redirects send users and crawlers from one URL to another.
The most common permanent redirect is a 301.
Google treats permanent redirects as strong signals that the destination should be considered the preferred URL. (developers.google.com)
Redirects are useful when:
A page moves.
A URL changes.
Two pages are merged.
A domain changes.
An old service page is replaced.
A product category is reorganised.
The destination should be closely related to the original page.
Do Not Redirect Everything to the Homepage
Suppose a website removes 100 old service pages and redirects all of them to the homepage.
This creates a poor user experience because someone following a link about a specific service arrives at a generic page.
Where a suitable replacement exists, redirect to it.
If there is no relevant replacement and the page is permanently gone, allowing an appropriate 404 or 410 response may be more accurate.
Redirects should preserve meaning.
Redirect Chains
A redirect chain occurs when one URL redirects to another, which redirects again.
For example:
A → B → C → D
The browser and crawler eventually reach D, but the process is inefficient.
A better setup is:
A → D
After redesigns and migrations, old chains often accumulate.
Update internal links so that they point directly to the final URL.
Clean up unnecessary intermediate redirects where practical.
Redirect Loops
A redirect loop occurs when URLs redirect in a circle.
For example:
A → B
B → A
The page never loads.
WordPress redirect loops can be caused by:
Incorrect HTTPS configuration.
Caching.
Cloudflare settings.
Plugin conflicts.
Wrong site URL settings.
Server rules.
Test critical URLs after any redirect or SSL change.
404 Errors
A 404 response means the requested page could not be found.
404s are normal when content has genuinely been removed or when someone types an incorrect URL.
The problem is not that a website has any 404s.
The problem is when important internal links, backlinks or customer journeys lead to them unnecessarily.
A custom 404 page should help visitors continue.
It might include:
A search box.
Main navigation.
Popular services.
Contact information.
A link to the homepage.
Do not disguise every missing page as a successful 200 response.
That can create soft 404 problems.
Soft 404s
A soft 404 occurs when a page appears missing or empty but returns a normal success status instead of a proper not-found response.
For example, a deleted product page might say:
“Product not found”
while still returning HTTP 200.
Search engines may interpret this as a soft 404.
Use correct server responses.
A missing page should usually return a genuine 404 or redirect to a meaningful replacement.
Server Errors
A 5xx status generally indicates a server-side problem.
Examples include:
500 Internal Server Error.
502 Bad Gateway.
503 Service Unavailable.
504 Gateway Timeout.
Temporary server errors happen occasionally.
Persistent errors are serious.
They can prevent customers and crawlers from accessing the site.
Monitor hosting logs and uptime.
A local business website that is offline several times a week is losing customers before SEO is even considered.
Uptime
Uptime measures whether the site is available.
A business should monitor its main website, especially when enquiries depend on it.
A simple monitoring service can notify the owner when the site stops responding.
Investigate recurring outages.
Possible causes include:
Poor hosting.
Plugin failures.
Memory limits.
Database problems.
Traffic spikes.
Security incidents.
Server configuration.
DNS problems.
Do not accept repeated downtime as normal.
Website Hosting and SEO
Hosting can affect website reliability and speed.
Important considerations include:
Server response time.
Uptime.
PHP versions.
Database performance.
Caching.
Resource limits.
Backups.
Security.
Support.
Geographical server location can affect latency, though modern CDNs and infrastructure can reduce the importance of physical distance.
A local South African business does not necessarily require a South African server to rank locally, but a reliable server with good response times for the target audience is important.
Choose hosting based on performance and operational requirements rather than marketing claims about “SEO hosting.”
Core Web Vitals
Core Web Vitals are metrics Google uses to evaluate aspects of real-world user experience.
As of 2026, the core metrics include:
Largest Contentful Paint, or LCP.
Interaction to Next Paint, or INP.
Cumulative Layout Shift, or CLS.
Google’s current guidance describes recommended thresholds using the 75th percentile of real-user page loads. (web.dev)
These metrics focus on loading, responsiveness and visual stability.
They are useful indicators, but they should not become the only objective of website development.
Largest Contentful Paint
LCP measures how long it takes for the largest significant visible content element to render.
This is often a hero image, heading block or large content section.
A slow LCP can make the page feel as though nothing is happening.
Common causes include:
Huge hero images.
Slow server responses.
Render-blocking CSS.
Heavy page builders.
External fonts.
Large sliders.
JavaScript-heavy effects.
Poor caching.
For a local business homepage, the hero section should normally load quickly enough that the visitor can identify the business without staring at a blank screen.
Interaction to Next Paint
INP measures responsiveness to user interactions.
A website may load visually but respond slowly when the user taps a menu, button or form field.
Common causes include:
Heavy JavaScript.
Large third-party scripts.
Complex animations.
Too many tracking tools.
Poorly optimised page-builder scripts.
Chat widgets.
Advertising scripts.
A mobile customer tapping “Call Now” should not experience a noticeable delay because the browser is busy processing unnecessary scripts.
Cumulative Layout Shift
CLS measures unexpected movement of page elements.
Imagine trying to tap a booking button when an image loads and pushes the button downward.
You accidentally tap something else.
That is the kind of experience CLS is designed to measure.
Common causes include:
Images without defined dimensions.
Ads loaded late.
Fonts changing layout.
Dynamic banners.
Cookie notices inserted unpredictably.
Late-loading widgets.
Reserve space for elements before they load.
A visually stable page feels more professional and is easier to use.
Lab Data and Field Data
Performance tools often show two types of information.
Lab data is generated in a simulated test environment.
Field data reflects real user experiences where sufficient data exists.
Both are useful.
Lab data helps diagnose technical issues.
Field data shows what real visitors experience across devices and networks.
Do not panic when one synthetic test gives a poor result while real-user performance is acceptable.
Likewise, do not ignore consistently poor field data because a desktop test looks fast.
PageSpeed Insights
Google PageSpeed Insights combines Lighthouse diagnostics with real-world Chrome User Experience Report data where available.
It can help identify:
Slow loading.
Large images.
JavaScript problems.
Layout shifts.
Caching opportunities.
Render-blocking resources.
Third-party impact.
Do not treat the score as a business KPI.
A 100 score does not automatically mean the site will rank first.
A score of 92 instead of 96 is rarely more important than a broken enquiry form.
Use performance testing to improve real customer experience.
WordPress Performance
WordPress can perform extremely well when configured carefully.
It can also become slow when overloaded.
Common causes include:
Too many plugins.
Poor plugins.
Large images.
Unnecessary page-builder widgets.
Excessive animation.
Third-party tracking scripts.
Slow databases.
Poor hosting.
No caching.
Large option tables.
Unused CSS and JavaScript.
External fonts.
Heavy sliders.
Video backgrounds.
The solution is not automatically to remove every plugin.
Identify which components are actually causing problems.
Elementor Performance
Elementor allows sophisticated layouts but can become heavy when a page is built inefficiently.
Common mistakes include:
Excessive nested containers.
Animations on many elements.
Multiple icon libraries.
Large background videos.
Huge hero images.
Several sliders.
Unnecessary addons.
Duplicate scripts from addon packs.
Large DOM structures.
A well-built Elementor page should use a clean container structure and only the widgets required.
Avoid installing five addon packs because each provides one widget.
Use custom CSS or lightweight code where that is more efficient and maintainable.
Plugin Discipline
Every plugin introduces code, database activity or maintenance.
Before installing one, ask:
Is the functionality already available?
Is the plugin actively maintained?
Is it compatible with the current WordPress and PHP version?
Does it load assets on every page?
Does it create database bloat?
Does it have a reliable security history?
Can the same result be achieved more cleanly?
Do not install plugins merely because they appear in an SEO checklist.
A local business website does not need dozens of SEO plugins performing overlapping tasks.
Caching
Caching stores generated content so that the server does not need to rebuild everything for every visitor.
It can significantly improve WordPress performance.
Caching may exist at several levels:
Browser cache.
Page cache.
Object cache.
Server cache.
CDN cache.
Misconfigured caching can also create problems.
A customer may see an outdated page.
Forms may fail.
Logged-in users may receive cached content incorrectly.
WooCommerce carts may behave unpredictably.
Configure exclusions for dynamic pages such as carts, checkout and account sections where required.
Content Delivery Networks
A CDN stores website assets across distributed servers.
Visitors can receive files from a location closer to them.
CDNs may also provide:
Caching.
Image optimisation.
Security.
DDoS protection.
DNS.
A CDN can improve performance, particularly for geographically distributed audiences.
It is not mandatory for every small local website.
A fast local site with efficient hosting may perform perfectly well without an elaborate CDN setup.
Use technology to solve actual problems.
Image Performance
Images are often the largest files on local business websites.
A photographer may upload 10 MB images directly from a camera.
An Elementor designer may use a 4000-pixel-wide image for a 600-pixel container.
A tourism site may load 20 full-resolution photos at once.
Optimise images before or during upload.
Use appropriate dimensions.
Use compression.
Use modern formats where suitable.
Lazy-load below-the-fold images.
Do not lazy-load the main LCP image unnecessarily if doing so delays it.
The important hero image may need priority loading.
Video Backgrounds
Video backgrounds can look impressive but are expensive in bandwidth and processing.
On mobile, they may slow the page substantially.
Ask whether the video improves the customer’s understanding.
A tourism business may benefit from a short marine video.
A plumber probably does not need a looping 30 MB background behind the phone number.
Where video is important, optimise it and provide suitable fallback imagery.
Fonts
Web fonts can delay rendering.
A website may load several font families and numerous weights even though only two are used.
Reduce unnecessary font files.
Consider system fonts or locally hosted fonts where appropriate and properly licensed.
Use preload carefully for critical fonts.
Avoid loading every weight from 100 to 900 when the design uses only 400 and 700.
Typography should support design without becoming a performance burden.
JavaScript and Third-Party Scripts
Third-party scripts can significantly affect speed.
Examples include:
Analytics.
Advertising.
Chat tools.
Heatmaps.
Booking systems.
Social embeds.
Cookie platforms.
Tracking pixels.
Review widgets.
Each may be useful individually.
Together they can create a heavy page.
Audit third-party scripts regularly.
Remove tools no longer used.
Load scripts only where necessary.
A booking widget does not necessarily need to load on every blog page.
Mobile-Friendly Design
A technically crawlable site can still fail customers on mobile.
Check:
Text size.
Button spacing.
Menus.
Forms.
Telephone links.
WhatsApp links.
Maps.
Tables.
Accordions.
Popups.
Sticky elements.
Cookie banners.
Image scaling.
Horizontal scrolling.
Google uses mobile-first indexing, meaning the mobile version is the primary version used for indexing and ranking. (developers.google.com)
Important content should not disappear on mobile simply because the desktop layout is too complex.
Responsive Design
Responsive design uses one set of URLs while adapting the layout to screen size.
Google recommends responsive design as a common approach because it is easier to maintain and reduces opportunities for mobile and desktop content to diverge. (developers.google.com)
Most modern WordPress and Elementor websites use responsive design.
Test actual breakpoints.
Do not assume that because Elementor shows a mobile preview, the live site works perfectly on every device.
Mobile Content Parity
The mobile version should include the same important information as desktop.
A common design shortcut is hiding large content sections on mobile.
If those sections contain service details, locations, reviews or internal links, the mobile version may become weaker.
Google specifically advises that important content and structured data should be equivalent across mobile and desktop versions. (developers.google.com)
Hiding a decorative image is different from hiding half of the service description.
Popups on Mobile
Mobile screens have limited space.
A full-screen newsletter popup can make a page unusable.
A cookie banner can cover the contact button.
A live chat window can overlap navigation.
A floating WhatsApp button can block form fields.
Test all overlays together.
A desktop design may appear fine while the mobile version has four competing fixed elements.
Prioritise the customer’s main action.
Contact Buttons
Local pages should make contacting the business easy.
Telephone links should use a proper tel: format.
For example:
tel:+27793330911
WhatsApp links should use the correct supported URL format.
Email links can use mailto: where appropriate.
Test them on real mobile devices.
A typo in a WhatsApp URL can cause every mobile lead to fail.
Forms and Technical Reliability
Forms can fail because of:
SMTP issues.
Spam filtering.
JavaScript conflicts.
Caching.
CAPTCHA errors.
Plugin updates.
Server restrictions.
Expired API keys.
Never assume a form works because it looks correct.
Submit test enquiries regularly.
Confirm that notifications arrive.
Check spam folders.
Store submissions securely where appropriate.
Display a confirmation message to the customer.
For high-value enquiries, consider keeping a secondary record inside the website or CRM so that an email failure does not destroy the lead.
Email Deliverability
WordPress hosting servers sometimes send mail unreliably through default PHP mail functions.
Using authenticated SMTP or a reputable transactional email provider can improve reliability.
DNS records such as SPF, DKIM and DMARC can also affect email authentication and deliverability.
These are not direct local SEO ranking factors, but they affect whether leads reach the business.
SEO that generates enquiries is wasted when the enquiry email disappears.
Structured Data
Structured data provides machine-readable information about page content.
Google supports several schema types that may be relevant to local businesses.
Examples include:
Organization.
LocalBusiness.
Product.
Breadcrumb.
Article.
Event.
Video.
JobPosting.
Some categories support additional structured data types depending on the content.
Google recommends JSON-LD as a convenient structured-data format when possible. (developers.google.com)
Structured data should represent visible, truthful information.
LocalBusiness Schema
LocalBusiness schema can describe a local business location.
Possible properties include:
Name.
Address.
Telephone.
URL.
Opening hours.
Geo coordinates.
Business type.
Images.
Price range.
Google’s documentation explains the supported use of LocalBusiness structured data for information such as opening hours and location details. (developers.google.com)
Do not add properties merely because they exist.
Use information relevant to the actual business.
Organization Schema
Organization schema can describe the broader company.
It may include:
Name.
Logo.
URL.
Contact information.
Address.
Social profile references.
Other identifying information.
This can be especially useful for companies operating nationally or with multiple business locations.
Avoid conflicting markup between Organization and LocalBusiness blocks.
The company name, logo and URLs should agree.
Breadcrumb Schema
Breadcrumbs show the hierarchy of a page.
For example:
Home → Services → Local SEO
Breadcrumb structured data can help Google understand the page’s position within the site hierarchy and may influence breadcrumb displays in search results. (developers.google.com)
Breadcrumbs are also useful for visitors on larger websites.
They should reflect the real navigation structure.
Article Schema
Blog posts and guides can use Article or BlogPosting markup where appropriate.
Properties may include:
Headline.
Author.
Date published.
Date modified.
Image.
Publisher.
The structured data should match the visible article.
Do not claim a publication date different from the actual content merely to make it appear newer.
When an article is substantially updated, the visible modified date and structured data can reflect the update accurately.
Product Schema
E-commerce businesses may use Product structured data.
It can describe information such as:
Product name.
Images.
Price.
Availability.
Offers.
Ratings where eligible.
The visible product information and structured data must agree.
Do not show one price to users and another price in schema.
Keep stock status current.
WooCommerce SEO plugins may generate much of this automatically, but the output should still be tested.
Event Schema
Businesses hosting real events may use Event structured data.
Examples include:
Workshops.
Conferences.
Training sessions.
Tours.
Public events.
The event must genuinely exist.
Do not create fake event pages as an SEO tactic.
Include accurate dates, venue, availability and booking information.
Schema Does Not Guarantee Rankings
Schema can improve understanding and make certain content eligible for enhanced search appearances.
It does not automatically improve rankings.
It does not create a local office.
It does not make fake reviews legitimate.
It does not compensate for thin content.
Treat schema as structured clarification, not a shortcut.
Validate Structured Data
Use Google’s Rich Results Test for markup types supported in rich results.
Search Console may also report structured-data enhancement issues.
Schema.org validators can help inspect broader schema syntax.
Check:
Missing required properties.
Invalid values.
Conflicting entities.
Incorrect URLs.
Old phone numbers.
Wrong addresses.
Old logos.
Outdated opening hours.
A technically valid markup block can still be factually wrong.
Validation should include both syntax and truth.
Duplicate Schema From WordPress Plugins
WordPress websites often use multiple plugins that generate schema automatically.
For example:
An SEO plugin.
A review plugin.
A local SEO plugin.
A page builder.
A WooCommerce extension.
These can create duplicated or conflicting markup.
One plugin may identify the company as an Organization.
Another may output LocalBusiness with a different address.
A third may add review markup incorrectly.
Inspect the final rendered markup.
Do not assume that more schema is better.
One clean, accurate entity definition is preferable to several contradictory ones.
JavaScript Rendering
Modern websites may rely on JavaScript for parts of their content.
Google can process JavaScript, but rendering introduces complexity.
Important local information should not depend on fragile scripts unnecessarily.
If the service description, telephone number or location content only appears after a JavaScript API call fails or succeeds, accessibility may suffer.
Use normal HTML for critical content when practical.
Interactive features can enhance the experience without making the core business information dependent on them.
Lazy Loading
Lazy loading delays loading of images or other resources until they are near the visible screen.
This can improve performance.
Use it carefully.
Below-the-fold gallery images are excellent candidates.
The main hero image is often not.
If the LCP image is lazy-loaded unnecessarily, the largest visible element may appear late.
Test the actual impact rather than enabling every optimisation option automatically.
Internal Site Search
Some websites generate a unique URL for every internal search query.
For example:
/?s=wordpress
Search-result pages can create large amounts of low-value or duplicate content if indexed.
For most local business sites, internal search results do not need to appear in Google.
They can usually be marked appropriately to prevent indexing.
The main service and blog pages should be indexed instead.
Filter and Parameter URLs
E-commerce and directory websites often create URL parameters for:
Sorting.
Filtering.
Search.
Price ranges.
Categories.
Locations.
These can produce thousands of combinations.
For example:
/cars/?make=BMW&colour=black&sort=price
Some filtered pages may be valuable.
Many are not.
Large websites need a deliberate crawling and indexing strategy.
Do not allow every possible filter combination to become an indexable page by default.
This can create duplication and crawl waste.
Faceted Navigation
Faceted navigation allows users to refine large result sets.
This is useful for:
Online stores.
Vehicle marketplaces.
Property websites.
Directories.
However, every filter combination can create a new URL.
Google provides specific guidance for managing faceted navigation because uncontrolled combinations can create extremely large crawl spaces. (developers.google.com)
Smaller local business sites rarely need complex faceted indexing.
Large marketplace projects should plan it from the beginning.
Pagination
Blogs, products and archives may span several pages.
Pagination should allow users and crawlers to move through the sequence.
Google no longer relies on the historical rel="next" and rel="prev" signals for indexing, but normal crawlable links remain important.
Do not hide page 2 and beyond behind JavaScript-only “load more” behaviour without crawlable URLs if the content needs to be discovered.
Infinite Scroll
Infinite scroll can improve browsing, but search engines and users need accessible pagination or equivalent URLs behind the interface.
If a local marketplace loads more products only through JavaScript and no crawlable paths exist, discovery may be incomplete.
Design the interface for both usability and technical accessibility.
Duplicate Content
Duplicate content occurs when the same or substantially similar information is available at multiple URLs.
Common causes include:
Print versions.
Parameters.
HTTP and HTTPS.
WWW and non-WWW.
Staging sites.
Copied location pages.
Tag archives.
Category archives.
Attachment pages.
Duplicate product variants.
Duplicate content is not automatically a penalty.
The problem is confusion and inefficiency.
Use canonical URLs, redirects and sensible architecture to indicate preferred versions.
WordPress Attachment Pages
WordPress may create individual attachment pages for media files.
These pages often contain very little content.
Depending on the site setup, an SEO plugin may redirect attachment pages directly to the media file or parent page.
Review whether attachment pages provide any meaningful user value.
Do not allow thousands of thin attachment URLs to become part of the indexed site accidentally.
Tag Archives
WordPress tags can be useful when curated carefully.
They can also create hundreds of thin archive pages.
If every blog post has ten one-off tags, the site may generate many weak pages containing only one article.
Use categories and tags intentionally.
If a tag archive provides no unique value, consider whether it needs indexing.
Author Archives
Multi-author publications may benefit from author archive pages.
A small business with one author may produce a duplicate archive similar to the main blog.
Decide whether the author page adds useful information.
An expert author profile can strengthen trust when it includes biography, experience and articles.
A thin archive containing only repeated post titles may not deserve search visibility.
Date Archives
WordPress can generate monthly and yearly archives.
These may be useful for certain publications but often provide little value for local business sites.
Review whether they are needed.
Do not keep every default archive indexable simply because WordPress created it.
Broken Internal Links
Broken links frustrate users and waste crawling.
Common causes include:
Renamed pages.
Deleted posts.
Domain changes.
Incorrect relative links.
Typing mistakes.
Old portfolio URLs.
Changed category structures.
Crawl the site periodically or use a reliable link-checking tool.
Fix the source link rather than relying on redirects forever where practical.
External Broken Links
Blog posts often link to external sources.
Over time, those sources may move or disappear.
Review important evergreen guides periodically.
Replace dead sources with current authoritative references.
Do not leave educational content filled with broken government or documentation links.
Search Console Coverage and Page Indexing
Search Console groups indexing information into categories that may include:
Indexed.
Not indexed.
Redirected.
Blocked.
Duplicate.
Crawled but not indexed.
Discovered but not indexed.
Other reasons.
Do not treat every excluded URL as a problem.
A redirected page should not normally be indexed.
A noindex thank-you page is behaving correctly.
Focus on important URLs that should be indexed but are not.
“Crawled – Currently Not Indexed”
This status can occur when Google crawled a page but did not include it in the index at that time.
Possible reasons can include:
Low-value content.
Duplication.
Temporary processing decisions.
Weak internal linking.
A very new page.
Technical signals.
Do not respond by resubmitting the URL every day.
Review the page objectively.
Is it useful?
Is it unique?
Does it have internal links?
Does it duplicate another page?
Does it deserve to exist?
“Discovered – Currently Not Indexed”
This can mean Google knows the URL but has not crawled it yet.
On small local sites, important pages should usually be discovered and crawled reasonably efficiently if the structure is healthy.
A very large website may face crawl-priority issues.
Check server health, internal links, sitemap quality and the overall number of low-value URLs.
Crawl Budget
Crawl budget is often discussed excessively by small-business SEO providers.
For a normal website with tens or hundreds of pages, it is rarely the main problem.
Google’s detailed crawl-budget guidance is more relevant to very large or frequently changing sites. (developers.google.com)
A 50-page plumbing website does not need an advanced crawl-budget strategy.
Focus on:
Working pages.
Clean navigation.
Sitemaps.
Performance.
No accidental blocks.
Useful content.
Crawl management becomes more important for large e-commerce sites, marketplaces and directories.
Domain Migrations
Changing a domain is a significant technical event.
For example:
oldbrand.co.za
to:
newbrand.co.za
A migration should include:
Mapping old URLs to new URLs.
Permanent redirects.
Updating canonicals.
Updating internal links.
Updating sitemaps.
Updating structured data.
Updating important external profiles.
Updating Search Console properties.
Testing HTTPS.
Testing forms.
Monitoring errors.
Do not simply point every old URL to the new homepage.
Preserve equivalent page relationships.
Website Redesigns
A redesign can damage SEO even when the domain remains the same.
Common causes include:
Changed URLs.
Removed content.
Missing headings.
Lost internal links.
Broken schema.
Slow new layouts.
Noindex tags copied from staging.
Forms breaking.
Missing analytics.
Mobile content being removed.
Before launching, crawl the old site and record important URLs.
After launch, compare.
A visually improved website should not accidentally erase years of search history.
Change of CMS
Moving from one system to another can create structural differences.
For example:
WordPress to a custom React application.
WordPress to Shopify.
Shopify to WooCommerce.
The new platform may use different URL formats.
Plan redirects before launch.
Preserve metadata where useful.
Recreate structured data.
Ensure the new pages render and index properly.
A CMS migration should be treated as both a development and SEO project.
React and JavaScript Applications
Modern React applications can rank, but the implementation matters.
Client-side rendering can delay content availability.
Server-side rendering or pre-rendering can make important public pages easier to access and improve initial performance.
For a large marketplace or SaaS product, determine which pages need search visibility.
A logged-in dashboard generally does not.
Public landing pages, documentation, product pages and location pages may.
Technical architecture should reflect that distinction.
Next.js and Server Rendering
Frameworks such as Next.js can support server rendering, static generation and hybrid approaches.
These can improve the delivery of indexable public content.
Ensure:
Canonical URLs are correct.
Metadata is unique.
Sitemaps update correctly.
Dynamic routes return real 404s when missing.
Redirects are configured properly.
Structured data renders in the final HTML where appropriate.
Hydration does not remove important content.
Framework choice does not replace SEO fundamentals.
Security and SEO
Security is not only an IT issue.
A hacked website can be:
Defaced.
Redirected.
Filled with spam pages.
Used for phishing.
Blocked by browsers.
Removed from search results in severe cases.
Local businesses should maintain:
WordPress updates.
Plugin updates.
Theme updates.
Strong passwords.
Multi-factor authentication where available.
Backups.
Malware monitoring.
Appropriate user permissions.
Secure hosting.
Do not give administrator accounts to every staff member.
WordPress Updates
Outdated plugins and themes can create security and compatibility risks.
Use a controlled update process.
Backup first.
Update in staging where appropriate.
Test critical forms and pages afterwards.
Do not leave commercial plugins unlicensed and unpatched for years.
A stable website is part of the technical SEO foundation.
Backups
A backup should exist before something goes wrong.
A useful backup strategy includes:
Database.
Files.
Offsite copies.
Retention history.
Regular automated schedules.
Periodic restore testing.
A backup that has never been tested may not be usable when needed.
Again, backups are not a direct ranking factor.
They protect the website that generates rankings, leads and business.
Malware and Spam Pages
A hacked WordPress site may generate thousands of pages promoting unrelated products or scams.
Search Console may report unexpected URLs.
Search results may display strange titles.
If this happens:
Take the site out of harm where necessary.
Identify the compromise.
Remove malicious files.
Update software.
Change credentials.
Review user accounts.
Restore from a clean backup where appropriate.
Request security review through relevant Google tools after the problem is resolved.
Do not merely delete visible spam pages while leaving the vulnerability active.
HTTPS Certificate Expiry
Modern certificates often renew automatically.
Renewal can still fail because of DNS, hosting or configuration problems.
An expired certificate can make the site appear dangerous to visitors.
Monitor certificate expiry and renewal.
This is especially important for e-commerce and membership sites.
DNS Reliability
DNS connects a domain name with the servers that provide the website and email.
Misconfigured DNS can take an entire business offline.
Common problems include:
Wrong A records.
Incorrect nameservers.
Broken MX records.
Missing verification records.
Conflicting CNAMEs.
Failed migrations.
DNS changes should be documented and made carefully.
Do not delete unfamiliar records without understanding their purpose.
They may control email, verification or other services.
Local Structured Data and Multiple Locations
A multi-location business should represent each genuine location accurately.
Each branch page may include:
Its address.
Telephone number.
Opening hours.
Map.
Branch-specific LocalBusiness schema.
The overall company may use Organization markup.
Do not create schema for locations that exist only as service areas.
A service area is not automatically a branch.
Geo Coordinates
LocalBusiness schema may include latitude and longitude information.
These should represent the real business location.
Do not manipulate coordinates to appear closer to a desirable suburb.
The map profile and visible address should remain consistent with reality.
Opening Hours Schema
Opening hours in structured data should match:
The website.
Google Business Profile.
Actual business operations.
If the business changes hours seasonally, update the schema when appropriate.
Do not mark a business as open 24 hours because the website accepts online enquiries at any time.
Online form availability is not the same as staffed operating hours.
Breadcrumbs for Local Websites
A good hierarchy might look like:
Home
→ Locations
→ Durban
→ WordPress Web Design
or:
Home
→ Services
→ WordPress Web Design
→ Durban
The best structure depends on the website.
Avoid creating unnecessary nesting purely for SEO.
Breadcrumbs should help users understand where they are.
Local SEO Plugins
WordPress plugins can simplify technical setup.
Popular SEO plugins may provide:
Titles.
Meta descriptions.
XML sitemaps.
Canonicals.
Schema.
Robots controls.
Breadcrumbs.
Social metadata.
Local SEO extensions may provide additional business information.
Plugins are tools.
They do not perform SEO automatically.
Installing an SEO plugin does not optimise service content, earn reviews or create local authority.
Configure the plugin properly.
Avoid Running Multiple SEO Plugins
Running several full SEO suites simultaneously can create conflicts.
Two plugins may both generate:
Titles.
Canonicals.
Sitemaps.
Schema.
Open Graph data.
This can produce duplicate or inconsistent output.
Choose one primary SEO system and add specialised functionality only where needed.
Disable overlapping features where appropriate.
Open Graph and Social Metadata
Open Graph tags control how pages may appear when shared on platforms such as Facebook or LinkedIn.
They can specify:
Title.
Description.
Image.
URL.
This is not directly local ranking optimisation, but strong social previews improve sharing and brand presentation.
Use clear branded images for important pages and articles.
Do not leave every page sharing the same generic image when a specific visual is available.
Favicon and Site Identity
A favicon is a small brand icon shown in browser tabs and potentially in search interfaces.
Use a clear, recognisable version of the logo.
Ensure the site name and Organization markup are consistent.
Small identity details help create a professional branded result.
Technical SEO Audit for a Small Local Business
A beginner-friendly audit can begin with several practical checks.
Open the site on a mobile phone.
Check that it loads securely.
Test the menu.
Call the telephone number.
Use the WhatsApp button.
Submit the contact form.
Check the Google Business Profile website link.
Search Console can then be used to inspect important pages and indexing.
Review the sitemap.
Check robots.txt.
Inspect canonicals.
Check titles.
Test Core Web Vitals and PageSpeed.
Look for broken pages.
Check structured data.
Review SSL.
Test key redirects.
This process will identify many of the technical problems affecting ordinary local business sites.
Technical SEO Audit for WordPress
For WordPress, also check:
Search engine visibility setting.
Permalink structure.
SEO plugin configuration.
Duplicate SEO plugins.
Sitemap output.
Attachment pages.
Tag archives.
Author archives.
Caching.
Plugin count.
PHP version.
Theme and plugin updates.
Admin users.
Backups.
Database size.
Form email delivery.
Image sizes.
Elementor structure.
Third-party scripts.
Staging environment.
A WordPress site can accumulate technical debt over several years.
Periodic cleanup is worthwhile.
Technical SEO Audit for Elementor
For an Elementor site, inspect:
Container nesting.
Unused widgets.
Unused addon packs.
Global fonts.
Global colours.
Responsive visibility settings.
Mobile order.
Custom CSS.
Entrance animations.
Background videos.
Image dimensions.
Popup behaviour.
Header and footer templates.
Sticky elements.
Loop grids.
Dynamic content.
JavaScript errors.
The objective is not to remove Elementor features.
It is to use them deliberately.
Technical SEO Audit for E-Commerce
WooCommerce and other e-commerce websites require additional attention.
Check:
Product URLs.
Category URLs.
Out-of-stock products.
Product schema.
Prices.
Availability.
Cart.
Checkout.
Account pages.
Filter URLs.
Search URLs.
Pagination.
Duplicate variations.
Image performance.
Payment gateways.
Order emails.
The business should decide what happens when a product is permanently discontinued.
If a close replacement exists, a redirect may be suitable.
If the product may return, keeping the page live with an out-of-stock message may be better.
Do not automatically redirect every unavailable product to the homepage.
Technical SEO Audit for Local Marketplaces
Property, automotive and multi-vendor platforms can become much larger than ordinary local sites.
Technical planning should include:
Indexable listing pages.
Expired listings.
Search filters.
Location filters.
Pagination.
Canonical rules.
Duplicate listings.
Vendor pages.
User-generated content.
Sitemaps.
Image handling.
Structured data.
Crawl management.
Expired content policies.
For example, a sold vehicle listing could remain available temporarily with a “sold” status and links to similar vehicles, or it could redirect when there is a meaningful replacement.
The approach should support users as well as indexing.
Logging and Monitoring
Larger websites should monitor:
Server logs.
Application errors.
404 trends.
5xx errors.
Slow requests.
Failed form submissions.
Payment failures.
Search Console alerts.
Security events.
Uptime.
This allows the team to identify problems before customers report them.
Small businesses may use simpler tools, but some monitoring is still valuable.
Technical SEO Does Not Mean Chasing Perfection
A business can waste enormous time trying to achieve:
100/100 scores.
Zero warnings.
Perfect validation across every tool.
The objective is not technical perfection.
The objective is a website that is:
Accessible.
Indexable.
Fast.
Secure.
Stable.
Understandable.
Easy to use.
A warning that has no meaningful effect on users or search visibility may be lower priority than a broken quotation form.
Prioritise according to business impact.
Technical SEO Priority Levels
Critical issues should be handled first.
Examples include:
Website offline.
HTTPS broken.
Entire site blocked from indexing.
Important pages returning errors.
Malware.
Broken checkout.
Broken enquiry forms.
Wrong canonical domain.
Staging site indexed instead of live site.
High-priority issues might include:
Very slow mobile performance.
Large numbers of broken internal links.
Incorrect redirects.
Duplicate indexable location pages.
Important structured-data errors.
Lower-priority issues might include:
Minor image optimisation.
Small metadata warnings.
A few old external links.
Cosmetic performance improvements.
This helps avoid spending hours polishing details while serious problems remain.
A Technical SEO Example for Addweb
Suppose Addweb launches a redesigned WordPress and Elementor website.
The first task is to confirm that:
The live site uses HTTPS.
The WordPress search-engine visibility setting is disabled appropriately for public indexing.
The staging domain remains blocked or protected.
Important pages return HTTP 200.
Old URLs redirect to their closest new equivalents.
The XML sitemap lists the new service and blog URLs.
The sitemap is submitted in Search Console.
Canonicals point to the live domain.
The homepage uses one preferred WWW or non-WWW format.
The local SEO service page is internally linked.
The Durban location page is internally linked.
Forms send correctly.
Telephone and WhatsApp buttons work.
The mobile header functions properly.
Hero images are compressed.
Elementor containers are not excessively nested.
Unused scripts are removed.
Organization and LocalBusiness schema use the correct business identity.
No fake Durban address appears in structured data.
Search Console monitors indexing after launch.
The focus is not one plugin setting.
It is the complete technical pathway from search result to customer enquiry.
Common Technical SEO Mistakes
The first mistake is leaving WordPress set to discourage indexing after launch.
The second is blocking the entire site in robots.txt.
The third is assuming a sitemap guarantees indexing.
The fourth is placing redirected or noindex pages in the sitemap.
The fifth is using incorrect canonical URLs.
The sixth is leaving staging canonicals on a live website.
The seventh is failing to redirect HTTP to HTTPS.
The eighth is ignoring mixed content.
The ninth is redirecting every removed page to the homepage.
The tenth is allowing long redirect chains.
The eleventh is ignoring broken internal links.
The twelfth is focusing on a PageSpeed score instead of usability.
The thirteenth is loading enormous images.
The fourteenth is installing too many overlapping WordPress plugins.
The fifteenth is hiding important mobile content.
The sixteenth is adding incorrect schema.
The seventeenth is allowing multiple plugins to output conflicting schema.
The eighteenth is failing to test forms.
The nineteenth is forgetting to protect staging environments.
The twentieth is redesigning a site without preserving important URLs.
Questions to Ask During a Technical Audit
Can Google crawl the important pages?
Are important pages allowed to be indexed?
Is the correct site version indexed?
Is the staging website protected?
Does the sitemap contain only useful canonical URLs?
Are canonicals correct?
Does HTTP redirect to HTTPS?
Are WWW and non-WWW handled consistently?
Are there redirect chains?
Are important pages returning 404 errors?
Does the website experience server errors?
Does it load quickly on mobile?
Are the Core Web Vitals reasonable?
Are images properly sized?
Are unnecessary scripts loading?
Does the mobile version contain all important information?
Do call buttons work?
Does WhatsApp work?
Do enquiry forms deliver messages?
Is schema accurate?
Do multiple plugins produce conflicting schema?
Are WordPress plugins and themes maintained?
Are backups working?
Is the website monitored?
Have recent migrations been checked?
If a customer arrives from Google now, can they complete the action they came to perform?
Part 9 Quiz
Question 1
What is technical SEO?
Question 2
What is the difference between crawling and indexing?
Question 3
Does every page on a website need to be indexed?
Question 4
Why should important pages have internal links?
Question 5
What can the URL Inspection tool help diagnose?
Question 6
What is the difference between noindex and robots.txt?
Question 7
Can robots.txt protect confidential information?
Question 8
What WordPress setting should always be checked after launch?
Question 9
Why should staging sites be protected?
Question 10
What is an XML sitemap?
Question 11
Should redirects and noindex pages normally appear in an XML sitemap?
Question 12
What does a canonical URL do?
Question 13
Why is canonicalising every page to the homepage dangerous?
Question 14
Why is HTTPS important?
Question 15
What is mixed content?
Question 16
Is WWW better than non-WWW for rankings?
Question 17
When should a permanent redirect be used?
Question 18
Why should unrelated old pages not all redirect to the homepage?
Question 19
What is a redirect chain?
Question 20
Is every 404 error automatically a serious SEO problem?
Question 21
What is a soft 404?
Question 22
Why does uptime matter?
Question 23
What are the three Core Web Vitals used in 2026?
Question 24
What does LCP measure?
Question 25
What does INP measure?
Question 26
What does CLS measure?
Question 27
Should PageSpeed scores be treated as the main business KPI?
Question 28
What common WordPress problems can make a site slow?
Question 29
Why can excessive Elementor nesting be a problem?
Question 30
What should be considered before installing another plugin?
Question 31
What is caching?
Question 32
Can caching break dynamic pages when configured incorrectly?
Question 33
Why should large images be resized?
Question 34
Should the main hero image always be lazy-loaded?
Question 35
Why must mobile content remain equivalent to desktop content?
Question 36
Why should forms be tested regularly?
Question 37
What is LocalBusiness schema?
Question 38
Does schema guarantee rankings?
Question 39
Should a service-area business add a false office address to schema?
Question 40
Why can multiple schema plugins create problems?
Question 41
What is faceted navigation?
Question 42
Why can filter URLs become a technical SEO problem?
Question 43
What is duplicate content?
Question 44
Are WordPress tag archives always useful?
Question 45
What is the biggest technical risk during a redesign?
Question 46
What should happen to old URLs during a domain migration?
Question 47
Can React websites appear in Google Search?
Question 48
Why is website security relevant to SEO?
Question 49
What should be prioritised first during a technical audit?
Question 50
What is the ultimate test of technical SEO?
Quiz Answers
Technical SEO focuses on whether a website can be accessed, crawled, understood, indexed and used reliably.
Crawling is the process of accessing and discovering pages, while indexing is the process of processing eligible pages for potential inclusion in search results.
Utility, account, duplicate and other low-value URLs do not all need indexing.
Internal links help users and search engines discover and understand important pages.
URL Inspection can show indexing status, crawl information and canonical details for a specific URL.
noindex requests exclusion from search results, while robots.txt controls crawling.
Robots.txt is not a security mechanism.
WordPress’s “Discourage search engines from indexing this site” setting should be checked after launch.
A staging site can create duplicate content and may appear in search instead of the live website.
An XML sitemap provides search engines with a list of important URLs and their relationships.
A sitemap should generally contain indexable canonical pages rather than redirects, errors or intentionally excluded URLs.
A canonical identifies the preferred version among duplicate or similar URLs.
It may cause service and location pages to be interpreted as duplicates of the homepage.
HTTPS secures data and creates a trustworthy browsing environment.
Mixed content occurs when an HTTPS page loads insecure HTTP resources.
Neither WWW nor non-WWW has an inherent ranking advantage; consistency matters.
A permanent redirect is appropriate when content has moved permanently or a URL has been replaced.
Redirecting unrelated pages to the homepage creates poor relevance and user experience.
A redirect chain is a sequence of multiple redirects before reaching the final destination.
404s are normal for genuinely missing pages but should not interrupt important customer or linking paths unnecessarily.
A soft 404 is a missing or empty page that incorrectly returns a success response.
Downtime prevents both customers and crawlers from reaching the site.
LCP, INP and CLS.
LCP measures loading of the largest important visible element.
INP measures responsiveness to user interaction.
CLS measures unexpected visual movement.
Performance scores are diagnostics, not the primary business goal.
Large images, excessive plugins, heavy scripts, poor caching and weak hosting are common causes.
Deep or unnecessary nesting increases markup and can make layouts heavier and harder to maintain.
Check necessity, maintenance, compatibility, performance impact and whether existing tools already provide the feature.
Caching stores reusable content so the server can serve pages more efficiently.
Dynamic content such as carts and logged-in areas can break if cached incorrectly.
Correct sizing reduces page weight and loading time.
The main LCP image often benefits from early loading rather than unnecessary lazy loading.
Google uses mobile-first indexing and customers need access to the same essential information on mobile.
Forms can fail because of updates, mail configuration, scripts, caching or server changes.
LocalBusiness schema provides machine-readable information about a genuine local business.
Structured data does not guarantee ranking or rich-result placement.
Structured data must represent the actual business rather than creating fake locations.
Several plugins can produce duplicated or contradictory structured data.
Faceted navigation allows users to filter large sets of products or listings.
Every filter combination can create additional URLs and a very large crawl space.
Duplicate content is substantially similar content accessible at several URLs.
Tags should be used only where their archive pages provide meaningful organisation and value.
Important URLs, content, internal links and metadata can be lost during redesign.
Old URLs should be mapped and permanently redirected to the most relevant new destinations.
React websites can be indexed when public content is implemented in a crawlable and technically accessible way.
A hacked site can produce spam, warnings, redirects and loss of customer trust or search visibility.
Critical failures such as indexing blocks, downtime, malware, broken forms and wrong canonicals should be handled before cosmetic optimisation.
A technically successful website allows a customer arriving from search to access the correct information quickly, securely and reliably and complete the intended action.
Part 9 Summary
Technical SEO creates the infrastructure that allows every other part of local SEO to work properly.
Search engines must be able to crawl and index important pages.
Customers must reach the secure, correct version of the website.
Sitemaps, canonical URLs, redirects, internal links and indexing directives must communicate a consistent site structure.
Mobile performance is especially important because many local searches happen on phones.
Core Web Vitals provide useful measurements of loading, responsiveness and visual stability, but they should be treated as customer-experience diagnostics rather than a competition for perfect scores.
WordPress and Elementor can produce fast, search-friendly websites when built carefully. Problems usually arise from excessive plugins, large assets, duplicated functionality, unnecessary scripts and neglected maintenance rather than from WordPress itself.
Structured data can help search engines interpret organisations, local businesses, products, articles, events and other entities. It must remain truthful and consistent with visible information.
Schema cannot manufacture a branch.
A sitemap cannot guarantee indexing.
A plugin cannot create expertise.
A PageSpeed score cannot replace a working enquiry process.
The technical objective is straightforward: when a customer finds the business through local search, the website should be fast, secure, stable, understandable and ready to help them.
In Part 10, we will move into local content marketing: how to create blog articles, guides, FAQs, local stories, service education, seasonal content and expert resources that strengthen topical authority and attract customers without producing generic SEO filler.
