Standard Operating Procedure: 1. Technical SEO Optimization Security & Infrastructure

Table of Content

• Purpose & Goals
• Roles & Responsibilities
• Prerequisites / Required Resources
• Detailed Procedure:
  • 1.1 HTTPS Implementation
  • 1.2 Server Configuration
  • 1.3 Domain Configuration
  • 1.4 Site Architecture
• External Web References

Purpose & Goals

This Standard Operating Procedure (SOP) outlines the systematic steps required to implement and maintain essential technical SEO configurations related to website security and infrastructure. The primary purpose of this SOP is to ensure the website adheres to technical SEO best practices that enhance security, improve website performance, and optimize crawlability for search engines.

Main Objectives:

• Enhance Website Security: To implement and maintain HTTPS across the entire website, enforce HTTP Strict Transport Security (HSTS), and optimize TLS versions to protect user data and build trust.
• Improve Website Performance: To configure server settings for optimal speed, including HTTP/2 or HTTP/3 implementation and server-side compression (Gzip/Brotli), and to leverage browser caching through Expires/Cache-Control headers.
• Optimize Crawlability and Indexability: To ensure search engine crawlers can efficiently access and index all important website content by establishing proper domain canonicalization (WWW vs. non-WWW), planning effective site architecture, and optimizing URL structures.
• Maintain Domain Health: To establish procedures for domain expiration monitoring and DNS optimization, ensuring continuous website availability and efficient DNS resolution.
• Establish a Robust Technical SEO Foundation: To create a standardized process for technical SEO aspects related to security and infrastructure, ensuring consistent implementation and ongoing maintenance.

Roles & Responsibilities

Role: Technical SEO Specialist

• Responsibilities:
  • Execute all procedures outlined in this SOP with precision and attention to detail.
  • Utilize specified tools and resources effectively to perform each step.
  • Ensure accurate verification and testing at each stage of the procedures.
  • Maintain documentation of all configurations and changes made as part of this SOP.
  • Proactively monitor website security and infrastructure related to technical SEO, and address any issues or deviations from this SOP.
  • Stay updated with the latest technical SEO best practices and recommend updates to this SOP as needed.
  • Collaborate with web development, server administration, and other relevant teams as necessary to implement and maintain these procedures.

Prerequisites / Required Resources

Software & Tools:

• Web Browsers: Chrome, Firefox, Safari, Edge (or any modern web browser) for website inspection and verification.
• SSL Checker Tools: Online SSL certificate validation tools (e.g., Ultahost SSL Checker, SSL Labs SSL Test).
• HTTP/2 and HTTP/3 Test Tools: Online HTTP protocol version checkers (e.g., KeyCDN HTTP/2 Test).
• Compression Check Tools: Online Gzip/Brotli compression verification tools (e.g., Check Gzip Compression).
• HTTP Header Checkers: Online tools for inspecting HTTP response headers (e.g., Webconfs HTTP Header Check, HSTS Preload List Checker).
• Redirect Checkers: Online tools for verifying HTTP redirects and status codes (e.g., httpstatus.io).
• WHOIS Lookup Tool: Online service for domain registration information retrieval (e.g., WHOIS).
• DNS Speed Test Tools: Online tools for measuring DNS resolution speed (e.g., Dotcom-Tools DNS Speed Test).
• Command-Line Interface (CLI): Terminal (macOS/Linux) or Command Prompt/PowerShell (Windows) for using curl and dig/nslookup commands.
• Text Editor: For editing configuration files (.htaccess, Nginx configuration files, etc.).
• FTP/SFTP Client (Optional): May be required to access and modify server files directly, depending on hosting setup.
• Website Crawling Tool (Optional but Recommended for Audits): Tools like Screaming Frog or Sitebulb for comprehensive website crawling and analysis (for advanced audits and internal link analysis).

Access & Permissions:

• Web Server Access:
  • Administrative access to the web server (Apache, Nginx, etc.) to modify server configurations. This may involve:
    • Direct server access (SSH).
    • Control panel access (cPanel, Plesk, etc.).
    • Access through hosting provider’s interface.
  • Permissions to modify server configuration files (e.g., .htaccess, Nginx server block files, SSL configuration files).
  • Permissions to restart web server services (Apache, Nginx).
• Domain Registrar Account Access:
  • Login credentials for the domain registrar account (e.g., GoDaddy, Namecheap, Google Domains) to manage DNS settings and domain registration.
  • Permissions to modify DNS records (A records, CNAME records, NS records, etc.).
  • Permissions to manage domain auto-renewal and contact information.
• CDN (Content Delivery Network) Access (If Applicable):
  • Login credentials for the CDN provider’s control panel.
  • Permissions to configure CDN settings related to SSL, redirects, HTTP protocol versions, and caching.
• Google Search Console Access:
  • Access to the Google Search Console property for the website to potentially set the preferred domain (legacy setting) and monitor website performance.

Detailed Procedure:

1.1 HTTPS Implementation

Ensuring that a website is served over HTTPS is crucial for security, user trust, and modern SEO best practices. This section details the steps to properly implement and maintain HTTPS.

1.1.1 SSL Certificate Installation

An SSL (Secure Sockets Layer) or TLS (Transport Layer Security) certificate is essential to enable HTTPS. It encrypts communication between the user’s browser and the web server.

Procedure:

1. Verify Current SSL Certificate Status:
   • Tool: Browser (Chrome, Firefox, Safari, Edge), SSL Checker Tools (e.g., https://ultahost.com/ssl-checker)
   • Action: Visit the website’s homepage in a web browser.
   • Check Browser Address Bar:
     • Secure: Look for a padlock icon and https:// at the beginning of the URL. This indicates a valid SSL certificate is likely installed. Click on the padlock to view certificate details and verify it is valid and issued to the correct domain.
     • Not Secure/Warning: If you see “Not Secure”, “http://”, or a warning icon (triangle, red padlock), the website either lacks an SSL certificate, has an expired certificate, or has an improperly installed certificate.
   • Use SSL Checker Tool: Navigate to an online SSL checker tool (e.g., Ultahost SSL Checker). Enter the website’s domain name and run the check.
   • Review Tool Results: The SSL checker will provide detailed information about the SSL certificate, including:
     • Validation: Check if the certificate is valid, properly installed, and trusted.
     • Expiration Date: Note the certificate’s expiration date to ensure timely renewal.
     • Issuer: Identify the Certificate Authority (CA) that issued the certificate.
     • SSL/TLS Version: Verify the version of SSL/TLS supported (TLS 1.2 or higher is recommended).
   • Issue: If the website is not served over HTTPS or the SSL certificate is invalid, expired, or improperly configured, proceed with installation or renewal.
2. SSL Certificate Acquisition (If Needed):
   • Action: If an SSL certificate is required, you will need to obtain one from a Certificate Authority (CA) or through your hosting provider/CDN. Common options include:
     • Let’s Encrypt: A free, automated, and open CA. Ideal for basic SSL needs and widely supported.
     • Commercial CAs: Companies like DigiCert, Sectigo, GlobalSign offer paid certificates with varying levels of validation and features.
     • Hosting Provider/CDN SSL: Many hosting providers and CDNs offer free or paid SSL certificates that can be easily installed through their control panels.
   • Choose Certificate Type: Decide on the appropriate certificate type based on needs:
     • Domain Validation (DV): Basic validation, suitable for most websites. Quick and easy to obtain (like Let’s Encrypt).
     • Organization Validation (OV): Validates the organization’s details in addition to domain ownership. Offers a higher level of trust.
     • Extended Validation (EV): Highest level of validation, displaying a green address bar with the organization’s name in some browsers (though less prominent now).
     • Wildcard SSL: Secures the main domain and all its first-level subdomains (e.g., example.com and *.example.com).
3. SSL Certificate Installation Process:
   • Action: The installation process varies depending on your hosting environment (web server, control panel, CDN). Refer to your hosting provider’s documentation or CDN provider’s instructions for SSL certificate installation. Generally, this involves:
     • Generating a CSR (Certificate Signing Request): This is usually done on your server or through your hosting control panel.
     • Submitting CSR to CA: Provide the CSR to your chosen Certificate Authority.
     • Domain Validation: Complete the domain validation process required by the CA (usually involves DNS record changes or file uploads).
     • Receiving SSL Certificate Files: After successful validation, you will receive the SSL certificate files (typically .crt or .pem file and potentially a chain certificate .ca-bundle).
     • Installing Certificate Files: Upload or paste the certificate files and private key into your hosting control panel, server configuration files (e.g., Apache VirtualHost or Nginx server block), or CDN settings as per their specific instructions.
4. Post-Installation Verification:
   • Tool: Browser, SSL Checker Tools (e.g., https://ultahost.com/ssl-checker)
   • Action: After installation, re-verify the SSL certificate status using the browser and an SSL checker tool (as in step 1). Ensure no errors or warnings are present.
   • Check Certificate Details: Confirm the certificate is issued to the correct domain, is valid, and not expired.

1.1.2 HTTPS Redirection Implementation

Once HTTPS is enabled, it is essential to set up proper redirects from HTTP to HTTPS to ensure users and search engines always access the secure version of the website and to avoid duplicate content issues.

Procedure:

1. Choose a Preferred HTTPS Version (WWW vs. non-WWW):
   • Decision: Decide whether you prefer the www. version (e.g., https://www.example.com) or the non-www. version (e.g., https://example.com) as your canonical HTTPS website. This decision should ideally be consistent with your overall domain canonicalization strategy (see section 1.3 Domain Configuration and 3.1 Canonicalization Management).
   • Consistency is Key: Once you choose, all HTTP and the non-preferred HTTPS versions should redirect to this single, preferred HTTPS version.
2. Implement 301 Redirects:
   • Method: Redirects should be implemented using 301 “Permanent Redirects”. This signals to search engines that the move to HTTPS is permanent, preserving SEO value (link equity).
   • Implementation Location: Redirects are typically configured at the server level. Common methods include:
     • .htaccess (Apache Servers): Use .htaccess file in the website’s root directory.
     • Nginx Configuration: Modify the server block configuration for your website in Nginx.
     • Web Hosting Control Panel: Some hosting providers offer redirect management tools in their control panels.
     • CDN (Content Delivery Network): If using a CDN, some providers allow redirect configuration within the CDN settings.
3. .htaccess Redirect Example (Apache):
   • Action: Edit the .htaccess file in your website’s root directory (create one if it doesn’t exist). Add the following code block (adjust based on your preferred version – example below redirects to non-WWW HTTPS):

apache

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off [OR]
    RewriteCond %{HTTP_HOST} ^www\. [NC]
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NC]
</IfModule>

• Explanation of Code:
  • <IfModule mod_rewrite.c>: Checks if the mod_rewrite module is enabled in Apache (usually is).
  • RewriteEngine On: Enables the rewrite engine.
  • RewriteCond %{HTTPS} off [OR]: Condition: Redirect if HTTPS is OFF (i.e., HTTP is being used) OR
  • RewriteCond %{HTTP_HOST} ^www\. [NC]: Condition: Redirect if the host starts with www. (case-insensitive).
  • RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NC]: Rule: For any request (^), redirect to https:// + the current host (%{HTTP_HOST}) + the requested URI (%{REQUEST_URI}). [L,R=301,NC] are flags: L – Last rule, R=301 – 301 Permanent Redirect, NC – No Case sensitivity.
• Adjust for WWW Preferred: If you prefer the www. version, modify the RewriteRule to explicitly add www. if it’s missing:

4. Nginx Redirect Example:
   • Action: Edit your Nginx server block configuration file for the HTTP site (usually located in /etc/nginx/sites-available/ or similar). Add server blocks for both HTTP and HTTPS, configuring redirects within the HTTP block. Example (redirecting to non-WWW HTTPS):

nginx

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    # ... (SSL certificate configuration and rest of your HTTPS site configuration) ...
}

• Explanation:
  • server { listen 80; … }: This block handles HTTP traffic (port 80).
  • server_name example.com www.example.com;: Specifies the domains handled by this server block.
  • return 301 https://$host$request_uri;: Instructs Nginx to return a 301 redirect to HTTPS, using the requested host ($host) and URI ($request_uri).
  • server { listen 443 ssl; … }: This block configures the HTTPS site (port 443, ssl directive indicates SSL/TLS configuration).

5. Testing Redirects:
   • Tool: Browser, curl command-line tool (or online redirect checkers)
   • Browser Test:
     • Action: Open a web browser and type in the following variations of your website’s URL:
       • http://example.com
       • http://www.example.com
       • https://example.com (if you prefer WWW as canonical, test non-WWW HTTPS version and vice-versa)
       • www.example.com (without http:// or https:// – browsers often default to HTTP initially)
     • Verify Redirection: In each case, confirm that you are correctly redirected to your preferred HTTPS version (e.g., https://example.com or https://www.example.com) and that the browser address bar shows the padlock and https://. Check that the redirect is a 301 (permanent).
   • curl Command-Line Test:
     • Action: Open a command-line terminal (Terminal on Mac/Linux, Command Prompt on Windows). Use the curl -I command to check headers for each URL:

bash

curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com  (if non-WWW preferred)
curl -I https://www.example.com (if WWW preferred)

• Examine Headers: In the output, look for:
  • HTTP/1.1 301 Moved Permanently (or similar indicating 301 status).

Location: https://your-preferred-https-version.com/ (verify the Location header points to your desired HTTPS canonical URL).

1.1.3 HSTS (HTTP Strict Transport Security) Setup

HSTS is a security header that tells browsers to always connect to the website using HTTPS, even if an HTTP URL is entered or clicked. This helps prevent protocol downgrade attacks and reinforces HTTPS security.

Procedure:

1. Verify HTTPS Redirection is Working (Prerequisite): Ensure that proper 301 redirects from HTTP to HTTPS are in place and functioning correctly (as per section 1.1.3). HSTS is effective only when HTTPS is the primary access method.
2. Set the HSTS Header in Server Configuration:
   • Method: HSTS is implemented by setting the Strict-Transport-Security HTTP response header. This is usually configured in the web server (Apache or Nginx).
   • .htaccess (Apache): Add the following line within the <VirtualHost> block for your HTTPS website or in the .htaccess file (ensure it’s applied to the HTTPS site only):

apache

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

• Nginx Configuration: Within the server { listen 443 ssl; … } block of your HTTPS server configuration file, add the following line:

nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

• Header Parameters Explained:
  • Strict-Transport-Security: The header name.
  • max-age=31536000: Specifies the duration (in seconds) for which the browser should remember to only access this domain via HTTPS (31536000 seconds = 1 year). Choose a suitable duration. Consider starting with a shorter max-age for initial testing (e.g., max-age=600 for 10 minutes) and gradually increase it as confidence grows. A full year (31536000) is a common production value.
  • includeSubDomains: (Optional but Recommended) If included, HSTS policy applies to all subdomains of the current domain (e.g., sub.example.com, another.example.com). If you want to enforce HTTPS on all subdomains, include this directive. Be sure that all subdomains are also HTTPS-ready before using this.
  • preload: (Optional but Recommended for Enhanced Security and Browser Preloading) Allows you to submit your domain to the HSTS preload list maintained by browsers. Browsers pre-load this list and will enforce HTTPS for preloaded domains even on the first visit. For production websites, consider adding preload. Important: Ensure your HTTPS configuration is flawless before using preload. Once preloaded, it can be more complex to remove. See https://hstspreload.org/ for details on preloading process and requirements.

3. Test HSTS Header Implementation:
   • Tool: Browser Developer Tools (Network Tab), curl command-line, Online HSTS Checkers (https://hstspreload.org/ for preload status)
   • Browser Developer Tools:
     • Action: Open browser developer tools (Inspect > Network). Visit your HTTPS website.
     • Find Document Request: Select the initial document request (usually the first request listed).
     • Check Response Headers: In the “Headers” tab of the request details, look for the Strict-Transport-Security header under “Response Headers”. Verify that it’s present and has the correct parameters (e.g., max-age, includeSubDomains, preload if you set them).
   • curl Command-Line Test:

bash

curl -I https://example.com

• Examine Headers: Look for the Strict-Transport-Security header in the output.
• Online HSTS Checkers/Preload Status: Use tools like https://hstspreload.org/ to check if HSTS is properly implemented and to verify preload eligibility or current preload status.

4. Consider HSTS Preloading (Optional but Recommended for Production):
   • Action: If you have implemented HSTS with a sufficient max-age, are using includeSubDomains (if applicable), and are confident in your HTTPS setup, consider submitting your domain to the HSTS preload list at https://hstspreload.org/.
   • Review Preload Requirements: Understand the requirements and implications of preloading. Ensure you meet the criteria (sufficient max-age, includeSubDomains if needed, valid HTTPS setup for the domain and subdomains, permanent HTTPS enforcement).
   • Submit Domain for Preloading: Follow the instructions on https://hstspreload.org/ to submit your domain. The process usually involves checking your HSTS header and then submitting your domain for inclusion in the preload list.
   • Check Preload Status: Use https://hstspreload.org/ to check the preload status of your domain. It may take time for changes to propagate to browser updates.

1.1.4 TLS Version Optimization

TLS (Transport Layer Security) is the cryptographic protocol that provides HTTPS encryption. Using modern TLS versions ensures stronger security and potentially better performance.

Procedure:

1. Determine Current TLS Version Support:
   • Tool: SSL Checker Tools (e.g., https://www.ssllabs.com/ssltest/), Browser Developer Tools (Security Tab)
   • SSL Labs SSL Test:
     • Action: Visit the SSL Labs SSL Test (https://www.ssllabs.com/ssltest/). Enter your website’s domain name and run the test.
     • Review Results: The SSL Labs test provides a comprehensive analysis of your SSL/TLS configuration, including:
       • Overall Grade: A letter grade summarizing the SSL/TLS quality (aim for A or A+).
       • Protocols Section: Check the “Protocol Support” section. It lists the TLS versions enabled on your server (e.g., TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, SSL 3, SSL 2).
       • Weak Protocols/Ciphers Warnings: The test will highlight if outdated or weak protocols (like SSL 3, TLS 1.0, TLS 1.1) are enabled and if weak ciphers are supported.
   • Browser Developer Tools (Security Tab):
     • Action: Visit your HTTPS website in a browser (e.g., Chrome). Open developer tools (Inspect > Security tab).
     • View Connection Details: Click “Connection” in the Security overview.
     • Check Protocol: Look for “Protocol” information. It will display the TLS version negotiated for the current connection (e.g., “TLS 1.3”, “TLS 1.2”). This shows the TLS version used for that specific connection. The SSL Labs test provides a broader overview of server capabilities.
2. Optimize TLS Configuration (Disable Outdated Versions, Enable Modern Versions):
   • Goal: Disable support for outdated and insecure TLS versions (SSL 3, TLS 1.0, TLS 1.1) and prioritize modern versions like TLS 1.3 and TLS 1.2.
   • Server Configuration: TLS version configuration is typically done in your web server’s (Apache, Nginx, etc.) SSL/TLS configuration files. The exact file location and syntax depend on your server and operating system.
   • Apache Configuration (Example):
     • Locate SSL Configuration File: Common locations include /etc/apache2/mods-available/ssl.conf, /etc/httpd/conf.d/ssl.conf, or within your VirtualHost configuration.
     • SSLProtocol Directive: Use the SSLProtocol directive to specify the enabled TLS versions. Example to enable TLS 1.2 and TLS 1.3 and disable older versions:
       apache
       SSLProtocol -all +TLSv1.2 +TLSv1.3
3. Cipher Suite Optimization (Strengthen Encryption):
   • Cipher Suites: Cipher suites define the encryption algorithms used for key exchange, bulk encryption, and message authentication during the TLS handshake. Optimizing cipher suites involves selecting strong and secure ciphers and prioritizing them correctly.
   • Tools: SSL Labs SSL Test (https://www.ssllabs.com/ssltest/) will analyze cipher suites. Mozilla SSL Configuration Generator (https://ssl-config.mozilla.org/) provides recommended configurations.
   • Mozilla SSL Configuration Generator:
     • Action: Visit https://ssl-config.mozilla.org/. Choose your web server (Apache, Nginx, etc.), TLS version, and desired security profile (e.g., “Modern”, “Intermediate”, “Old backward compatibility”).
     • Generate Configuration: The tool will generate recommended configuration snippets for cipher suites, HSTS, and other security settings tailored to your choices.
     • Implement Recommended Ciphers: Copy the generated cipher suite configuration into your web server’s SSL/TLS configuration files (e.g., SSLCipherSuite in Apache or ssl_ciphers in Nginx). Important: Always test configurations carefully after changes to avoid server inaccessibility.
4. Re-test and Verify TLS Configuration:
   • Tool: SSL Labs SSL Test (https://www.ssllabs.com/ssltest/)
   • Action: After making TLS and cipher suite configuration changes, re-run the SSL Labs SSL Test (https://www.ssllabs.com/ssltest/) for your website.
   • Review Updated Results:
     • Overall Grade: Verify you are still achieving an A or A+ grade.
     • Protocol Support: Confirm that only TLS 1.2 and TLS 1.3 (or your intended modern versions) are enabled, and older versions (TLS 1.1, TLS 1.0, SSL 3, etc.) are disabled (marked as “No” in the SSL Labs test).
     • Cipher Suites: Check the “Cipher Suites” section to ensure strong and modern cipher suites are prioritized. SSL Labs often indicates cipher strength and security level in its report.

By completing these steps for HTTPS implementation, you will significantly improve your website’s security posture and align with technical SEO best practices. Remember to test thoroughly after each configuration change.

1.2 Server Configuration

Proper server configuration is vital for website speed, crawlability, and overall technical health. This section covers key server-side optimizations.

1.2.1 HTTP/2 or HTTP/3 Implementation

HTTP/2 and HTTP/3 are modern versions of the HTTP protocol that offer significant performance improvements over HTTP/1.1, including multiplexing, header compression, and prioritization. Implementing these protocols can lead to faster page load times and a better user experience.

Procedure:

1. Check Current HTTP Protocol Version:
   • Tool: Browser Developer Tools (Network Tab), curl command-line tool, Online HTTP/2 Test Tools (https://tools.keycdn.com/http2-test)
   • Browser Developer Tools:
     • Action: Visit your website in a browser (Chrome, Firefox, etc.). Open developer tools (Inspect > Network tab). Reload the page.
     • Find Document Request: Select the initial document request (the main HTML document).
     • Check Protocol Column: In the “Protocol” column (you might need to enable this column if it’s not visible by default – right-click on the headers row and select “Protocol”), you will see the protocol version used for the connection (e.g., “h2” for HTTP/2, “h3” for HTTP/3, “http/1.1” for HTTP/1.1).
   • curl Command-Line Test:
     • Action: Use curl with the –head and –http2 flags to specifically request HTTP/2 headers (or –http3 for HTTP/3 if supported by your curl version and server).

bash
Copy
curl --head --http2 https://example.com

# For HTTP/3 (might require specific curl builds and server support)

# curl --head --http3 https://example.com

• Examine Output: Look for headers in the response. If HTTP/2 or HTTP/3 is in use, you will see a response header indicating the protocol, like HTTP/2 200 or HTTP/3 200. If it falls back to HTTP/1.1, you will see HTTP/1.1 200.

• Online HTTP/2 Test Tools:
  • Action: Use online tools like the KeyCDN HTTP/2 Test or similar tools. Enter your website’s URL.
  • Review Test Results: The tools will analyze your website and report whether HTTP/2 or HTTP/3 is detected as being supported and used by your server.

2. Enable HTTP/2 or HTTP/3 on the Server:
   • Prerequisites: HTTPS is required for both HTTP/2 and HTTP/3 in modern browsers. Ensure HTTPS is correctly implemented before enabling these protocols.
   • Web Server Configuration: Enabling HTTP/2 or HTTP/3 typically involves configuring your web server (Apache, Nginx, etc.).
   • Apache (HTTP/2):
     • Module Check: Ensure the mod_http2 module is enabled in Apache. You may need to install and enable it if it’s not already present (e.g., sudo a2enmod http2 on Debian/Ubuntu, check your distribution’s documentation).
     • Protocol Directive: In your Apache VirtualHost configuration for your HTTPS site, add or modify the Protocols directive to include h2 (for HTTP/2) along with http/1.1. Example:

apache
Copy
<VirtualHost *:443>

    ServerName example.com

    # ... other configurations ...

    Protocols h2 http/1.1

• Restart Apache: Restart Apache for the changes to take effect (e.g., sudo systemctl restart apache2 or sudo service apache2 restart).

• Nginx (HTTP/2):
  • Configuration Directive: In your Nginx server { listen 443 ssl http2; … } block for your HTTPS website, include http2 after ssl in the listen directive. Example:

nginx
Copy
server {

    listen 443 ssl http2;

    server_name example.com;

    # ... other configurations ...

}

• Restart Nginx: Restart Nginx (e.g., sudo systemctl restart nginx or sudo service nginx restart).

• HTTP/3 (Currently less common and more complex setup):
  • Server and Library Support: HTTP/3 implementation is newer and requires specific server software and libraries that support the QUIC protocol (on which HTTP/3 is based).
  • Nginx (with QUIC Module): Nginx can be configured with a QUIC module (often requires compiling Nginx with the module). Refer to specific guides and your distribution’s packages if available.
  • CDN Support (Easier Path for HTTP/3): CDNs (like Cloudflare, Fastly) are often early adopters of HTTP/3. Using a CDN might be an easier way to enable HTTP/3 without complex server-side configuration. Check your CDN provider’s documentation for HTTP/3 support.
  • Consider Stability and Browser Support: HTTP/3 adoption is growing but might be less universally supported across all server environments and older browsers compared to HTTP/2. HTTP/2 is generally a safer and more widely compatible choice for immediate performance gains.

3. Verify HTTP/2 or HTTP/3 Implementation After Enabling:
   • Tool: Browser Developer Tools (Network Tab), curl command-line, Online HTTP/2/HTTP/3 Test Tools (as in step 1).
   • Repeat Tests from Step 1: Use browser developer tools, curl, and online tools again to check the HTTP protocol version being used after enabling HTTP/2 or HTTP/3 on your server and restarting the web server.
   • Confirm Protocol Version: Ensure the tests now consistently report “h2” (for HTTP/2) or “h3” (for HTTP/3) in the Protocol column/output for your website when accessed over HTTPS.

1.2.2 Server-Side Compression Setup

Server-side compression (using Gzip or Brotli) reduces the size of text-based resources (HTML, CSS, JavaScript, text-based formats) transmitted from the server to the browser, leading to faster download times and improved page load speed. Brotli generally offers better compression ratios than Gzip, but Gzip is also widely effective.

Procedure:

1. Check Current Compression Status:
   • Tool: Browser Developer Tools (Network Tab), curl command-line tool, Online Compression Check Tools (https://checkgzipcompression.com/)
   • Browser Developer Tools:
     • Action: Visit your website in a browser. Open developer tools (Network tab). Reload the page.
     • Find a Text-Based Resource: Select a text-based resource in the Network tab (e.g., a CSS file, JavaScript file, or the HTML document itself).
     • Check Response Headers: In the “Headers” tab for the resource, look at the “Response Headers” section. Check for these headers:
       • Content-Encoding: gzip – indicates Gzip compression is used.
       • Content-Encoding: br – indicates Brotli compression is used.
     • “Size” Column: Compare the “Size” column (transfer size) and the “Content” or “Decoded” size column. If compression is working, the “Size” (transfer size) will be significantly smaller than the “Content” (decoded) size.
   • curl Command-Line Test:
     • Action: Use curl -I with the -H “Accept-Encoding: gzip, br” header to request compressed content (accepting both Gzip and Brotli).
       • bash
         Copy
         curl -I -H “Accept-Encoding: gzip, br” https://example.com
         
     • Examine Headers: Look for the Content-Encoding header in the response to see if gzip or br is listed.
       • Online Compression Check Tools:
         • Action: Use online tools like Check Gzip Compression or similar tools. Enter your website’s URL and run the check.
         • Review Results: The tool will report if Gzip and/or Brotli compression is detected as being enabled on your server for different resource types. It might also show the compression ratio achieved.
2. Enable Server-Side Compression (Gzip or Brotli):
   • Web Server Configuration: Compression is enabled in your web server configuration.
   • Apache (Gzip – using mod_deflate):
     • Module Check: Ensure mod_deflate is enabled (e.g., sudo a2enmod deflate).
     • .htaccess Configuration (Common): Add the following code to your .htaccess file in the website’s root:

apache
Copy
<IfModule mod_deflate.c>

    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript text/javascript text/css application/json application/ld+json font/woff font/woff2 font/ttf font/otf image/svg+xml

    <IfModule mod_mime.c>

        AddType text/html .html .htm .shtml

    </IfModule>

• VirtualHost Configuration (Alternative): Alternatively, configure mod_deflate within your Apache VirtualHost configuration.
• Restart Apache: Restart Apache for changes to apply.

• Nginx (Gzip – using ngx_http_gzip_module – usually enabled by default):
  • Configuration Directives: In your Nginx http { … } block, server { … } block, or location { … } block, add the following directives. Common to configure in the http block for site-wide compression:

nginx
Copy
gzip on;

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6; # Adjust compression level (1-9, 6 is a good balance)

gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-javascript image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype application/font-woff2 font/woff application/vnd.geo+json application/json application/ld+json application/manifest+json application/x-web-app-manifest+json application/xhtml+xml application/xml; # MIME types to compress

gzip_disable "msie6"; # Disable for IE6 (may be outdated concern now)

gzip_min_length 1000; # Minimum size to compress (in bytes) - avoid compressing very small files which can be counterproductive

• Brotli (Nginx – using ngx_brotli module – often requires installation and compilation):
  • Module Installation: Nginx Brotli module often needs to be installed and compiled separately. Check your OS package manager or compile Nginx from source with the Brotli module.
  • Configuration Directives: Similar to Gzip, configure Brotli directives in your Nginx configuration (often in the http block):

nginx
Copy
brotli on;

brotli_vary on;

brotli_comp_level 6; # Adjust compression level (1-11, 6 is a good balance)

brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-javascript image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype application/font-woff2 font/woff application/vnd.geo+json application/json application/ld+json application/manifest+json application/x-web-app-manifest+json application/xhtml+xml application/xml;

brotli_min_length 1000;

• Choose Gzip or Brotli or Both: Brotli typically gives better compression but may require more server resources for compression. Gzip is widely supported and efficient as well. You can choose to enable Gzip, Brotli, or even configure server to use Brotli when supported by the browser (via Accept-Encoding header) and fallback to Gzip if not.

3. Verify Compression After Enabling:
   • Tool: Browser Developer Tools (Network Tab), curl command-line, Online Compression Check Tools (as in step 1).
   • Repeat Tests from Step 1: Re-run the tests (browser dev tools, curl, online tools) after enabling server-side compression in your web server configuration and restarting the server.
   • Confirm Content-Encoding Header: Verify that you now see Content-Encoding: gzip or Content-Encoding: br (or both if you enabled both and browser supports Brotli) in the response headers for text-based resources.
   • Check “Size” vs. “Content” Size: Confirm that the transferred “Size” of resources is significantly smaller than the decoded “Content” size, indicating effective compression.

1.2.3 Expires Headers Configuration

Expires headers (and Cache-Control: max-age – more modern alternative which can be used together) instruct browsers to cache static assets (images, CSS, JavaScript, fonts) for a specified duration. This reduces the number of requests to the server for repeat visits, leading to faster page loads, especially for returning users.

Procedure:

1. Check Current Expires/Cache-Control Headers:
   • Tool: Browser Developer Tools (Network Tab), curl command-line tool, Online Header Checkers (https://www.webconfs.com/http-header-check.php)
   • Browser Developer Tools:
     • Action: Visit your website in a browser. Open developer tools (Network tab). Reload the page.
     • Find a Static Asset: Select a static resource in the Network tab (e.g., an image, CSS file, JavaScript file, font file).
     • Check Response Headers: In the “Headers” tab for the resource, look for these “Response Headers”:
       • Expires: If present, it specifies an absolute date and time after which the resource is considered expired.
       • Cache-Control: If present, look for directives like max-age=… (specifies cache lifetime in seconds), public (resource can be cached by browsers and intermediate caches like CDNs), private (resource only intended for browser cache, not intermediate caches), no-cache (revalidate with server before using), no-store (do not cache).
   • curl Command-Line Test:
     bash
     Copy
     curl -I https://example.com/images/logo.png
     
     • Examine Headers: Look for Expires and Cache-Control headers in the output.
   • Online Header Checkers:
     • Action: Use online header checker tools. Enter the URL of a static asset (e.g., image URL).
     • Review Results: The tool will display all HTTP response headers, including Expires and Cache-Control.
2. Configure Expires/Cache-Control Headers on Server:
   • Web Server Configuration: Header configuration is done in the server configuration.
   • Apache (using mod_expires and mod_headers):
     • Module Check: Ensure mod_expires and mod_headers modules are enabled (e.g., sudo a2enmod expires headers).
     • .htaccess Configuration (Common): Add to your .htaccess file:

apache
Copy
<IfModule mod_expires.c>

    ExpiresActive On

    ExpiresDefault "access plus 1 month" # Default for all content

    ExpiresByType image/jpg "access plus 1 year"

    ExpiresByType image/jpeg "access plus 1 year"

    ExpiresByType image/png "access plus 1 year"

    ExpiresByType image/gif "access plus 1 year"

    ExpiresByType image/svg+xml "access plus 1 year"

    ExpiresByType text/css "access plus 1 year"

    ExpiresByType text/javascript "access plus 1 year"

    ExpiresByType application/javascript "access plus 1 year"

    ExpiresByType application/x-javascript "access plus 1 year"

    ExpiresByType application/font-woff "access plus 1 year"

    ExpiresByType application/font-woff2 "access plus 1 year"

    ExpiresByType application/vnd.ms-fontobject "access plus 1 year"

</IfModule>

<IfModule mod_headers.c>

    # Recommended Cache-Control (more modern approach, can be used together with Expires)

    <filesMatch ".(ico|jpg|jpeg|png|gif|svg|webp|js|css|swf|eot|ttf|otf|woff|woff2)$">

        Header set Cache-Control "max-age=31536000, public" # 1 year (in seconds), public for CDN caching

    </filesMatch>

• Explanation:
  • ExpiresActive On: Enables mod_expires.
  • ExpiresDefault “access plus 1 month”: Sets a default expiration of 1 month from access time for all file types (if no more specific ExpiresByType rule matches). Adjust this default as needed.
  • ExpiresByType …: Sets specific expiration times for different MIME types. “access plus 1 year” is often used for static assets like images, CSS, JS, fonts, meaning they are considered fresh for 1 year after the first access by a browser and can be cached. “modified plus” is also an option to cache relative to file modification time.
  • Cache-Control header using mod_headers: max-age=31536000 sets cache lifetime to 1 year (in seconds). public allows caching by browsers and intermediary caches (like CDNs). Adjust max-age and public/private/other directives as needed.
• VirtualHost Configuration (Alternative): Configure in VirtualHost files if preferred instead of .htaccess.
• Restart Apache: Restart Apache after configuration changes.

• Nginx (using ngx_http_headers_module – usually enabled by default):
  • expires Directive: In Nginx http { … }, server { … }, or location { … } block, use the expires directive. Example in location block targeting static assets:

nginx
Copy
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff2|woff|ttf|eot)$ {

    expires 1y; # 1 year expiration

    add_header Cache-Control "public"; # Add Cache-Control for clarity and CDN compatibility

    add_header "Pragma" "public"; # For very old browsers that might still rely on Pragma

}

• Explanation:
  • location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff2|woff|ttf|eot)$: This location block applies to URLs ending in common static asset extensions (case-insensitive using ~*). Adjust extensions as needed for your site’s asset types.
  • expires 1y;: Sets Expires header to 1 year from current time. You can use different time units (e.g., 1d for day, 1h for hour, 30m for minutes, epoch for never expire – use cautiously, max).
  • add_header Cache-Control “public”;: Adds the Cache-Control: public header.
  • add_header “Pragma” “public”;: Pragma: public – for older HTTP/1.0 clients (less relevant now but sometimes included for broader compatibility, mainly for very old browsers).

3. Verify Expires/Cache-Control Headers After Configuration:
   • Tool: Browser Developer Tools (Network Tab), curl command-line, Online Header Checkers (as in step 1).
   • Repeat Tests from Step 1: Re-run tests (browser dev tools, curl, online tools) after configuring Expires/Cache-Control headers on your server and restarting the web server.
   • Confirm Expires and Cache-Control Headers: Verify that you now see the Expires header with a date in the future, and Cache-Control header (especially max-age and public if set) in the response headers for static assets you configured.

1.3 Domain Configuration

Correct domain configuration is fundamental for SEO, impacting website accessibility, URL structure, and content organization. This section covers key domain-related settings and best practices.

1.3.1 WWW vs. non-WWW Canonicalization

Choosing and consistently enforcing either the WWW (www.example.com) or non-WWW (example.com) version of your domain as the canonical version is crucial to prevent duplicate content issues and signal your preferred domain to search engines.

Procedure:

1. Determine Preferred Domain Version (WWW or non-WWW):
   • Consider Historical Usage and Branding: Check if your website has historically been known and linked to more often with or without the www. Brand preference can also play a role.
   • SEO Perspective: From a pure SEO standpoint, there’s no inherent advantage to either WWW or non-WWW. The key is consistency. Choose one and stick with it.
   • Technical Considerations (Slightly Favoring Non-WWW in some scenarios):
     • DNS Simplicity: Non-WWW (bare domain) can sometimes have slightly simpler DNS setup, particularly if you are also using a CDN for the root domain itself.
     • Cookie Scope (Minor Factor): Cookies set on a bare domain (non-WWW) are potentially accessible to all subdomains by default, while cookies set on www.domain.com are limited to www. If you heavily use subdomains, non-WWW might offer slightly broader cookie sharing, but this is a very minor technicality in most cases and can be controlled by cookie path/domain attributes.
   • Make a Clear Decision: Document your chosen preferred domain version (e.g., “We will use the non-WWW version, example.com, as our canonical domain”).
2. Implement 301 Redirects to Enforce Canonical Version:
   • Goal: Regardless of whether a user types in or arrives at the non-preferred version (WWW or non-WWW), they should be automatically redirected to your chosen canonical version using a 301 “Permanent Redirect”.
   • Redirect Scenarios:
     • If Non-WWW is Preferred:
       • http://example.com -> https://example.com
       • http://www.example.com -> https://example.com
       • https://www.example.com -> https://example.com
     • If WWW is Preferred:
       • http://example.com -> https://www.example.com
       • http://www.example.com -> https://www.example.com
       • https://example.com -> https://www.example.com
   • Implementation Methods: Redirects are typically set up at the server level using:
     • .htaccess (Apache): Use .htaccess in the website’s root directory.
     • Nginx Configuration: Modify the server block configuration for your website in Nginx.
     • Web Hosting Control Panel: Many hosting panels provide redirect management tools.
     • CDN (Content Delivery Network): Some CDNs allow redirect configuration.
3. .htaccess Redirect Examples (Apache):
   • Non-WWW Preferred Example: Add to your .htaccess file (or VirtualHost if preferred). This example redirects both HTTP and WWW versions to the non-WWW HTTPS version.

apache
Copy
<IfModule mod_rewrite.c>

    RewriteEngine On

    # Redirect HTTP to HTTPS (and Non-WWW Preferred in this example - adjust HTTP_HOST in RewriteRule for WWW if needed)

    RewriteCond %{HTTPS} off [OR]

    RewriteCond %{HTTP_HOST} ^www\. [NC]

    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NC] #Note: This line assumes you want to redirect to the non-WWW of whatever host is used (could be WWW or non-WWW already). To *force* non-WWW, replace %{HTTP_HOST} with your non-WWW domain e.g. example.com

    # Optional: Redundant redirect from WWW HTTPS to Non-WWW HTTPS (if needed for HTTPS versions already accessed via WWW - typically the previous rule handles this)

    #RewriteCond %{HTTPS} on

    #RewriteCond %{HTTP_HOST} ^www\. [NC]

    #RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301] # *Specific* Non-WWW domain here

</IfModule>

• WWW Preferred Example: Modify .htaccess for WWW canonicalization.

apache
Copy
<IfModule mod_rewrite.c>

    RewriteEngine On

    # Redirect HTTP to HTTPS (and WWW Preferred in this example)

    RewriteCond %{HTTPS} off [OR]

    RewriteCond %{HTTP_HOST} !^www\. [NC] # Condition changed: Redirect if *NOT* starting with www.

    RewriteCond %{HTTP_HOST} !^$         # Added: Ensure HTTP_HOST is not empty

    RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NC] # Forcefully prepend www.

    # Optional: Redundant redirect from Non-WWW HTTPS to WWW HTTPS (if needed)

    #RewriteCond %{HTTPS} on

    #RewriteCond %{HTTP_HOST} !^www\. [NC] # Condition changed: Redirect if *NOT* starting with www.

    #RewriteCond %{HTTP_HOST} !^$         # Added: Ensure HTTP_HOST is not empty

    #RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NC] # Forcefully prepend www.

</IfModule>

4. Nginx Redirect Examples:
   • Non-WWW Preferred Example (Nginx Config):

nginx
Copy
# HTTP to HTTPS and Non-WWW preferred (both for HTTP and HTTPS)

server {

    listen 80;

    listen 443 ssl; #Listen for HTTPS too (for initial HTTPS non-WWW access that might be typed in)

    server_name www.example.com example.com; #Both WWW and non-WWW here for redirects

    if ($scheme = http) { # Condition for HTTP requests only

        return 301 https://example.com$request_uri; # Redirect HTTP to HTTPS Non-WWW

    }

    if ($host = www.example.com) { # Condition for WWW domain, for HTTPS or HTTP (though HTTP is already redirected above)

        return 301 https://example.com$request_uri; # Redirect WWW to Non-WWW (HTTPS)

    }

    # The server block for the *canonical* Non-WWW HTTPS site would also be defined separately, typically.

}

# Example separate block for canonical HTTPS non-WWW domain configuration:

server {

    listen 443 ssl;

    server_name example.com;

    # ... (SSL certificate configuration, and other configurations for canonical site) ...

}

• WWW Preferred Example (Nginx Config):

nginx
Copy
# HTTP to HTTPS and WWW preferred

server {

    listen 80;

    listen 443 ssl; # Listen for HTTPS too for initial access

    server_name www.example.com example.com; #Both names, for redirect handling

    if ($scheme = http) {

        return 301 https://www.example.com$request_uri; # Redirect HTTP to HTTPS WWW

    }

    if ($host = example.com) {  #Condition for non-WWW (for both HTTP/HTTPS initial requests as HTTP already redirected above)

        return 301 https://www.example.com$request_uri; # Redirect non-WWW to WWW HTTPS

    }

    # Server block for canonical WWW HTTPS site defined separately...

}

#Example of the canonical WWW HTTPS server block:

server {

    listen 443 ssl;

    server_name www.example.com;

    #... SSL config and other settings for canonical WWW site ...

}

5. Test and Verify WWW vs. non-WWW Redirections:
   • Tool: Browser, curl command-line, Online Redirect Checkers (https://httpstatus.io/)
   • Browser Testing:
     • Action: Test all four variations of your domain in a browser:
       • http://example.com
       • http://www.example.com
       • https://example.com (if non-WWW preferred – test WWW if WWW preferred)
       • https://www.example.com (if WWW preferred – test non-WWW if non-WWW preferred)
     • Verify Redirection and Canonical URL: For each, ensure you are correctly redirected to your chosen canonical HTTPS version (e.g., https://example.com if non-WWW is preferred). Confirm the browser address bar shows the padlock and https:// and the canonical domain version. Verify that the redirect is a 301 (permanent).

curl Command-Line Testing:

bash
Copy
curl -I http://example.com

curl -I http://www.example.com

curl -I https://example.com  (if non-WWW preferred)

curl -I https://www.example.com (if WWW preferred)

• Examine Headers: In the output for each curl command:
  • Verify HTTP/1.1 301 Moved Permanently status code (or similar indicating 301).
  • Check the Location: header points to your chosen canonical HTTPS domain version (e.g., https://example.com or https://www.example.com).

• Online Redirect Checker: Use an online tool like httpstatus.io to test the redirect chain for each of the four URL variations and confirm 301 redirects to the correct canonical HTTPS URL.

6. Update Google Search Console (GSC) Preferred Domain (Legacy Setting – less crucial now, but still good practice):
   • Tool: Google Search Console (GSC) – though Google may be phasing out this specific setting’s direct impact.
   • Action: Go to Google Search Console for your property. Navigate to “Settings” (gear icon in the bottom left) > “Settings” Page. Then, look for “Preferred domain” section (if still visible – Google has been reducing emphasis on this setting). If the option is available, select your preferred domain (either example.com or www.example.com) to reinforce your preference to Google. Note: This setting might become deprecated over time as Google gets better at automatically understanding canonicalization.

1.3.2 Subdomain vs. Subdirectory Decision Making

Deciding whether to organize different sections of your website using subdomains (e.g., blog.example.com, shop.example.com) or subdirectories (e.g., example.com/blog, example.com/shop) is a strategic SEO decision.

Guideline Considerations:

1. Content Thematic Relatedness:
   • Subdirectories (Generally Preferred for closely related content): If the content sections are thematically closely related to your main website’s topic and brand, and they support and enhance the core website’s topical authority, subdirectories are generally the better choice for SEO. They tend to consolidate SEO equity to the primary domain.
   • Subdomains (for Distinctly Themed or Functionally Separate Content): Use subdomains when the content section is thematically distinct or represents a functionally separate entity/application that is somewhat independent of your main website, even if still under the same brand umbrella. Examples:
     • blog.domain.com – If blog content is on very different topics than the main site. (However, often blog content is topically related, making /blog subdirectory better in many cases).
     • careers.domain.com – Job postings are often considered separate content entities.
     • help.domain.com, support.domain.com – Customer support portals, documentation sites, if truly distinct entities.
     • app.domain.com, webmail.domain.com – Web applications or services that are clearly separate functional entities from the marketing website.
     • Different Language Versions (e.g., es.example.com, fr.example.com) – If you are heavily targeting very distinct geographical/linguistic markets with highly localized content, sometimes subdomains can be used, although subdirectories or separate country-code TLDs are often better for international SEO in most cases.
2. Content Volume and Scalability:
   • Subdirectories (Scalable within single domain infrastructure): Subdirectories are highly scalable within your main domain’s infrastructure. Easier to manage from a single website platform.
   • Subdomains (Potential for technical/management overhead): If you foresee very large volumes of content in a particular section that might eventually become almost as large or larger than the main website, and require independent scaling/hosting or management, subdomains could be considered. However, be mindful of the SEO signal dilution and potential technical management complexities of separate subdomains.
3. Brand Perception and User Expectation:
   • Subdirectories (Unified User Experience): Subdirectories typically contribute to a more cohesive and unified user experience, as users remain on the same primary domain.
   • Subdomains (For Distinct Brands or Products under parent company): If the different sections represent somewhat separate brands or product lines under a parent company and you want to maintain a level of perceived separation, subdomains could be used.
4. Link Equity and Authority Flow:
   • Subdirectories (Consolidated SEO Authority): Subdirectories benefit from the SEO authority of the root domain. Backlinks to subdirectory pages generally contribute to the overall authority of your main domain. This consolidated authority can benefit ranking of all content under the main domain.
   • Subdomains (Treated more like Separate Websites by search engines, Diluted Authority): Search engines generally treat subdomains as somewhat separate websites. While subdomains can gain their own SEO authority over time, link equity might not flow as directly or strongly to the main domain as it does with subdirectories. Backlinks to subdomains primarily boost the subdomain’s authority. While links between subdomains and the root domain do help, the signal is often less direct than internal linking within subdirectories of a single domain.
5. Technical Complexity and Management:
   • Subdirectories (Simpler Technical Setup): Generally easier to manage technically, especially with most CMS platforms and hosting setups. Single website platform, often easier SSL certificate management, unified analytics tracking.
   • Subdomains (More Complex Setup in some scenarios): Subdomains can increase technical complexity if you treat them as fully separate websites requiring separate hosting, CMS installations, SSL certificates (wildcard SSL simplifies this now though), analytics setups. Cross-domain tracking for user journeys spanning subdomains may require additional configuration in analytics.
6. Keyword Targeting and Topical Focus:
   • Subdirectories (Organize topically related keywords under main domain): Subdirectories are excellent for organizing content clusters and targeting keyword variations within a focused topical area under your main domain. Example: example.com/product-category/product-page.
   • Subdomains (For significantly different keyword themes, sometimes – but be cautious about signal dilution): In some (less frequent) cases, if the content section targets extremely different primary keyword themes, subdomains have been historically used (e.g., blog.domain.com targeting entirely different keywords than domain.com). However, this practice needs to be carefully weighed against the benefits of consolidating authority under a single domain and modern SEO recommendations often favor subdirectories for topical relatedness.

Decision Making Recommendation:

• Default to Subdirectories: For most websites, especially businesses and organizations, subdirectories are the recommended approach for organizing content sections like blogs, shops, resources, etc., as they generally offer SEO benefits through authority consolidation and are often simpler to manage.
• Use Subdomains Strategically for Truly Distinct Content: Reserve subdomains for sections that are demonstrably and functionally separate from your core website in terms of theme, purpose, application, or branding.

1.3.3 Domain Expiration Monitoring

Ensuring your domain name does not expire is critical. Domain expiration can lead to website inaccessibility, loss of search engine rankings, and potential domain hijacking.

Procedure:

1. Identify Domain Registrar and Account Details:
   • Action: Determine who your domain registrar is (e.g., GoDaddy, Namecheap, Google Domains, etc.) and locate your account login information for managing your domain registrations.
   • If Registrar Unknown: If you are unsure who your registrar is, use a “WHOIS” lookup service (https://www.whois.com/whois, or similar WHOIS tools). Enter your domain name. The WHOIS record typically lists the registrar.
2. Check Domain Expiration Date:
   • Action: Log in to your domain registrar account.
   • Locate Domain Management Section: Navigate to the domain management area where you can view your registered domain names.
   • Find Expiration Date: Look for the “Expiration Date” or “Renewal Date” for your domain. Note this date.
   • Repeat for All Key Domains: If you have multiple domain names (e.g., different TLDs, country-specific domains), check the expiration date for each.
3. Set Up Domain Auto-Renewal (Recommended):
   • Action: In your domain registrar account settings for your domain(s), enable the “Auto-Renewal” feature (if it’s not already enabled by default).
   • Payment Method: Ensure a valid payment method (credit card, PayPal, etc.) is associated with your domain registration account, so auto-renewal can be processed successfully.
   • Check Renewal Period: Confirm the auto-renewal period (e.g., renew for 1 year, renew for multiple years). Longer renewal periods reduce the frequency of needing to manage renewals.
4. Set Up Expiration Reminders (Redundancy):
   • Registrar Reminders (Often Default but Verify): Most registrars send email reminders before domain expiration. Verify that you have email reminders enabled in your registrar account settings and that the contact email address is correct and actively monitored.
   • Calendar Reminders (Manual but Reliable Backup): Set up calendar reminders in your personal or team calendar (e.g., Google Calendar, Outlook Calendar) a few weeks or a month before the domain expiration date as a backup reminder in case registrar emails are missed or filtered.
   • Domain Monitoring Services (Optional, for multiple domains or agency management): For agencies or organizations managing many domains, consider using domain monitoring services. These services actively track domain expiration dates across registrars and send alerts.
5. Regularly Review Domain Status and Payment Information:
   • Periodic Account Check (e.g., Quarterly): Make it a regular task (e.g., quarterly review) to log in to your domain registrar account to:
     • Verify Auto-Renewal Status: Confirm that auto-renewal is still enabled for your domain(s).
     • Check Payment Method: Ensure the payment method is still valid and up-to-date (not expired credit card).
     • Update Contact Information: Verify that your contact email address and other contact details in your domain registration are current so that renewal reminders reach you reliably.
   • Address Renewal Issues Promptly: If you receive any expiration warnings or if auto-renewal fails for any reason (e.g., payment issue), take immediate action to renew the domain manually to prevent expiration.

1.3.4 Domain Name Server (DNS) Optimization

Optimizing your Domain Name Server (DNS) configuration can improve website speed and availability by reducing DNS lookup times. Efficient DNS resolution is a crucial first step in the website loading process.

Procedure:

1. Check Current DNS Provider and Performance:
   • Tool: Online DNS Speed Test Tools (https://www.dotcom-tools.com/dns-speed-test), dig command-line tool (or nslookup)
   • Online DNS Speed Test:
     • Action: Use online DNS speed test tools. Enter your domain name. The tool will query DNS servers from various locations worldwide and measure DNS lookup times.
     • Analyze Results: Review the DNS lookup times from different geographical locations. Ideally, DNS lookup times should be relatively low (under 100-200ms globally is a good target, faster is better). Identify if there are significantly slower DNS responses from certain regions, which might indicate DNS server performance issues or suboptimal DNS provider network.
   • dig Command-Line (or nslookup) – for more technical analysis:
     • Action: Use dig or nslookup command to query DNS directly from your terminal. Example: dig example.com. For specific record types (e.g., NS – Name Server records): dig NS example.com.
     • Examine Query Time: In dig output, look for the “Query time:” value in the “Query time” section at the end. This is the DNS query time from your location to the queried DNS server.
     • Trace DNS Resolution Path (using dig +trace): Use dig +trace example.com to see the complete DNS resolution path and response times from root servers down to your authoritative name servers. This can help identify bottlenecks if any part of the chain is slow.
     • Check Name Server Records (NS Records): Use dig NS example.com to retrieve the Name Server (NS) records for your domain. These NS records list the authoritative DNS servers for your domain (e.g., provided by your DNS hosting provider). Note these name servers.
2. Choose a Reputable and Performant DNS Provider:
   • If Using Default Registrar DNS (often basic): If you are currently using the default DNS name servers provided by your domain registrar, consider switching to a more performant dedicated DNS hosting provider, especially if you are experiencing slow DNS lookup times or want advanced DNS features. Registrar’s default DNS is often adequate for basic setups, but dedicated DNS services usually offer better speed, reliability, and features for performance-critical websites.
   • Dedicated DNS Hosting Providers: Popular and performant DNS hosting providers include:
     • Cloudflare DNS: Free and paid plans, excellent performance, global network, DDoS protection.
     • Amazon Route 53: Highly scalable and reliable, integrates well with AWS ecosystem.
     • Google Cloud DNS: Fast, global anycast network, integrates with Google Cloud Platform.
     • Azure DNS: Microsoft’s Azure cloud-based DNS.
     • DNS Made Easy: Reputable provider known for performance and uptime.
     • Constellix (DNS.net): Focus on DNS performance and reliability.
     • Akamai Fast DNS: Part of Akamai’s CDN and security offerings, high performance.
3. Configure Authoritative Name Servers:
   • Action: Once you’ve chosen a DNS hosting provider and set up an account, you will need to configure your domain to use their authoritative name servers.
   • Obtain Name Server Records from DNS Provider: Your DNS provider will give you a set of name server records (typically 2 or more, e.g., ns1.example-dns-provider.com, ns2.example-dns-provider.com, etc.).
   • Update Name Servers at Domain Registrar: Log in to your domain registrar account. Navigate to the DNS management section for your domain. Find the area to update “Name Servers” (or “DNS Servers”). Replace the current name servers with the name servers provided by your new DNS hosting provider. This process tells the global DNS system to use your new DNS provider’s servers to resolve your domain.
   • DNS Propagation Time: After updating name servers, DNS changes can take some time to propagate across the internet (DNS propagation). This can range from a few minutes to 24-48 hours, depending on DNS caching.
4. Configure DNS Records at DNS Hosting Provider:
   • DNS Hosting Provider Interface: Log in to your DNS hosting provider’s control panel or management interface.
   • Add/Manage DNS Records: Configure essential DNS records for your domain, such as:
     • A Records: Map your domain name (and www subdomain) to the IP address of your web server.
     • CNAME Records: For subdomains (like www, cdn, etc.) to point to other domain names (e.g., for CDN, or for www to point to the non-WWW domain if using non-WWW as primary in DNS).
     • MX Records: For email routing.
     • TXT Records: For verification (e.g., for Google Search Console), SPF/DKIM/DMARC email authentication.
     • AAAA Records: For IPv6 addresses (if your server supports IPv6 and you want IPv6 connectivity).
   • TTL (Time To Live) Values: Set appropriate TTL (Time To Live) values for your DNS records. TTL determines how long DNS resolvers (ISPs, public DNS servers) cache your DNS records. Shorter TTLs (e.g., a few minutes, an hour) allow for faster DNS record updates to propagate, but might increase DNS query frequency to your authoritative servers. Longer TTLs (e.g., hours, days) reduce DNS lookups but make record updates take longer to propagate. Balance based on how frequently your records change.
5. Utilize DNS Features for Performance:
   • Anycast DNS (Typically Provided by Premium DNS Hosts): Choose a DNS provider that uses “Anycast” DNS. Anycast networks route DNS queries to the nearest DNS server from a global network of servers. This reduces latency by serving DNS responses from geographically closer servers. Most of the recommended DNS providers (Cloudflare, Route 53, Google Cloud DNS, etc.) use Anycast.
   • DNSSEC (Domain Name System Security Extensions): Consider enabling DNSSEC for your domain if supported by your DNS provider and registrar. DNSSEC adds cryptographic signatures to DNS records to verify their authenticity and prevent DNS spoofing and tampering. Enhances security, although doesn’t directly impact speed as much.
6. Test and Monitor DNS Performance:
   • DNS Speed Test Tools (Re-test after changes): After switching DNS providers and configuring DNS records, re-run DNS speed tests to see if DNS lookup times have improved. Compare results before and after the changes.
   • Website Speed Monitoring: Monitor your website’s overall speed using performance monitoring tools. Improved DNS resolution contributes to faster TTFB and overall page load times.
   • DNS Monitoring Services (Optional, for uptime and error alerts): Consider using DNS monitoring services that continuously check your DNS configuration for errors, availability, and response times, and alert you to any issues.

By optimizing your domain configuration across these areas, you ensure a strong foundation for your website’s technical SEO, contributing to better crawlability, user experience, and search engine performance.

1.4 Site Architecture

A well-defined site architecture is critical for SEO success. It dictates how your website is organized, how content is interlinked, and how easily users and search engine crawlers can navigate and understand your website.

1.4.1 Information Architecture Planning

Information architecture (IA) is the blueprint of your website’s content structure. Effective IA planning ensures content is organized logically, findable, and meets user needs and SEO goals.

Procedure:

1. Define Website Goals and Target Audience:
   • Website Purpose: Clearly define the primary goals of your website (e.g., e-commerce sales, lead generation, content publishing, brand awareness, community building).
   • Target Audience: Identify your primary target audience(s) – their needs, search intents, technical proficiency, and content consumption preferences.
   • SEO Objectives: Define key SEO objectives – what keywords and topics are you targeting? What kind of search visibility are you aiming for?
2. Content Inventory and Audit (If Existing Website):
   • Catalog Existing Content: For an existing website, create a comprehensive inventory of all existing pages, content types (e.g., product pages, blog posts, articles, landing pages, media files), and their current URLs. Tools like Screaming Frog crawl export, sitemaps, and content audits can be helpful.
   • Content Audit (Qualitative Assessment): Evaluate existing content for:
     • Relevance: How well does it align with website goals and target audience needs?
     • Quality: Is the content high-quality, accurate, comprehensive, and engaging?
     • SEO Performance: Check current rankings, organic traffic, and on-page optimization levels for key pages. Identify high-performing and underperforming content.
     • Duplicate Content Issues: Identify potential areas of duplicate or very similar content that might need consolidation or canonicalization.
     • Content Gaps: Identify topics or content areas that are missing but are relevant to website goals and target audience interests.
3. Keyword Research and Topic Clustering:
   • Keyword Research: Conduct thorough keyword research to identify relevant keywords your target audience uses to search for products, services, information, or solutions you offer. Use keyword research tools (e.g., Google Keyword Planner, SEMrush, Ahrefs, Moz Keyword Explorer). Focus on:
     • Topic Relevance: Keywords closely related to your core business, industry, and content.
     • Search Volume: Keywords with reasonable search volume to drive traffic.
     • Keyword Intent: Understand the search intent behind keywords (informational, navigational, transactional, commercial investigation).
     • Long-Tail Keywords: Identify longer, more specific keyword phrases.
   • Topic Clustering/Content Siloing: Group related keywords and content ideas into logical topic clusters or silos. These clusters will form the basis for your website sections and categories. For example, if you sell coffee:
     • Cluster 1: “Coffee Beans” (keywords: buy coffee beans, best coffee beans, arabica beans, robusta beans, specific bean origins, etc.)
     • Cluster 2: “Coffee Makers” (keywords: best coffee maker, drip coffee maker, espresso machine, French press, pour over, reviews of coffee makers, etc.)
     • Cluster 3: “Coffee Brewing Guides” (keywords: how to brew coffee, best brewing methods, coffee recipes, cold brew guide, espresso brewing, etc.)
4. Define Website Sections and Categories:
   • Top-Level Sections: Based on your topic clusters and website goals, define the major sections or categories of your website. These will often become your main navigation menu items and top-level subdirectories (or subdomains if strategically justified). Examples for an e-commerce site: “Shop”, “Blog”, “About Us”, “Contact”. For a SaaS site: “Products”, “Solutions”, “Pricing”, “Resources”, “Company”.
   • Subcategories: Within each top-level section, identify logical subcategories. For “Shop” -> “Coffee Beans” -> “Arabica Beans”, “Robusta Beans”, “Blends”, “Single Origin”. For “Blog” -> “Brewing Guides”, “Coffee Types”, “Equipment Reviews”, “Coffee Culture”.
   • Hierarchy Planning: Create a hierarchical structure for your website sections and categories. Visual tools like sitemap generators or mind mapping tools can be helpful to map out the IA visually.
5. User Journey and Navigation Planning:
   • Map User Flows: Consider common user journeys on your website. For example, in e-commerce: Homepage -> Category Page -> Product Page -> Cart -> Checkout. For a blog: Homepage -> Category Page -> Article Page -> Related Articles.
   • Navigation Paths: Plan clear navigation paths for users to easily find the information they need. Consider:
     • Main Navigation Menu (Header): Prominent, intuitive main navigation menu with top-level categories.
     • Footer Navigation: Links to important pages (About Us, Contact, Privacy Policy, Terms of Service), potentially subcategories or popular content.
     • Breadcrumbs: Implement breadcrumbs to show users their current location within the site hierarchy and enable easy navigation up levels.
     • Internal Linking (Contextual): Strategic internal links within content to guide users to related and relevant pages.
     • Search Functionality: Implement a robust site search, especially for larger websites.
     • Filtering and Sorting (for e-commerce or large content lists): Implement faceted navigation and sorting options for product listings, blog posts, etc.
   • Click Depth Optimization: Plan the IA so that important content is reasonably accessible within a few clicks from the homepage (flat architecture considerations, see 1.4.2).
6. URL Structure Planning (aligned with IA – see 1.4.4):
   • Logical and Keyword-Rich URLs: Plan URL structures that reflect your IA hierarchy, are human-readable, and ideally incorporate relevant keywords. (Details in section 1.4.4).
   • URL Consistency: Establish consistent URL conventions across your website.
7. Taxonomy Definition and Tagging (see 1.4.7):
   • Taxonomies for Organization: Plan site taxonomies (categories, tags, custom taxonomies in CMS like WordPress) to further organize and classify content within sections. This aids content findability and internal linking. (Details in section 1.4.7).
8. Iterative Refinement and Testing:
   • Usability Testing (User Feedback): After initial IA implementation, conduct usability testing with representative users to evaluate if the structure is intuitive, findable, and meets user needs. Gather user feedback.
   • Analytics Monitoring: After launch, monitor website analytics (bounce rates, time on page, pageviews per visit, navigation paths in user flow reports) to identify if users are easily navigating the website or encountering navigation issues.
   • SEO Performance Tracking: Track keyword rankings and organic traffic to pages in different sections to assess if the IA is effectively supporting SEO goals.
   • Iterative Adjustments: Be prepared to refine and adjust your IA based on user feedback, analytics data, SEO performance, and evolving business needs over time. IA is not static; it should adapt as your website and content grow.

1.4.2 Flat vs. Deep Architecture Decisions

Website architecture can be broadly categorized as “flat” or “deep,” referring to the number of clicks it takes to reach content from the homepage. Choosing between these approaches impacts crawlability, user experience, and SEO.

Guideline Considerations:

1. Understanding Flat vs. Deep Architectures:
   • Flat Architecture (Fewer Clicks): Important content is closer to the homepage, often accessible within 2-3 clicks from the homepage. Fewer hierarchical levels in the URL structure. e.g., example.com/category-a/, example.com/product-b/, example.com/blog-post-c/ (all sections relatively close to the root).
   • Deep Architecture (More Clicks): Important content is buried deeper in the site hierarchy, requiring more clicks (4+ clicks) from the homepage. More hierarchical URL structure. e.g., example.com/section/subsection/category/subcategory/product-page/ (many levels deep).
2. SEO Implications of Architecture Depth:
   • Crawlability: Search engine crawlers prefer and more efficiently crawl websites with flatter architectures. Fewer clicks to reach content means crawlers can discover and index more of your site’s pages more readily, potentially improving indexation and crawl budget utilization. Deep architectures can make it harder for crawlers to find and index deeply buried content.
   • Link Equity Distribution (PageRank): In a flat architecture, link equity (PageRank) from the homepage and top-level pages tends to flow more easily and strongly to pages closer to the surface (deeper pages receive less relative link equity due to distance from homepage). Flat structures can distribute homepage authority more broadly.
   • User Experience (Navigation and Findability): Flat architectures generally make it easier for users to find key content and navigate the website efficiently. Fewer clicks to reach desired information, better for usability and user satisfaction, especially on mobile devices. Deep architectures can make navigation more cumbersome and users may get lost if not carefully planned.
   • Relevance Signals (Topical Siloing): Both flat and deep architectures can support topical siloing if implemented correctly with internal linking strategies within content clusters. Deep hierarchies are not inherently necessary for effective siloing; flat structures can achieve siloing via well-organized sections and categories linked through navigation and content.
3. Factors Influencing Flat vs. Deep Choice:
   • Website Size and Content Volume:
     • Smaller Websites (often benefit from flatter): For smaller websites with a limited number of pages, a flatter structure is often more effective. Easier to maintain, improves crawlability, and keeps important content readily accessible.
     • Large and Complex Websites (might need some level of hierarchy, but avoid excessive depth): Larger websites with extensive content libraries (e-commerce sites with many product categories, large content portals) may require some level of hierarchy to organize content effectively. However, strive to keep the most important content (top-selling products, key service pages, high-value informational pages) relatively flat (within 2-3 clicks) and avoid unnecessary depth.
   • Content Interrelatedness:
     • Closely Related Content (flatter often suitable): If your website’s content sections are closely interrelated thematically and serve a relatively focused audience, a flatter architecture can work well to highlight all important sections readily.
     • Distinct and Independent Content Sections (might justify deeper hierarchy or subdomains strategically): If content sections are more thematically distinct or represent separate entities (as discussed in 1.3.2 for subdomains), a somewhat deeper architecture within those sections might be justified (though still aim for reasonable flatness within each section itself), or consider subdomains if truly separate.
   • User Intent and Navigation Needs: Consider typical user journeys and what information users need quickly. Prioritize access to high-demand or conversion-focused content in a flatter manner. For less frequently accessed or supplementary content, a deeper structure might be acceptable.
4. Recommended Approach (Hybrid – Favoring Flatter Structure):
   • Strive for a Primarily Flat Architecture for Important Content: Aim to keep your most important pages (homepage, primary service/product categories, key conversion pages, high-value informational content) within 2-3 clicks from the homepage. This improves crawlability and user findability for critical content.
   • Use Moderate Depth for Less Critical or Granular Content: For less crucial or highly granular/detailed content (long-tail blog articles, less popular product variations, very detailed documentation), some degree of depth might be acceptable (3-4 clicks, potentially deeper for archive content). But still, avoid unnecessary clicks and keep overall depth reasonable.
   • Category Pages as Hubs: Use category pages as important “hub” pages within your structure. Ensure category pages are well-linked to from the homepage and internal navigation, and that they effectively link out to relevant subcategories and individual content items.
   • Prioritize Internal Linking (Contextual and Navigational): Regardless of flat or deep, robust internal linking is crucial. Use strategic internal links from higher-authority pages to important deeper pages to improve their discoverability, crawlability, and link equity. Navigation menus and contextual in-content links are key.
   • Click Depth Analysis and Monitoring: Periodically analyze click depth of your important pages (using crawl data or website analytics that can track navigation paths) to ensure key content is not too buried and adjust architecture as needed. Aim to reduce click depth for pages that should have higher visibility.

1.4.3 Category Depth Optimization

Category pages are essential for organizing content and improving navigation. Optimizing category depth involves strategically deciding how many levels of categories and subcategories to use, balancing content organization with crawlability and user experience.

Guideline Considerations:

1. Define Category Levels Based on Content Volume and Granularity:
   • Start with Broad Top-Level Categories: Begin by defining broad, primary categories that represent the main sections of your website (as planned in IA, 1.4.1). These become your top-level navigation items.
   • Subcategories Only When Necessary for Organization: Introduce subcategories only when the content within a top-level category becomes large and diverse enough to warrant further subdivision for better user navigation and organization. Avoid creating subcategory levels for the sake of hierarchy if the content volume doesn’t justify it.
   • Granularity Matching User Search Behavior: Subcategory levels should ideally reflect how users naturally categorize information in their minds and how they search for content related to your domain. Align category structure with typical user search queries and logical topic groupings.
   • Avoid Excessive Category Depth: Generally, aim for no more than 2-3 levels of categories (including top-level category and subcategories). Excessive category depth (e.g., Category -> Subcategory -> Sub-subcategory -> Sub-sub-subcategory) can make navigation cumbersome, dilute link equity flow within categories, and create overly complex URL structures. Deeper is not always better; simpler is often more effective.
2. Category Page Optimization:
   • Unique and Optimized Category Page Content: Each category page should be a valuable, unique landing page with:
     • Descriptive Category Title (H1): Use relevant keywords in the category title (H1 heading).
     • Compelling Category Description: Write informative, keyword-rich content for each category page to explain what the category is about, highlight key products/content, and encourage users to explore further. Category descriptions improve SEO and user understanding of the category.
     • Visually Appealing Category Layout: Design category pages that are visually appealing and easy to scan. Use clear headings, product/content snippets with images, filters/sorting options, and calls to action to explore subcategories or individual items within the category.
   • Internal Linking from Category Pages: Category pages should effectively link out to:
     • Subcategories (if any): Prominently link to subcategory pages (visually clear subcategory navigation on the category page).
     • Key Content Items within the Category: Feature and link to important products, blog posts, or content items that are most relevant to that category from the category page itself.
     • Cross-Category Linking (Where Relevant): In some cases, it may be relevant to link from one category page to a related category page to enhance topical connections across sections of your site.
3. Category URL Structure:
   • Category URLs Reflecting Hierarchy (Subdirectories): Category URLs should clearly reflect the category hierarchy using subdirectories. Example: example.com/category-name/subcategory-name/.
   • Keyword-Rich Category URLs: Incorporate relevant keywords in category slugs (URL path components) to make URLs descriptive and SEO-friendly.
   • Consistent URL Structure: Maintain a consistent URL structure across all categories.
4. Breadcrumb Navigation for Category Hierarchy:
   • Implement Breadcrumbs: Implement breadcrumb navigation on category pages and product/content pages within categories. Breadcrumbs show users the hierarchical path back to the homepage through the category structure and improve internal linking and user navigation.
5. Category Page SEO (On-Page Optimization):
   • Optimize Title Tags and Meta Descriptions for Category Pages: Craft unique and keyword-rich title tags and meta descriptions for category pages to target category-level keywords and improve click-through rates from search results.
   • Heading Hierarchy on Category Pages: Use H1 for the main category title, H2s and H3s for subheadings within category descriptions or for product/content groupings on the page.
6. Regularly Review and Refine Category Structure:
   • Content Growth and Evolution: As your website’s content grows, periodically review your category structure. Are existing categories still logical? Are new categories needed? Are some categories becoming too large and needing further subdivision into subcategories?
   • User Behavior Analysis: Monitor website analytics to see how users navigate category pages. Are users easily finding what they need within categories? Are there any category pages with high bounce rates that might indicate navigation issues or content irrelevance within the category?
   • SEO Performance Analysis of Category Pages: Track keyword rankings and organic traffic to category pages. Are category pages effectively ranking for relevant category-level keywords? If not, review on-page optimization and internal linking to category pages.

1.4.4 URL Structure Planning

A well-planned URL structure is essential for SEO and user experience. URLs should be clean, readable, keyword-rich, and reflect your website’s hierarchy.

Procedure:

1. Establish URL Structure Principles:
   • Readability and User-Friendliness: URLs should be human-readable and understandable. Users should get a sense of the page’s content just by looking at the URL.
   • Keyword Relevance: Incorporate relevant keywords in URLs, especially for primary target keywords of each page.
   • Hierarchy and Site Structure Reflection: URLs should reflect the logical hierarchy and structure of your website’s information architecture. Use subdirectories to represent categories and subcategories.
   • Conciseness (Keep URLs Short): Aim for shorter URLs where possible while maintaining readability and keyword relevance. Avoid overly long URLs with unnecessary words or parameters.
   • Consistency: Be consistent with URL structure across your website. Use a standardized approach for similar content types (e.g., product pages, blog posts, category pages).
   • Avoid Unnecessary Parameters in Primary URLs: Minimize the use of URL parameters (?, &, =) in primary URLs, especially for indexable content. Use parameters mainly for filtering, sorting, tracking (UTM parameters), and non-indexable variations. If parameters are needed for faceted navigation, implement proper canonicalization and parameter handling (covered in section 2.7).
2. URL Format Standardization:
   • Lowercase URLs (Recommended): Consistently use lowercase characters in URLs. While most servers are case-insensitive, it’s best practice for uniformity and to avoid potential issues.
   • Use Hyphens (-) as Word Separators (Recommended): Use hyphens to separate words in URLs. Hyphens are widely recognized as word separators by search engines and users. Avoid underscores (_), spaces (%20 in URLs), or other separators. Example: example.com/product-category/blue-widgets/ (good) vs. example.com/productCategory/Blue_Widgets/ (less ideal).
   • Trailing Slash Consistency: Decide whether to use trailing slashes (/) at the end of directory URLs (e.g., example.com/category/) and maintain consistency. Either with or without trailing slashes is acceptable, but inconsistency can cause issues. Generally, trailing slashes are more conventionally used for category and directory URLs, and no trailing slash for individual page or file URLs, but server configuration can enforce either behavior. Ensure redirects are in place to handle both versions consistently.
3. URL Structure by Content Type (Examples):
   • Homepage: Use the root domain: example.com or www.example.com (canonical version).
   • Category Pages: Use subdirectories to represent categories and subcategories, reflecting IA hierarchy. Example:
     • Top-level category: example.com/category-name/
     • Subcategory: example.com/category-name/subcategory-name/
   • Product Pages (E-commerce): Include category and product name in URLs. Example:
     • example.com/product-category/product-name/
     • Potentially, even flatter: example.com/products/product-name/ (if category level in URL not crucial).
   • Blog Posts/Articles: Use subdirectories like /blog/ followed by post title or a slug derived from the title. Example:
     • example.com/blog/how-to-optimize-url-structure-seo/
     • Consider including the publication year/month if content is time-sensitive or for archive organization: example.com/blog/2024/01/url-structure-seo/
   • Service Pages: Use subdirectories to organize services. Example:
     • example.com/services/seo-audit/
     • example.com/services/website-design/
   • About Us, Contact, Privacy Policy, Terms of Service: Typically placed directly at the root level (or under a main section like /company/):
     • example.com/about-us/
     • example.com/contact/
     • example.com/privacy-policy/
     • example.com/terms-of-service/
4. Keyword Integration in URLs:
   • Primary Keywords: Include your primary target keywords for each page in the URL, especially in the relevant URL path components (category, product, article slug).
   • Front-Load Keywords: Ideally, place the most important keywords closer to the beginning of the URL (immediately after the domain).
   • Descriptive but Concise Keywords: Use keywords naturally and descriptively but keep the URLs concise. Don’t keyword-stuff URLs with excessive or irrelevant keywords.
5. URL Length Optimization:
   • Aim for Shorter URLs: Shorter URLs are generally better for user experience, easier to share and remember, and can be perceived as slightly more favorable by search engines. Aim for URLs under 75-100 characters in total length (domain + path + query parameters combined).
   • Remove Unnecessary Words: Exclude stop words (e.g., “the,” “and,” “of”) or very generic words if they don’t add significant clarity or keyword value to the URL.
   • Prioritize Key Terms: Focus on including the most relevant and descriptive keywords, even if it means shortening less important parts of the URL.
6. Special Character Handling and URL Encoding:
   • Avoid Special Characters (in general): Try to avoid using special characters (beyond hyphens, and alphanumeric characters) in URLs whenever possible, as they can sometimes lead to encoding issues or be less user-friendly. Stick to letters, numbers, and hyphens.
   • URL Encoding for Special Characters (If Necessary): If you must use special characters (e.g., in user-generated content), ensure proper URL encoding (URL-encode any characters outside the allowed URL character set). Most CMS systems handle URL encoding automatically. Be aware that overly complex URLs with many encoded characters can be less readable and less SEO-friendly.
   • Non-ASCII Characters (International Domains/Content): For multilingual websites with non-ASCII characters, consider using Punycode for internationalized domain names (IDNs) in the domain part, and for URL paths, use UTF-8 encoding. However, for URL paths in non-Latin scripts, consider using transliteration or translation to Latin-script based slugs for better readability in URLs, especially if your primary audience is globally distributed or English-speaking users might link to your content. Hreflang tags (section 3.8) are essential for multilingual SEO, regardless of URL script choice.
7. Canonicalization and URL Variations (See Section 3.1):
   • Canonical Tags for Parameterized URLs: If you use URL parameters for variations (e.g., product variations, filters), ensure proper canonical tags point to the primary, canonical URL for each content item to prevent duplicate content issues (see section 3.1 Canonicalization Management and 2.7 Faceted Navigation & Parameters).
   • 301 Redirects for URL Changes: If you change URLs, implement 301 permanent redirects from the old URLs to the new URLs to preserve SEO equity and avoid broken links.

1.4.5 Internal Linking Architecture

Internal linking is the practice of linking pages within your own website to each other. A strong internal linking architecture improves website crawlability, distributes link equity, and guides users to relevant content, enhancing SEO and user experience.

Procedure:

1. Identify Key Pages and Content Clusters (Based on IA and Keyword Research):
   • Pillar Pages/Hub Pages: Identify your most important “pillar” or “hub” pages for key topics. These are comprehensive, high-authority pages covering broad topics in depth (e.g., category pages, service overview pages, in-depth guides).
   • Supporting Content/Cluster Content: Identify supporting content pieces (e.g., blog posts, product pages, specific service detail pages) that are related to and support your pillar/hub pages, forming content clusters or silos around core topics.
   • Keyword Mapping to Pages: Map primary keywords to your pillar pages and secondary/long-tail keywords to supporting content pages.
2. Strategic Internal Linking Implementation:
   • Navigation Menus (Primary and Footer): Main navigation menus (header and footer) should provide links to your most important top-level category pages, service pages, or core content sections (pillar pages).
   • Contextual In-Content Links: The most impactful internal links are usually contextual links embedded within the body content of pages.
     • Relevance: Link from one page to another when there is a natural, thematic relevance and it makes sense for users to explore the linked page for more information or context. Link should add value to user experience, not just for SEO purposes.
     • Anchor Text Optimization: Use relevant, descriptive, and keyword-rich anchor text for internal links (the visible, clickable text of the link). Anchor text should clearly indicate the topic of the linked page and ideally include target keywords for the linked page. Avoid generic anchor text like “click here” or “read more”. Use keyword variations and semantic keywords within anchor text strategically.
   • Category Pages and Hub Pages Linking: Category pages and pillar/hub pages should act as central hubs, linking out to:
     • Subcategory Pages (from category pages): Clearly link to subcategory pages within the same main category.
     • Supporting Content: Link from pillar/hub pages to related supporting content pieces within the same topic cluster (blog posts, detailed product pages, service details, etc.).
     • Related Categories/Pillars (Cross-linking where relevant): If thematically connected, consider linking between related category or pillar pages to reinforce topical relevance across sections.
   • Footer Links (Judiciously Used): Use footer links to link to important utility pages (About Us, Contact, Privacy Policy, Terms of Service). You can also strategically link to a limited number of important category pages or key service/product pages from the footer, but don’t overload the footer with excessive or repetitive links.
   • Sitemaps (XML and HTML – see section 2.2): Sitemaps, while primarily for search engine crawling, indirectly facilitate internal linking by providing a comprehensive list of all website pages. HTML sitemaps are also for users to browse.
3. Internal Link Relevance Assessment:
   • Content Similarity: Ensure the linking page and the linked-to page are thematically related. Link from a page about “coffee brewing methods” to pages about “French press brewing” or “pour over techniques”, for example, not to unrelated pages.
   • User Intent Alignment: Internal links should guide users to pages that are relevant to their current context and fulfill potential user intent at that stage of their website journey. Link to pages that provide valuable next steps or related information.
   • Anchor Text-Page Relevance: Verify that the anchor text accurately and clearly describes the content of the linked page.
4. Anchor Text Optimization for Internal Links:
   • Keyword-Rich Anchor Text: Use relevant keywords in anchor text, reflecting the target keywords for the linked page, but vary anchor text naturally.
   • Descriptive Anchor Text: Anchor text should be descriptive and provide context for the linked page.
   • Variety in Anchor Text: Avoid over-optimizing anchor text by always using the exact same keyword phrase. Use variations, semantic keywords, and LSI keywords in anchor text to make it sound natural and avoid looking manipulative.
   • Long-Tail Keywords in Anchor Text (When Appropriate): Use longer, more specific anchor text (long-tail keywords) when linking to pages that target those specific long-tail phrases.
5. Orphaned Page Identification and Resolution:
   • Crawl Analysis (using Screaming Frog, Sitebulb, etc.): Use website crawlers to identify “orphaned pages” – pages that are not linked to from any other page on your website. Orphaned pages are difficult for search engines and users to discover.
   • Sitemap Comparison: Compare your XML sitemap with crawled URLs to identify pages in the sitemap that were not found during crawling, which might be orphaned.
   • Resolve Orphaned Pages: For any identified orphaned pages that should be indexable and accessible, integrate them into your internal linking architecture. Link to them from relevant category pages, hub pages, or other related content pieces to make them discoverable. If pages are intentionally orphaned (e.g., thank you pages after forms), ensure they are correctly set to noindex (section 3.6).
6. Click Depth Analysis and Optimization (re-emphasizing 1.4.2):
   • Crawl Visualization Tools (Screaming Frog, Sitebulb crawl graphs): Use crawl visualization features in tools like Screaming Frog or Sitebulb to visually analyze your internal linking structure and click depth.
   • Click Depth Reports (from Crawlers): Many advanced SEO crawlers can provide reports showing the click depth of pages from the homepage.
   • Optimize for Reduced Click Depth (for important pages): Aim to reduce click depth for your most important pages (homepage, category pages, key service/product pages) to make them easily accessible to users and crawlers. Strategically add internal links from higher-authority, more frequently visited pages to push link equity and discoverability to important, potentially deeper pages.
7. Internal Link Audit and Maintenance:
   • Regularly Crawl Website (for Link Analysis): Periodically crawl your website to analyze your internal link structure, identify broken internal links (fix or update), and find new opportunities for strategic internal linking as your content evolves.
   • Internal Link Metrics (Advanced SEO Tools): Some advanced SEO tools can analyze internal linking metrics like “Internal LinkRank” or “Authority Flow”. While not as crucial as external link metrics, these can give insights into internal link distribution.

1.4.6 Navigation Hierarchy Planning

Website navigation is how users find their way around your site. Well-planned navigation hierarchy, reflecting your IA, is essential for usability and SEO.

Procedure:

1. Primary Navigation (Main Menu – Header Navigation):
   • Top-Level Categories (Main Sections): Primary navigation should clearly present your main website sections or top-level categories (aligned with IA planning and top-level URLs). Limit the number of top-level navigation items to avoid overwhelming users (5-7 items is a common guideline, though can vary based on website complexity).
   • Dropdown Menus (for Subcategories – Judiciously Used): For categories with subcategories, use well-designed dropdown menus (mega menus for large category structures can be useful for e-commerce or complex sites). Avoid overly deep dropdown menus (more than 2 levels deep is generally discouraged as it becomes less usable).
   • Clear and Concise Navigation Labels: Use clear, concise, and descriptive labels for navigation menu items. Use terms that users understand and that reflect the content of each section.
   • Mobile-Friendly Navigation (Responsive Menus): Ensure your primary navigation is fully responsive and user-friendly on mobile devices (hamburger menus, collapsible sections, etc.).
   • Consistent Placement and Design: Keep the primary navigation in a consistent location (typically in the header area, globally visible on all pages) and maintain a consistent visual design and styling.
2. Footer Navigation:
   • Utility Navigation (Privacy Policy, Terms, Contact, About): Footer navigation is often used for “utility” links – links to legal pages, contact information, “About Us,” sitemap, etc.
   • Key Category Links (Strategic – Selectively): You can strategically place a limited number of important category pages or high-value pages in the footer, especially if they are crucial but not prominently featured in the main header navigation. Avoid excessive link repetition or keyword stuffing in the footer.
   • Company Information (Address, Copyright, Social Media Links): Footer also typically includes company address, copyright notice, and links to social media profiles.
3. Breadcrumb Navigation (Hierarchical):
   • Implement Breadcrumbs on Category Pages and Content Pages within Categories: Breadcrumbs visually represent the hierarchical path from the homepage to the current page (e.g., Home > Category > Subcategory > Product).
   • Clear Hierarchy Representation: Breadcrumbs should clearly display the site hierarchy.
   • Clickable Navigation Links (for hierarchy levels): Each element in the breadcrumb trail should be a clickable link back to the corresponding page in the hierarchy (e.g., “Home” link to homepage, “Category” link to category page, etc.).
   • Placement (Typically Above Content): Breadcrumbs are usually placed at the top of the content area, just below the header or page title.
4. Sidebar Navigation (Contextual – Optional and Content-Dependent):
   • Category/Subcategory Sidebar Menus (on category pages): On category pages, you can use sidebar menus to display subcategories within that category, or related categories for further browsing.
   • Related Content Sidebar (on content pages): On content pages (like blog posts or articles), sidebars can be used to link to “Related Articles,” “Popular Posts,” “Latest News,” or other contextually relevant content.
   • Widgets and Dynamic Content (Sidebar – Judicious Use): Sidebars can also host widgets like search bars, subscription forms, social media feeds, but keep sidebar content relevant to the page content. Avoid cluttered or overly distracting sidebars. Consider if sidebars are really needed for user experience, especially on mobile where sidebars often get pushed below the main content, losing prominence.
5. Site Search Functionality (Important for Large Sites):
   • Prominent Search Bar: Make site search easily accessible and visible, typically in the header area.
   • Effective Search Engine: Use a robust site search engine that provides relevant search results, handles misspellings and synonyms, and potentially offers features like auto-suggestions. Built-in CMS search might be basic; consider using dedicated site search solutions (e.g., search plugins for CMS, cloud-based site search services) for larger, more complex websites or e-commerce sites.
   • Search Results Page Optimization: Ensure the site search results page itself is well-designed and user-friendly, clearly displaying results, providing filters/sorting options, and visually separating search results.
6. “Back to Top” Links (For Long Pages – Enhance Mobile Usability):
   • Implement “Back to Top” Link: For long pages (especially on mobile), provide a clear “Back to Top” link or button that allows users to easily scroll back to the top of the page without excessive scrolling. This improves usability on long-form content.
7. Visual Hierarchy and Design for Navigation:
   • Visual Cues for Navigation Elements: Use visual cues (clear styling, spacing, icons) to distinguish navigation menus, buttons, links, and other interactive elements.
   • Intuitive Design Principles: Follow established web design conventions and usability principles for navigation design (clear typography, sufficient contrast, consistent styling).
   • Testing and User Feedback: Conduct usability testing to evaluate the effectiveness of your navigation hierarchy and get user feedback. Analyze website analytics data (navigation paths, drop-off points, search usage) to identify potential navigation bottlenecks or areas for improvement.

External Web References

• Ultahost SSL Checker: https://ultahost.com/ssl-checker – Tool for verifying SSL certificate installation and details.
• SSL Labs SSL Test: https://www.ssllabs.com/ssltest/ – Comprehensive SSL/TLS configuration analysis and grading.
• HSTS Preload List Submission: https://hstspreload.org/ – Website for submitting domains to the HSTS preload list and checking preload status.
• KeyCDN HTTP/2 Test: https://tools.keycdn.com/http2-test – Online tool to test if a website is using HTTP/2.
• Check Gzip Compression: https://checkgzipcompression.com/ – Tool to verify Gzip and Brotli compression status.
• Webconfs HTTP Header Check: https://www.webconfs.com/http-header-check.php – Online HTTP header inspector.
• httpstatus.io: https://httpstatus.io/ – Online redirect checker and HTTP status code verifier.
• WHOIS: https://www.whois.com/whois – Domain registration information lookup service.
• Dotcom-Tools DNS Speed Test: https://www.dotcom-tools.com/dns-speed-test – Online DNS resolution speed testing tool.

Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/ – Tool for generating recommended SSL/TLS server configurations.