My staging version at test.site.com is protected with Basic Auth, but server logs show Googlebot still accessing those URLs. Can the bot somehow bypass password protection, or are these just crawl attempts being blocked?

Googlebot CANNOT bypass Basic Auth. It's a reliable server-level protection. Googlebot gets a 401 Unauthorized response and cannot access content. Logs show attempts to access links found on the main site or sitemap. The bot simply gets denied access. For peace of mind, add robots.txt with Disallow: / on the test subdomain and noindex meta tags.

Technical SEO Checklist for Georgia: 14 Requirements Before Launch

Q: PageSpeed Insights gives my mobile version 48 points due to 'unused JavaScript,' but disabling those scripts breaks functionality. What matters more for rankings — speed or functionality?

Short answer: functionality always matters more than a number in PageSpeed Insights. A score of 48 is not a disaster, especially if it's caused by necessary functionality (shopping cart, calculator, forms). Aim for 60–70 — that's already a solid result. Focus on real Core Web Vitals metrics: LCP (< 2.5 sec), INP (< 200 ms), and CLS (< 0.1). A site scoring 60 but with a fast LCP ranks better than a site scoring 90 with a slow LCP.

Q: The W3C validator shows 200+ warnings, mostly from deprecated attributes in a CMS template. Do I need to rewrite all the code, or does Google only care about critical errors like unclosed tags?

Google doesn't look at W3C validity, but at the ability to parse the page correctly. Critical errors (must fix): unclosed tags, incorrect nesting, duplicate IDs, and missing alt tags. Non-critical warnings (deprecated attributes, vendor prefixes) can be left alone. If functionality works and Google sees your content correctly in Search Console, rewriting everything is not necessary.

Q: Text on the site loads via AJAX with a 0.5-second delay for a smooth animation. In Search Console's URL Inspection the text is visible — but will it be indexed with the same weight as content in clean HTML?

Google's official position: the crawler can execute JavaScript, but there are nuances. Google has a limited JS execution timeout — usually around 5 seconds. Your 0.5s delay fits, but two-phase indexing is used: first HTML, then (hours/days later) JS content. We recommend keeping critical content (H1-H6, main text) in clean HTML, using AJAX only for secondary content (reviews, comments).

Q: My blog has 500 articles split across 50 pagination pages. Google only indexes the first 10. Is this a crawl budget issue, or are deep pagination pages simply not supposed to be indexed?

This is typical for large blogs. The issue is Google may lack crawl budget or motivation to index deep pages. Solutions: add all pagination pages to sitemap.xml to signal importance. Improve internal linking: add a paginator with jump links (1, 2, 3 ... 25 ... 50). Boost indexation priority: improve site speed and fix errors that consume crawl budget.

Q: Canonical tags are set correctly on all pages, but Search Console says 'Page is a duplicate, another page was selected.' Why is Google ignoring my canonical and can it be fixed?

This is a common pain point. Important: canonical is a hint, not a directive. Google may ignore your canonical if it thinks another page is a better candidate. Reasons: pages are duplicates, redirects contradict canonical, external links point to another version, or sitemap.xml contains the non-canonical version. Unify all signals: canonical, links, sitemap, and redirects must point to the same version.

Q: I blocked the /admin/ directory in robots.txt, but server logs show Googlebot still accessing those URLs. Does this mean the file isn't working, or does the bot check availability of blocked pages?

Important rule: robots.txt blocks indexation, but NOT crawling (visiting). Googlebot may access the page to check links, redirects, or rules updates. If you need to completely hide content, use password protection (Basic Auth) or the noindex meta tag. In Search Console's 'URL Inspection', seeing 'URL is blocked by robots.txt' means it is configured correctly.

Q: My sitemap has 8,000 URLs, but the recommendation is no more than 50,000. Should I split it into multiple files now, or only when I cross a certain threshold?

With 8,000 URLs you are below the 50,000 limit, but splitting is useful for management. If you have different content types (products, articles, categories) or update frequencies, create separate files. This helps track indexation better in Search Console. If you plan active growth (over 20,000 URLs soon), split the sitemap now to simplify future management.

Q: My site is responsive, but Google Search Console reports 'Content wider than screen' errors on some pages. How do I find the specific elements causing the issue when everything looks fine visually?

Common mobile issue. Use browser mobile emulation (Chrome: F12 + Ctrl+Shift+M), scroll slowly, and look for horizontal scrolling. You can run a console script: document.querySelectorAll('*').forEach(el => { if (el.offsetWidth > window.innerWidth) console.log(el); }); Typical causes: tables without responsive wrappers, fixed-width images, or embedded iframes (video, maps) without responsive containers.

Q: I added Product markup with price and rating, but star ratings aren't appearing in search results. The Schema.org validator shows everything is correct. What determines whether Google will show a rich snippet?

Valid markup ≠ guaranteed rich snippet. Google uses markup as an opportunity, not an obligation. Usually, it takes 2-4 weeks after indexing for rich snippets to appear. For stars, aggregateRating (ratingValue and reviewCount) fields are mandatory. Google might not show ratings if there are few reviews (under 5) or if they look suspicious (all posted on the same day).

Introduction: Why Technical SEO Is the Foundation of Your Online Success

Imagine building a beautiful store in the heart of the city, but forgetting to add an entrance or any signs pointing to it. That's essentially what a website without proper technical optimization looks like — it exists, but search engines can't see it, and potential customers can't find it.

Technical SEO is the foundation on which all of your website's Google promotion is built. It's a set of technical configurations and requirements that allow search engine bots to correctly crawl and index your site, while giving users a smooth browsing experience. Without this base, even the highest-quality content and expensive advertising won't deliver the results you're aiming for.

This article is a technical requirements checklist for launching a new website that will rank well in search engines. We'll break down each aspect in plain language, so you understand not just "what to do" but "why it matters".

1. Setting Up 301 Redirects: One Clear Path to Every Page

What Is a 301 Redirect and Why Do You Need It?

A 301 redirect is a permanent redirect from one page address to another. Think of it as a sign saying "Office has moved to a new address" that automatically sends visitors to the right place.

The problem is that technically the same page can be accessible via multiple addresses. For example:

https://site.com/
http://site.com/
https://www.site.com/
https://site.com/index.html

To Google, these are different pages with identical content — duplicates. This dilutes the page's authority and negatively impacts rankings.

Required Redirects for Your Website

1. Redirects from Index Files

All variants with index.html or index.php should redirect to the clean URL:

From https://site.com/index.html → to https://site.com/
From https://site.com/blog/index.php → to https://site.com/blog/

2. Redirects to HTTPS

In 2026, a website without an SSL certificate is considered bad practice and is viewed negatively by both search engines and users. Google officially uses HTTPS as a ranking factor:

From http://site.com/ → to https://site.com/

3. Redirects for www / non-www

Choose one version (with www or without) and stick to it:

From https://www.site.com/ → to https://site.com/ (or the other way around)

4. Redirects for Trailing Slashes

The key rule here is to choose a single consistent format for your entire website and redirect all variations to the canonical version. Both approaches are technically valid:

Option A (recommended):

Homepage — always WITH a trailing slash: https://site.com/
All other pages — always WITHOUT a trailing slash: https://site.com/blog

Option B:

All pages with a trailing slash

We recommend Option A, but the most important thing is not to mix approaches. If you chose no trailing slash for internal pages, set up a redirect from /blog/ to /blog for all URLs.

Important: Avoid Redirect Chains

A common mistake is setting up multiple sequential redirects:

http://www.site.com/blog/ → https://www.site.com/blog/ → https://site.com/blog/ → https://site.com/blog

That's 4 redirects! Each one slows down loading and may cause search engine bots to simply stop crawling the page. Configure your rules so there's a maximum of 1–2 redirects.

2. Website Loading Speed: Why It's Critically Important

Target Performance Metrics

Google explicitly states that loading speed is a ranking factor, especially through the lens of Core Web Vitals — a set of metrics that measure real user experience. This is particularly important for mobile devices.

Your targets:

PageSpeed Insights: 70–75 points for mobile, 85+ for desktop
TTFB (Time To First Byte): no more than 0.6 seconds
First Interactive (TTI): no more than 3–5 seconds on 4G emulation

How to Measure Speed Correctly

Use two tools:

Google PageSpeed Insights (developers.google.com/speed/pagespeed/insights)
Shows your score and specific improvement recommendations
WebPageTest.org
Set the test location to your target region, enable mobile device emulation and 4G speed. Pay attention to TTFB and First Interactive.

Practical Steps for Faster Load Times

As a starting point after launch:

Connect a CDN (Content Delivery Network) — even the free Cloudflare plan will significantly speed up the delivery of static files
Enable HTTP/3 (QUIC) — by 2026 this is the standard that significantly accelerates loading on mobile networks (or at minimum HTTP/2)
Enable Gzip or Brotli compression for text-based resources
Configure caching for static files (minimum 3 days)

3. HTML Code Validity: Clean Under the Hood

Your website's HTML code should be valid — that is, it should conform to W3C standards. Serious code errors can cause search engine bots to misunderstand the page structure or fail to process it altogether.

How to Check Validity

Use the official validator: validator.w3.org

100% validity isn't always achievable (some modern technologies may trigger warnings), but there should be no critical errors. Google pays attention primarily to structural problems — unclosed tags, incorrect nesting of elements.

4. Content Rendering: What Google Actually Sees on Your Site

Rule: Important Content Must Be in HTML

A common mistake is loading text, headings, or navigation via JavaScript with a delay (AJAX requests). Google's crawler has a very short timeout for executing JS scripts, and it may simply not wait for important content to load.

The right approach: all SEO-relevant content (H1–H6 headings, main body text, links to other pages, meta tags) must be present directly in the page's HTML source code.

Lazy Loading for Images: The Modern Approach

Lazy loading is an excellent technique for speeding up your site. It's easy to implement using modern built-in browser capabilities.

Recommended method: use the native loading="lazy" attribute:

<img src="image.jpg" alt="Description" loading="lazy">

This is a built-in browser feature that is fully supported by Google and requires no additional scripts. Images will only load when the user scrolls down to them.

Important (LCP Exception): Never use loading="lazy" on the first image on the page (main banner, logo, or hero product photo). For that image, use fetchpriority="high" so it loads instantly.

For complex cases: if you need support for older browsers or more granular control (for example, for CSS background images), you can use JavaScript solutions like yall.js, but always verify that your chosen solution is SEO-friendly.

Important: after implementing any form of Lazy Load, always verify correct rendering using the URL Inspection tool in Google Search Console.

5. Pagination: How to Handle Multi-Page Structures Correctly

Pagination is the practice of splitting a long list (products, articles, events) across multiple pages. It's standard practice for blogs and catalogs, but there are many SEO nuances to be aware of.

Core Rules for Pagination

1. Links Must Be Crawler-Friendly

Use standard HTML links:

<a href="/blog/?page=2">2</a>

Do not use JavaScript-only navigation without HTML links.

2. Non-Existent Pages Return 404

If your blog has 50 articles at 10 per page (5 pagination pages total), then:

/blog/?page=6 must return a 404 Not Found status
/blog/?page=qwerty or /blog/?page=-1 must also return 404

3. Avoid Duplicates

The pages /blog/ and /blog/?page=1 contain the same content.

Solution: set up a 301 redirect from /blog/?page=1 to /blog/

The pagination widget itself should not contain a link to /?page=1 — only to the clean URL /blog/.

4. Unique Title and Description for Pagination Pages

Build in the ability to use meta tag templates:

Page 1: "Company Blog — Useful Articles About Digital Marketing"
Page 2: "Company Blog — Page 2 | Digital Marketing Articles"

This helps prevent the duplicate content issues we'll cover in detail in the "Fighting Duplicates" section.

6. Structured Data: Helping Google Understand Your Content

Open Graph is a set of meta tags that define how your page will appear when shared on Facebook, LinkedIn, or in messaging apps.

Required tags:

<meta property="og:title" content="Page Title" />
<meta property="og:description" content="Page Description" />
<meta property="og:image" content="https://site.com/image.jpg" />
<meta property="og:url" content="https://site.com/page" />

Validation: use developers.facebook.com/tools/debug or opengraphcheck.com

Breadcrumbs with Schema.org Markup

Breadcrumbs are navigation trails like:
Home > Services > SEO Promotion

They should be marked up using Schema.org in JSON-LD format:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "Home",
    "item": "https://site.com/"
  },{
    "@type": "ListItem",
    "position": 2,
    "name": "Services",
    "item": "https://site.com/services"
  }]
}
</script>

Important: use Schema.org only, not the outdated data-vocabulary.org.

Validation: search.google.com/structured-data/testing-tool

7. Hreflang and HTML Lang: Working with Multilingual Websites

If your website operates in multiple languages — which is highly relevant for businesses targeting an international audience in Georgia — you need to tell search engines about it correctly.

The HTML lang Attribute

On every page, specify the language of the content in the <html> tag:

<html lang="en"> <!-- for the English version -->
<html lang="ka"> <!-- for the Georgian version -->
<html lang="ru"> <!-- for the Russian version -->

Important: case matters. Correct: en, ka. Incorrect: EN, Ka.

The hreflang Attribute

Hreflang tells Google that you have alternative language versions of a page. According to Google's official documentation, you can specify either just a language code, or a language + region combination.

When the Language Code Alone Is Enough:

In most cases, specifying just the language (ka, ru, en) is sufficient:

<link rel="alternate" hreflang="en" 
  href="https://site.com/en/page" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/page" />
<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/page" />

When to Add a Regional Code:

A regional code (e.g., en-GE, ka-GE) is only added when the content for an audience in a specific country differs significantly from content for speakers of that language in other countries. For example, for a website operating in Georgia:

Prices are in GEL instead of dollars or euros
Local laws, addresses, and realities are referenced
Content is tailored to the local market

<link rel="alternate" hreflang="en-GE" 
  href="https://site.com/en/page" />
<link rel="alternate" hreflang="ka-GE" 
  href="https://site.com/ka/page" />

The x-default Attribute:

x-default is a special hreflang attribute that tells Google which page to show users whose language or region doesn't match any of the specified hreflang values.

How to use x-default:

Option 1: If your business is international (Hotels, IT, Exports)

If you want any visitor — whether French, Japanese, or Swedish — to be able to understand your content, set x-default to the English version.

<link rel="alternate" hreflang="x-default" 
  href="https://site.com/en/" />
<link rel="alternate" hreflang="en" 
  href="https://site.com/en/" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/" />
<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/" />

Option 2: If your business is local (food delivery in Georgia, local services)

If your services are country-specific and you want to show the "original" version, set x-default to the Georgian (primary local) language.

<link rel="alternate" hreflang="x-default" 
  href="https://site.com/ka/" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/" />
<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/" />
<link rel="alternate" hreflang="en" 
  href="https://site.com/en/" />

Self-referencing rule: every page must link to itself. This block of links must be identical across all language versions.

For example, on the English version it looks exactly the same as on the Georgian version:

<link rel="alternate" hreflang="en" 
  href="https://site.com/en/page" />
<link rel="alternate" hreflang="ka" 
  href="https://site.com/ka/page" />
<link rel="alternate" hreflang="ru" 
  href="https://site.com/ru/page" />

8. Fighting Duplicates: One Piece of Content, One URL

Duplicate content is one of the most common technical SEO problems — it dilutes page authority and undermines rankings.

Typical Causes of Duplicate Content

1. Trailing Slashes

As discussed in the redirects section, choose one format and redirect all variations to the canonical version.

2. URL Case Sensitivity

/services and /Services are technically different pages. Always normalize URLs to lowercase.

3. Infinite Slashes

Some websites return a 200 OK response to requests like:
/blog/////article/////

Solution: set up a 301 redirect to the normalized URL.

4. Internal Search Pages

Pages with internal site search results (/search?q=keyword) generate an unlimited number of duplicate URLs. A common issue for many business owners is that these pages end up in the index and compete with key landing pages.

Solution:

Add to <head>:

<meta name="robots" content="noindex, nofollow" />

Block in robots.txt: Disallow: /*?search=

5. GET Parameters with Arbitrary Values

If you have sorting like /catalog?sort=price, then the page /catalog?sort=randomvalue should not return 200 OK — only 404 or a 301 redirect to the default value.

Exception: UTM parameters (e.g., ?utm_source=facebook) can contain arbitrary values — that's fine.

9. Canonical URL: Indicating the Primary Version of a Page

A canonical tag is a special element that tells Google: "If there are several similar pages, this one is the authoritative version."

Key Rules for Using Canonical Tags

1. Every Page Must Have a Canonical

Even if a page is not a duplicate, its canonical should point to itself:

<link rel="canonical" href="https://site.com/page" />

2. Pagination: Canonical Points to Itself

Unlike some older recommendations, we believe each pagination page changes content, so:

/blog/?page=2 → canonical points to https://site.com/blog/?page=2

3. GET Parameters That Don't Affect Content

For UTM parameters and other parameters that don't change content:

/page?utm_source=fb → canonical points to https://site.com/page

4. Always Use Absolute URLs

Incorrect:

<link rel="canonical" href="/page" />

Correct:

<link rel="canonical" href="https://site.com/page" />

5. Always Point to the Primary Domain Version

If both HTTP and HTTPS versions are accessible, the canonical on both should point to the HTTPS version.

10. Website Security: SSL and Vulnerability Protection

SSL Certificate Is Non-Negotiable

In 2026, HTTPS is not an option — it's a baseline requirement. Google explicitly demotes sites without SSL in search results, and browsers display alarming security warnings.

SSL verification:

SSL Labs — you should score no lower than an A grade
htbridge.com — check for correct configuration

Vulnerability Scanning

Always check your site using:

A vulnerable website is not just a hacking risk — it can also lead to Google penalties.

11. Mobile Optimization: Most Traffic Comes from Phones

Mobile-Friendliness Test

Every page on your website should pass the check:
search.google.com/test/mobile-friendly

Content Must Be Identical

A critical rule under Google's Mobile-First Index: content on the mobile and desktop versions must be identical.

This includes:

All H1–H6 headings
Title and Description meta tags
Main body text
Images
Internal links between pages
Structured data markup

On the mobile version, content can be hidden inside tabs or accordions, but it must be present in the page's HTML (not loaded via AJAX).

Prohibited: permanently hiding important content blocks on the mobile version.

12. URL Structure Requirements

What's Allowed in URLs

Before the "?" character:

Latin letters (a–z)
Numbers (0–9)
Hyphens (-)
Underscores (_) — allowed but not recommended

In GET parameters (after "?"):

Latin letters
Numbers
Hyphens
Underscores

What's Not Allowed

Spaces
Periods, commas
Quotation marks
Special characters (#, %, &, except as GET parameter delimiters)
Unicode characters (Cyrillic, Georgian script in URLs, emoji)

Replace all disallowed characters with hyphens or remove them entirely.

URL Stability

Critically important: when page content changes (for example, when renaming a product), the URL must remain the same. URLs should only be changed in extreme cases, and always with a 301 redirect in place.

13. Additional Technical Requirements

H1–H6 Heading Structure

H1 — only one per page (the main heading)
H2–H6 — used strictly for content headings and subheadings
Headings should not be used for navigation menus or site-wide elements

External CSS and JavaScript

Styles go into separate .css files
JavaScript goes into .js files
Minimize the number of external files (combine where possible)
Avoid inline styles

Character Encoding

Use UTF-8 for all pages:

<meta charset="UTF-8">

Frames

Do not use frames (

&lt;frame&gt;

&lt;iframe&gt;

for building site structure) — this is outdated technology that interferes with indexation.

Meta Tag Editing

You must have the ability to:

Edit the Title, Description, Keywords, and H1 for each page individually
Configure meta tag templates for groups of pages of the same type (e.g., all product pages)

ALT Attributes for Images

All meaningful images must have an alt attribute with a descriptive text:

<img src="product.jpg" 
  alt="Red leather sofa in a Scandinavian living room" />

Internal Links

All links to other pages on your site must use <a href="...">
Links must be visible in the HTML (not generated exclusively via JavaScript)
Avoid using rel="nofollow" on internal links

404 Page

Must return HTTP status 404 (not 200 or 302)
Must be styled to match the rest of the site
Must include navigation and a prompt to return to the homepage

Sitemap.xml

Ideally generated automatically
Must pass validation
Must include all main pages (sections, products, articles)
Must not include pagination pages, duplicates, broken links, or noindex pages

Favicon

Must be located in the root of the website (/favicon.ico) and be at least 32×32 pixels in size.

Google Analytics

Install Google Analytics (we recommend via Google Tag Manager) to track the effectiveness of your promotion efforts.

14. Requirements for the Staging / Test Version of the Site

If you're developing a website, always follow these rules for the staging environment:

Location: only on a subdomain of the main site (test.site.com)
Access: login-protected only

Meta robots: on every page

<meta name="robots" content="noindex, nofollow" />

X-Robots-Tag: add to HTTP headers
```
X-Robots-Tag: noindex, nofollow
```

This is critically important to prevent Google from indexing an unfinished version of your site.

Frequently Asked Questions (FAQ)

1. I set up an HTTP to HTTPS redirect, but Search Console shows both versions as separate properties. Does this mean the redirect isn't working, or has Google just not updated its data yet?

This is a normal situation that often confuses website owners.

Google Search Console allows you to add different versions of your site as separate "properties" — HTTP, HTTPS, www and non-www. This doesn't mean the redirect isn't working. Having both versions in Search Console is simply a way to see statistics for old URLs that may still be indexed.

How to verify the redirect is working:

Use an HTTP header checking tool (httpstatus.io)
Enter http://site.com and confirm the server returns status 301 (not 302) with a redirect to https://site.com
In Search Console check the "Coverage" section — the HTTP version should show zero indexed pages a few weeks after the redirect is configured

What to do:

If the redirect is working correctly (code 301), just wait. Google will gradually re-index all pages under the new version
Submit sitemap.xml for the HTTPS version only
Use the "Change of Address" tool in Search Console (if you migrated from one domain to another)

Full transition typically takes between 2 weeks and 2 months, depending on site size.

2. PageSpeed Insights gives my mobile version 48 points due to "unused JavaScript," but disabling those scripts breaks functionality. What matters more for rankings — speed or functionality?

This is one of the most common dilemmas in website auditing.

Short answer: functionality always matters more than a number in PageSpeed Insights.

Detailed explanation:

Google uses speed as a ranking factor, but it's not the only one — or even the most important. A site scoring 48 points with excellent content and a strong user experience will rank better than a site scoring 95 with useless content.

The right strategy:

Don't chase a perfect score. A score of 48 is not a disaster, especially if it's caused by necessary functionality (shopping cart, calculator, forms). Aim for 60–70 — that's already a solid result.
Optimize without breaking functionality:
- Defer loading of non-critical scripts using the defer or async attribute
- Load heavy libraries (maps, social media widgets) only when the user scrolls to them
- Minify JS files
- Use tree-shaking to remove unused portions of libraries
Focus on the actual Core Web Vitals metrics:
- LCP (Largest Contentful Paint) — time to load the main content (target: < 2.5 sec)
- INP (Interaction to Next Paint) — delay after user interaction (target: < 200 ms). This metric officially replaced the deprecated FID in March 2024.
- CLS (Cumulative Layout Shift) — visual stability during loading (target: < 0.1)
These metrics matter more than the overall PageSpeed score.

A site scoring 50–60 with a fast LCP of 2 seconds ranks very well. A site scoring 90 with an LCP of 5 seconds (due to a heavy hero slider) suffers in search results.

3. The W3C validator shows 200+ warnings, mostly from deprecated attributes in a CMS template. Do I need to rewrite all the code, or does Google only care about critical errors like unclosed tags?

Google doesn't look at W3C validity — it looks at its ability to parse the page correctly.

Critical errors (must fix):

Unclosed tags (<div> without a closing </div>)
Incorrect nesting (e.g., a <p> inside another <p>)
Duplicate element IDs
Malformed table structure
Missing required attributes (e.g., alt on important images)

These errors prevent browsers and search bots from correctly understanding the page structure.

Non-critical warnings (can leave):

Deprecated attributes (e.g., align, valign — they work, just not recommended)
Experimental HTML5 elements not recognized by W3C
CSS property warnings
Vendor prefixes

If you have 200 warnings due to deprecated attributes in a CMS template (WordPress, Joomla with a prebuilt theme), there's no need to rewrite everything.

What to do:

Check for critical errors. In the W3C validator report, these are usually highlighted in red.
Fix critical errors (unclosed tags, incorrect nesting).
Check rendering in Search Console. Use the "URL Inspection" tool — if Google correctly sees your content, you're fine.
Don't waste time on cosmetic warnings if the functionality works.

Exception: if you're building a site from scratch, follow modern standards from the start — it will make future maintenance easier.

4. Text on the site loads via AJAX with a 0.5-second delay for a smooth animation. In Search Console's URL Inspection the text is visible — but will it be indexed with the same weight as content in clean HTML?

Google's official position: the crawler can execute JavaScript and index dynamic content, but there are important caveats.

The reality:

Google has a limited JS execution timeout — typically around 5 seconds. Your 0.5-second delay fits within that, but:
- If the page has many scripts, the bot may not wait
- If the delay depends on external factors (slow server, API), the bot may miss the content
Two-phase indexation. Google first indexes the HTML, then returns later (hours or days) to render the JavaScript. If your content is critical for establishing the page's topic, the indexation delay can hurt.
Content weighting. If URL Inspection shows the text, it will get indexed. However, there is no official confirmation that dynamic content carries the same weight as static HTML. We believe any difference, if it exists, is minimal.

Our recommendation:

Business-critical content (H1–H6 headings, main text, the first screen) must be in clean HTML.
Secondary content (reviews, comments, related articles) can be loaded via AJAX.
If the animation is important for UX, keep it, but make sure the content is still present in the HTML in a hidden state (e.g., display: none with an animation-on-appear effect).

How to check:

Open the page in "View Source" mode (Ctrl+U in browser)
Search for the important text (Ctrl+F)
If the text isn't in the source HTML — it's being loaded via JavaScript

If the text is loading via JS and this is critical for your business, consider server-side rendering (SSR) or rework the loading logic.

5. My blog has 500 articles split across 50 pagination pages. Google only indexes the first 10. Is this a crawl budget issue, or are deep pagination pages simply not supposed to be indexed?

This is a typical situation for large blogs and catalogs.

The issue isn't that Google shouldn't index deep pagination pages — it's that it may not have enough crawl budget or motivation to do so. In 2026, Google crawls deep pagination pages even less frequently.

What is crawl budget:

This is the approximate number of pages Google is willing to crawl on your site within a given period. For small sites (under 10,000 pages) this usually isn't an issue, but for large sites it can be.

Why Google stops at page 10 of pagination:

Low value of deep pages. Google understands that most users don't go past page 2–3, so the first pages get indexation priority.
Crawling issues. Check:
- Whether links to deep pagination pages exist in the HTML (not generated only via JavaScript)
- Whether these pages are blocked in robots.txt
- Whether they return a 200 status (not 404 or 302)
Lack of internal linking. If pages 40–50 of pagination have no inbound links except from page 39, Google may not discover them.

Solutions:

Add all pagination pages to sitemap.xml — this signals to Google that they're important.
Improve internal linking:
- Add a paginator with jump links (1, 2, 3 ... 25, 26, 27 ... 48, 49, 50)
- Create an "Article Archive" page with links to all pagination pages
- Add categories or tags that split 500 articles into smaller, more focused groups
Boost indexation priority:
- Improve site speed (slow sites receive less crawl budget)
- Fix all 404 errors, duplicates, and redirect chains — they consume crawl budget
Consider alternatives to classic pagination:
- Infinite scroll with correct implementation (unique URL for each state)
- More granular article categorization

Important: if the first 10 pages are indexed, that's already 100 articles. Make sure the remaining 400 articles are accessible through other site sections (categories, tags, site search).

6. Canonical tags are set correctly on all pages, but Search Console says "Page is a duplicate, another page was selected." Why is Google ignoring my canonical and can it be fixed?

This is one of the most common frustrations among SEO specialists. Let's break down why it happens.

Important to understand: canonical is a hint, not a directive.

Google may ignore your canonical if it believes another page is a better candidate for indexation. This is called a "Google-selected canonical."

Reasons Google might ignore your canonical:

The pages are genuinely duplicated.
- Check whether the content on both pages is identical
- The canonical may be incorrectly set (relative instead of absolute URL)
- The canonical may conflict with other signals (e.g., hreflang)
Redirects contradict the canonical.
If the canonical points to page A, but there's a redirect to page B, Google will get confused
External and internal links point to a different version.
If all links on the site point to /page/, but the canonical specifies /page, Google may choose /page/ as the more popular version
Sitemap.xml contains the non-canonical version.
Make sure sitemap.xml contains only canonical URLs
Mobile and desktop versions differ significantly.
If mobile and desktop versions are very different, Google may choose a different page as the canonical

How to fix it:

Check Search Console → Coverage → "Excluded" → find specific URLs with the "Duplicate, submitted URL not selected as canonical" issue.
Compare both pages (the one you specified in canonical, and the one Google chose):
- Is the content identical?
- Which version has more internal links pointing to it?
- Which version is in sitemap.xml?
Unify all signals:
- Canonical must point to the correct version
- All internal links must point to that version
- Only that version should be in sitemap.xml
- Set up 301 redirects from all alternative versions
Wait. After fixing, Google may take 2–4 weeks to re-index the pages.

When not to worry:

If Google has chosen a canonical that works for you (e.g., HTTPS over HTTP, no trailing slash over with trailing slash) and the content is identical — there's no actual problem. Google simply made the decision for you.

7. I blocked the /admin/ directory in robots.txt, but server logs show Googlebot still accessing those URLs. Does this mean the file isn't working, or does the bot check availability of blocked pages?

Important rule: robots.txt blocks indexation, but does NOT block crawling (visiting).

What this means:

Indexation — adding a page to Google's database with its content.
Crawling — the bot technically visiting the page to check links, redirects, and other signals.

Even when a page is blocked in robots.txt:

Googlebot may still visit it (you'll see this in logs)
Google may check whether robots.txt rules have changed
Googlebot may check redirects from that page

But the page's content will not be indexed.

Verify your robots.txt configuration:

User-agent: *
Disallow: /admin/

Make sure:

The trailing slash (/admin/) covers everything that starts with /admin/
The file is accessible at https://site.com/robots.txt
There are no syntax errors

How to verify robots.txt is working:

Go to Google Search Console → "URL Inspection"
Enter any URL from the /admin/ directory
Click "Test URL"
If you see "URL is blocked by robots.txt" — everything is working correctly

When the block doesn't work:

If there are external links from other websites to a page in /admin/, Google may add it to the index even without crawling — showing only the URL without a description (this is called "soft indexation").

Solution for complete protection:

If you truly need to hide a directory completely:

Block it in robots.txt (against indexation)
Password-protect it via .htaccess or server configuration (against access)
Add to all pages in the directory
```
<meta name="robots" content="noindex, nofollow" />
```
(double protection)

8. My sitemap has 8,000 URLs, but the recommendation is no more than 50,000. Should I split it into multiple files now, or only when I cross a certain threshold?

Google's official limits:

Maximum 50,000 URLs in a single sitemap.xml
Maximum file size — 50 MB (uncompressed)

At 8,000 URLs you're far from the limit, but there are nuances.

When to split your sitemap now:

Different content types.
If you have:
- 3,000 product pages
- 2,000 blog articles
- 2,000 categories
- 1,000 utility pages
It's better to create separate sitemaps for each type:
- sitemap-products.xml
- sitemap-blog.xml
- sitemap-categories.xml
This simplifies management and indexation tracking in Search Console.
Different update frequencies.
- Products updated daily → sitemap-products.xml (submit to Google frequently)
- Articles added weekly → sitemap-blog.xml
- Static pages don't change → sitemap-static.xml
File size approaching 10 MB.
Even with 8,000 URLs, if each entry includes images (<image:image> tags), the file can get large.

When a single file is fine:

If all 8,000 URLs are roughly the same type (e.g., only blog articles)
If the site grows slowly (100–200 pages per year)
If the file is under 5 MB

How to split correctly:

Create a sitemap index file (sitemap-index.xml):

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex 
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://site.com/sitemap-products.xml</loc>
    <lastmod>2026-02-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://site.com/sitemap-blog.xml</loc>
    <lastmod>2026-02-14</lastmod>
  </sitemap>
</sitemapindex>

In Search Console, submit only the index file.

Our recommendation:

If you plan to grow the site actively (more than 20,000 URLs in the coming year), split the sitemap now — it'll simplify management later. If the site is stable, a single file is fine; split it when you reach 15,000–20,000 URLs.

9. My site is responsive, but Google Search Console reports "Content wider than screen" errors on some pages. How do I find the specific elements causing the issue when everything looks fine visually?

A common pain point when working on mobile optimization.

Causes of the "Content wider than screen" error:

Images with a fixed width greater than the viewport
Tables without a responsive wrapper
Blocks with width: 1000px or min-width exceeding the screen size
Elements with negative margin or pixel-based padding
Embedded videos or maps without a responsive wrapper

How to find the problematic element:

Method 1: Mobile device emulation in browser

Open the problematic page in Chrome
Press F12 (Developer Tools)
Press Ctrl+Shift+M (mobile device mode)
Select "iPhone SE" (375px) or "Galaxy S8" (360px) screen size
Slowly scroll from top to bottom
Look for horizontal scrolling — that's your signal

Method 2: Automated search via DevTools

In mobile emulation mode, press Ctrl+Shift+C
Hover over elements — the browser will show their dimensions
Look for elements wider than 360–375px
Check the CSS in the right-hand panel — which property is setting the width

Method 3: JavaScript in the console

Run this script in the browser console (F12 → Console):

let elements = document.querySelectorAll('*');
elements.forEach(el => {
  if (el.offsetWidth > window.innerWidth) {
    console.log('Element wider than screen:', el, 
      'Width:', el.offsetWidth);
    el.style.outline = '3px solid red';
  }
});

This will highlight in red all elements that are wider than the screen.

Typical fixes:

For images:

img {
  max-width: 100%;
  height: auto;
}

For tables:

<div style="overflow-x: auto;">
  <table>...</table>
</div>

For embedded iframes (videos, maps):

<div style="position: relative; 
  padding-bottom: 56.25%; height: 0;">
  <iframe src="..." style="position: absolute; 
    top: 0; left: 0; width: 100%; height: 100%;">
  </iframe>
</div>

After fixing:

Re-test in emulation mode
After 1–2 weeks, use "URL Inspection" in Search Console → request re-indexation
The error should disappear from the "Coverage" report within 2–4 weeks

10. I added Product markup with price and rating, but star ratings aren't appearing in search results. The Schema.org validator shows everything is correct. What determines whether Google will show a rich snippet?

Important to understand: valid markup ≠ guaranteed rich snippet display.

Google treats structured data as an opportunity to show a rich snippet, not an obligation.

Why Google may not show a rich snippet:

Page was recently indexed
- Rich snippets typically appear 2–4 weeks after indexation
- Google rolls out display gradually
Insufficient data in the markup
Required fields for Product markup:
- name — product name
- image — image
- offers with the fields:
  - price — price
  - priceCurrency — currency (GEL, USD)
  - availability — availability
To display star ratings, you also need:
- aggregateRating — average rating
  - ratingValue — score (e.g., 4.5)
  - reviewCount — number of reviews (minimum 1)
Too few reviews
Google may not show stars if:
- Fewer than 5 reviews
- All reviews have the same rating (looks suspicious)
- Reviews were added too quickly (all on the same day)
Rich snippet competition
If 2–3 results for your query already show rich snippets, Google may not show yours in order to diversify the SERP.
Spam or manipulation
Google may ignore markup if:
- The rating shown on the page doesn't match the markup
- Reviews are clearly fake
- Markup is applied to a page that isn't a product (e.g., the homepage)
Regional differences
Rich snippets may display in one region and not in another. Always check SERPs from your target region (use a VPN or the &gl=XX parameter in the search URL).

How to improve your chances of getting a rich snippet:

Verify markup correctness:
Use the Rich Results Test (the latest version of the validator)
Collect genuine reviews:
- At least 5–10 reviews
- Posted on different dates
- With varying scores (mostly 4–5 stars, but some 3-star reviews too)
Ensure markup matches visible content:
- If markup says 4.8 stars, the visible widget on the page must show the same rating
- Price in markup = price on the page
Request re-indexation:
Search Console → URL Inspection → "Request Indexing"
Wait 4–6 weeks after all fixes.

How to check if Google sees your markup:

Search Console → "Enhancements" → "Products"
Here you'll see all pages with Product markup and any errors.

11. My site has three languages: Georgian (primary), Russian, and English. Do I need to add an x-default hreflang tag, and which language version should it point to — Georgian, or should I create a separate language selection page?

It's straightforward. x-default is the page Google will show to any user whose language you haven't covered in your hreflang settings.

The choice of language for this attribute depends entirely on who your primary customer is:

1. Choose ENGLISH for x-default if:

Your site targets the whole world.

Logic: English is the international language. If a Swedish, Japanese, or French visitor arrives, they're more likely to understand English than any other local language.
Who it suits: Hotels, export companies, IT services, international blogs.

2. Choose GEORGIAN (local) for x-default if:

Your business is tied to a specific country.

Logic: Your service is only available in Georgia. If a foreigner searches for something within the country, they should see the "original" version of the site with accurate local data — even if they don't know the language (the browser will offer auto-translation).
Who it suits: City food delivery, local legal services, government services, purely domestic online stores.

3. Choose RUSSIAN for x-default if:

Your audience spans CIS countries.

Logic: If you sell products to, say, Kazakhstan, Armenia, and Uzbekistan, but don't have versions in those national languages, Russian serves as the best common denominator for that region.
Who it suits: Wholesale trade within CIS, regional media resources.

How to decide in 5 seconds:

Ask yourself: "What language does my 'random' visitor speak — the one whose language I haven't accounted for?"

If it's a "citizen of the world" — go with English.
If it's "someone currently in my country" — go with the local language.

Technical rule: always set x-default to a URL that already exists in your hreflang list.

If you decided English is the default — put the English page URL in x-default.
If Georgian — the Georgian page URL.

Additional tips:

Browser language auto-detection:
Use JavaScript to automatically redirect to the appropriate version on the first visit (but don't show a language selection screen every time).
Language switcher on all pages:
The site header should have flags or buttons for switching languages, visible on every page.
Hreflang validation:
Use the Hreflang Tags Testing Tool to verify the configuration is correct.
Search Console:
Check the "International Targeting" section — it will show hreflang errors if any exist.

Mistakes to avoid:

Don't create closed loops: ka only references ka, en only references en — all versions must reference each other
Don't forget self-referencing — every page must reference itself
Make sure all URLs in hreflang are accessible (returning status 200, not 404 or 301)

12. Alt attributes are added to all images, but Google Images doesn't show my photos in image search. Is this an image optimization issue (size, format), or has not enough time passed since indexation?

Google Images is a separate system with its own set of rules. Let's go through all the factors.

Indexation timeline:

For images to appear in Google Images, you typically need:

2–4 weeks for a new website
1–2 weeks for an established site with a good track record

If it's been less than a month, wait.

Ranking factors in Google Images:

Image quality and optimization
- Format: JPEG for photos, PNG for graphics, WebP for modern sites
- Size: minimum 300×300 pixels (800×600 or larger is better)
- File size: no more than 200 KB (optimize via TinyPNG)
- Filename: red-sofa-living-room.jpg, not IMG_12345.jpg
Alt attribute (done right)
Simply adding an alt isn't enough — it must be descriptive and unique:

❌ Bad: alt="Image"
❌ Bad: alt="Product"
✅ Good:
```
alt="Red leather sofa in Scandinavian style"
```
Context around the image
Google looks at:
- The page heading (H1)
- Text surrounding the image (within 50–100 words)
- Caption beneath the image (<figcaption> if using <figure>)
If an image of a sofa appears on a page about tables, Google will be confused.
Technical accessibility
- The image must not be blocked in robots.txt
- The page containing the image must be indexed
- The image must load without errors (not returning 404)
- The image path must be in the HTML (not only via CSS background-image)
Structured data (optional, but it helps)
For products, add structured markup with an image field in JSON-LD format.

How to check image indexation:

URL search:
In Google Images enter: site:site.com/images/
This shows all indexed images from your site.
Search Console:
Unfortunately, Search Console doesn't show image-specific statistics directly, but you can check indexation of the pages where images appear.
Google Lens:
Upload your image to Google Lens — if Google has recognized it, you'll see similar results.

Common problems:

Lazy Load incorrectly implemented — Google can't see images loaded via JavaScript
Duplicate images — the same image used on 10 different pages
Low quality — blurry or tiny images aren't indexed
No image sitemap — create a separate image-sitemap.xml

What to do:

Optimize images (size, weight, file names)
Improve alt attributes (unique, descriptive)
Add context around images (text, headings)
Create an image sitemap
Wait 4–6 weeks
Check via site:site.com/images/ in Google Images

13. Search Console is connected, but it's been showing "Data is being processed" for a week. Is this normal for a new site, or is there an error in the ownership verification setup?

Don't worry — for a new website, this is completely normal.

Typical timelines for data to appear in Search Console:

For a new site (domain less than 3 months old): 7–14 days
For an existing site being reconnected: 2–3 days
For a site after a redesign: 3–5 days

Why it takes so long:

Google needs to:

Discover your site (via sitemap or links from other sites)
Crawl the main pages
Index the content
Accumulate impression and click data

For a new site with no existing search rankings, the process moves more slowly.

How to verify everything is set up correctly:

Ownership verification
Go to Search Console → Settings → "Ownership verification"
There should be a green checkmark with the verification date.

If not, re-verify using one of these methods:
- HTML file
- HTML tag in <head>
- Google Analytics (if the tracking code is already installed)
- Google Tag Manager
Sitemap submitted and processing
Go to "Sitemap" section → enter your sitemap.xml URL → "Submit"
Status should show "Success" (may appear 1–3 days after submission)
Check indexation of individual pages
Use the "URL Inspection" tool:
- Enter your homepage https://site.com/
- Click "Test URL"
- If indexed, you'll see "URL is in Google Index"
If pages aren't indexed yet, click "Request Indexing" to speed things up.
Check robots.txt
Make sure you haven't accidentally blocked the entire site from indexation:

Open https://site.com/robots.txt

Check there's no line like this:
```
User-agent: *
Disallow: /
```
This blocks the entire site. The correct version is:
```
User-agent: *
Allow: /
Sitemap: https://site.com/sitemap.xml
```

What to do if data still hasn't appeared after 2 weeks:

Check indexation via search:
Enter in Google: site:site.com
If at least the homepage shows — the site is in the index, Search Console data will appear later.
Check coverage errors:
Search Console → "Coverage" → if zero pages, check the "Excluded" tab for reasons.
Speed up the process:
- Submit 5–10 main pages via "Request Indexing"
- Create a few quality external links (social media profiles, business directories)
- Make sure you have quality, unique content (not copied from other sites)

When to actually be concerned:

If after 3–4 weeks:

The site:site.com search shows no pages at all
The "Coverage" section in Search Console shows zero pages
All indexing requests are being ignored

Then check:

Whether the domain has penalties (you may have purchased a domain with a bad history)
Whether you're accidentally duplicating content from another one of your sites
Whether there's an aggressive noindex applied across all pages

14. My staging version at test.site.com is protected with Basic Auth, but server logs show Googlebot access attempts. Can the bot somehow bypass password protection, or are these just crawl attempts being blocked?

Googlebot CANNOT bypass Basic Auth.

Basic Authentication (HTTP authorization) is a reliable protection method that operates at the web server level. Googlebot receives a 401 Unauthorized response and cannot access the content.

What you're seeing in your logs:

These are access attempts that are being blocked by the server. Here's what happens:

Googlebot requests a URL: GET https://test.site.com/page
The server checks authorization → finds none → returns status 401
Googlebot receives 401 and leaves (doesn't see the page content)
The server log records the access attempt

Why Googlebot tries to access your staging version at all:

Links from the main site
If somewhere on the main site (site.com) there's a link to the staging version:
```
<a href="https://test.site.com/page">
  Test page
</a>
```
Googlebot will find it and try to crawl it.

Solution: check the main site for any links to the test. subdomain.
Main site's sitemap.xml
If the main sitemap includes URLs from the staging version — remove them.
DNS records are publicly visible
Even if the site is password-protected, the DNS records for test.site.com are visible to everyone. Googlebot may periodically check subdomains of known domains.
External links
If someone accidentally linked to the staging version from another site, Googlebot will try to crawl it.

How to confirm the staging version is protected:

Check the response code
Open an incognito browser window (so saved passwords aren't used) and navigate to https://test.site.com/

You should see a login/password prompt. In DevTools (F12 → Network), check the response code — it should be 401.
Check Google Search Console
If you've added test.site.com as a separate property in Search Console, check the "Coverage" section:
- Should show 0 indexed pages
- All pages should be in the "Excluded" section with the reason "Blocked by authorization"
Check via search
Enter in Google:
```
site:test.site.com
```
If even one page shows up — your protection is misconfigured.

Additional protection measures:

If you want to completely eliminate Googlebot access attempts to the staging version:

Robots.txt on the subdomain:
Create a file at https://test.site.com/robots.txt:
```
User-agent: *
Disallow: /
```

Meta tags on all pages:

<meta name="robots" 
  content="noindex, nofollow">

X-Robots-Tag in HTTP headers:
Configure your server (Apache/.htaccess or Nginx) to send:
```
X-Robots-Tag: noindex, nofollow
```
Lock down by IP whitelist:
If possible, additionally restrict access to only your team's specific IP addresses.

Bottom line:

Googlebot access attempts to your staging version are normal and harmless as long as Basic Auth is properly configured. The bot receives a 401 and leaves without seeing any content. But for complete peace of mind, add robots.txt and noindex as an extra layer of protection.

Conclusion: Technical SEO Is an Investment That Pays for Years

Technical website optimization may seem complex and time-consuming, but it's the kind of foundation you lay once and that works for you indefinitely. Unlike paid advertising, where you pay for every click, a properly configured website attracts organic traffic from Google far more cost-effectively, month after month.

We recommend implementing these requirements at the development stage — fixing errors after the fact costs 3–5 times more. If your site is already live, run a technical audit to identify and resolve critical issues.

Find Out Which Technical Errors Are Preventing Your Website from Reaching Page One of Google

Order a technical SEO audit from us:

✅ We'll identify all duplicate content issues within 48 hours
✅ We'll configure all redirects and canonical tags
✅ We'll implement hreflang for .ge domains

From 500 GEL for 100 pages | ROI within 1.5–3 months

Contact us today:

WhatsApp Telegram +995 591 102 653

SEO Optimization

Get Found on Google

Technical SEO, on-page optimization, and content strategy to rank higher in search results.

This Portfolio: A Deep Dive

The Technology Behind The Scenes

A case study on the Single-Page Application you're using right now, featuring a Firebase backend, a custom CMS, and dynamic SEO.

Landing Page vs. Website?

26.12.2025

Confused about choosing a landing page or a full website? We break down the pros, cons, and best use cases to help you make the right choice for your business in Georgia.

The Art of Keyword Research

A Guide for Businesses in Georgia 01.08.2025

Learn how to find the 'golden' keywords your customers in Georgia are using on Google. A practical guide to boost your SEO and attract ready-to-buy leads.

E-commerce SEO in Georgia: A Market Guide

How to Claim Your Share of a Rapidly Growing Market 12.08.2025

Georgia's e-commerce market is exploding, yet only 3-4% of local companies are online. This guide, based on TBC Capital data, reveals how to use strategic SEO to capture your market share.

The Ultimate Guide to Websites for Businesses in Azerbaijan

20.12.2025

Your competitors are winning clients online. Our complete guide shows you how to build a successful website in Azerbaijan—from real costs in Baku to local SEO secrets.

Technical SEO Checklist for Launching a Website in Georgia: Complete Guide 2026

Introduction: Why Technical SEO Is the Foundation of Your Online Success

1. Setting Up 301 Redirects: One Clear Path to Every Page

What Is a 301 Redirect and Why Do You Need It?

Required Redirects for Your Website

1. Redirects from Index Files

2. Redirects to HTTPS

3. Redirects for www / non-www

4. Redirects for Trailing Slashes

Important: Avoid Redirect Chains

2. Website Loading Speed: Why It's Critically Important

Target Performance Metrics

How to Measure Speed Correctly

Practical Steps for Faster Load Times

3. HTML Code Validity: Clean Under the Hood

How to Check Validity

4. Content Rendering: What Google Actually Sees on Your Site

Rule: Important Content Must Be in HTML

Lazy Loading for Images: The Modern Approach

5. Pagination: How to Handle Multi-Page Structures Correctly

Core Rules for Pagination

1. Links Must Be Crawler-Friendly

2. Non-Existent Pages Return 404

3. Avoid Duplicates

4. Unique Title and Description for Pagination Pages

6. Structured Data: Helping Google Understand Your Content

Open Graph for Social Media

Breadcrumbs with Schema.org Markup

7. Hreflang and HTML Lang: Working with Multilingual Websites

The HTML lang Attribute

The hreflang Attribute

When the Language Code Alone Is Enough:

When to Add a Regional Code:

The x-default Attribute:

8. Fighting Duplicates: One Piece of Content, One URL

Typical Causes of Duplicate Content

1. Trailing Slashes

2. URL Case Sensitivity

3. Infinite Slashes

4. Internal Search Pages

5. GET Parameters with Arbitrary Values

9. Canonical URL: Indicating the Primary Version of a Page

Key Rules for Using Canonical Tags

1. Every Page Must Have a Canonical

2. Pagination: Canonical Points to Itself

3. GET Parameters That Don't Affect Content

4. Always Use Absolute URLs

5. Always Point to the Primary Domain Version

10. Website Security: SSL and Vulnerability Protection

SSL Certificate Is Non-Negotiable

Vulnerability Scanning

11. Mobile Optimization: Most Traffic Comes from Phones

Mobile-Friendliness Test

Content Must Be Identical

12. URL Structure Requirements

What's Allowed in URLs

What's Not Allowed

URL Stability

13. Additional Technical Requirements

H1–H6 Heading Structure

External CSS and JavaScript

Character Encoding

Frames

Meta Tag Editing

ALT Attributes for Images

Internal Links

404 Page

Sitemap.xml

Favicon

Google Analytics

14. Requirements for the Staging / Test Version of the Site

Frequently Asked Questions (FAQ)

1. I set up an HTTP to HTTPS redirect, but Search Console shows both versions as separate properties. Does this mean the redirect isn't working, or has Google just not updated its data yet?

2. PageSpeed Insights gives my mobile version 48 points due to "unused JavaScript," but disabling those scripts breaks functionality. What matters more for rankings — speed or functionality?

3. The W3C validator shows 200+ warnings, mostly from deprecated attributes in a CMS template. Do I need to rewrite all the code, or does Google only care about critical errors like unclosed tags?

4. Text on the site loads via AJAX with a 0.5-second delay for a smooth animation. In Search Console's URL Inspection the text is visible — but will it be indexed with the same weight as content in clean HTML?

5. My blog has 500 articles split across 50 pagination pages. Google only indexes the first 10. Is this a crawl budget issue, or are deep pagination pages simply not supposed to be indexed?

6. Canonical tags are set correctly on all pages, but Search Console says "Page is a duplicate, another page was selected." Why is Google ignoring my canonical and can it be fixed?

7. I blocked the /admin/ directory in robots.txt, but server logs show Googlebot still accessing those URLs. Does this mean the file isn't working, or does the bot check availability of blocked pages?

8. My sitemap has 8,000 URLs, but the recommendation is no more than 50,000. Should I split it into multiple files now, or only when I cross a certain threshold?