Post/Redirect/Get

 Share 

Purpose

Figure: Post/Redirect/Get - Author: Seobility - License: CC BY-SA 4.0

The Post/Redirect/Get pattern prevents duplicate form submissions on a website when a user updates a page or clicks the back arrow in his browser. This problem can occur, for example, with orders in an online shop or registrations on a website. The following example illustrates this situation:

Let's say a user completes an order in an online shop and then directly gets to the confirmation page. If the user now clicks on "Refresh" or "Back" in his browser and no Post/Redirect/Get is implemented, the POST form (i.e. the order) is sent to the server again, which can theoretically result in undesired consequences like duplicate orders and/or payments, among other things.

In practice, browsers react by opening a window and asking users whether they really want to resend the data in such cases. However, t users who do not have in-depth technical knowledge may not understand this question and click on yes anyway. This can harm the website’s usability.

Background information: GET vs. POST requests

Basically, both GET and POST requests can be sent to a server.

A GET request is used to request data from a server, such as HTML files, images, etc. Such forms can be crawled by Google.

POST, on the other hand, is a method of transferring data to a server. In contrast to the GET method, Google cannot follow POST forms in most cases.

How Post/Redirect/Get works

To explain how the Post/Redirect/Get pattern works, we will use the example of placing an order at an ecommerce store again. The process can be divided into three steps:

• Step 1 (POST): A user completes their order and sends a POST request to the server using his browser. The server, in turn, processes this request and saves the order in a database.
• Step 2 (REDIRECT): Instead of sending the confirmation page directly to the user, the server replies to the browser with a redirect (with status code 3xx) to a new URL, which leads to the confirmation page.
• Step 3 (GET): Due to the redirect, the browser then sends a new GET request to the server (since it must retrieve a new URL), in order to request the confirmation page.

If the user now updates the page, the browser sends another GET request and the server responds with the confirmation page. Without the PRG pattern, the user would resend the POST request by refreshing the page and the server would save the order twice.

Code example

The following simplified code example illustrates how the PRG pattern works:

If post data transferred Then
  execute code (such as database updates)
End If 

set location header with requested URL
End

Best practices for implementing the PRG pattern

When implementing the Post/Redirect/Get (PRG) pattern, it’s beneficial to adhere to a number of general best practices. Some of these include:

• Consistent use: Apply the PRG pattern consistently on all forms across your application to prevent form resubmission issues and enhance user experience.
• Clear user feedback: After a POST request, provide clear feedback to the user. For instance, display a success message or confirmation page following the redirect.
• Idempotent GET requests: Ensure that GET requests are idempotent, meaning they can be repeated without causing additional changes or side effects.
• Proper status codes: Use appropriate HTTP status codes for redirects (e.g. 301) to clearly communicate the nature of the redirect to clients and browsers.
• Bookmarkable URLs: Design URLs to be bookmarkable and shareable, especially for the final GET request, improving the user experience.

Common pitfalls in implementing the PRG pattern

While the PRG pattern can be very beneficial, developers can sometimes run into issues. Being aware of these can help avoid common issues:

• Overuse of the pattern: Implement the PRG pattern only where necessary. Overusing it, especially for simple GET requests, can complicate the application unnecessarily.
• Losing form data: Ensure that any form data or user input is not lost during the redirect process. Utilize sessions or other mechanisms to persist data when needed and test thoroughly before deployment.
• Ignoring user experience: Neglecting user experience can lead to confusion. For example, not providing feedback after a form submission or redirect can leave users uncertain about the action's outcome.
• Inadequate error handling: Failing to handle errors properly can lead to a poor user experience. Implement robust error handling to manage exceptions and provide informative messages to users.

Benefits for search engine optimization (SEO)

The PRG pattern not only prevents multiple submission of form data to a web server but can also be beneficial in the field of search engine optimization (SEO), for example with regard to filter navigation (faceted navigation) in online shops.

Such navigations can be problematic because the various filter functions (e.g. by color, size, etc.) are implemented by URL parameters and thus generate a large number of new URLs. The mass of internal links associated with this requires a high amount of the limited crawl budget for a website, which may be needed for other subpages. In addition, problems can arise with (near) duplicate content if the products displayed on the various filter pages are very similar.

The PRG pattern provides a solution to this problem: filter links on the website are integrated as a POST form. The form element is hidden by display:none or visibility:0. When such a filter link is clicked, a POST request is sent to the server. The server responds with a redirect to the original result page, which now contains the corresponding parameters in its URL. Since Google bot does not follow the POST form, it cannot find this URL, which avoids duplicate content and effectively uses the crawl budget for the website. At the same time, the URL exists and can, therefore, be shared by users.

This can help to optimize crawl budget in certain situations. However, since the pages do still exist and are technically crawlable if search engine crawlers do discover the pages, for example via a backlink, other techniques (e.g. robots.txt) may also be required.

Another advantage of this method is the ability to control the link equity that is passed from a page. Link masking using PRG patterns allows webmasters to control exactly which links this link equity should flow to and which it should not (= masked links). This makes it possible to bundle the link equity on really relevant pages that should appear in Google’s search results.

Practical relevance

As you can see from the examples above, the Post/Redirect/Get pattern is especially relevant for online shops to avoid duplicate orders and to hide filter links from Google bot.

A possible problem, however, is that the PRG pattern is not supported by every content management system and implementing it by yourself requires in-depth programming knowledge. For this reason, despite its advantages, the method is not used by many shop operators.

In summary: Post/Redirect/Get FAQs

What is the Post/Redirect/Get pattern?

Post/Redirect/Get stands for a pattern that is used to avoid duplicate form submissions, for example in online shops.

What is an example for Post/Redirect/Get usage?

A common example is e-commerce. Post/Redirect/Get can prevent customers from placing an order multiple times. Without the PRG pattern, refreshing the confirmation page after buying something could send the order again.

What is the difference between POST and GET?

GET requests are used to request files while POST is used to transfer data to a server.

Why is Post/Redirect/Get good for SEO?

Post/Redirect/Get can help you to avoid problems with duplicate content, especially if you are using faceted navigation.

Similar articles

• WWW Redirect
• GET Parameters