Technical SEO on Your Own Server: What the Hosting Side Controls

Most SEO advice is about content and links. But when you run your own VPS, a whole layer of SEO is your responsibility: whether the site is reachable, how fast it responds, which status codes it returns, and how crawlers are guided around it. Search engines can’t rank pages they can’t crawl reliably. This checklist covers what the server controls.

1. Availability

Repeated 5xx errors or timeouts make Googlebot slow its crawling, and pages that stay down can drop out of the index.

Monitor uptime from outside. See Uptime Kuma.
During planned maintenance, return 503 with a Retry-After header, not a 200 “maintenance” page or a 404. Crawlers understand 503 as temporary.

error_page 503 /maintenance.html;
location = /maintenance.html {
    root /var/www/maintenance;
    add_header Retry-After 3600 always;
    internal;
}
location / {
    return 503;
}

2. Speed (TTFB)

A slow server response hurts Core Web Vitals (LCP), and also reduces how much Google crawls. Aim for a TTFB under 0.8 s, ideally 200 ms or less, with page caching, PHP OPcache and a tuned database. See Core Web Vitals and server performance and web performance testing.

3. HTTPS everywhere

Valid certificate, automatic renewal, full chain. See Let’s Encrypt with Certbot.
Redirect HTTP to HTTPS with a 301. See redirect HTTP to HTTPS in Nginx.
No mixed content (HTTP images and scripts on HTTPS pages).

4. One canonical host

http://, https://, www and non-www are four different URLs to a crawler. Pick one, and 301 the others to it. Then reinforce it with <link rel="canonical"> tags. See redirect www to non-www and canonical URLs.

Also be consistent about trailing slashes (/page vs /page/): serve one, and redirect the other.

5. Correct status codes

Situation	Return
Page exists	200
Moved permanently	301 (or 308)
Temporary move	302 (or 307)
Not found	404
Deliberately removed	410
Maintenance	503 + Retry-After

A common problem is the soft 404: a “not found” page that returns 200. Make sure your error pages send real 404 codes. See HTTP status codes and 301 vs 302 redirects.

6. Crawl control

robots.txt at the root, reachable, returning 200 (a 5xx on robots.txt can pause crawling). See the robots.txt guide.
XML sitemap listing canonical, indexable URLs, referenced from robots.txt. See XML sitemaps.
noindex for pages that shouldn’t appear in search (internal search results, staging copies). Use the X-Robots-Tag header for PDFs and other non-HTML files:

location ~* \.pdf$ {
    add_header X-Robots-Tag "noindex";
}

Protect staging sites with a password, not just robots.txt.

7. Crawl budget hygiene

On large sites, avoid wasting crawls on:

endless parameter combinations (filters, sorting, session IDs);
redirect chains (A → B → C). Redirect straight to the final URL;
duplicate content across hosts or paths.

8. Server logs

Your access logs show exactly what Googlebot crawls, how often, and which errors it hits. That is information no SEO tool has. See log file analysis for SEO.

9. Server location and CDN

Location affects latency for visitors, and therefore speed metrics. It’s not a direct ranking factor for country targeting: use hreflang and Search Console for that. Choose a location near your audience, and use a CDN for global audiences. See choosing a VPS location, CDN for websites and the hreflang guide.

10. Security

Hacked sites get spam pages injected and warnings in search results. Keep software updated, use a firewall, and watch Search Console’s security issues report. See Linux server hardening.

Checklist

Area	Check
Uptime	External monitoring; 503 during maintenance
Speed	TTFB < 0.8 s; caching enabled
HTTPS	Valid cert, auto-renew, HTTP → HTTPS 301
Host	One canonical host and slash style
Status codes	Real 404s, 410 for removed pages, no soft 404s
Crawling	robots.txt 200, sitemap, noindex where needed
Monitoring	Search Console + server logs

SEO
Nginx
Web Development