NGINX Plus 助力电子商务供应商提高 SEO 效果

Floyd Smith of NGINX

内容营销总监

2016-11-11

With NGINX and NGINX Plus, you can change your site architecture as needed without suffering SEO penalties. The high performance of NGINX, and its easy‑to‑implement rewrite rules, make it simple to point existing URLs to new page locations. In addition, powerful rewrite rules and other NGINX features make it easy to move to HTTPS, which increases user confidence in your site and gives you an SEO boost.

Problem

Search engine optimization – SEO – is a concern for all sites. The lessons in this blog post apply, to some extent, to anyone managing a site. But SEO is even more of a “do or die” concern for ecommerce sites, large and small.

Showing up on the first page of Google search results for relevant products – preferably at the top – is crucial for all online retailers, both “pure play” ecommerce sites like Amazon or eBay and top brick‑and‑mortar retailers with websites, such as Macy’s or Nordstrom. Appearing “below the fold” damages revenues, competitiveness, and brand perception. And, since SEO success is self‑reinforcing, the damage from bad SEO can be permanent – even fatal.

Unfortunately, the operational needs of a website can undermine good SEO results. Retailers frequently need to change the URLs of products, often by the hundreds or even thousands at a time. Common reasons for URL changes are to add or change product categories or to revamp the architecture for content storage and delivery – for example, by adding a content distribution network (CDN), or making changes to the CDN.

In addition, changes to specific product pages, or small groups of products, are common. Products might be moved to a new category, added to another category, or replaced by a similar product.

Any of these changes can damage SEO and search engine results. How does this happen? The reason is built into the basic functionality of any search engine:

• The search engine crawls the web and records information about (indexes) most pages.
• Each page is weighted for its use of key terms and relevance to user searches, the number of links associated with each term, the popularity of the linking pages, and other factors.
• The search engine repeats the web crawl:
  • If the search engine finds the page at its stored URL, the search engine updates the page’s entry with new information. The page’s ranking increases or decreases as ranking signals change.
  • If the page is moved without a redirect, the search engine receives a 404 error. The previous search engine ranking, such as the Google PageRank, does not transfer to the relocated page. Instead, the SEO history for the relocated page starts over from scratch.

Reviewing this process exposes the underlying problem caused by routine site maintenance and changes in site structure. These changes in the site hierarchy make the URL of specific pages change, even though the pages are otherwise the same. The search engine fails to find the site during its next crawl, and the page’s ranking in search results plummets.

NGINX, Inc. recently helped an enterprise customer with a business problem caused by site changes of just this type – and the ongoing need to make similar changes. SEO ratings for the company’s product pages were dropping sharply. Sales immediately dropped in tandem with the worsening search results.

The solution that NGINX implemented for this customer can benefit any site that needs to change its site architecture while continuing to achieve superior SEO results.

Solution Part 1 – Rewrite Rules

NGINX and NGINX Plus are powerful, flexible tools for redirecting requests. In this approach, you use NGINX rewrite rules to redirect old URLs, established when a site had a previous hierarchical structure, to new URLs, matching a new hierarchy.

The strong rewrite capabilities of NGINX and NGINX Plus have proven successful across a wide range of SEO concerns, including:

• User‑friendly visible URLs
• Translating old‑form URLs to new‑form URLs
• Standardizing use and nonuse of the www. prefix on a site name
• Accommodating common misspellings of URL elements, especially domain names

The large ecommerce site that recently came to NGINX for help had “broken” existing links and SEO results after they implemented a change to their site hierarchy. They were using a mix of rewrite rules, cascading configuration files, and custom application code to rewrite URLs. But their existing solution did not reliably transfer inbound links and search engine queries to the new URLs. They saw steadily worsening SEO results and declining sales.

With NGINX rewrite rules, they were able to reliably support existing inbound links and search engine queries, as well as map existing search engine information to their new site structure. They use conditional rewrite rules – old‑style links get rewritten, while newer links are left unchanged.

Here’s an example of using NGINX configuration code to support the transfer of content from one domain name to another, while preserving SEO results. The following code redirects clients to a completely different domain name:

server {
    listen 80;
    server_name www.old-name.com;
    return 301 $scheme://www.new-name.com$request_uri;
}

In this example:

• The listen directive captures HTTP traffic from port 80.
• The server_name directive applies changes to URLs with the old domain name.
• The return directive maps the old URL to a new domain name.

For details on this approach, including the use of the rewrite and try_files directives, with detailed examples, see Creating NGINX Rewrite Rules on our blog.

By adding NGINX to your stack, you can use several performance optimization strategies. NGINX rewrite rules enable you to implement changes to your site architecture without worry about possible SEO penalties. You can use NGINX as a reverse proxy server in front of existing application servers, to cache both static content (such as image files and CSS code) and dynamic content generated by your application servers, and to terminate protocols such as HTTPS, offloading even more work from your application servers.

Solution Part 2 – SSL/TLS and HTTP/2

If you don’t already use HTTPS – that is, implement SSL/TLS encryption for communication between users and your website – implementing rewrite rules gives you an opportunity to improve SEO results by moving to HTTPS. Rewrite rules help ensure that requests to the http:// version of your site are redirected to the new https:// location, with no loss of inbound link effectiveness or SEO juice.

This is an especially good time to move to HTTPS, even for pages that don’t have particularly sensitive user data. The reasons include:

• Search engines are increasingly rewarding the use of HTTPS – which, relatively speaking, means they are penalizing HTTP.
• The Chrome browser will soon add an icon (a padlock crossed out with a red “X”) to the URL bar of non‑HTTPS websites, implying that the site is insecure.
• The use of HTTPS is growing, having nearly doubled among the top million sites in the last year; sites that don’t use it may stand out to users in a bad way.
• The recent introduction of HTTP/2 means you can avoid all, or nearly all, of the performance penalty associated with using SSL/TLS and HTTP/1.x.
• By using NGINX as a reverse proxy server, you terminate HTTPS at the reverse proxy server; communications with backend servers use HTTP, with no performance overhead.
• If you do want secure communications between servers, using microservices and the Fabric Model of the NGINX Microservices Reference Architecture allows you to use SSL/TLS for interservice communications, with almost no performance penalty.

You can implement HTTPS in ways that minimize performance penalties, using techniques such as session caching, session tickets, and OCSP stapling (which includes SSL/TLS certificate content in the SSL/TLS response from the NGINX server).

Using rewrite rules, as described in the previous section, you can adopt SSL/TLS and HTTP/2 with no drop‑off in SEO or inbound link effectiveness. For instance, if you implement a reverse proxy server – which can include caching support, SSL/TLS termination, and/or HTTP/2 termination – then rewrite rules help you support your previous URL structure against a new physical layout for some or all of your files.

What to Expect

The customer we mentioned previously saw outstanding results from their rapid implementation of NGINX. Using rewrite rules, they mapped their previous URL structure to their new site hierarchy, which quickly restored the previous SEO ranking of their products and led to a rapid rebound in revenues. The customer still has the opportunity to fully implement HTTPS, which will give them a further increase in SEO ranking.

Using NGINX rewrite rules, you can give yourself needed site‑management flexibility, implement performance optimization strategies, and move to HTTPS, all without any SEO penalty caused by changes in your site hierarchy or URL contents.

To try NGINX Plus, start your free 30-day trial today or contact us to discuss your use cases.