Why technical SEO matters for hosting sites

Technical SEO is the part of search optimization that helps a hosting site crawl cleanly, render correctly, and make sense to search engines. For HostnExtra customers, that usually means better service pages, faster docs, cleaner indexation, and fewer migration headaches.

This tutorial walks through a Linux-based hosting site from the server layer up: HTTP response behavior, robots access, canonical handling, structured data, sitemap delivery, and the performance signals that affect crawlability. It uses a fresh dedicated server running Ubuntu, Debian, AlmaLinux, or Rocky Linux, with a simple Nginx example you can adapt for a blog, help center, or service page.

If you are also comparing server options before launch, start with How to Choose a Dedicated Server in 2026 and How to Compare Dedicated Server Options in 2026. If your site already exists and you are cleaning up after a migration, Fix 404 Errors After Migrating an Apache Website is a useful companion.

Build a crawlable, testable site on a fresh Linux server

Goal: publish a small static site with robots.txt, sitemap.xml, canonical tags, and schema markup, then verify server headers and indexability. This example uses Nginx because it is common for hosting documentation and marketing sites.

Prerequisites

• A dedicated server from HostnExtra running Ubuntu, Debian, AlmaLinux, or Rocky Linux.
• A DNS A record for www.example.com and optionally example.com pointing to your server IP.
• Open ports: 22 for SSH, 80 for HTTP, and 443 for HTTPS.
• Example placeholders you will replace: SERVER_IP=203.0.113.10, ADMIN_USER=deploy, DOMAIN_NAME=example.com, WWW_DOMAIN=www.example.com, WEB_ROOT=/var/www/example.com.

Local computer: connect to the server

ssh [email protected]

If your SSH service uses a custom port, include it in the command, for example ssh -p 2222 [email protected]. Keep this root session open until the non-root account test later succeeds.

VPS as root: identify the operating system

cat /etc/os-release

Confirm whether the server is Debian-family or RHEL-family before you use the package commands below. The output should show the OS name and version.

Ubuntu/Debian section

VPS as root: update package lists and install base tools

apt update
apt install -y nginx curl unzip ca-certificates certbot python3-certbot-nginx

This installs Nginx, curl for HTTP checks, unzip for assets, and Certbot for TLS. The install should complete without errors.

VPS as root: create a non-root sudo user

adduser deploy
usermod -aG sudo deploy

Replace deploy with your preferred admin username if needed. The first command creates the account; the second adds sudo access through the sudo group.

VPS as root: prepare SSH keys for the new user

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

If you do not already use key-based access, place your public key into /home/deploy/.ssh/authorized_keys from your local computer instead of copying root keys. The permissions matter: 700 for the directory and 600 for the file.

Local computer: test the new account in a second terminal

ssh [email protected]
sudo -v

The login should work, and sudo -v should ask for the account password, then return cleanly. Do not disable root login until this test passes.

VPS as root: create the site directory and content

mkdir -p /var/www/example.com
chown -R deploy:deploy /var/www/example.com

VPS as deploy user: create the site files

cat > /var/www/example.com/index.html <<'EOF'


  
Example Hosting Site
  
This page is intentionally simple for crawlability testing.

EOF
cat > /var/www/example.com/robots.txt <<'EOF'
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml
EOF
cat > /var/www/example.com/sitemap.xml <<'EOF'


  
    https://example.com/
  

EOF

Replace the sample brand, domain, and description with your real site values. The page includes a canonical tag, meta description, and basic schema that search engines can read.

VPS as root: configure Nginx for the domain

cat > /etc/nginx/sites-available/example.com <<'EOF'
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location = /robots.txt {
        allow all;
    }

    location = /sitemap.xml {
        allow all;
    }
}
EOF
ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
nginx -t

The syntax test must succeed before you reload Nginx. If it fails, fix the file path or a missing brace first.

VPS as root: reload Nginx and allow HTTP/HTTPS through the firewall

systemctl reload nginx
ufw allow 80/tcp
ufw allow 443/tcp
ufw status

Reloading applies the site without dropping connections. The firewall commands open the web ports your visitors and crawlers need.

VPS as deploy user: check the public response

curl -I http://example.com
curl -s https://example.com/ | head

Look for a 200 response, the expected title, and the canonical URL in the HTML. If HTTPS is not ready yet, run the HTTP test first.

VPS as root: issue a TLS certificate

certbot --nginx -d example.com -d www.example.com

Choose the redirect option if you want HTTP to move to HTTPS. A successful run updates the Nginx configuration automatically.

VPS as deploy user: confirm the secure endpoint

curl -I https://example.com
curl -s https://example.com/robots.txt
curl -s https://example.com/sitemap.xml

Check that HTTPS returns 200, robots.txt is reachable, and sitemap.xml is valid XML content.

AlmaLinux/Rocky Linux section

VPS as root: update packages and install tools

dnf update -y
dnf install -y nginx curl unzip ca-certificates certbot python3-certbot-nginx policycoreutils-python-utils

This installs the same web stack plus SELinux utilities that are often needed on RHEL-compatible systems.

VPS as root: create a non-root sudo user

adduser deploy
passwd deploy
usermod -aG wheel deploy

Use a strong password and add the account to wheel for sudo access.

VPS as root: set up SSH access for the new user

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Use your own public key if root keys are not already in place. Ownership and permissions must match exactly.

Local computer: verify the new account

ssh [email protected]
sudo -v

Keep the original root session open until this second-terminal login and sudo check succeed.

VPS as root: create site files and fix SELinux labels

mkdir -p /var/www/example.com
chown -R deploy:deploy /var/www/example.com
cat > /var/www/example.com/index.html <<'EOF'


  
Example Hosting Site
  
This page is intentionally simple for crawlability testing.

EOF
cat > /var/www/example.com/robots.txt <<'EOF'
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml
EOF
cat > /var/www/example.com/sitemap.xml <<'EOF'


  
    https://example.com/
  

EOF
semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
restorecon -Rv /var/www/example.com

The last two commands apply SELinux labels so Nginx can read the files.

VPS as root: configure Nginx and test syntax

cat > /etc/nginx/conf.d/example.com.conf <<'EOF'
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location = /robots.txt {
        allow all;
    }

    location = /sitemap.xml {
        allow all;
    }
}
EOF
nginx -t

Use the exact domain names you plan to publish. The syntax test should pass before any reload.

VPS as root: open the firewall, enable Nginx, and issue TLS

systemctl enable --now nginx
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
certbot --nginx -d example.com -d www.example.com

These commands start Nginx at boot, allow web traffic, and request a certificate. If you use a different SELinux profile or custom policy, review access logs after issuance.

Final checks, troubleshooting, and rollback

Server verification

systemctl status nginx --no-pager
ss -tulpn | grep -E ':80|:443'
curl -I https://example.com
curl -s https://example.com/ | grep -E 'canonical|application/ld\+json|Example Hosting'

You want Nginx active, ports 80 and 443 listening, and the page source exposing the canonical tag and schema markup.

Check logs when something fails

journalctl -u nginx -n 50 --no-pager
tail -n 50 /var/log/nginx/error.log

If you see permission denied errors, revisit file ownership, SELinux labels on RHEL-family systems, and the Nginx root path.

Rollback procedure

rm -f /etc/nginx/sites-enabled/example.com
rm -f /etc/nginx/sites-available/example.com
rm -f /etc/nginx/conf.d/example.com.conf
rm -rf /var/www/example.com
nginx -t

Remove the site configuration only after you are sure you no longer need it. If the syntax test passes, reload Nginx to clear the retired virtual host from memory.

systemctl reload nginx

Functional smoke test

curl -I https://example.com/robots.txt
curl -I https://example.com/sitemap.xml
curl -I https://example.com/

These requests confirm that search-engine-facing files and the homepage are reachable over HTTPS. For a live HostnExtra setup, use your real domain, then submit the sitemap in your search console after DNS and TLS are stable.

If you are publishing content on a new dedicated server and want a buying reference, see HostnExtra dedicated servers. For regional placement decisions, the London and Germany options are often relevant for European audiences.

FAQ

Does technical SEO start on the server?

Yes. Clean HTTP status codes, stable TLS, fast responses, and accessible robots.txt and sitemap.xml files all start at the server layer.

Should I use Nginx or Apache for a hosting content site?

Either can work. Nginx is a practical default for static pages, docs, and reverse proxy setups. Apache is still a good choice when your existing stack already depends on it.

Do I need schema markup for a hosting company site?

Schema is not required for indexing, but it helps search systems understand your organization, service pages, FAQs, and support content more clearly.

What should I test after a migration?

Check redirects, canonical URLs, sitemap delivery, HTTPS certificates, server logs, and a handful of important pages with curl before and after launch.