{"id":18336,"date":"2026-03-12T15:08:01","date_gmt":"2026-03-12T14:08:01","guid":{"rendered":"https:\/\/webhosting.de\/server-side-includes-ssi-hosting-config-serverflex\/"},"modified":"2026-03-12T15:08:01","modified_gmt":"2026-03-12T14:08:01","slug":"server-side-includes-ssi-hosting-config-serverflex","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/server-side-includes-ssi-hosting-config-serverflex\/","title":{"rendered":"Server Side Includes: SSI Hosting and Web Server Configuration"},"content":{"rendered":"<p><strong>SSI Hosting<\/strong> integrates Server Side Includes directly into static HTML files and thus delivers finished HTML code without client-side dependencies. I will show you how to activate SSI, use typical directives and implement the <strong>webserver configuration<\/strong> on Apache cleanly.<\/p>\n\n<h2>Key points<\/h2>\n<p><strong>SSI<\/strong> makes recurring page parts maintainable and speeds up delivery if the web server is configured correctly.<\/p>\n<ul>\n  <li><strong>Includes<\/strong> bundle header, footer, navigation.<\/li>\n  <li><strong>.htaccess<\/strong> enables parsing for .html and .shtml.<\/li>\n  <li><strong>Security<\/strong> through restrictive rights and NOEXEC.<\/li>\n  <li><strong>Performance<\/strong> benefits from caching and NVMe.<\/li>\n  <li><strong>Compatibility<\/strong> with Apache and shared hosting.<\/li>\n<\/ul>\n<p>With just a few directives, you can build modular pages and significantly reduce maintenance work without having to use a CMS. In this guide, I focus on clear examples, solid <strong>Practice<\/strong> and reliable configurations for fast results.<\/p>\n\n<h2>What are Server Side Includes (SSI)?<\/h2>\n<p><strong>Serverincludes<\/strong> are instructions in the HTML that the web server interprets before delivery. The code is in comments such as <code><!--#include virtual=\"\/includes\/header.html\" --><\/code> and ends up as finished markup in the browser. This saves you JavaScript logic for repeated blocks and gives you clean, indexable content. The syntax always starts with <code>&lt;!--#<\/code>, uses lowercase letters and requires quotation marks for the parser to work correctly. I keep the commands minimal so that the overhead remains low and the <strong>Maintenance<\/strong> remains clear.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/serverraum-ssi-hosting-4728.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Requirements and webserver configuration<\/h2>\n<p><strong>Apache<\/strong> the module <code>mod_include<\/code> must be active for SSI to work. Many hosts only parse <code>.shtml<\/code>; with a suitable <code>.htaccess<\/code> you also activate parsing for <code>.html<\/code>. Also check whether your package <code>AllowOverride<\/code> is allowed for your directory, otherwise the file will not work. To choose the right stack, it is worth taking a look at <a href=\"https:\/\/webhosting.de\/en\/webserver-comparison-apache-nginx-litespeed-perfopt-serverboost\/\">Apache, Nginx or LiteSpeed<\/a>, because SSI is based on Apache on the server side. I pay attention to the <strong>Configuration<\/strong> always security, performance and future scaling.<\/p>\n\n<h2>Granular Apache configuration without .htaccess<\/h2>\n<p><strong>Best Practice<\/strong> in your own server environments: Enable SSI centrally in the vHost or in the Apache configuration and <code>AllowOverride None<\/code> use. This saves you having to read in the <code>.htaccess<\/code> and retain control over permitted options.<\/p>\n<pre><code>ServerName example.org\n  DocumentRoot \/var\/www\/example\/public_html\n\n  \n    Options +IncludesNOEXEC\n    AllowOverride None\n    Require all granted\n    AddOutputFilter INCLUDES .html\n    # Optional: Parse only selected files\n    \n      Options +IncludesNOEXEC\n      AddOutputFilter INCLUDES .html\n    \n  \n\n  # Alternative, selective activation: XBitHack (see below)\n  # XBitHack full\n<\/code><\/pre>\n<p>In shared hosting environments, you stay with <code>.htaccess<\/code>, on my own servers, however, I prefer to keep the configuration bundled in the vHost.<\/p>\n\n<h2>Setup step by step<\/h2>\n<p><strong>Preparation<\/strong> begins in the document master, usually <code>public_html<\/code>. Create a directory <code>\/includes\/<\/code> write there your <code>header.html<\/code> and <code>footer.html<\/code> and use absolute paths in the directives. Then create the <code>.htaccess<\/code> in the root and enter the following lines so that Apache parses HTML files on SSI:<\/p>\n<pre><code>AddType text\/html .html\nAddOutputFilter INCLUDES .html\nOptions +Includes\nAddHandler server-parsed .html\n<\/code><\/pre>\n<p>Now you can integrate blocks into any pages, e.g. <code><!--#include virtual=\"\/includes\/header.html\" --><\/code>. After that, I always clear caches in the browser and server-side caches to safely save changes. <strong>check<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/ServerSideIncludesKonfigur6894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Use include virtual vs. include file correctly<\/h2>\n<p><strong>Choice<\/strong> of the variant determines flexibility and access protection:<\/p>\n<ul>\n  <li><strong>include virtual<\/strong> uses URL paths (e.g. <code>\/includes\/header.html<\/code>), therefore runs through rewrites, access rules and can cleanly resolve absolute paths. Suitable if fragments may be visible on the web or you deliberately work via the URL space.<\/li>\n  <li><strong>include file<\/strong> reads directly from the file system and is <em>Relative<\/em> to the current file (no leading slash). It ignores URL rewrites and is ideal for <em>internal<\/em> Fragments that should not be directly accessible. Use unique file names such as <code>header.inc.html<\/code> and place it in a subdirectory of the page, such as <code>includes_priv\/<\/code>.<\/li>\n<\/ul>\n<p>A typical pattern for private fragments:<\/p>\n<pre><code># In the \/includes_priv\/ subfolder of the project:\n# .htaccess (block access externally)\nRequire all denied\n<\/code><\/pre>\n<pre><code><!-- In the page (e.g. index.html, same root directory) -->\n<!--#include file=\"includes_priv\/header.inc.html\" -->\n<!--#include file=\"includes_priv\/footer.inc.html\" -->\n<\/code><\/pre>\n<p>The browser cannot retrieve the files, but SSI continues to read them locally. I avoid nested paths and keep <code>file<\/code>-The references should be as flat as possible so that the project remains clear.<\/p>\n\n<h2>Security and authorizations with SSI<\/h2>\n<p><strong>Security<\/strong> starts with rights: Set files to <code>644<\/code> and folders on <code>755<\/code>, to avoid accidental releases. Avoid <code>#exec<\/code> consistently, because execution rights open the door to infiltration. In shared environments, I use <code>Options +IncludesNOEXEC<\/code>, to exclude script calls. Sensitive files such as <code>.env<\/code> or configurations are locked with an additional <code>.htaccess<\/code> in the directory. This significantly reduces the risk and keeps the <strong>Control<\/strong> about integrated content.<\/p>\n\n<h2>Hardening: Scope, headers and clean boundaries<\/h2>\n<p><strong>Scope<\/strong> Keep it tight: Only allow SSI where you need it. In large projects, I limit parsing with <code>FilesMatch<\/code> to specific patterns, e.g. <code>*.inc.html<\/code> or <code>*.shtml<\/code>. In addition, I set security headers globally, because finished HTML output benefits directly from them:<\/p>\n<pre><code>Header set X-Content-Type-Options \"nosniff\"\n  Header set X-Frame-Options \"SAMEORIGIN\"\n  Header set Referrer-Policy \"strict-origin-when-cross-origin\"\n  Header set Content-Security-Policy \"default-src 'self'\"\n<\/code><\/pre>\n<p>I separate publicly accessible fragments (e.g. footers) and internal elements (e.g. variable files) cleanly so that rules remain clear and audits are quick.<\/p>\n\n<h2>Practical SSI examples for projects<\/h2>\n<p><strong>Example<\/strong> 1: A global header. Place <code>\/includes\/header.html<\/code> and bind it with <code><!--#include virtual=\"\/includes\/header.html\" --><\/code> in every page. Example 2: A footer with copyright notice via <code><!--#include virtual=\"\/includes\/footer.html\" --><\/code>. Example 3: A date stamp above <code><!--#echo var=\"DATE_LOCAL\" --><\/code> in the sidebar. Example 4: Last change to a file with <code><!--#flastmod file=\"\/path\/file.html\" --><\/code> for transparent up-to-dateness. I keep the paths consistently absolute so that the integration in different directory depths is reliable. <strong>works<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/ssi-hosting-webserver-konfig-4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Variables, formatting and simple logic (XSSI)<\/h2>\n<p><strong>directives<\/strong> like <code>set<\/code>, <code>echo<\/code>, <code>config<\/code> and <code>if<\/code> are sufficient for many cases without slipping into application logic.<\/p>\n<pre><code>&lt;!-- Ausgabeformat f&uuml;r Datum\/Gr&ouml;&szlig;en setzen --&gt;\n&lt;!--#config timefmt=&quot;%d.%m.%Y, %H:%M&quot; sizefmt=&quot;abbrev&quot; --&gt;\n\n&lt;!-- Eigene Variablen definieren und ausgeben --&gt;\n&lt;!--#set var=&quot;site_env&quot; value=&quot;production&quot; --&gt;\n&lt;!--#set var=&quot;build_date&quot; value=&quot;2026-03-10 12:30&quot; --&gt;\nBuild: &lt;!--#echo var=&quot;build_date&quot; --&gt; (Env: &lt;!--#echo var=&quot;site_env&quot; --&gt;)\n\n&lt;!-- Einfache Bedingungen --&gt;\n&lt;!--#if expr=&quot;$site_env = \/production\/&quot; --&gt;\n  &lt;p&gt;&lt;strong&gt;Live hint:&lt;\/strong&gt; Productive environment&lt;\/p&gt;\n&lt;!--#else --&gt;\n  &lt;p&gt;Staging\/Test&lt;\/p&gt;\n&lt;!--#endif --&gt;\n\n&lt;!-- Umgebungsvariablen inspizieren (Debug) --&gt;\n&lt;pre&gt;&lt;!--#printenv --&gt;&lt;\/pre&gt;\n<\/code><\/pre>\n<p>I keep logic flat, avoid nesting and document variables in one place (e.g. <code>includes_priv\/vars.inc.html<\/code>), which I received via <code>file<\/code> into each page.<\/p>\n\n<h2>Performance, caching and CDN with SSI<\/h2>\n<p><strong>Performance<\/strong> benefits from SSI because the server outputs finished HTML code and the browser has less work to do. I supplement this with file compression via <code>mod_deflate<\/code> or <code>mod_brotli<\/code>, so that transmissions remain small. Server-side caching at proxy or app accelerator level can additionally buffer HTML results. A CDN helps with global distribution, while SSI parsing continues to take place on the origin server. The correct sequence remains important: first render includes, then the finished markup in the cache <strong>hold<\/strong>.<\/p>\n\n<h2>Cache header, ETag and targeted parsing<\/h2>\n<p><strong>Header<\/strong> determine how browsers and proxies reuse results. For dynamic fragments, I use moderate max-age values and permitted stale caching:<\/p>\n<pre><code>Header set Cache-Control \"public, max-age=600, stale-while-revalidate=30\"\n  Header unset Pragma\n\n# Standardize or deactivate ETags to avoid inconsistencies\nFileETag MTime Size\n<\/code><\/pre>\n<p>If you do not have all <code>.html<\/code> but only specific files, you save resources. Two ways have proven themselves:<\/p>\n<ul>\n  <li><strong>FilesMatch approach:<\/strong> Only <code>*.inc.html<\/code> and parse these fragments per <code>virtual<\/code> or <code>file<\/code> integrate.<\/li>\n  <li><strong>XBitHack:<\/strong> With <code>XBitHack full<\/code> only files with the execution bit set are parsed. In addition, Apache sets the <em>Last-Modified<\/em>-header based on the file timestamp, which simplifies validation.<\/li>\n<\/ul>\n<pre><code># Selective parsing via XBitHack\nXBitHack full\n# \"mark\" file via chmod +x\n# chmod +x index.html\n<\/code><\/pre>\n<p>After making changes, I always test whether <em>Last-Modified<\/em> and cache behavior behave as expected so that users see new content without hard reloads.<\/p>\n\n<h2>SSI vs. PHP and CMS<\/h2>\n<p><strong>Comparison<\/strong> turns out like this: SSI is suitable for modular, static pages with a few dynamic sprinkles. PHP covers application logic, forms or database access, but requires more maintenance. A CMS provides editing functions, but costs resources and requires regular updates. For landing pages, documentation and small websites with recurring modules, I consider SSI to be the lean solution. Before I make a decision, I check the content and the mix of <a href=\"https:\/\/webhosting.de\/en\/static-vs-dynamic-pages-guide-webprojekt-hub\/\">static and dynamic pages<\/a>, so that the architecture fits the target and can be easily <strong>scalable<\/strong> remains.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/SSI_Hosting_Webserver_9982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Migration path and hybrid approaches<\/h2>\n<p><strong>Pragmatic<\/strong> switch: Start with header\/footer as includes, add navigation and recurring teasers and leave special logic in PHP or your CMS. In this way, you can gradually reduce templating duplications without disrupting editorial processes. For completely static areas (e.g. documentation), you can go SSI-first and embed dynamic islands (forms, search) via independent endpoints. I keep the cut clear so that each layer does exactly what it is built for.<\/p>\n\n<h2>Hosting selection for SSI projects<\/h2>\n<p><strong>Selection<\/strong> depends on Apache availability, <code>mod_include<\/code>, <code>AllowOverride<\/code> and fast NVMe storage. I pay attention to free <code>.htaccess<\/code>-usage so that I can use includes for <code>.html<\/code> can be activated. Plans with sufficient CPU clock provide short response times, which makes SSI even more attractive. Switching options without migration make upgrades easier if your project grows. The following table shows typical features of plans that SSI performs well <strong>support<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tariff<\/th>\n      <th>Price\/month<\/th>\n      <th>Memory<\/th>\n      <th>WordPress pages<\/th>\n      <th>SSI-capable<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Starter<\/td>\n      <td>10 \u20ac<\/td>\n      <td>10 GB NVMe<\/td>\n      <td>1<\/td>\n      <td>Yes (Apache)<\/td>\n    <\/tr>\n    <tr>\n      <td>Pro<\/td>\n      <td>47,60 \u20ac<\/td>\n      <td>75 GB NVMe<\/td>\n      <td>5<\/td>\n      <td>Yes (Apache)<\/td>\n    <\/tr>\n    <tr>\n      <td>Business<\/td>\n      <td>95,20 \u20ac<\/td>\n      <td>150 GB NVMe<\/td>\n      <td>10<\/td>\n      <td>Yes (Apache)<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>I don't plan resources too tightly so that caches work and reserves remain. If you add PHP or CMS later on, you benefit from headroom in RAM and CPU without the <strong>Stability<\/strong> to risk.<\/p>\n\n<h2>Fault diagnosis and troubleshooting<\/h2>\n<p><strong>Problems<\/strong> often appear as \u201eraw\u201c SSI comments in the HTML source code. In this case, the server does not parse the file, usually missing <code>AddOutputFilter INCLUDES .html<\/code> or the MIME type is incorrect. Also check whether the file is saved as <code>text\/html<\/code> and no editor quotation marks interfere. Absolute paths prevent <code>..\/<\/code>-references come to nothing. I look at the server logs last, because that's where the concrete clues are that quickly lead me to the <strong>Cause<\/strong> lead.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/ssi_hosting_konfig_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Advanced troubleshooting: typical pitfalls<\/h2>\n<p><strong>500 Internal Server Error<\/strong> to <code>Options +Includes<\/code> in <code>.htaccess<\/code> often indicates <em>AllowOverride<\/em>-restrictions. Solution: Have the option set on the server side or ask the hoster for approval. <strong>403 Forbidden<\/strong> at <code>include virtual<\/code> indicates access restrictions in the target directory; in such cases it is better to use <code>include file<\/code> and block the source directory for HTTP access. <strong>Character set or BOM problems<\/strong> (invisible characters at the beginning of the file) can lead to strange output - save fragments as UTF-8 without BOM. If you encounter unusual whitespaces in minified code, check if your build process removes comments\/SSI directives. For debug sessions I temporarily activate <code><!--#printenv --><\/code>, to inspect headers and variables, and then deactivate it again.<\/p>\n\n<h2>Reverse proxy and modern setups<\/h2>\n<p><strong>Architectures<\/strong> with an upstream proxy such as Nginx or Traefik allow Apache to render in the background. The proxy takes care of TLS, caching and compression, while Apache parses includes and delivers finished HTML. This allows you to combine low latency with the flexibility of SSI. Read the overview of <a href=\"https:\/\/webhosting.de\/en\/reverse-proxy-setups-webhosting-architecture-proxyhosting\/\">Reverse proxy setups<\/a>, before you plan your routing. I like to start with a simple chain and expand step by step so that I can clearly measure effects and determine the <strong>Performance<\/strong> in a targeted manner.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/hosting-serverraum-8391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatibility and operating modes<\/h2>\n<p><strong>Compatibility<\/strong>Apache is the target system for the SSI usage described here. Many hosters use LiteSpeed as an Apache replacement; the common SSI syntax is usually supported. Nginx has its own SSI features with a different syntax; in mixed environments, Nginx typically performs proxy tasks, while Apache handles SSI parsing. With Apache MPM I prefer <strong>event<\/strong> for static\/SSI-heavy sites (in combination with PHP-FPM), as it keeps connections more efficient. I only use Prefork where legacy modules make it necessary.<\/p>\n\n<h2>Deployment, versioning and quality assurance<\/h2>\n<p><strong>Process<\/strong> keep clean: Fragments and variable files belong in version control. I define standards (file extensions such as <code>.inc.html<\/code>, Directory structure <code>\/includes\/<\/code> and <code>\/includes_priv\/<\/code>) and check with each commit whether includes can be resolved. A small CI step can upload a staging build, clear caches and retrieve a health page with test includes. A minimal test is quickly built:<\/p>\n<pre><code>&lt;!-- test.shtml --&gt;\n&lt;!--#config timefmt=&quot;%Y-%m-%d %H:%M:%S&quot; --&gt;\nServer time: &lt;!--#echo var=&quot;DATE_LOCAL&quot; --&gt;&lt;br&gt;\nURI: &lt;!--#echo var=&quot;DOCUMENT_URI&quot; --&gt;&lt;br&gt;\nInclude: &lt;!--#include virtual=&quot;\/includes\/header.html&quot; --&gt;\n<\/code><\/pre>\n<p>If this page fails, the problem is almost always in the basic configuration (parsing, rights or paths). I have a small checklist ready to perform rollbacks in minutes.<\/p>\n\n<h2>Compact tips for clean SSI<\/h2>\n<p><strong>Paths<\/strong> I set absolutely, so <code>\/includes\/header.html<\/code> instead of relative references, so that bindings in subfolders remain stable. I use variables sparingly and name them uniquely, for example <code>site_env<\/code> or <code>build_date<\/code>. I test changes in a staging environment and only copy live afterwards to avoid downtime. Before making any changes to the <code>.htaccess<\/code> I back up the current version so that I can go back immediately if necessary. After deployments, I clear browser and server caches so that users can use the new version without old artifacts. <strong>See<\/strong>.<\/p>\n\n<h2>Targeted use of extended SSI features<\/h2>\n<p><strong>XSSI<\/strong> brings simple conditions and variable logic, but remains deliberately limited in order to keep parsing lightweight. Typical cases are different banners per directory or one hint per language version. You structure conditions with <code><!--#if expr=\"...\" --><\/code> and closes it with <code><!--#endif --><\/code>. For computational logic, switch to PHP or build the output into your build process in advance. I avoid nested directives so that the page remains readable and the <strong>Debugging<\/strong> quickly.<\/p>\n\n<h2>Summary in plain text<\/h2>\n<p><strong>Bottom line<\/strong> SSI delivers fast, maintainable pages by merging recurring content before it is sent. With just a few lines in the <code>.htaccess<\/code> activate parsing for <code>.html<\/code> and keep the structure of your project lean. You achieve security with restrictive rights and by not using <code>#exec<\/code>; protects in shared environments <code>IncludesNOEXEC<\/code>. NVMe storage, clean caching and, if required, an upstream proxy ensure speed. If I want to build modularly and do without overhead, I rely on SSI hosting, secure the webserver configuration cleanly and maintain it for years <strong>simple<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Server Side Includes (SSI) in hosting: configuration, advantages and best **SSI hosting** providers. Optimize your site with SSI.<\/p>","protected":false},"author":1,"featured_media":18329,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18336","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"702","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"SSI Hosting","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18329","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/18336","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=18336"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/18336\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/18329"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=18336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=18336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=18336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}