← Back to Blog

Squarespace, GoDaddy, And The Markdown For Agents Warning — What You Can And Cannot Fix

Squarespace, GoDaddy, And The Markdown For Agents Warning — What You Can And Cannot Fix

If you ran a URL through the Agent Runtime Readiness audit and the third check came back amber, you saw:

Host did not return Markdown content when Accept: text/markdown was requested. Enable Cloudflare Markdown for Agents or implement content negotiation at your origin.

If your site is on Squarespace, GoDaddy Website Builder, Wix, Shopify, or another closed managed builder, the answer is harder to give cleanly than on Netlify or Vercel. The honest split:

  • Closed builders (Squarespace, GoDaddy Website Builder, Wix, Shopify standard plans) — you cannot fully fix this warning because you don't have access to HTTP-level controls. There is one partial workaround. There is also an upgrade path if this matters enough.
  • GoDaddy Managed WordPress, cPanel shared hosting, and similar PHP-with-.htaccess setups — you can fully fix this. The implementation is a small .htaccess rule plus a PHP filter.

This post covers both honestly.

Closed builders — the partial workaround and the limit

Squarespace, GoDaddy Website Builder, Wix, and Shopify (on standard plans) all hide the HTTP layer from you on purpose. You can edit page content, themes, fonts, and metadata. You cannot:

  • Set custom response headers (Content-Type, Vary, Content-Signal)
  • Intercept or rewrite responses based on request headers
  • Serve different bodies to different Accept types
  • Run server-side code or middleware in the request path

Without those, real HTTP content negotiation is impossible. The audit is checking whether your host responds with text/markdown body when asked nicely; closed builders cannot respond that way regardless of what you put in your settings.

The one thing you can do — the passive declaration

Most closed builders allow some form of HTML head injection (Squarespace calls it Code Injection; Shopify uses theme.liquid; GoDaddy Website Builder has a more limited head-injection slot on premium plans only). You can use that to add this line to your <head>:

<link rel="alternate" type="text/markdown" href="/your-page-slug.md">

This tells AI runtimes that scan a page's <head> for alternate format declarations that a markdown twin exists at a known URL. It does not satisfy the Agent Runtime Readiness audit — the audit verifies that the host actually responds with markdown when negotiated, not that it advertises a companion. The audit's third check will continue to warn.

It does, however, get you partial credit with retrievers that look for the <link rel="alternate"> declaration even when the negotiation fails. The Mega Analyzer audit on this site picks up the declaration as a separate signal, distinct from the negotiation check.

There's a deeper problem with this workaround on closed builders: even if you publish a /your-page-slug.md URL, the closed builder won't serve it as text/markdown. It'll either 404, or serve a generic HTML wrapper page with the slug in the URL bar. So the <link rel="alternate"> points at a URL that doesn't actually deliver markdown. Some retrievers will follow the link and fall back to scraping the HTML; some will record the failed fetch and not retry.

In other words: on closed builders, the warning stays. The partial workaround helps a little. The full fix requires moving off the closed builder.

When this matters enough to consider migrating

It depends on your traffic shape. If your site gets meaningful AI-runtime traffic — chat citations, retriever fetches, search-grounding queries — and that traffic is growing, the cost of being illegible to runtimes is real. The cleanest migration paths from a closed builder, ranked roughly by effort:

  1. Squarespace → static-site generator on Netlify or Vercel — biggest behavior change, fully fixable, lowest ongoing cost. See the Netlify Edge Functions or Vercel Edge Middleware post for the implementation.
  2. Squarespace → WordPress on managed hosting (including GoDaddy Managed WordPress) — familiar editing experience, fully fixable, see the next section.
  3. Squarespace → Shopify Plus or Wix Velo — same closed-builder problem at higher cost. Skip.

If your traffic is mostly human visitors and AI-runtime traffic is currently negligible, leave the warning as-is. It's a warn, not a fail. Your page is still readable by every runtime that exists. Revisit the migration question when AI traffic starts showing up in your access logs.

GoDaddy Managed WordPress and cPanel — the real fix

If your site is on GoDaddy Managed WordPress, GoDaddy cPanel shared hosting, or any LAMP-stack environment with .htaccess and PHP access, you can implement the same content negotiation that Cloudflare's toggle provides. Two layers — an .htaccess rule for static .md files and a PHP filter for dynamic WordPress posts.

Step 1 — .htaccess for static markdown files

If you have markdown files you can upload directly (e.g., a doc page you want available as both HTML and Markdown), put them in your site root and add this to .htaccess:

# Always advertise that responses vary by Accept
Header always set Vary "Accept"

# Serve .md as text/markdown
AddType "text/markdown; charset=utf-8" .md

RewriteEngine On

# Rewrite directory URLs to /index.md when client wants markdown
RewriteCond %{HTTP_ACCEPT} text/markdown [NC]
RewriteRule ^(.+)/$ /$1/index.md [L]

# Rewrite extensionless URLs to /file.md when client wants markdown
RewriteCond %{HTTP_ACCEPT} text/markdown [NC]
RewriteCond %{REQUEST_FILENAME} !\.md$
RewriteCond %{REQUEST_FILENAME}.md -f
RewriteRule ^(.+[^/])$ /$1.md [L]

GoDaddy Managed WordPress allows .htaccess edits via the File Manager in cPanel or via SFTP. After saving, request the URL with curl -H "Accept: text/markdown" and confirm the rewrite fires.

Step 2 — PHP filter for WordPress posts

For WordPress posts (which are generated dynamically rather than from static .md files), add a must-use plugin that intercepts the response when the request Accept header includes text/markdown and outputs markdown.

Create wp-content/mu-plugins/markdown-for-agents.php:

<?php
/**
 * Plugin Name: Markdown for Agents
 * Description: Returns post content as text/markdown when client requests it.
 */

add_action('template_redirect', function () {
    if (!is_singular()) return;

    $accept = $_SERVER['HTTP_ACCEPT'] ?? '';
    if (stripos($accept, 'text/markdown') === false) return;

    global $post;
    $title = get_the_title($post);
    $excerpt = get_the_excerpt($post);
    $rendered = apply_filters('the_content', $post->post_content);

    // Convert rendered HTML to markdown
    $converter = new \League\HTMLToMarkdown\HtmlConverter([
        'header_style' => 'atx',
        'strip_tags' => true,
    ]);
    $body = $converter->convert($rendered);

    $md = "# {$title}\n\n";
    if ($excerpt) $md .= "_{$excerpt}_\n\n";
    $md .= $body . "\n";

    header('Content-Type: text/markdown; charset=utf-8');
    header('Vary: Accept');
    echo $md;
    exit;
});

The League\HTMLToMarkdown\HtmlConverter class comes from the league/html-to-markdown Composer package. To install it on GoDaddy Managed WordPress, you have two options:

  • If you have SSH access (Pro/Ultimate plans): cd into your site root, composer require league/html-to-markdown. The package autoloads via Composer's vendor directory.
  • If you only have FTP/cPanel access: download the package's release tarball from GitHub, extract it into wp-content/mu-plugins/vendor/league/html-to-markdown/, and add require_once __DIR__ . '/vendor/league/html-to-markdown/src/HtmlConverter.php'; (plus its dependencies) at the top of the mu-plugin file.

The cPanel-only path is awkward but works. SSH access makes it routine.

Step 3 — Verify

curl -s -H "Accept: text/markdown" -i https://yoursite.com/some-post-slug/ | head -10

Look for content-type: text/markdown; charset=utf-8 and vary: Accept. Re-run the Agent Runtime Readiness audit on the same URL — the third check should pass.

Common false negatives on GoDaddy Managed WordPress specifically:

  • Object cache served the HTML response. GoDaddy Managed WordPress runs an object cache that may have stored the HTML response under the URL key without considering Accept. After enabling the mu-plugin, flush the cache from the GoDaddy dashboard.
  • .htaccess not honored. GoDaddy's managed-WordPress configuration overrides certain .htaccess directives. If the rewrite isn't firing, check whether AllowOverride is set to a level that includes FileInfo and Options for your site root. Support can adjust this.
  • PHP version too old. The league/html-to-markdown package requires PHP 8.0+. Older shared-hosting plans may default to PHP 7.4. Upgrade in the GoDaddy dashboard before testing.

What about WordPress.com, Webflow, Big Cartel?

These platforms sit between the two cases above:

  • WordPress.com Free / Personal / Premium plans: same closed-platform problem as Squarespace. Custom plugins and .htaccess aren't allowed. Partial workaround only.
  • WordPress.com Business or Pro plans: plugin uploads are allowed, so the mu-plugin pattern above works. Treat this case the same as GoDaddy Managed WordPress.
  • Webflow: closed platform, no HTTP-level access. Same constraint as Squarespace.
  • Big Cartel, Etsy storefronts, Substack: closed platforms, no fix.

The pattern across all of these is consistent: if the platform exposes plugin uploads, custom code, or .htaccess, you can implement the fix. If it doesn't, you can advertise the alternate via <link rel="alternate"> and that's the ceiling.

Related reading

Fact-check notes and sources

If you're at the point where the closed-builder ceiling is starting to bite — and you want a leaner, owned, build-your-own-web stack — The $20 Dollar Agency covers the migration and operating model end to end.

This post is informational, not legal or SEO-consulting advice. Mentions of Squarespace, GoDaddy, WordPress, Cloudflare, and other third parties are nominative fair use; no affiliation is implied.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026