# Installation

## Staying on search engines

Naviga web has clean and friendly article URLs, based on article Section and Headline. Making it as friendly both for humans and robots. To make search engines happy you should have all your old URLs redirected to these new Naviga Web URLs.

Naviga Web redirects with *HTTP/1.1 301 Moved Permanently* to set correct new protocol, domain and URL.

{% hint style="info" %}
For redirects to work, article mapping needs to be done **before go-live**, otherwise search engines will crawl and find 404:s, resulting in the migrated articles being permanently deleted from the search result. On migration of old articles, make sure you add all existing old URLs for every article.
{% endhint %}

## Map old URLs in article metadata

Add old URLs as *itemMetaExtProperty* values like this.

```markup
<?xml version="1.0" encoding="UTF-8"?>
<newsItem ...>
    <itemMeta>
        <itemMetaExtProperty type="imext:originalUrl" value="https://example.com/my-old-article-1.234"/>
        <itemMetaExtProperty type="imext:originalUrl" value="http://www.example.com/my-old-folder/my-old-article/"/>
        ...
    </itemMeta>
    ...
</newsItem>
```

The syntax is important, but some variations are supported.

{% hint style="success" %}
**Supported URL variations**

As you see in the example above, originalUrl has some wildcard support. The plugin will match visitors coming from URLs:

* both with "http" and "https"
* both with and without leading "[www](http://www)." subdomain
* both with and without trailing slash ("/")
  {% endhint %}

This being said, it is preferable to enter the **exact** old URLs that the search engines have indexed.

{% hint style="success" %}
**Multiple URLs**

Multiple originalUrls per article is supported.
{% endhint %}

## Setting up the plugin

The plugin needs to be configured to run optimally. Most of it can be done automatically.

When you have entered all your originalUrls, go to the plugin's settings page.

Start by configuring the field *Name of the OriginalUrls property*. By default, it is "OriginalUrls". You only need to change this if you have another value in your OC configuration. If you are using Base Theme 1, you should change the value to "OriginalUrl".

Press the "Analyze migrated URLs..." button to search your OC. When analysis is done, the form will automatically suggest optimal values to not use more wildcards than is actually necessary.

If you find that there is any domain missing in the *Domains used* list, you can add it manually and press "Analyze migrated URLs..." again.

Save the settings.

### If you have had multiple domains

If you have originalUrls from any other domain name(s) than the one you currently use, you can configure your domains in different ways.

If precision is extra important (for example, if you both have an originalUrl <https://old-site.com/sports/> and a current URL <https://new-site.com/sports/> , and they should lead to different content), point your old domains' DNS to the same server as your new one, and use [*Domain mapping plugin*](https://wordpress.org/plugins/wordpress-mu-domain-mapping/) to connect them to the same Wordpress site. That way, the Redirect Original URLs plugin is guaranteed to get to work on the actual originalUrl, rather than a redirect to <https://new-site.com/sports/> .

If cases like the above are not an issue, the plugin will handle the redirects automatically.

## Test and development

### How to verify that your migrated document in Open Content will work?

You can test your originalUrl by using public Open Content search.

This is an OC match query. You can run it on your public Open Content to test your migration:

`contenttype:Article AND OriginalUrls:"https://old.com/foo"`

Replace the URL above with the **exact** OriginalUrl that you put in *itemMetaExtProperty*.

## How to test on stage or local dev environment?

{% hint style="success" %}
No extra metadata is required for stage and local dev environments. They are mapped to production domain automatically.
{% endhint %}

Simply try URL:s on your stage or local dev environment as if it were your production environment. This also works if you have original URLs from another domain than your production environment.

**Example:** if the original URL is \
&#x20;<https://old-site.com/1999/05/13/headline> , and the final URL should be \
&#x20;<https://new-site.com/section/headline/> , and your stage or local dev environment is running on \
&#x20;<https://your-site.stage.infomaker.io/> , then simply test \
&#x20;<https://your-site.stage.infomaker.io/1999/05/13/headline> . It should redirect to \
&#x20;<https://your-site.stage.infomaker.io/section/headline/> .

{% hint style="warning" %}
Caveat: If you have several old domains, and they have some URLs with identical paths, such as <https://old-site1.com/1999/05/13/headline> and <https://old-site2.com/1999/05/13/headline> , you can only test one of them.
{% endhint %}

## Redirects when new Naviga content change?

When you change URL for an article, Naviga Web will automatically remember the old and handle redirects for you.

If you delete (unpublish) an article it will be removed; page not found (404). Republishing will not give you a redirect.

Same goes for Concepts and other content.

## Static content and redirect between sites

If you want some custom URLs you can do that with different 3rd party plugin settings, for example [Simple 301 Redirects](http://scottnelle.com/simple-301-redirects-plugin-for-wordpress/).

{% hint style="success" %}
**That solves in-site shortcuts:**

`/about` =>`/customer-service/contact-information/about-us`

**And nice marketing links:**

`/podcast` => `https://www.our-podcast-platform.com/example-site`
{% endhint %}