개요

미리 요약

1. 검색엔진은 반드시 정적인 리소스만 크롤링 하는 것이 아니라, 서버의 모든 응답을 크롤링 합니다.

2. 그러므로, URL 이 변경될 때 서버는 리디렉션 응답을 명확하게 주고, 리디렉션된 리소스에 명확한 표시만 해둔다면 로그들을 유지하며 URL 을 변경 할 수 있습니다. (301 리디렉션 & canonical 설정)

3. slug 형태의 URL 을 사용하더라도, 내부적으로는 id 형태로 리소스를 관리하는 것이 좋습니다.

4. 영구적인 301 리디렉션의 경우 브라우저가 자동으로 캐시합니다. 물론, 시크릿 모드로 개발하신다면 신경 쓰지 않아도 됩니다.

목표

1. 기존 운영 중에 있는 노션 블로그의 블로그 포스트의 /posts/{post-id} 형태의 URL 를 /posts/{title} 형태로 제공한다.

2. 지금까지 SEO 를 해두었기 때문에 이 실적을 유지한다.

3. 현재 제공되고있는 서비스는 이용자들에게 변경이 없는 것 처럼 느껴지게 한다. (구글에서 검색된 링크를 타고 들어오면 변경한 URL 로 리디렉션)

1. 포스트 관리 용이: GSC(Google Search Console) 에서나 Vercel 을 통해 통계를 모니터링 할 때, URL 을 직접 보여주곤 합니다. 하지만, 인기있는 게시글이나 이런 것을 확인 할 때는 post-id 만 적혀있으면 어떤 게시글이 인기가 있는지 알 수가 없습니다. 이를 개선 할 수 있을 것이라 생각 했습니다.

2. SEO 점수 개선: 검색 엔진이 직접 URL 을 평가하지는 않지만, 구글 URL 설계 권장 사항에 사용자가 읽기 좋은 URL 이라면 공유할 때 더 신뢰가 가기 때문에 긍정적인 효과가 있다고 적혀있습니다. 이를 통해 간접적인 점수 개선이 일어날 것을 기대했습니다.

Google URL Structure Guidelines | Google Search Central  |  Documentation  |  Google for Developers

It's a good idea to keep your site's URL structure as simple as possible. Learn more about the URL format recommended by Google, such as the use of hyphens, underscores, and domain structure.

https://developers.google.com/search/docs/crawling-indexing/url-structure

1. 보안: 노션의 페이지 id 가 노출되는 것은 사실 그렇게 큰 문제가 될 일은 아니지만, 그래도 어떤 엔티티의 id 가 직접 노출되는 것은 바람직하지 않다고 생각했습니다. 결국 제 notion 정보를 탈취 당하면 제 페이지를 누군가 강제로 수정 할 수 있으니까요.

설계

설계 목표

1. SEO 관리 시 중복 URL로 판별이 난다면 SEO 점수에 직접적으로 악영향이 가기 때문에, 301 리디렉션으로 컨텐츠가 영구적으로 리디렉션 되었다는 것을 검색 엔진에게 알립니다.

2. 기존 페이지는 현재 이미 배포되어 실적을 내고 있으므로 사용자는 중간에 검색엔진에서 제공받던 페이지를 끊김없이 받을 수 있어야합니다.

3. 결국 post-id 로 페이지 상세 정보를 검색 해야하기 때문에, 브라우저에서 /posts/{slug} 형태로 호출 하더라도 내부적으로는 slug 를 post-id 로 변환해 관리하도록 합니다.

4. slug 는 URL 친화적으로 변경해야합니다. 사실 slug 를 한글로 제공하려는 것 자체는 URL 친화적이지는 않지만, 그 외의 부분을 최대한 맞추려고 합니다.

설계안

1. notion API 를 호출해서 slug-id mapper 를 서버 내에 파일 형태로 저장 + ISR 처럼 주기적으로 파일을 업데이트 할 수 있다면 최고

2. 이 파일을 기준으로 ISR 형태로 포스트 페이지들을 빌드한다. 또한, posts/[slug] 형태 이외에 이전에 posts/[postId] 도 미리 빌드해 검색엔진이 기존에 서비스하던 리소스를 잃지 않게 합니다.

3. 이 파일을 fetch 해서 next.js 의 middleware 에서 posts/[param] 형태의 api 호출 시, id 인지 여부를 확인하고, posts/[postId] 면 permanent redirection 형태로 posts/[slug] redirect 해준다.

4. SEO 를 위해 posts/[slug] 페이지에 필요한 메타데이터를 설정해둔다. (canonical 설정)

Page Indexing report - Search Console Help

See which pages Google can find and index on your site, and learn about any indexing problems encountered. Open Page Indexing report

https://support.google.com/webmasters/answer/7440203#google_chose_different_canonical_than_user

1. slug-id mapper 는 서버 컴포넌트 내에서만 필요하므로, react 의 cache api 를 통해 최대한 캐시하여 사용

2. posts/[slug] 리소스만 미리 빌드하고, ISR 한다. posts/[postId] 형태의 리소스는 그냥 리디렉션 처리만 해두어도 괜찮다.

3. middleware 에서 posts/[param] 형태의 api 호출 시, id 인지 여부를 확인하고, posts/[postId] 면 permanent redirection 형태로 posts/[slug] redirect 해준다. middleware 의 리디렉션이 필요한 포스트 개수가 적으므로 middleware 에서 사용할 mapper 는 하드코딩 한다.

4. SEO 를 위해 posts/[slug] 페이지에 필요한 메타데이터를 설정해둔다. (canonical 설정)

개발

개발 현황 정리

1. ISR 부분

2. 메타데이터 부분

3. 리디렉션 부분

ISR 부분 현황 및 변경 개발

변경 전

/** 생략... */

export const revalidate = 180;

export async function generateStaticParams() {
  const posts = (await getNotionPosts()).map(Post.create);

  return posts.map(({ id }) => (
    {
      postId: id,
    })
  );
}

/** 생략... */

변경 후

/** 생략... */

export const revalidate = 180;

export async function generateStaticParams() {
  const posts = (await getNotionPosts()).map(Post.create);

  return posts.map(({ slugifiedTitle }) => (
    {
      slug: slugifiedTitle,
    })
  );
}

/** 생략... */

변경될 페이지 부분 현황 및 변경 개발

변경 전

/** 생략... */

export async function generateMetadata({ params }: PostDetailPageProps) {
  const { title, content, tags } = await getNotionPostMetadata(params.postId);

  return {
    title,
    description: content,
    keywords: tags,
  };
}

/** 생략... */

변경 후

/** 생략... */

export async function generateMetadata({ params }: PostDetailPageProps) {
  const postId = await slugToPostId(params.slug);

  const { title, content, tags } = await getNotionPostMetadata(postId);

  return {
    title,
    description: content,
    keywords: tags,
    alternates: {
      canonical: `${process.env.BLOG_URL}/posts/${slug(title)}`,
    },
  };
}

/** 생략... */

리디렉션 부분

변경 후

import { isNotionPageId } from "@/entities/posts/utils";
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

// 미들웨어 전용 헬퍼 객체, 추가되는 포스트는 미들웨어를 통한 리디렉션 필요 없을 가능성 농후
const slugMapHelper = {
  "18주차-타입챌린지-스터디": "1e63c18b-cccb-8077-a44e-e0447ff198c7"
  /** ... 생략 */
};

const idMapHelper = Object.fromEntries(
  Object.entries(slugMapHelper).map(([slugifiedTitle, id]) => [
    id,
    slugifiedTitle,
  ]),
);

// This function can be marked `async` if using `await` inside
export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;
  const slugOrId = pathname.split("/posts/")[1];

  if (!slugOrId) {
    return NextResponse.next();
  }

  if (isNotionPageId(slugOrId)) {
    const slugifiedTitle = idMapHelper[slugOrId];

    if (slugifiedTitle) {
      const url = request.nextUrl.clone();
      url.pathname = `/posts/${slugifiedTitle}`;
      return NextResponse.redirect(url, 301);
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: "/posts/:path*",
};

개발중 새롭게 알게된 점

1. 검색 엔진이 크롤링을 할 때는 정적 HTML 만을 크롤링 하는 것이 아닌, 서버 응답을 크롤링합니다.

2. 영구적인 리디렉션의 경우 브라우저가 자동으로 캐시합니다. 이것 때문에 개발모드에서 리디렉션이 되지 않아야할 상황임에도 불구하고 정상적인 리디렉션이 되기도 했습니다.

적용 후

결론

1. 검색엔진은 반드시 정적인 리소스만 크롤링 하는 것이 아니라, 서버의 모든 응답을 크롤링 합니다.

2. 그러므로, URL 을 변경할 것이라면, 이전 URL 을 미리 빌드해두어 정적 리소스 형태로 둘 필요가 없습니다.

3. 그저, URL 변경을 명확하게 검색엔진에게 전해주면 됩니다. 이는 딱 두가지만 해주면 됩니다. 301 영구 리디렉션, 리소스 메타데이터에 canonical 설정

4. slug 형태로 관리하면 여러 문제가 있기에 내부적으로는 id 형태로 돌려 사용하는 것이 필요합니다.

5. 브라우저는 301 리디렉션 페이지를 만나면 자동으로 캐시 할 수 있습니다. 이는, 이러한 개발을 하며 디버깅 할 때 알아두면 좋을 것 같습니다.