Your questions
Our answers

Our web tools (web editor & cockpit) run in any reasonably modern browser, such as Chrome, Firefox, MS Edge, or Safari. Our web editor is usually most performant in Chrome or MS Edge.

Our native macOS editor requires macOS 10.13 or later and works best on macOS 11 "Big Sur" or later. We support both Intel and Apple Silicon.

Your pagestrip publications work in any browser released within the last 5 years, and usually even older versions as well. However, we do not support Internet Explorer 11 anymore.

Yes! While we do not track your readers ourselves for reasons of data privacy, you can integrate any tracker or analytics tool that you already have in use. This is also advantageous, since you won't have to learn a new tool, but will see all your analytics in one place instead.

If you embed pagestrip on your business website, it will attempt to use your existing trackers automatically, provided that they are loaded by your website. In this case you won't need to set up anything specific, and everything will "just work".

In case you need help with setting up your analytics with pagestrip, and it doesn't work out-of-the-box, please reach out, and we'll figure it out together.

All your data is hosted with pagestrip. We do not use any third-party providers in our tools, such as Google Fonts or Javascript CDNs.

Our infrastructure is provided by Amazon Web Services. Our contractual party is Amazon Data Services Austria GmbH, which is located in Vienna, Austria (Europe) – much like ourselves.

We only use AWS locations in Europe for our storage and origin servers. Personal data that you do not make publicly available in a story (which can thus be accessed from anywhere in the world) will therefore not leave the EU area.

No, we are currently not offering self-hosting of our software stack. pagestrip includes a lot of dynamic components and microservices, such as image processors, feed generators, and a tiered CDN infrastructure, which would not be trivial to recreate in a third-party environment.

However, as per our license terms, we will continue to host your content indefinitely, even if you cancel your license (you only lose the ability to create new content).

Additionally, in our native macOS editor, you can actually export stories or collections of stories to a folder or zip file and host them statically yourself, but we do not provide customer support for this setup.

Yes, there are multiple ways to setup private, internal publications:

You can protect your project with a password if you view it via pagestrip.com or your own custom domain. Alternatively (or in addition), you can whitelist specific IP address ranges to bypass the password protection. As an example, you can use this for an employee magazine, where people can access it from home by using a password, but access within your office network or VPN is unrestricted.

If you intend to embed content in an already private area, such as an intranet, you can add an authentication key to the embed in order to bypass the protection. Thus, people accessing the embed in your intranet will not be prompted for a password, but your content is still protected from access from anywhere else.

You only need to set up a CNAME record in your DNS settings: Simply create a CNAME for your desired domain name (say, magazine.brand.com) that points to customers.pagestrip.com.

If you want to use a top-level domain, we recommend to set up the CNAME to www. at that domain instead and provide a redirect from domain.com to www.domain.com via your domain provider. This way, you remain in control of your domain and can use features such as hosting email at that domain yourself, even if you want to set these up later instead.

If your domain is proxied by a CDN service such as Cloudflare or Fastly, we recommend to turn off proxying for your pagestrip domain. We already provide our own caching and WAF infrastructure, so that an additional proxy won't do any good (and can, in rare cases, actually cause issues).

If you do not add your own trackers to your pagestrip project, you do not need a cookie banner, since pagestrip does not track your readers.

If you use your own tracker, it will most likely require a cookie banner. Some trackers already come with their own consent management, or you may be using another consent tracking solution already. In these cases, please refer to the documentation of your trackers and consent managers in order to find out which codes you need to add to your pagestrip project to make them work there.

If you have a tracker, but no consent manager, you can also create a cookie banner in pagestrip directly: While we do not enforce a specific design for cookie banners, we recommend that you set it up in a way that all buttons, including the "reject" button, are of a similar visual appearance, since cookie banners emphasizing one option over another have been challenged in courts all throughout Europe before.

If you embed pagestrip into an existing website, it will likely already come with trackers and consent managers, so you won't have to set up anything additional for your embed in this case.

While there isn't a specific API to hook directly into our rendering and styling system, there are some possibilities:

Our editors include a widget box, which enable you to include existing HTML/CSS/Javascript code verbatim. If you write code and add it into a widget box, it will execute when the page is rendered to the screen. This is a great way to add elements to a story, such as newsletter signups or third-party widgets.

You can also react to page navigations within a pagestrip publication by registering a listener for the DOM event "psNavigate", which will be emitted by the host element of your pagestrip embed and bubbles up all the way to the document. The details of this custom event include ample information about the navigation.

However, we discourage you from using CSS selectors referring to pagestrip-generated classes and overwrite CSS properties: Not only is it easy to introduce subtle bugs and problems by interfering with our renderer, but these classes are also randomized during our build process, so that they may change at any time.

You genereally don't need to worry about script loading order within a widget box. Our renderer takes care to handle your scripts similarly to how they would work on a static HTML page, specifically:

• Script tags that are not async or deferred will be loaded and executed in-order, so that these scripts are each executed before the next one is fetched and run.
• Script tags that are either async or deferred will be loaded in parallel and be executed whenever they have finished loading.
• Script tags containing inline scripts will be executed in-order, and subsequent script tags will be deferred to run in the next browser frame.

From your perspective, you only need to include a short HTML snippet into your host page. This script will fetch and render your pagestrip content within the context of the host page at the location where you have placed the snippet.

The embed will immediately (per default, but this is configurable) show an empty placeholder to "stretch" your host page apart. This prevents layout shifts when the content is rendered. If there are any DOM elements within the target of your embed, they will be cleared automatically when the embed runs.

The embed isolates CSS properties and global Javascript state from your host page by using specificity prefixing and IIFE-style module loading.

During operation, the embed takes great care to feel as native as possible to your readers: As an example, scroll positions will automatically be managed when you use the back/forward buttons in your browser, fixed elements in your host page are automatically detected for positioning fixed elements in pagestrip against them, and so much more.

Additionally, you can deep-link directly to any page within your embed.

There aren't any specific requirements in terms of which system or CMS you are using for your host website, but there are some points to keep in mind:

• You need to be able to add an HTML snippet to your host page. Usually, this can be done by users themselves in most CMS systems, but sometimes, it may require a developer. In any case, the task is rather easy, though.
• If you use a strict content security policy on your host page, you need to make sure that loading scripts and media data (fonts, images, etc…) is allowed from *.pagestrip.com.
• If you are blocking outbound connections to some domains or websites in your business-internal firewall, make sure that access to *.pagestrip.com is allowed for your users. Always white-list by domain, not by IP address(es): Our infrastructure uses IP addresses that depend on access location and can change at any time.
• If your host page uses CSS with !important modifiers on unscoped HTML tags, there may be minor visual glitches in your embed. However, professional sites using such CSS structure are rare, so this is usually not an issue and can always be fixed with local CSS overrides in any case.

Yes! Please use the HTML snippet below to test the embed straight-away. It will render a simple story. Add the code to an "empty page" in your CMS or on your website and have a look at the results.

<script src="https://j2.pagestrip.com/public/dist/player/loader.min.js" charset="UTF-8"></script>
<div id="pagestrip_demo-embed-35C4Hlew"><div style="min-height:100vh;"></div></div>
<script>
  (function () {
    (((s=window.pagestrip)&&(s=s.render))||function(e){e.innerHTML="<a href=//pagest.rip/7>NOT LOADED</a>"})(
      document.getElementById("pagestrip_demo-embed-35C4Hlew"),
      {
        publisher: { embedId: "demo-embed-35C4Hlew" }
      }
    );
  })();
</script>

If you need additional help, have questions or even issues with the embed, don't hesitate to get in touch with us.

Yes! While we want to underline that the only issue to take with the hashbang is for aesthetic reasons, you can switch our embed to use browser paths instead.

However, you'll need to do some configuration on your host server for this: You need to rewrite URLs (not redirect!) below the path of your embed host page to the URL of the embed host page. As an example, if your embed is available at the path /my-brand/magazine/, you need to rewrite URLs such as /my-brand/magazine/my-pagestrip-story/ to /my-brand/magazine/.

Without these rewrites, your readers would receive a "not found" error from your website when they refresh the deep-link directly, since your website is not aware that there is pagestrip content available at that sub-path.

Please refer to your host site's documentation or the documentation of your web server on how to set up rewrite rules. With nginx, this can be done in your nginx.conf, and for Apache you can use an .htaccess file.

Once your rewrite rule is implemented, you need to modify the pagestrip embed code to switch it into browser URL navigation mode and tell it about the base path of your embed page, so that it knows which part of the URL path are managed by your web server, and which part shall be managed by the embed. Building on our example from below, where your embed is located at /my-brand/magazine/, you would update your embed code with the following "router" option (the embed code below refers to a demo story):

<script src="https://j2.pagestrip.com/public/dist/player/loader.min.js" charset="UTF-8"></script>
<div id="pagestrip_demo-embed-35C4Hlew"><div style="min-height:100vh;"></div></div>
<script>
  (function () {
    (((s=window.pagestrip)&&(s=s.render))||function(e){e.innerHTML="<a href=//pagest.rip/7>NOT LOADED</a>"})(
      document.getElementById("pagestrip_demo-embed-35C4Hlew"),
      {
        publisher: { embedId: "demo-embed-35C4Hlew" },
        router: {
          history: "browser",
          basename: "/my-brand/magazine/"
        }
      }
    );
  })();
</script>

Please adapt basename to match the path you are actually using. Also ensure that this path ends with a / (slash).

Congratulations, you are now using path-based URLs with your embed! Also, be aware that all previous links (with #!) will continue to work and redirect you to the new URL (without the #!), so you don't need to worry about older links breaking.

Yes! This is a sensible setup when you embed only a single story where your readers can't navigate within the embed. Since there is no URL change anymore, browser back/forward navigation would not work between deep-links, and search engines couldn't index deep-links as well, but that doesn't matter for a single-story embed.

If you want to enable this behavior, please add the following "router" option to your embed, like in this example code (that refers to a demo story):

<script src="https://j2.pagestrip.com/public/dist/player/loader.min.js" charset="UTF-8"></script>
<div id="pagestrip_demo-embed-35C4Hlew"><div style="min-height:100vh;"></div></div>
<script>
  (function () {
    (((s=window.pagestrip)&&(s=s.render))||function(e){e.innerHTML="<a href=//pagest.rip/7>NOT LOADED</a>"})(
      document.getElementById("pagestrip_demo-embed-35C4Hlew"),
      {
        publisher: { embedId: "demo-embed-35C4Hlew" },
        router: {
          history: "memory",
        }
      }
    );
  })();
</script>

That's it! The URL won't change anymore when the embed loads, and navigation is technically still possible, but the URL won't change either (in fact, the "memory" history acts like a hidden internal URL that only exists in memory, so that the "real URL" doesn't need to be changed).

Yes! You can manage all behavioral, SEO and other settings per embed in our cockpit at any time, and the changes will immediately become active anywhere the embed is already placed.

The only options that need to be set at the embed code directly are the router options as described in the previous two FAQ items about URLs: This is because the URL scheme already needs to be known at the time when the embed loads, so it can unfortunately not depend on any options loaded together with the embed.

Platforms like Facebook expect OpenGraph metadata (like a story title and image) to be present directly in the server response sent by the host site where the embed is placed. It is technically impossible for the embed to add them directly, unless the social media platforms change the way they fetch OpenGraph data.

However, there is a solution! Your pagestrip project includes an URL shortening service that can inject the correct OpenGraph data for your embedded story, while redirecting readers to the embedded story. You can generate such a URL for any content item in the "Sharing" section of your cockpit and then post it on the social media service of your choice.

Your URL shortener uses your custom domain if you have configured one. Otherwise, our own shortening domain pagest.rip will be available to you.

No, you don't need to set up anything specifically for SEO metadata and structured data. pagestrip will always include automatically generated metadata derived from your story's title, description, and so on, or that you define manually. Just make sure that your titles and descriptions are relevant to humans.

The term "SEO plugin" refers to extensions necessary on other publishing platforms in order to get meaningful markup. You do not need such things with pagestrip.

Yes! In our cockput, navigate to the "Sharing" section of your story to add custom titles, descriptions, and images for search engines and OpenGraph.

This is not necessary. Your embed will automatically advertise your public content via an RSS/Atom feed, which search engines use exactly like a sitemap.

If you don't want to advertise your public content to search engines in this way, you can turn off feed injection in your embed settings within our cockpit.

Yes! We are well aware that some SEO practicioners are unsure about script-driven websites and search engine indexing. It is also not unlikely that there have been bad experiences with custom-made complex websites, since there are many details to take care of, so that the site can be indexed well. Many developers tend to introduce problems here.

However, rest assured that search engine indexing (and ranking) works very well with embedded pagestrip content due to the mechanisms we employ and the copious amounts of SEO metadata that we add.

Regarding script-driven websites, some SEO practicioners are also referring to topics that are no longer relevant, but used to be a few years ago. We recommend this article by Vercel, a leading provider of website development infrastructure and tools. It debunks most myths around this topic and can be interesting to you or your SEO partners.