
So you are working on your Next.js app (either in development or production) and everything is seemingly going well, until you pop open your console and discover a message similar to this:

```sh
  GET https://www.yoursite.com/_next/static/cRaZyRaNdOmStRiNg/pages/something.js net::ERR_ABORTED 404
```

Despite the error message detailing which file is missing, it is a fairly nebulous message, as it is not immediately obvious what needs to be done about it. And this is one of those errors that a lot of people seem to run in to, and have a hard time getting support for.

One option is to ask on the [Next.js Spectrum channel](https://spectrum.chat/next-js), my personal favorite place to scream in to a vacant abyss, so completely void of any response that even an echo would seem like a welcome voice of support.

Fast forwarding here, and lots of research later, you'll discover that the issue is that you did not create your `<Link>` components properly.

Here is what you probably did:

```jsx
<Link href={`/articles/${uri}`}>
  <a>Some text</a>
</Link>
```

Here is what you should have done:

```jsx
<Link href={`/something-else?uri=${uri}`} as={`/articles/${uri}`}>
  <a>Some text</a>
</Link>
```

What is going on in the second example is that href is telling the application which of your files in `/pages` to attempt to use to render this request, but to serve the URL as `/articles/the-page`. The first example makes the mistake of only including href, which basically says that the front-end URL shown to the browser should match exactly the name of the template in your `/pages` folder.

If that is the case in your application, you probably won't run in to this issue. If you have a fairly large application, you likely will need to specify these attributes to handle routing and logic properly.

Coding up your `<Link>` components as shown in the second example should solve your issue in development, however to completely remove the issue in production I had to add this to my `next.config.js` file ([supposedly you shouldn't have to](https://spectrum.chat/next-js/general/next-static-pages-js-404-not-found-build-issue~de17fd85-fd62-47e2-a324-93abd35f6837?m=MTU1Mzk0MjY4NjIzMQ==). In my case I had to):

```js
module.exports = {
  ...
  distDir: "_next",
  generateBuildId: async () => {
    if (process.env.BUILD_ID) {
      return process.env.BUILD_ID;
    } else {
      return `${new Date().getTime()}`;
    }
  },
  ...
}
```

See Link [Next.js](https://nextjs.org/docs#with-link) docs for more details.

Build, deploy, you should be good to go.


Solving "/_next/static/.../pages/***.js 404 Not Found"


Here was our situation as we approached launch of a recent Next.js-powered large content website. We were about 3 weeks away from launch and wanted to start the production server setup, testing deployment, exports, etc.

Everything was running smoothly until we got to the Next.js static exports part of the deployment. Thus far in the project, our team had always been running static export tests from their local dev machines which were some physical distance away from the production server. Sufficiently far that the dev machines were unlikely to overload the production server (the location of the API for the project).

If you are still trying to get static exports setup on your project, check out our [detailed post on the WPGraphQL blog](https://www.wpgraphql.com/2019/03/01/easy-static-html-exports-of-your-next-js-graphql-site/).

## Everyone's favorite error: 502

Nearly as soon as we fired off the export from the same server as the API, our terminals filled with 502 errors, specifically:

```js
Error while running `getMarkupFromTree` { Error: Network error: Unexpected token < in JSON at position 0
    at new ApolloError (/var/www/next/node_modules/apollo-boost/node_modules/apollo-client/bundle.umd.js:92:26)
    at /var/www/next/node_modules/apollo-boost/node_modules/apollo-client/bundle.umd.js:1581:34
    at /var/www/next/node_modules/apollo-boost/node_modules/apollo-client/bundle.umd.js:2001:15
    at Set.forEach (<anonymous>)
    at /var/www/next/node_modules/apollo-boost/node_modules/apollo-client/bundle.umd.js:1999:26
    at Map.forEach (<anonymous>)
    at QueryManager.broadcastQueries (/var/www/next/node_modules/apollo-boost/node_modules/apollo-client/bundle.umd.js:1997:20)
    at /var/www/next/node_modules/apollo-boost/node_modules/apollo-client/bundle.umd.js:1476:29
    at <anonymous>
    at process._tickDomainCallback (internal/process/next_tick.js:228:7)
  graphQLErrors: [],
  networkError:
   { ServerParseError: Unexpected token < in JSON at position 0
    at JSON.parse (<anonymous>)
    at /var/www/next/node_modules/apollo-link-http-common/lib/index.js:35:25
    at <anonymous>
    at process._tickDomainCallback (internal/process/next_tick.js:228:7)
     name: 'ServerParseError',
     response:
      Response {
        size: 0,
        timeout: 0,
        [Symbol(Body internals)]: [Object],
        [Symbol(Response internals)]: [Object] },
     statusCode: 502,
     bodyText: '<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body bgcolor="white">\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.10.3 (Ubuntu)</center>\r\n</body>\r\n</html>\r\n' },
  message: 'Network error: Unexpected token < in JSON at position 0',
  extraInfo: undefined }
```

This was a [WPGraphQL](https://www.wpgraphql.com/) ([our review](/blog/wpgraphql-the-hero-the-static-site-stack-needs/)) API, running from a Wordpress site. If you've been building Wordpress sites at substantial scale for some time, you can probably guess the error we got from PHP:

```js
[error] 1248#1248: *5807411 connect() to unix:/run/php/php7.0-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: website.com, request: "GET /this/page HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "www.website.com"
```

If you have run in to a 502 error on a Wordpress site, you also know that your day was just ruined. There are a near infinite number of causes to which this error could refer.

## De-DDOS yourself

It became clear after some discussion with @p-k on [Spectrum](https://spectrum.chat/next-js/general/next-static-export-crashing-graphql-server-i-think~b3267727-ed82-4a32-8030-0fc3461d0c5a) (ht for the excellent sleuthing on this), that the issue here is that Next.js export process runs on multiple threads, and due to the proximity of the applications and the speed of execution, you essentially DDOS yourself every time you export your site.

Since we plan to export several times a day as the site contents are updated, this would obviously have been a non-starter. This is also the reason why we don't build the site locally and simply deploy the exported site to production.

So, we need to tell Next.js to run on fewer threads and with lower concurrency in order to successfully build this site on the production server.

Easy enough: update your `package.json` file, specifically the export script to include the `--threads` and `--concurrency` options, for example:

```json
{
  "scripts": {
    ...
    "export": "next export --threads 1 --concurrency 1",
    ...
  },
  ...
}
```

This should solve the issue, but will mean _much_ slower export times. Ours went from about 10-12 minutes to about 60 minutes. Further testing will help us determine what the API can handle in terms of additional threads and higher concurrency. In the mean time, this still accomplishes our goal of multiple builds per day.

Check out the next post in our series on building static [Next.js sites, Next.js + Multiple Apollo Clients & GraphQL Sources](/blog/next-js-two-apollo-clients-two-graphql-data-sources-the-easy-way/)


Export your Next.js site without DDOSing yourself


The WP REST API was exciting back in 2016 for approximately 5 minutes, until you started using it. While it's nice to be able to request raw data from Wordpress, making the requisite nested queries to pull together a basic page with related posts had me lamenting the darkened soul of man.

Luckily, WPGraphQL has come along to get us querying Wordpress using GraphQL like modern hominids, and restored my faith in mankind's ability to overcome tediousness.

But WPGraphQL is about more than just freeing you from soul-crushing verbosity, it's also useful for building websites and software.

So I suppose we should touch on that as well.

## Emerging from the cave: The Wordpress-via-API pattern reaches maturity

We have been building websites and apps using the [Wordpress REST API](https://developer.wordpress.org/rest-api/) for 4 years now, and GraphQL on other projects since 2017. Only recently has there been the opportunity to "merge" the two (Wordpress and GraphQL). The combination is an extremely welcome evolution.

By the way, if you need a more general primer on GraphQL, the WPGraphQL has put together [a good walkthrough](https://docs.wpgraphql.com/getting-started/intro-to-graphql).

We have built websites and apps using several flavors of React front ends, from "vanilla" React to [Gatsby](https://www.gatsbyjs.org/) and [Next.js](https://nextjs.org/), and have become fond of saying that this stack (that is: a solid CMS, GraphQL and a React / similar front-end) is what they meant when they first said "website", all those years ago.

The stack provides the best experience from end-to-end:

- The developer gets the experience they have always wanted (whether they knew it or not)
- The customer gets a responsive developer who can literally do anything they can imagine with ease
- And the end-user gets insanely fast, static rendered HTML pages that still provide rich, interactive experiences

Which is why WPGraphQL plays such an important role in the modern web development stack: if you want to use this stack with Wordpress, it's simply a critical piece of your infrastructure.

While WPGraphQL is still a bit in its early days, it is already remarkably robust and full-featured. The team is knowledgeable, and as responsive of a free software / open source team as I have seen to feedback, issue & bug reports, and answering questions.

## Why do we refer to it as the hero the "static-site stack" needs? I.e. why so broad or agnostic?

We perceive WPGraphQL's value and relevance to be so broad because the chances are that you are probably using Wordpress as your CMS. And if you aren't, consider it.

While **front-end** templating with Wordpress has the same charm as a stroll through an old west ghost town, it's also nearly as engaging, robust and innovative.

However, WP Admin is great, and clients love using it. Plus, it's not going anywhere.

For internal and personal projects, we actually moved away from Wordpress for some time maybe 5-6 years ago. But, the evolving API brought us back, and for most sorts of projects (though definitely not all), it remains our go-to.

We envision that most large, robust sites will continue to use Wordpress, and that as WPGraphQL becomes more popular, that even **more** developers will opt to use it for their projects. Even the too-cool-for-school avant-garde.

Any failings Wordpress may have aside, it's the most developed CMS in the world, and with a solid GraphQL API available, there's simply no counterargument for most projects that fall within the general purview of "website".

## How full featured is WPGraphQL?

In our experience, there has been nothing that we have wanted to go that we cannot currently do as of the latest release. That doesn't mean that nothing is missing, just that as we have used the software, it has progressed to the point where all the endpoints we need are covered.

This means posts, pages, comments, categories, tags, custom post types, settings, menus, plugins, everything.

## Difference in development experience

Getting down to the nitty-gritty, let's take a look at what it's like to work with the REST API vs. WPGraphQL.

As mentioned earlier, we'll use the example of pulling the data for a simple post, along with some posts from related tags or categories, perhaps the most common use case.

### A basic content request via the REST API

I'll spare you the code spam of making requests but it essentially looks like this:

- Request the post, get back title, content, publish date, etc.
  - From the response, parse the URL + ID info for the featured image and tags and / or categories
    - Request the image endpoint, which will tell you where the images are
      - Request the tag and / or category endpoints. Let's say the first 10.
        - Request the posts at those endpoints. That's 10 API requests.
          - Request the images for each of those posts (10 more API requests! Each!!)

And this is the simple version. In reality you end up handling edge cases like an old post having no image, etc., all stuff that the WPGraphQL model handles for you.

Oh, and don't forget to do the same for the author and any attached metadata you want to get from the post!

### A basic content request via WPGraphQL

Now let's make the same request with WPGraphQL – only here we have already included the author and metadata:

```graphql
query GET_POSTS {
  posts {
    edges {
      node {
        id
        title
        date
        someCustomMetaData # some custom meta data
        author {
          firstName
          lastName
          email
          avatar {
            url
          }
        }
        featuredImage {
          mediaDetails {
            sizes {
              sourceUrl
            }
          }
        }
        categories(first: 10) {
          edges {
            node {
              name
              slug
              posts(first: 10) {
                edges {
                  node {
                    id
                    title
                    date
                    featuredImage {
                      mediaDetails {
                        sizes {
                          sourceUrl
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
        tags(first: 10) {
          edges {
            node {
              name
              slug
              posts(first: 10) {
                edges {
                  node {
                    id
                    title
                    date
                    featuredImage {
                      mediaDetails {
                        sizes {
                          sourceUrl
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
```

For the record, that is **one query** with _everything_ that we want. And it took about 30 seconds to write.

Which do you prefer? Which would you prefer to maintain? Which is going to give you more development agility and excitement to do more magic for your clients?

## Even more powerful when you have more than one application consuming this data

Consider this case for a moment. Using the REST API you would have around **double the code** to maintain. Remember those edge cases from the REST API section above? Well, using the REST API every consumer is responsible for its own fetch / parse / round-trip logic.

Whereas with WPGraphQL does all the heavy lifting, you can simply pass the same query or something completely new without having to create any new wiring (_ht WPGraphQL creator [@jasonbahl](https://github.com/jasonbahl)_).

## Fasten your cape

If you are not using WPGraphQL to build static websites with Wordpress, you soon will be. [Do yourself a favor and start today](https://www.wpgraphql.com/).

It's a web development superpower.


WPGraphQL: The hero the static-site stack needs


If you build websites or offer SEO services, unquestionably at some point you have run in to the question of the trade-offs and risks of changing the URL structure on a website.

For example, a website might have the following URL structure:

```
https://www.website.com/2019/04/26/the-post-title/
```

Whereas you would prefer to have something similar to either of these:

```
https://www.website.com/the-post-title/
https://www.website.com/articles/the-post-title/
```

You probably also know that such changes can be incredibly risky. If you work in either of the above mentioned disciplines, you likely feel the weight of the responsibility you bear either to your own business or your clients' businesses.

If you don't, just a very short summary: your content ranks where it does (let's say, _first page of Google_) because Google has found its URL, and it confident that if someone searches for a relevant query, it can send them to that URL and they will find the information they seek.

If that URL does not exist anymore because you have changed your URL structure and have not managed the change properly, your traffic also does not exist anymore.

## Suggested reading to brush up on URL structure and redirects

There is quite a lot of subtlety in getting this right, and much has been written on the subject. [This post on the Moz forum](https://moz.com/community/q/looking-to-remove-dates-from-url-permalink-structure-what-do-you-think-of-this-idea) covers the general gamut of questions and concerns.

We highly recommend [this post from Ahrefs](https://ahrefs.com/blog/301-redirects/) on the subject. The short version is this: You get this wrong you can kill their business - or at least severely hinder it for the near-term, along with your reputation. Take that as our disclaimer for pursuing this.

However, what that post does not cover, and what we have found to work incredibly well for safely changing URL, is the method described in this post.

We call it the **Toe-Dip Method** for changing URL structure.

## Why do a canon ball when you can simply dip in your toes?

Canon balls are great at pool parties with well-dressed company, but when it comes to advising our clients' businesses, changing the scenery calls for a bit more subtlety.

This post describes how to make substantial changes to the URL structure of a website, without risking tidal waves.

We use Wordpress in this post (since [there is a good chance you are using it](https://kinsta.com/wordpress-market-share/)), but the same concept would apply equally in other popular content management systems as well.

So let's dive in. ...er, test the waters.

## A bit of background

One of our clients with well over 10,000 posts on their website has, since the inception of the site used the date-based structure above (`site.com/yyyy/mm/dd/post-title`). What this means is that many of their high-quality posts are showing up in search results like this:

![Changing URL structure without betting the farm ||"width": "1024", "height": "569"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/changing-url-structure-cover-update.png)

<span>Things probably look about like this right now.</span>

What makes matters worse is that this client's industry is one where, rightly or wrongly, freshness of content is seen as an exclusive mark of relevance. So, even if search engines rank the content highly, their organic CTRs are unquestionably somewhat depressed by the age of the content.

Due to the competitiveness of the space, it has become a near imperative to change the URL structure, to ensure they are putting their best foot forward in every regard.

An idea dawned on us as to the best way to optimize risk vs. reward once we decided on the new URL structure:

```
https://www.website.com/articles/post-title
```

Consider this: if you are a veteran Wordpress user, the first thing that comes to mind when considering URL structure is the **Permalink Settings** page in WP Admin:

![Concept image of old content displayed in Google search result ||"width": "1024", "height": "534"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/current-permalinks-screenshot.png)

If you are not familiar with this screen, it's where you tell Wordpress how to structure the URLs of Posts on your site. It's a simple tool to manage something with huge impact. We'll come back to this screen later in the post to finalize our changes after doing lots of testing.

But the problem with looking at this page for a solution is that URL structure changes made here are **all-or-nothing**: change the setting on this screen and every post immediately changes, site-wide.

As the Yoast SEO plugin warns us at the top of this screen:

> Changing your permalinks settings can seriously impact your search engine visibility. It should almost never be done on a live website.
>
> Yoast SEO Plugin

How, then, could we test this new URL structure on just a subset of posts, say 20 or so, and then evaluate the results? Would search engines find the new home of the content without devastating rankings?

Here is how we did exactly that.

## The Toe-Dip Method, explained

We begin by creating a new custom post type called "Articles" (which will have a slug of "articles"). The best way to create and manage custom post types is the Wordpress plugin called CPT UI, or [Custom Post Type UI](https://wordpress.org/plugins/custom-post-type-ui/).

Install that plugin, and then create your new custom post type called "Articles". If you need instructions on setting up a new CPT, [view the documentation](https://docs.pluginize.com/category/126-custom-post-type-ui).

The best way to find out which posts to test URL changes with is to go to your Google Analytics (or similar) and find some posts that have substantial traffic, but may not be your top posts (again, mitigating risk). Make a list of the posts you want to test, save their names and URLs somewhere convenient, as you will want to come back to your analytics again several times over the coming weeks to evaluate performance.

Now to change the post-type of the posts in question, you will need to do one of two things.

You should either:

- Have database access and know-how, in order to find the ID of the post in question, and manually change the value of the `post_type` field from `post` to `article`, if you feel confident doing so. This method will be the faster, by far, as you begin to include lots of posts in the test. If you don't feel comfortable making this change, make sure to [hire a developer](https://loudnoises.io/contact/), and of course, back up your website first! Or,

- Install [Post Type Switcher](https://wordpress.org/plugins/post-type-switcher/), and make the change from the post edit screen. [Here is a post](https://wpshout.com/quick-guides/change-post-type/) on making the change with this method. Note: this method will become tedious as you include more and more posts in your test.

Use your chosen method for each post you want to test, and then a bit of magic happens. Since Wordpress processes requests based on the post-type of a post, you don't even need to manually create any redirects! As soon as you request the old URL again, Wordpress will automatically redirect you to the new url location at:

Use your chosen method for each post you want to test, and then a bit of magic happens. Since Wordpress processes requests based on the post-type of a post, you don't even need to manually create any redirects! As soon as you request the old URL again, Wordpress will automatically redirect you to the new url location at:

```
https://www.website.com/articles/post-title
```

In this way, the work is actually extremely minimal to accomplish the desired result. Our test posts now use our new, final URL structure, the rest of our content has no idea anything has changed, and we can sit back and wait to gather new analytics data to see how the changes proceed.

Before you move on, make sure you double-check that each URL is redirecting properly and everything works as expected. Would be a shame to have your test fail for an honest mistake.

## Establish test performance intervals

Now that you have your test in place, we recommend closely monitoring the performance of these URLs over the coming days and weeks. We used the following schedule to make sure we were keeping a close eye on things:

- One day after
- Three days after
- One week after
- Two weeks after
- Three weeks after

Why wait a full three weeks? Things change a lot with SEO and website performance, sometimes quickly, sometimes slowly. Our decision to run these tests for so long was based in the fact that we have a way to de-risk this change, and there was no substantial urgency, so why rush things and add risk by moving too fast? You can, of course, adjust your testing schedule to meet your the needs of your organization.

As alluded to previously, we started with only 20 medium-impact posts for our first test batch. Having seen success there (see "Our Results" below), we moved on to a larger batch of 100 posts, then 500 posts, then 1,000, then the remaining thousands of posts. Again, de-risking such a massive change was of critical important to us.

Worth noting, however, that as we established confidence with each subsequent test, we used shorter and shorter confidence intervals.

## Evaluating performance: setting up a quick report

The method we used here is fairly simple but extremely powerful, and once it's setup, dead-easy to use.

We're going to be creating a custom report in Google Analytics, which filters for the URLs we're interested in. Open up your Google Analytics, and click on Customization->Custom Reports from the top of the sidebar:

![Screenshot of the Google Analytics Customization nav bar ||"width": "281", "height": "220"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/create-a-google-analytics-custom-report.png)

Then, setup your report to match the settings we show here:

![Screenshot of the Google Analytics Customization nav bar ||"width": "1024", "height": "655"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/create-a-ga-custom-report.png)

Feel free to add any metrics you find relevant, but in this example we have just added "**Entrances / Pageviews**", as the primary thing we are concerned with here is the impact of this URL structure change on traffic.

The slight bit of "magic" going on here is that under **Filters** we have included a [Regex](https://support.google.com/analytics/answer/1034324?hl=en) filter on "articles". This is where the power of this report comes in, as we add new posts to the test, they will be automatically included here.

**Note**: as you include new URLs in the test, your traffic in this report will also increase, so be sure that you create **Notations** in your report to keep a log of when you have added new URLs, otherwise it will look like performance has _skyrocketed_ (which it may possibly do, thus the utility of the notation).

With our filtered report setup, we can now evaluate our low-risk URL structure change test, and see if this is a change we should be rolling out site-wide.

## Time to make waves: Making the final change

So, you've ran the tests described above, and traffic performance is (hopefully) either flat or has improved to some degree, as measured by your custom Google Analytics report. You've gained confidence that this is the right direction to take without risking your (or your client's) business.

Let's make it official.

Before we begin, make sure to backup your website (including your database) in case you make any mistakes or need to revert your changes for any reason.

The final steps in this process end up being a bit nuanced, but completely doable if you (or your developer) have a bit of "techiness". Why?

Well it may seem that all that remains now is to go to **Settings->Permalinks** again and assign a custom structure that starts with `/articles/`, as you see below:

![Screenshot of the Google Analytics Customization nav bar ||"width": "1024", "height": "529"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/changing-permalinks-old.png)

DO NOT DO THIS - unless you have (and will always have) only one post type on
your site. Then it should be ok. But TEST!

The problem that comes up is that if you have any other post types on your site, this change will also prepend `/articles/` to URLs of that post-type as well.

So we're going to approach making this change with a **four-step approach** here: using the **Permalinks** settings and some simple logic in your `functions.php`. Have your code editor ready and this file open, as you will want to make these changes very quickly (or you risk impacting users). Of course think though the change before saving, but when you are ready to move - move!

### Step 1: Edit permalink settings

Go back in to Wordpress admin, and go to **Settings->Permalinks** once more, and make the change that you see here (look to the **Post name** area):

![Screenshot of the Google Analytics Customization nav bar ||"width": "1024", "height": "538"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/updated-permalinks-structure.png)

If you have multiple post types on your site, this is the setting you want,
combined with the rest of the steps below

Now save your changes. But we're not quite done yet!

### Step 2: Adding logic to tell Wordpress to prepend `/articles/` to Posts only

Add the following to your `functions.php` file, editing the `articles` bit as needed, if you are not using exactly that string for your new URLs.

[Grab the code snippet for this funcion at this Gist](https://gist.github.com/paulisloud/765bf9022e05a91ddd733684cdc77cce)

The action (see `add_action`) rewrites the URLs for our posts. The filter (see `add_filter` edits the post links that Wordpress generates at various places throughout the backend and frontend of your site.

### Step 3: Reassigning `articles` as `posts`

We still need to reassign the post-type of all of the posts we assigned to the Articles post-type earlier. Use whatever method you selected above to change the post type on these posts back (will be much faster if you chose the database option. Be sure to [hire a developer](https://loudnoises.io/contact/) to make this change if you don't feel confident doing so yourself).

Then, delete the Articles post type from your site using the CPT UI plugin.

### Step 4 and a "gotcha": Regex redirects from your web server

Remember when Wordpress easily handled changing from `/yyyy/mm/dd/post-title` to `/articles/post-title`? Well, that's not going to be the case now, because by changing the permalink structure, we've effectively interrupted the mechanism that was at play before (Wordpress was giving us the benefit of the doubt based on the post type).

Since we are now outside of Wordpress' mechanisms for handling redirects, we will need to give our web server specific instructions on what to do when requests for date based (`/yyyy/mm/dd/post`) URLs are received. We use Nginx, and here is the little snippet we came up with to handle this final step:

```nginx
location ~ "/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)" {
  return 301 https://www.website.com/articles/$4;
}
```

Here we create a location block in our Nginx server using a [regular expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions) which will respond to any routes with the format `/yyyy/mm/dd/`, and redirect the request to whatever we set inside the block. The `$4` part of the snippet means basically "the fourth part of the regex above", which in this case is the slug for the URL, absent the date (which is composed of parts `$1`, `$2`, and `$3` (not used here).

If you use Apache instead of Nginx, review [this post on Stack Overflow](https://stackoverflow.com/questions/18880216/mod-rewrite-rule-using-date-regex), which seems to have the solution.

## Test thoroughly!

Now, check out your site to make sure everything is still working properly. If you've followed the instructions above, all of your Posts should now be free of the old date-based URL structure (or whatever you had previously) and use the new `/articles/` structure (or whatever you chosen).

Make sure that you continue to monitor the traffic performance of your website over the course of the coming weeks and months. But rest well knowing that you have taken what is probably the lowest risk approach to changing your URL structure.

## What if you did see a decrease in performance?

The first thing you are going to want to verify is that you have setup the test properly. Open up a few of your test URLs and make sure that your content is accessible at its new location.

All clear? Good, moving on. No? Re-read this post, you have missed something.

Check the previous URL for this content (the version which in our example would have had the `/yyyy/mm/dd` structure). When navigating to that URL are you redirected to the new test URL?

Yes? Good, moving on. No? Again, re-read this post, you've probably missed a step.

Also, make sure you are running these tests as a logged-out, anonymous user with no browser cache, as this can affect results (browsers cache redirects).

If both of those checks result in successful redirection, look at your the 404 logs on your server to see if there ever was any interruption in resource availability. Unlikely, but worth ruling out.

While there are other possibilities, those are the most likely. If you've excluded those options and performance on these test URLs has taken a dip, you have a few main options:

- Wait a few weeks, the situation may improve
- Wait for the next major algorithm update from Google. These are generally spaced 6-8 months apart, so we don't recommend this, but Google should be able to find this content and understand the redirect, so it is possible that a full re-crawl of your site in anticipation of a major algorithm rollout could result in a change in performance, but consider this an edge case.
- Revert your changes and walk away knowing that you tested making this URL structure change, and that it _would have been_ catastrophic had you made it globally, and you just saved either yourself or your client (or both) a lot of heartache, which makes you fantastic and well ahead of the pack.

## Our Results: A very big win

![Our test results ||"width": "1024", "height": "538"||](/blog/posts/0004-the-toe-dip-method-for-changing-url-structure/results.png)

In our experience, this method worked incredibly well, and the client not only maintained their traffic for the test posts, but dramatically improved it for nearly all posts tested.

The best part is this: at **_no point_** during this test were they ever severely exposed to a massive risk with their traffic. And traffic is up considerably as a result.

We feel that this recipe is the missing "secret" for safely making site-wide URL structure changes.

## Need help running this test, or want us to do it for you?

No problem, we'd be happy to help. [Reach out to us](https://loudnoises.io/contact/) with some basic details about your website and we'll follow-up with you.


The Toe-Dip Method for changing URL structure


In the same spirit of last week's post about [adding citations to Schema.org data](https://loudnoises.io/how-to-cite-sources-using-schema-org-in-json-ld/), this post provides a quick and easy method for adding Schema.org data to a Next.js site.

In this project I am using Apollo to pull data via GraphQL from a Wordpress site (which ends up generating a static HTML site) - so assume standard WP post data structure. This method assumes you have called the Schema component in your Post (or similar) component in your Next.js app. So, call the Schema component as follows:

```jsx
<Schema post={post} />
```

And the Schema component itself:

```js
import Head from "next/head";
import { site, siteTitle } from "../../config";

function strip(html) {
  const one = html.replace(/<\/?[^>]+(>|$)/gm, "");
  const two = one.replace(/[\r\n]\s*[\r\n]/gm, "");

  return two;
}

const Schema = ({ post }) => {
  const {
    title,
    blurb,
    featuredImage,
    date,
    modified,
    slug,
    commentCount,
    author,
    ratingCount,
    ratingAverage,
    citations,
  } = post;
  const published = new Date(date);
  const copyrightYear = published.getFullYear();

  let mediaDetails, sourceUrl;

  if (featuredImage) {
    sourceUrl = featuredImage.sourceUrl;
  }

  const citationsList = citations.map((citation, i) => {
    return `{ "@type": "CreativeWork", "citation": ${JSON.stringify(
      citation
    )} }${i === citations.length - 1 ? "" : ","}\n`;
  });

  const citationsText = citationsList.join("");

  const org = `{ "@id": "${site}#organization", "type": "Organization", "name":"${siteTitle}", "logo": {
    "@type": "ImageObject",
    "name": "${siteTitle} Logo",
    "width": "230",
    "height": "67",
    "url": "${site}images/logo.png"
} }`;

  return (
    <Head>
      <script type="application/ld+json">{`
    {
      "@context":"https://schema.org/",
      "@type":"Article",
      "name":"${title}",
      ${
        ratingAverage > 4
          ? `"aggregateRating": {
        "@type":"AggregateRating",
        "ratingValue":${ratingAverage},
        "reviewCount":${ratingCount}
      },`
          : ""
      }
      "about": "${blurb}",
      "author": { "@type": "Person", "@id": "${site}author/${
        author.slug
      }", "name": "${author.name}" },
      ${
        citationsText.length
          ? `"citation": [
        ${citationsText}
      ],`
          : ""
      }
      "commentCount": ${commentCount},
      "copyrightHolder": { "@id": "${site}#organization" },
      "copyrightYear": ${copyrightYear},
      "datePublished": "${date}",
      "dateModified": "${modified}",
      "description": "${blurb}",
      "discussionUrl": "${site}articles/${slug}#comments",
      "editor": { "@id": "${site}author/${author.slug}#author" },
      "headline": "${title}",
      ${sourceUrl ? `"image": "${sourceUrl}",` : ""}
      "inLanguage": "English",
      "mainEntityOfPage": "${site}articles/${slug}",
      "publisher": { "@id": "${site}#organization" },
      "sourceOrganization": ${org},
      "url": "${site}articles/${slug}"

    }
    `}</script>
    </Head>
  );
};

export default Schema;
```

You'll see a `strip` function that I left in place in the example. I am trying to decide whether or not to include the post `content` in the Schema data. If so, that function is used to clean up the HTML returned as content, so that we can include it in the JSON response.

[Here is a gist of this snippet](https://gist.github.com/paulisloud/1966bf21c70458e058b38cda6bfb9685) if you have any ideas on how to improve. PRs of course welcome.


Adding Schema Data to Next.js Sites


Next.js + GraphQL turns out to be a pretty stellar way to build both small & large-scale static websites, especially if you make use of Next.js' static HTML exports (see [my post on WPGraphQL](https://www.wpgraphql.com/2019/03/01/easy-static-html-exports-of-your-next-js-graphql-site/) for a how-to on this using GraphQL).

One of the questions that many developers seem to have, and which takes an astonishing amount of Googling, research and testing to sort out is building one of these sites with two GraphQL data sources.

## A bit of background & boilerplate

To set the stage for the solution, here is why this ends up being a little bit of a challenge. The basic setup for an Apollo client in Next.js [source](https://github.com/zeit/next.js/blob/master/examples/with-apollo/) involves three files:

- Our /pages/\_app.js component
- /lib/init-apollo.js
- /lib/with-apollo-client.js

First, lets take a look at `_app.js`:

```js
import App, { Container } from "next/app";
import React from "react";
import withApolloClient from "../lib/with-apollo-client";
import { ApolloProvider } from "react-apollo";

class MyApp extends App {
  render() {
    const { Component, pageProps, apolloClient } = this.props;
    return (
      <Container>
        <ApolloProvider client={apolloClient}>
          <Component {...pageProps} />
        </ApolloProvider>
      </Container>
    );
  }
}

export default withApolloClient(MyApp);
```

The gist here is that we import `withApolloClient` and wrap the rest of our app in that component, passing the `apolloClient` that comes along from props as a result. This gives our child components access to the data coming from the GraphQL source that Apollo is connected to. Onward.

In `init-apollo.js`, we create the Apollo client and tell it where to connect:

```js
import { ApolloClient, InMemoryCache, HttpLink } from "apollo-boost";
import fetch from "isomorphic-unfetch";

let apolloClient = null;

// Polyfill fetch() on the server (used by apollo-client)
if (!process.browser) {
  global.fetch = fetch;
}

function create(initialState) {
  // Check out https://github.com/zeit/next.js/pull/4611 if you want to use the AWSAppSyncClient
  return new ApolloClient({
    connectToDevTools: process.browser,
    ssrMode: !process.browser, // Disables forceFetch on the server (so queries are only run once)
    link: new HttpLink({
      uri: "https://api.graph.cool/simple/v1/cixmkt2ul01q00122mksg82pn", // Server URL (must be absolute)
      credentials: "same-origin", // Additional fetch() options like `credentials` or `headers`
    }),
    cache: new InMemoryCache().restore(initialState || {}),
  });
}

export default function initApollo(initialState) {
  // Make sure to create a new client for every server-side request so that data
  // isn't shared between connections (which would be bad)
  if (!process.browser) {
    return create(initialState);
  }

  // Reuse client on the client-side
  if (!apolloClient) {
    apolloClient = create(initialState);
  }

  return apolloClient;
}
```

Pretty straightforward what is going on here, but keep an eye on that link line, we'll be coming back to that...

And finally `with-apollo-client.js`:

```js
import React from "react";
import initApollo from "./init-apollo";
import Head from "next/head";
import { getDataFromTree } from "react-apollo";

export default (App) => {
  return class Apollo extends React.Component {
    static displayName = "withApollo(App)";
    static async getInitialProps(ctx) {
      const { Component, router } = ctx;

      let appProps = {};
      if (App.getInitialProps) {
        appProps = await App.getInitialProps(ctx);
      }

      // Run all GraphQL queries in the component tree
      // and extract the resulting data
      const apollo = initApollo();
      if (!process.browser) {
        try {
          // Run all GraphQL queries
          await getDataFromTree(
            <App
              {...appProps}
              Component={Component}
              router={router}
              apolloClient={apollo}
            />
          );
        } catch (error) {
          // Prevent Apollo Client GraphQL errors from crashing SSR.
          // Handle them in components via the data.error prop:
          // https://www.apollographql.com/docs/react/api/react-apollo.html#graphql-query-data-error
          console.error("Error while running `getDataFromTree`", error);
        }

        // getDataFromTree does not call componentWillUnmount
        // head side effect therefore need to be cleared manually
        Head.rewind();
      }

      // Extract query data from the Apollo store
      const apolloState = apollo.cache.extract();

      return {
        ...appProps,
        apolloState,
      };
    }

    constructor(props) {
      super(props);
      this.apolloClient = initApollo(props.apolloState);
    }

    render() {
      return <App {...this.props} apolloClient={this.apolloClient} />;
    }
  };
};
```

Here we return two different versions of our HOC App component (which later wraps the child components in `_app.js`): the first is for SSR mode, the second is for everything else.

## Apollo expects one client

You've probably noticed the implicit assumption in all of the logic above that there is precisely one client.

The problem is I want multiple data sources, and I want to query them in the style that the libraries I am using in my project intend. And I don't want to hack something together that will destroy my ability to benefit from all of Apollo's great features, etc.

One option that came up was [schema stitching](https://medium.com/open-graphql/apollo-multiple-clients-with-react-b34b571210a5), but it just seemed like way more than I wanted to get into just to be able to query two or more clients.

After having [lots of discussions](https://github.com/trojanowski/react-apollo-hooks/issues/132), doing [lots of research](https://github.com/apollographql/react-apollo/issues/464), and refactoring more times than I'd like to admit, I realized that it comes down the what you really want to have "multiple" of.

## The solution

So what is the answer here? Do I want multiple clients? Multiple providers?

Nope, you're way off. And probably because I misled you with the title. Or perhaps because the Angular Apollo library has this option, and it is in fact done with multiple clients.

But we're in the React world, and the answer is: multiple links in your one Apollo client.

Luckily to get there we only have to make minor changes to two of our three files.

In `init-apollo.js`:

```js
import { ApolloLink } from "apollo-link";
import { ApolloClient, InMemoryCache, HttpLink } from "apollo-boost";
import fetch from "isomorphic-unfetch";

let apolloClient = null;

// Polyfill fetch() on the server (used by apollo-client)
if (!process.browser) {
  global.fetch = fetch;
}

// Create First Link
const firstLink = new HttpLink({
  uri: "https://www.firstsource.com/api",
  headers: yourHeadersHere,
  // other link options...
});

// Create Second Link
const secondLink = new HttpLink({
  uri: "https://www.secondsource.com/api",
  headers: yourHeadersHere,
  // other link options...
});

function create(initialState) {
  // Check out https://github.com/zeit/next.js/pull/4611 if you want to use the AWSAppSyncClient
  return new ApolloClient({
    connectToDevTools: process.browser,
    ssrMode: !process.browser, // Disables forceFetch on the server (so queries are only run once)
    link: ApolloLink.split(
      (operation) => operation.getContext().clientName === "second", // Routes the query to the proper client
      secondLink,
      firstLink
    ),
    cache: new InMemoryCache().restore(initialState || {}),
  });
}

export default function initApollo(initialState) {
  // Make sure to create a new client for every server-side request so that data
  // isn't shared between connections (which would be bad)
  if (!process.browser) {
    return create(initialState);
  }

  // Reuse client on the client-side
  if (!apolloClient) {
    apolloClient = create(initialState);
  }

  return apolloClient;
}
```

## `link` parameter of the Apollo Client to the rescue

Note the changes made:

- We factored out our first link, for readability, since we will be creating a second one (note that you can pass any options you need to [Apollo link modules](https://www.apollographql.com/docs/link/) here)
- We imported ApolloLink, which has as an available method `.split()`. This method takes at least two parameters (though it doesn't really make sense to pass less than three):
- The first is a function to decide which link to use
- The second is the link to use if this function returns `true`
- The third is the link to use if the function returns `false`

At this point, you probably get the essence of what's going on here.

## Nothing like a bit of context to clarify...

The question remains though, how do we tell a component which GraphQL API to query? By using the context of the query. Here is an example:

```js
const { data, error, loading } = useQuery(GET_STUFF, {
  context: { clientName: "second" },
});
```

Note: I am using [react-apollo-hooks](https://github.com/trojanowski/react-apollo-hooks)' useQuery to run the query, but [works exactly the same using the Query component](https://www.apollographql.com/docs/react/essentials/queries) if you are not using react hooks.

So, the point of that example is that we can set the value of context to anything we want in our query, and then on the network site (in our ApolloLink method in `init-apollo.js`). Just make sure you use the same values in both places.

What I like to do is set up my Apollo client's link as follows:

```js
// ...stuff
    link: ApolloLink.split(
      operation => operation.getContext().clientName === "second", // Routes the query to the proper client
      secondLink,
      firstLink
    ),
// ...stuff
```

Note that the "firstLink" is shown second, which actually makes it the default data source to use, if the context value set in the query does not match the value the `split` function looks for. This means that we only have to set context when we want to use our "non-default" client.

## Updating with-apollo-client to give us fully rendered HTML exports

Ok, so entering the home stretch here, all we need to do it edit our `with-apollo-client.js` to match the following:

```js
import React from "react";
import initApollo from "./init-apollo";
import Head from "next/head";
import { getDataFromTree } from "react-apollo";
import { getMarkupFromTree } from "react-apollo-hooks";
import { renderToString } from "react-dom/server";

export default (App) => {
  return class Apollo extends React.Component {
    static displayName = "withApollo(App)";
    static async getInitialProps(ctx) {
      const { Component, router } = ctx;

      let appProps = {};
      if (App.getInitialProps) {
        appProps = await App.getInitialProps(ctx);
      }

      // Run all GraphQL queries in the component tree
      // and extract the resulting data
      const apollo = initApollo();
      if (!process.browser) {
        try {
          // Run all GraphQL queries
          await getDataFromTree(
            <App
              {...appProps}
              Component={Component}
              router={router}
              apolloClient={apollo}
            />
          );
          // Create static markup for SSR HTML export
          await getMarkupFromTree({
            renderFunction: renderToString,
            tree: (
              <App
                {...appProps}
                Component={Component}
                router={router}
                apolloClient={apollo}
              />
            ),
          });
        } catch (error) {
          // Prevent Apollo Client GraphQL errors from crashing SSR.
          // Handle them in components via the data.error prop:
          // https://www.apollographql.com/docs/react/api/react-apollo.html#graphql-query-data-error
          console.error("Error while running `getDataFromTree`", error);
        }

        // getDataFromTree does not call componentWillUnmount
        // head side effect therefore need to be cleared manually
        Head.rewind();
      }

      // Extract query data from the Apollo store
      const apolloState = apollo.cache.extract();

      return {
        ...appProps,
        apolloState,
      };
    }

    constructor(props) {
      super(props);
      this.apolloClient = initApollo(props.apolloState);
    }

    render() {
      return <App {...this.props} apolloClient={this.apolloClient} />;
    }
  };
};
```

Note the only changes / additions are the two imports final imports (`getMarkupFromTree` & `renderToString`), and the addition of the getMarkupFromTree section, which allows us to have fully-rendered static HTML exports from Next.js.

## But what if I need more than two data sources in my application?

Well, funny you should ask, because the trick above (the `.split()` operation on `ApolloLink`) only works with up to two links. Bit of a chin scratcher at first, until you realize that the second `link` passed to the `.split` method does not have to be an `HttpLink`.

This second link can be another `ApolloLink`! As you can see below, we can just keep chaining links together until we've checked context on all possible data sources:

```js
// Create First Link
const firstLink = new HttpLink({
  uri: "https://www.firstsource.com/api",
  headers: yourHeadersHere,
  // other link options...
});

// Create Second Link
const secondLink = new HttpLink({
  uri: "https://www.secondsource.com/api",
  headers: yourHeadersHere,
  // other link options...
});

// Create Third Link
const thirdLink = new HttpLink({
  uri: "https://www.thirdsource.com/api",
  headers: yourHeadersHere,
  // other link options...
});

const otherLinks = ApolloLink.split(
  (operation) => operation.getContext().clientName === "third", // Routes the query to the proper client
  thirdLink,
  firstLink
);

function create(initialState) {
  const client = new ApolloClient({
    connectToDevTools: process.browser,
    ssrMode: !process.browser, // Disables forceFetch on the server (so queries are only run once)
    link: ApolloLink.split(
      (operation) => operation.getContext().clientName === "second", // Routes the query to the proper client
      secondLink,
      otherLinks
    ),
    cache: new InMemoryCache({ fragmentMatcher }).restore(initialState || {}),
  });
  return client;
}
```

## Bonus: but what about multiple queries?

If you are connecting to multiple clients, chances are that _somewhere_ in your project you will need to run two queries in the same component. Sure, we could import compose from `react-apollo` in to our project, but there's really no need in this case ([source](https://github.com/trojanowski/react-apollo-hooks/issues/120#issuecomment-477660041)). We can simply make our own hook (if you are using React hooks). This ends up looking something like:

```js
const queryMultiple = () => {
  const res = useQuery(GET_POST, {
    variables: {
      uri: props.uri,
    },
  });
  const res2 = useQuery(GET_SHOP, {
    context: { clientName: "second" },
  });
  return [res, res2];
};

const [res, res2] = queryMultiple();
const { data, error, loading } = res;
const { data: secondData, error: secondError, loading: secondLoading } = res2;
```

Hat tip to [@ThomasK33](https://github.com/ThomasK33) for his help on sussing this out.

## Bonus #2: What about mutating on multiple sources?

As of the most recent update here (and I will update this post as the situation changes), the answer seems to be "it depends".

If you are using a `<Mutation>` HOC, you can easily pass context to the operation ([docs](https://www.apollographql.com/docs/react/api/apollo-client/#ApolloClient.mutate)), and select your data source in a similar fashion to what we did above.

However, if you want to pass context to useMutation from the unofficial [react-apollo-hooks](https://github.com/trojanowski/react-apollo-hooks) library, you appear to be out of luck at present. The good news is that the official [Apollo React Hooks](https://www.npmjs.com/package/@apollo/react-hooks) library is currently in [beta](https://www.npmjs.com/package/@apollo/react-hooks), and it seems a certainty that they would include context as a property in their version of useMutation, so a solution here is likely around the corner.


Next.js + Multiple Apollo Clients & GraphQL Sources

Next.js + Plusiers Apollo Clients & GraphQL Sources

Next.js + Molteplici Clienti Apollo & GraphQL API


So you want to add your list of sources as citations to an article, blog post, or some other creative work? This is a short and sweet post that gives you the output format you are looking for.

This has been run through Google's [Structured Data Testing Tool](https://search.google.com/structured-data/testing-tool/) and successfully validates.

```json
{
  "@context": "https://schema.org/",
  "@type": "Article",
  "name": "The article title",
  "about": "The subject of your article",
  "author": {
    "@type": "Person",
    "@id": "https://www.website.com/author/your-name",
    "name": "Your Name"
  },
  "citation": [
    {
      "@type": "CreativeWork",
      "citation": "Smith et al, \"Some cited work\" Some Journal, Jan. 2015. "
    },
    {
      "@type": "CreativeWork",
      "citation": "Hatcher et al, \"Some other cited work\" Another Journal, Mar. 2019. doi: 12.3456/abc.01.123"
    }
  ],
  "commentCount": 100,
  "copyrightHolder": {
    "@id": "https://www.website.com/#organization"
  },
  "copyrightYear": 2019,
  "datePublished": "2019-04-23 01:23:45",
  "dateModified": "2019-04-23 03:23:45",
  "description": "The subject of your article",
  "discussionUrl": "https://www.website.com/blog/your-post#comments",
  "editor": {
    "@id": "https://www.website.com/author/your-name#author"
  },
  "headline": "The article title",
  "image": "https://www.website.com/wp-content/uploads/image.jpg",
  "inLanguage": "English",
  "mainEntityOfPage": "https://www.website.com/blog/your-post",
  "publisher": {
    "@id": "https://www.website.com/#organization"
  },
  "sourceOrganization": {
    "@id": "https://www.website.com/#organization",
    "type": "Organization",
    "name": "Our Company",
    "logo": {
      "@type": "ImageObject",
      "name": "Our Logo",
      "width": "230",
      "height": "67",
      "url": "https://www.website.com/images/logo.png"
    }
  },
  "url": "https://www.website.com/blog/your-post"
}
```

Other fields have been added above for context, and because this stuff can be a PITA to figure out.

You'll obviously want to edit the other fields accordingly. Happy citing!
