Quick Summary
Many website owners only begin paying attention to the server side of SEO after a migration, outage, or security incident causes a noticeable drop in organic traffic. The website may still appear to be online, yet Google Search Console starts reporting crawl errors, pages disappear from the index, old URLs return 404 responses instead of 301 redirects, and search engine crawlers occasionally receive 500 or 503 errors. In many cases, the problem is not the content but the hosting infrastructure.
Search engines evaluate not only the quality of your pages but also how reliably they can be accessed. DNS failures, long redirect chains, slow server responses, intermittent downtime and signs of a compromised website gradually reduce crawling efficiency and can eventually affect search visibility.
The best way to avoid these problems is to prepare the infrastructure before launching a new website or migrating an existing one. Verify DNS, configure SSL, enable uptime monitoring, test backups, secure the server against malware and prepare all required 301 redirects before changing your URL structure.
At Era.Host, support engineers regularly investigate migrations where rankings decline even though the website itself works correctly. The cause is often an overlooked infrastructure issue rather than a problem with the CMS or the site’s content.
A server does not improve search rankings on its own, but it provides the stable foundation that allows search engines to crawl the website consistently. When pages remain available, redirects work correctly, DNS resolves reliably and failures are detected quickly, SEO performance depends on the quality of the website rather than the limitations of the hosting environment.
How to Verify DNS Before Launching or Migrating a Website
One of the most common migration mistakes is checking only whether the homepage loads. The website appears to work, yet some visitors still reach the old server, email stops working, API requests continue to use the previous IP address, certain subdomains remain on the old infrastructure, and Google Search Console begins reporting crawl errors. In many cases, the problem is not the CMS but an incomplete DNS transition.
Before the migration, review your DNS zone and reduce the TTL of existing records. If the A record still uses a TTL of 86,400 seconds, recursive DNS servers may continue serving the old IP address for almost 24 hours. Lowering the TTL to 300–600 seconds 24 to 48 hours before the migration allows changes to propagate much faster.
Before switching DNS, verify that all required records have been prepared, including A, AAAA, CNAME, MX, TXT and NS records, together with any application-specific entries.
After updating DNS, do not rely on your browser because it may still use cached results. Verify the configuration from the command line.
dig example.com
dig A example.com
dig NS example.com
nslookup example.comIf the website uses IPv6, verify the AAAA record as well.
dig AAAA example.comEvery command should return the new IP address. If any of them still resolves to the previous server, DNS propagation is incomplete or one of the authoritative name servers still contains outdated information.
Next, query several public DNS resolvers.
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @9.9.9.9 example.comAll resolvers should return the same address. If they do not, users and search engine crawlers may still reach different servers.
Once DNS consistently resolves to the new server, verify that the website loads correctly over HTTPS, the SSL certificate is trusted, email, APIs and subdomains operate normally, and Google Search Console can inspect important pages. If the migration includes a new domain, confirm that the XML sitemap is accessible and error-free.
The migration should only be considered complete after DNS resolves correctly across public resolvers, all services operate from the new infrastructure, and search engines can crawl the website without errors.
How to Prepare for a Website Migration Without Losing Search Rankings
A website migration is often considered complete as soon as the site loads from the new server. A few days later, pages disappear from search results, Google Search Console reports crawl errors, search engine crawlers continue requesting the old IP address, and new content is indexed more slowly. In most cases, the problem is not the migration itself but incomplete preparation.
Start preparing one or two days before the migration by reducing the TTL of your primary DNS records to 300–600 seconds and verifying all required DNS records. Correcting DNS issues before the cutover is much easier than fixing them after users begin reporting problems.
Before changing DNS, prepare the new server completely. Access the website through a staging domain, temporary URL or a modified hosts file, then test the CMS, administration panel, database connectivity, images, contact forms, authentication, search, checkout process and other critical features.
Configure HTTPS before switching traffic. Install the SSL certificate, verify that it covers the required domains and subdomains, and confirm that the browser reports no certificate warnings.
Before updating DNS, inspect the robots.txt file to ensure no development restrictions remain.
User-agent: *
Disallow: /This directive is commonly used on staging environments. If left in place after launch, search engines will stop crawling the website.
Verify that the XML sitemap contains only current URLs, is available over HTTPS and does not include staging pages.
If the migration changes the URL structure or introduces a new domain, prepare all required 301 redirects before the DNS cutover. Avoid temporary 302 redirects and redirect chains. If a new domain is involved, add it to Google Search Console and verify ownership before launch.
Once the new server is ready, update the DNS records, wait for propagation, then verify the results with dig or nslookup. Test the homepage, key landing pages, contact forms and other important sections over HTTPS, ensuring there are no redirect loops, SSL warnings or HTTP 404 and 500 errors.
Finally, use Google Search Console’s URL Inspection tool to confirm that important pages return HTTP 200, remain eligible for indexing and that the updated XML sitemap has been processed successfully.
Continue monitoring Google Search Console and server logs during the following days, resolving crawl errors, unexpected 404 responses or SSL issues as soon as they appear.
The migration is complete once DNS resolves correctly, HTTPS works without warnings, robots.txt allows crawling, the XML sitemap is processed successfully, all 301 redirects point directly to their destination and Google Search Console confirms that the website can be crawled and indexed correctly.
How to Protect Your Website from Security Breaches That Damage SEO
Many website owners discover a security breach only after organic traffic drops. The website still appears to work normally, yet Google Search Console starts displaying security warnings, while search results begin showing pages about online casinos, cryptocurrency, pharmaceuticals or other content that never existed on the site. By that stage, malicious pages may already have been indexed, making recovery far more difficult than simply removing a few infected files.
Start by verifying that a Web Application Firewall (WAF) is actively protecting the server. Whether you use Imunify360, ModSecurity, Cloudflare WAF or another solution, it should block malicious requests rather than simply record them.
For Apache:
apachectl -M | grep securityFor Nginx:
nginx -V 2>&1 | grep modsecurityFor Imunify360:
systemctl status imunify360Confirm that the WAF operates in Blocking mode rather than Detection Only, then send a harmless SQL injection or XSS test request and verify that it appears in the WAF logs as blocked.
Enable automatic malware scanning.
maldet -a /var/www/example.comIf ClamAV is installed:
freshclam
clamscan -r /var/www/example.comInvestigate suspicious files before removing them, as legitimate CMS components may trigger alerts.
Verify file permissions.
find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;
ls -la /var/www/example.comIf multiple websites share the server, run each under a separate Linux user and PHP-FPM pool.
If AIDE is available, enable file integrity monitoring.
aide --init
aide --checkReview recently modified PHP files.
find /var/www/example.com -type f -name "*.php" -mtime -1Search directories where PHP files should never normally exist.
find /var/www/example.com/uploads -name "*.php"
find /var/www/example.com/images -name "*.php"Also search for suspicious code patterns.
grep -R "base64_decode" /var/www/example.com
grep -R "eval(base64_decode" /var/www/example.com
grep -R "gzinflate" /var/www/example.comReview scheduled tasks because attackers often use cron jobs to restore malware.
crontab -l
ls -la /etc/cron*From an SEO perspective, check the Security Issues section in Google Search Console and search Google using:
site:example.comUnexpected URLs, hidden directories or unrelated content usually indicate that a full security audit is required.
Finally, inspect the web server and WAF logs.
tail -100 /var/log/nginx/error.logRepeated SQL injection attempts, malicious uploads or web shell requests should be blocked rather than simply logged.
The security configuration can be considered complete when the WAF blocks attacks, malware scans run automatically, recommended permissions and website isolation are in place, file integrity monitoring detects unexpected changes, no suspicious PHP files or cron jobs remain, and neither Google Search Console nor a site: search reveals malicious content or hidden redirects.
How to Configure 301 Redirects When Changing URLs
After changing a CMS, reorganising your URL structure or renaming pages, many administrators simply check that the new website loads correctly and consider the migration complete. A few weeks later, Google Search Console reports hundreds of 404 errors, older pages disappear from search results and organic traffic begins to decline. In most cases, the problem is not the migration itself but missing, incorrect or inefficient redirects.
Start by creating a complete URL mapping before editing .htaccess or your Nginx configuration. Export every existing URL from your XML sitemap, Google Search Console, analytics platform or CMS database, then map each old address to its new destination. If a page has no suitable replacement, decide whether it should return 410 Gone or redirect to the closest relevant page. Avoid redirecting every removed URL to the homepage, as both users and search engines generally treat this as a poor replacement.
For Apache, add permanent redirects to .htaccess.
Redirect 301 /old-page https://example.com/new-page
Redirect 301 /catalog/old-product https://example.com/products/new-productIf an entire directory structure changes, use rewrite rules instead.
RewriteEngine On
RewriteRule ^catalog/(.*)$ /products/$1 [R=301,L]For Nginx, update the virtual host configuration.
location = /old-page {
return 301 https://example.com/new-page;
}For an entire section:
rewrite ^/catalog/(.*)$ /products/$1 permanent;Validate the configuration before restarting the web server.
For Apache:
apachectl configtestFor Nginx:
nginx -tIf no errors are reported, restart the service.
systemctl restart nginxor
systemctl restart apache2Next, verify the redirects from the command line instead of relying on a browser.
curl -I https://example.com/old-pageA correct response should return:
HTTP/2 301
Location: https://example.com/new-pageIf the server responds with 302 Found instead of 301 Moved Permanently, search engines may delay transferring ranking signals because the redirect is treated as temporary.
Then check for redirect chains.
curl -IL https://example.com/old-pageThe expected result is a single redirect followed by the destination page.
HTTP/2 301
Location: https://example.com/new-page
HTTP/2 200If additional 301 or 302 responses appear before the final 200 OK, eliminate the intermediate redirects so every old URL points directly to its final destination.
Do not limit testing to the homepage. Verify category pages, product pages, articles, images, pagination and URLs that previously generated the highest levels of organic traffic, as missing redirect rules and redirect loops are much more likely to appear on internal pages.
For large migrations, automate the verification.
cat old_urls.txt | while read url; do
curl -o /dev/null -s -w "%{http_code} %{redirect_url}\n" "$url"
doneThis quickly identifies missing redirects, incorrect destinations and URLs still returning HTTP 404.
Finally, inspect several old URLs in Google Search Console using the URL Inspection tool, confirm that Google receives an HTTP 301 response, update the XML sitemap and monitor indexing over the following days. If new 404 errors appear, add the missing redirect rules before search engines begin removing those pages from the index.
The migration can be considered complete when every old URL redirects directly to its final destination with a single 301 Moved Permanently response, no redirect chains or loops remain, batch testing confirms that all legacy URLs are covered, and Google Search Console stops reporting new crawl errors. This approach preserves accumulated ranking signals and minimises the risk of losing organic traffic after restructuring your URLs.
Choosing a Hosting Package for an SEO-Friendly Infrastructure
Once DNS, uptime monitoring, a WAF, backups and 301 redirects have been configured, it becomes clear that long-term SEO depends on more than the website itself. Even a well-optimised project can lose visibility if the server regularly returns errors, SSL is unreliable, logs are unavailable, backups cannot be restored quickly or every increase in traffic requires a complex migration. For this reason, choose a hosting platform for the quality of its infrastructure rather than disk space or monthly cost.
When comparing hosting plans, look beyond CPU cores and RAM. More important is whether the platform provides the tools needed to maintain, troubleshoot and scale the website.
| What to check | Why it matters |
|---|---|
| DNS management | Fast DNS updates during migrations and emergencies |
| Free SSL with automatic renewal | Prevents HTTPS errors and browser warnings |
| Backup and restore | Enables fast recovery after failures |
| Access to web server, PHP and database logs | Simplifies troubleshooting and technical SEO diagnostics |
| Current PHP versions | Improves security and CMS compatibility |
| WAF support | Helps prevent compromises that affect SEO |
| Resource scaling | Increases CPU, memory and storage without migration |
| Redirect and web server control | Essential for technical SEO and URL changes |
After reviewing these features, confirm that DNS can be managed without contacting support, backups can be restored, logs are accessible, WAF deployment is supported, and resources can be upgraded without moving the website.
Finally, think beyond current requirements. If traffic doubles next year, will the platform let you upgrade PHP, restore backups, modify DNS, analyse logs and increase resources without a full migration? If not, the infrastructure will probably become a limitation before storage capacity does.
A good hosting platform does not improve search rankings on its own. It provides a stable environment where search engines can crawl the website reliably, administrators can resolve infrastructure issues quickly, and the project can continue growing without unnecessary downtime or migrations.
